How to deal 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 (shown above) with striking turreted roofs and pristine, manicured gardens. The house was built from 1884 (notice from, not in 1884) 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 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, or leading architect is all too common place. Just as was the case with the Winchester house this approach invariably leads to design debt building up. This sort of design debt doesn’t take the form of windowless rooms or stairways to nowhere, but as usability issues that are never addressed; UI components that are inconsistent; sprawling navigation structures and terminology that changes from screen to screen. Unless it’s reduced, or better still minimised to being with design debt can slowly envelop a product and kill the user experience. Read on to find out exactly what design debit is, how to tackle it and how to stop it building up too much in the first place.
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, fast paced approach. If software debt were a huge hulking Iceberg waiting to sink your product, technical debt would be the ice lurking below the surface and design debt would be the tip of the Iceberg, poking out of the water for all to see.
Design debt is the primary button that’s styled differently on different screens. It’s the design pattern that varies from feature to feature. It’s the spacing that fluctuates wildly from UI component to component. It’s the menu with a never-ending list of seemingly randomly placed options. It’s 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. Painful as it may seem, sometimes crappy design will get released. Deal with it and move on. However, there are ways to minimise the amount of design debt building up and certainly strategies for reducing it to an acceptable level.
Keeping design debt to a minimum
There’s no one sure fire way to keep design debt to a minimum, you’ll need a multi-pronged attack. Here are some strategies that I’ve found to be effective in the past.
Have 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 real 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 to build and the sort of rooms they’ll be.
A master plan often takes the form of a product roadmap. There are lots of great ways to build a product roadmap, so I won’t cover them here. However, I can recommend Jeff Patton’s user story mapping exercise (and book) as a great way to build a master plan. Where there are big assumptions within your plan, such as whether users will actually find a product valuable or not, you’ll want to consider how to validate these prior to development. Of course, sometimes you’ll need to release something to find out how well it work. However, if you can validate an idea upfront, such as with a prototype or concept storyboard, it will lead to a lot less rework and therefore a lot less design debt.
Use a design system
Design systems are so 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 reduce 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.
Whilst it’s tempting to plough ahead without a design system in place, this invariably leads lots of design and technical debt building up. Retrospectively applying a design system is costly and in practice rarely happens so make sure you’ve got at least the foundations of one in place before getting too far with development.
Review 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 conditions, such as acceptance tests being passed with flying colours, one of those conditions should really 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. It’s much easier to change code before it’s been released into the wild, and of course any design issues that are caught prior to release will never be seen by users. As it’s not always desirable to block a release due to design debt you should make a note of any accepted design debt (there’s more about recording design debt later) and look to address it in a future release.
Level up the team
I’ve written before about how design is a team sport. Design is an activity not a role and it’s an activity that should be undertaken by the whole team. Raising the collective design know-how bar within a team is a very effective way to keep design debt to a minimum. You don’t just want a developer to notice that different line heights are used across a product, but also to understand why having an appropriate line height is so important for readability and good visual design.
The best way to level up a team is not just through training (although that can be helpful) but through collectively practising design. Involve developers in design reviews. Get the whole team to observe usability tests. Run team workshops to sketch and iterate design concepts. The more a team collectively know about design, the less design debt a team will unwittingly release.
Tackling design debt
Whilst there are certainly strategies for reducing the amount of design debt building up, some degree of design debt is inevitable. As the old saying goes, you can’t make an omelette, without breaking a few eggs! Here are some tactics for tackling design debt.
Factor tackling design debt into plans
The most important consideration is to factor tackling design debt into your plans. You need to be proactive when it comes to design debt, not just reactive. For example, you might designate an entire sprint for dealing with design debt, or have a stream of work that can continually chip away at it. As should be the case with technical debt, tackling design debt should be an ongoing activity, it should be planned and resourced as such.
Focus on key user journeys
Where do users get most value out of your product? What are the key user journeys? What are the really key moments in those journeys? As you consider how to tackle your design debt, these key user journeys and moments should be your focus. It’s often tempting to start with design debt that is easy to address, but really you should be starting with the most damaging debt, not the easiest to fix. A good way to identify design debt within key user journeys is through an exploratory UX testing session. Within a session you review a product against key user tasks and identify potential UX improvements. Take a look at my How to run an exploratory UX testing session article for more details.
Keep a record of design debt
Not all design debt can be resolved straight away, so it’s important to keep an ongoing record. Think of this as your debtors’ ledger. Because design debt related work tends to be relatively small in scope, I’d avoid simply adding it to your product backlog. If you do this design debt related items tend to languish at the bottom of the list and therefore never get resolved. By keeping a separate record of design debt, you can easily batch work together, such as for a sprint dedicated to paying off some of the most damaging debt.
I’ve used Trello in past to keep a record of design debt, but you could use a spreadsheet or a tool such as Jira. It’s useful to record details of the issue, screenshots, an indication of priority and a high-level estimate of the work that’s likely to be required to resolve it.
Conclusion
In today’s world of MVPs, experiments, Sprints and Agile product development, design debt is as inevitable as monetary debt. Much as we’d all like to be mortgage and debt free, that just isn’t going to happen for all but the most privileged, and the same is true for design debt. You should think about how you can minimise the amount of design debt piling up and have strategies for tackling the design debt that you have accumulated. Don’t let design debt slowly envelop your product and risk building your very own Winchester mystery house.
If you like this article then please recommend and share it. You can find lots more articles like this on my blog: UX for the Masses
Image credits
Originally published at www.uxforthemasses.com on December 19, 2019.
