Most people working in digital teams have heard of technical debt (“tech debt”) in conversations with our software engineer colleagues. And whilst technical debt is often understood by our product management colleagues, design debt on the other hand isn’t.
As designers our aim is to make sure we meet user needs by utilising strong user-centred design.
As multidisciplinary product teams we all have a responsibility in making sure we deliver consistent user-centred design by ensuring we iterate, question our hypotheses and have these made a priority in backlogs.
It’s important to understand the life cycle. An idea becomes released into a service or product at some stage. These ideas grow into patterns. Like any other aspect of design they are subject to change and improvement.
It is important to iterate. We should look at maintenance and improvement through design research.
What is Design Debt?
Forward thinking organisations will encourage their teams to identify and reuse standard components and patterns. This is a no-brainer for organisations who understand the need to save resources and avoid reinventing the wheel. By doing so we can focus our effort on the trickier aspects of a service or product that make it unique.
“Design Debt” are the deprecated design components, styles and patterns in the services, journeys and experiences of our users.
It’s what happens when we fail to iterate our designs based on new data, feedback or research or when we don’t keep design patterns up to date with parts of a design system which we may be using. It also happens when organisations become purely focused on feature releases without prioritising design maintenance as part of their backlog.
We often know that design debt will happen, we’re aware of it but dealing with it is different entirely.
In a large organisation that follows a design system, design debt can still accrue. In fact, design debt can rapidly increase when there are multiple teams working to different demands and it takes a level of resilience and self-motivation to keep on top of it. Teams may work faster than the design system can bring in new patterns or components. These patterns may not make their way up the design system.
For instance, multiple teams in a given area may be working at a different pace and inevitably may have breakdowns in communication.
The realisation of design debt
When the realisation hits that you’ve accrued design debt it can be quite daunting to deal with, not unlike dealing with financial debt. Let’s take a look at the compounding effects of design debt to you, your team and your organisation.
Is the design really consistent?
Stakeholders start to notice small inconsistencies with design across the organisation. Maybe different teams have presented to the same stakeholder within days of each other and the stakeholder notices differences in the design.
Design system alignment
Cracks start to show between approved patterns and components in the design system and design which has been approved for release to users. A single source of truth is no more.
Design governance
You may have some level of design governance in your organisation, but when design debt increases how do the governance models work? How is it known which design pattern or component is the correct one. Which one is assured? Has a governance team approved the wrong one for use without realising?
Design debt in to tech debt
As design debt mounts, there will be a point when it’s surfaced and taken into a backlog for a development team to update. Design Debt transfers at that point into technical debt which increases the overall debt amount quite considerably. In some cases updating something which is in a design system may need to be corrected in five different places in a live build.
These are just a few compounding problems which can occur from a design debt build up. There will be more and you’ve probably felt them at some point through your career.
Surfacing debt
Accepting design debt is the right thing to do.
Most importantly, surfacing the design debt is where you’ll find incredible value. It gives you a place to start. This is where you will be able to understand and quantify what you’re working with and begin a plan to work through and reduce it.
Below we’ll give a few examples of how to start as a design team and bring along our product and delivery colleagues to support us on the journey.
Acceptance
As we said above, start by accepting it’s there. Design debt will not go away by itself. If anything, once it starts it will only increase and cause more compounding effects like we’ve described above.
Inventory
By creating an inventory of design in your given area, you’ll be able to visualise the design components and patterns as well as being able to quantify what you’re working with. Surfacing these details puts you in a much better position going forwards to start working through your design debt. Below is a list of things to include in your inventory. As a starter you should surface;
- Service / Product / Tool
- Name of element
- Name of screen using component / pattern
- Component / pattern location on screen
- Component / pattern location in other service / product / tool — this is important to find the design consistency across different services / products or tools
Once you’ve surfaced the data you can then begin to add extra detail to enable you to measure your inventory;
- Confidence level rating (should be vs needs to be done)
- Risk of doing / not doing
- Opportunity of doing / not doing
- Proposed fix, fixes or iteration
- Time to design / research fix or iteration
- Team availability and activity required
- Any alternate hypotheses
Measuring the inventory will help to communicate with product and delivery managers in your organisation.
Documentation
There are various ways you can document the above information;
- Spreadsheet
- Trello board
- Miro board
- Github repo
- Print it out on a wall (not so easy during lockdown)
All of these will help visualise and describe the level of detail you need to extrapolate in order for it to be valuable.
Working big scale
As we’ve mentioned, working towards building an inventory in a large organisation is a challenge.
If you think of an example like having six or more large areas of an organisation, each with their own design team, their own priorities and motivations working with a design system which may not have everything they need you can begin to understand the scale of what you might come across.
Here’s a simple plan to get going;
- Treat the inventories like a broad project covering your organisation
- Identify your stakeholders
- Communicate the plan and the problem you’re trying to solve across your organisation
- Begin your inventories in your own area of your organisation
- Document the inventories as described above
- Bring these inventories together into a central working group
- Identify those patterns or components which should be used against those which shouldn’t
- In your area work with a product manager to prioritise the work required in a backlog
- Have your design system team take the ‘true’ pattern or component into the design system backlog
- Work with as much validated research and data as you can
Without a doubt you’ll find both consistency and inconsistency.
The scale of the work required might be large and it may take time to complete.
The important thing is to start.
Communicating with your product management colleagues
It often feels difficult to get project leads and stakeholders to understand the importance of dealing with design debt.
Their jobs are full of conflicting priorities and motivations and they are usually under pressure to deliver new features.
Think about it from their point of view. If it isn’t broken why fix it?
Delivery managers and product managers don’t often see design debt. In the same way they don’t see technical debt. This is not a fault. These concepts are highly specialised and require a trained eye to spot them.
If they cannot recognise design debt in their own service or product, how can they be expected to understand the impact it may have on other services or products without our help?
As experts in design we need to reinforce a constant message throughout a product’s lifecycle. That any design, including standard components, is our best understanding at any given time. Design should evolve as we learn more, either from our own team, the wider community or ultimately from our users.
It is our responsibility to highlight design debt as it’s spotted. For example, when adding tickets to your backlog include the reasons why it’s an issue. Why it’s going to cause problems in the future and the benefits of putting in the effort to deal with it now.
Will it save wasted effort in the future? Will it benefit other services? Most importantly, how will it impact users? What improvements will it bring them? Use this language when discussing design debt. Frame it as an opportunity, not a complaint. You may find your team start to use the same terminology.
Senior product leaders should create a culture where our delivery colleagues are encouraged to think about the impact their service has on the wider digital community. A culture that aims to deliver something great today, but also helps to deliver many great things tomorrow.
Product owners and managers should be recognised for releasing something back to the community that has an impact on their organisation beyond their own service.
It’s about open communication with our colleagues. Helping them to recognise that this is never just change for changes sake. Consistency is only part of it. More importantly, we all want the products and services we design to be the best they can be for our users. Each team must do its part by dedicating some resource to reducing its design debt over time.
How to stay on top
Once you have the process above ironed out, you will hopefully have the majority of the design debt cleared and you’ll have inconsistencies made consistent and documented in your design system. It’s good to iterate and revisit the process we’ve described over time, the scale will be smaller and you’ll be much more able to build design debt into your backlogs.
This article was co-authored with Jon Greer.
Thanks to Richard Young for his words which were included in the article.