How to deal with design debt

Image for post
Image for post
The Winchester mystery house in San Jose, California

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.

Image for post
Image for post
Just some of the curious design touches in the Winchester Mystery house

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.

Image for post
Image for post
Beware the design and technical debt iceberg

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.

Image for post
Image for post
Some examples of the sort of design debt that can build up

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.

Image for post
Image for post
It’s important to have a master plan, such as this user story map

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.

Image for post
Image for post
Follow Atlassian’s lead by using a design system to reduce design debt

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.

Image for post
Image for post
The best way to level-up a team is through collectively practicing design

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.

Image for post
Image for post
An exploratory UX testing session can be a great way to identify design debt within key user journeys

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.

Image for post
Image for post
A Trello board can be a great way to keep a record of design debt


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 on December 19, 2019.

Former techy turned UX Jedi. Checkout out my blog (UX for the Masses) for more about me.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store