Dealing with design debt
If you drive up South Winchester Boulevard in San Jose, California (being California you would always drive, not walk) at number 525 you’ll come to a rather grand Queen Anne Style Victorian mansion (show above) with striking turreted roofs and pristine, manicured gardens. The house was built by the fabulously wealthy Sarah Winchester, who inherited a fortune from her dead husband’s Winchester rifle company. Glance at the mansion and there doesn’t seem to be anything out of the ordinary. However, if you look a little more closely and certainly if you venture inside, you’ll start to see that everything is not as you would expect. The sprawling house featuring 161 rooms was built over 38 years from 1884 up to Sarah Winchester’s death in 1922. It was built without any master building plan or architect guiding the design. Sarah Winchester would continuously add new rooms, new sections and new features, creating a building almost purposely designed to disorientate and confuse its users. There are staircases that lead to nowhere, doors that open into walls and windows that will never see any sunlight.
The Winchester Mystery house as it has come to be known is an architectural oddity, but if it were constructed out of bits rather than bricks, it certainly wouldn’t be. With the rise of Agile software development, this sort of a continuous build with no real master plan is all too common place. Just as was the case with the Winchester house this approach invariably leads to harmful design debt building up. This sort of design debt doesn’t take the form of windowless rooms or stairways to nowhere, but instead as usability issues that are never addressed; UI components that are inconsistent; sprawling navigation structures and terminology that changes from screen to screen. As was the case with the Winchester Mystery house, unless it’s reduced, or better still minimised in the first-place, design debt can slowly envelop a product and kill the user experience. Find out what design debt is, how product teams at Redgate deal with it and how to ensure that it doesn’t significantly harm your product.
What is design debt?
The notion of technical debt is well acknowledged within the software industry. If technical debt is the unseen cost of MVPs, early iterations, sub-optimal solutions and quick fixes, design debt is the very visible cost of taking an Agile approach. If software debt were a hulking perilous Iceberg waiting to sink your product, technical debt would be the huge chunk of ice lurking below the surface and design debt would be the top of the Iceberg, poking out of the water for all to see.
Design debt is the primary call to action button that is styled differently on different screens. It’s the design pattern that varies from feature to feature. It’s the menu item with a never-ending list of seemingly randomly placed options and the feature upon feature upon feature that are added to a product with no consideration for the wider user experience.
Unless you’re still following a waterfall software development process from the 1960s, design debt is inevitable in today’s world of MVPs, experiments, Sprints and Agile product development. It’s certainly something that product teams at Redgate have to proactively deal with. Here are some of the strategies that teams use to minimise the amount of harmful design debt building up.
Having a master plan
Remember Sarah Winchester and her bonkers house? She didn’t have a master plan, meaning that she ended up with a house that made no sense. Whether you’re building a house, or a product you should have a master plan, a high-level idea of what your product will do and how users will get value from using it. You don’t need to know all the details but certainly you should know the type of product you’re building, some of the features you’ll need, and the sort of user experience required to deliver value. Going back to housebuilding, you don’t need to plan out exactly how every room will look prior to construction, but you should know how many rooms you’ll need and what sort of rooms they’ll be.
A master plan often takes the form of a product roadmap, such as the user story map shown below for SQL Change Automation. Where there are big assumptions within a plan, such as whether users will actually find a product valuable or not, teams will validate these as much as possible prior to development. For example, by evaluating an early prototype with users.
Using a design system
Design systems are in right now for a good reason. They’re not only a great way to turbo charge front-end development, but also to maintain consistency within a UI and therefore minimise design debt. Having a design system in place makes it easier to ensure that the same design patterns and UI components are used across a product and to generally keep everything in sync. Product teams at Redgate utilise our Honeycomb design system to do just this.
Reviewing designs as part of acceptance criteria
Whilst the exact definition can vary from organisation to organisation, acceptance criteria are usually the agreed conditions for something to be released. Aside from the usual checks, such as acceptance tests being passed with flying colours, one of the conditions used within product teams will be a design review. This is a quick review to catch unwanted design debt sneaking through. For example, different terminology being used, inconsistent UI components or even obvious usability issues that should be addressed. After all, it’s much easier to change code before it’s been released into the wild, and any design issues that are caught prior to release will never be seen by users.
Levelling up the team
Design is an activity not a role and it’s an activity that at Redgate is undertaken by the whole product team. We’ve found that raising the collective design know-how bar within a team is a very effective way to reduce design debt building up, and that the best way to level up a team is not just through training (although that can be helpful) but through collectively practising design. This is why developers are involved in design reviews, why the whole team are involved in customer research calls and why teams will regularly run workshops to generate design concepts and sketches. The more a team collectively know about design, the less design debt a team will unwittingly release.
Factoring design debt into plans
Product teams at Redgate are proactive when it comes to tackling design debt, not just reactive. For example, an entire sprint might be planned for dealing with design debt, or there might be an ongoing stream of work to chip away at it. Tackling design debt should be an ongoing activity and needs to be planned and resourced as such.
Focusing on key user journeys
Where do users get most value out of a product? What are the key user journeys? What are the really key moments in those journeys? It’s often tempting to start with the design debt that is the easiest to address, but instead you should be starting with the most damaging debt, not the easiest to fix. Product teams will often use exploratory UX testing sessions to review a product against key user tasks and to identify design debt to be addressed.
Keeping a record of design debt
Not all design debt can be resolved straight away, so it’s important to keep an ongoing record. Because design debt related work tends to be quite small in scope, teams tend to batch work together, such as for a sprint dedicated to paying off some of the most damaging debt. Many teams use a shared Trello board to keep a record of design debt and will record details such as screenshots, an indication of priority and a high-level estimate of the work required to resolve it.
Conclusion
In today’s world of MVPs, experiments, Sprints and Agile product development, some degree of design debt is inevitable. Like the product teams at Redgate you should think about how you can minimise the amount of design debt piling up and have strategies for tackling any debt that you have already accumulated. Don’t let design debt slowly envelop your product and risk building your very own Winchester mystery house.
