What is Design Debt?

Design Debt – Accumulated debt in the design process

“Design Debt is all the good design concepts of solutions that you skipped in order to reach short-term goals. It’s all the corners you cut during or after the design stage, the moments when somebody said: ‘Forget it, let’s do it the simpler way, the users will make do.’”

This paraphrase goes back to Ward Cunningham, one of the 17 authors of the Agile Manifesto and the inventor of the Wiki system. Cunningham also coined the metaphor of technical debt, which describes future, additional expenses as a result of delivering imperfect products in the present.¹ Design Debt is a type or manifestation of technical debt; consequently, it is debt accumulated in the design process that often has to be paid off in the course of a development.

Reasons for Design Debt

There is a whole range of causes and reasons that go beyond Ward Cunningham’s “simple” paraphrase. Design Debt can arise, for example, when

• design decisions are influenced by technical limitations or constraints.
• designers have to compromise due to limited resources or conflicting requirements.
• lack of time means that the design process cannot be iterated or thoroughly tested.
• stakeholders do not give appropriate importance to the user experience.

More abstractly, there are different types of Design Debt:

Intentional Design Debt: Intentional debt can give a company quick “wins”. The team makes a deliberate decision to bring the product or a version of the product to market as early as possible when the perceived benefits of that decision outweigh possible costs associated with eliminating the debt at a later point.²

Intentional Design Debt also often occurs when conventional design approaches are deliberately ignored. This can often be observed in hackathons, innovation sprints or community developments.

Unintentional Design Debt: It can arise from incompetence and lack of experience. The team “goes into debt” without being aware of it and without considering the consequences. This type of debt is often faced by companies in a fast-growth phase. Of course it should not be this way, but in fact it happens more often than one might think.

Interestingly, there can also be the combination of these manifestations: It is debt that accumulates over the course of a product’s existence due to changing market demands. The developers may have done a good job, but in retrospect they recognise how the design should have been. This observation leads to the realisation that design debt – similar to technical debt – cannot be avoided; accordingly, unavoidable Design Debt can also be declared as a characteristic.

Advantages and disadvantages of Design Debt

There are essentially two scenarios or advantages to intentionally incurring Design Debt:

• Accepting some Design Debt at the beginning of a project can speed up the initial development process, allowing a product to get to market faster.
• And even when creating prototypes or proof-of-concepts, it is often acceptable to temporarily incur design debt in order to quickly test ideas.

But this is offset by some weighty disadvantages:

• Over time, it becomes increasingly difficult and time-consuming to make changes and improvements to the design, leading to higher maintenance costs in the long run. (To stay with the metaphor: the interest burden becomes too high).
• It can slow down future development efforts because developers must first fix existing problems before they can implement new features.
• It often leads to more bugs, which lowers the overall quality of the software.
• When design debt adds up, the user experience suffers significantly. Users quickly project the quality of the design or product onto the brand, and trust in the company quickly dwindles. Lost trust leads to lower engagement. Lower engagement may lead to users advising others not to use the product or other products from the manufacturer. Ouch!

And last but not least, poor, inconsistent design of a product can contribute to qualified developers leaving a company or other developers shying away from working for the company, as eliminating debt is often very frustrating and demotivating.

Impulse to discuss:

Regular Design Reviews are considered an effective means against Design Debt. Is it worth using a checklist for such reviews?

Notes:

Feel free to share or link to the content on this page.

[1] Ward Cunningham: Debt Metaphor
[2] This approach is similar to the concept of a Minimum Viable Product (MVP), where a team compromises on long-term issues to get a product to market faster. In practice, it may subsequently make sense to plan for an “interest payment” in advance, i.e. in subsequent iterations, to allow time for appropriate product improvements.

Martin Fowler – another initial signatory of the Agile Manifesto and a recognised expert in object-oriented analysis and design – defines the so-called Technical Debt Quadrant:

• deliberate and reckless – we don’t have time for design
• deliberate and prudent – We must ship now and deal with consequences
• inadvertent and reckless – What’s layering?
• inadvertent and prudent – Now we know how we should have done it.

This Technical Debt Quadrant can also be applied to Design Debt.

You can download our free Technical Debt Guide here.

And here you can find additional information from our Smartpedia section: