Design Debt and Design Systems Design Debt and Design Systems

Design debt and design systems.

As your organisation grows, your digital services often grow with it. You add new web pages and apps, new projects along with sub-branding to distinguish them from older ones. New buttons and menus, new colours and animations to bring projects to life. New designers come on board and introduce new ideas, assets, and layouts. It becomes difficult to keep track of project changes. Designers become unsure which assets are the most up-to-date. Developers don’t know which assets to use in a given scenario. Faced with strict deadlines, they start to make ad-hoc decisions to plug gaps in the finished products. This process is called design debt.

Why is design debt a problem?

Even though these hurried decisions appear to save some time and money, they actually cost much more in the long run. Apps and websites don’t work as they should. Customers become confused. The project gradually spirals out of control.

Repaying the debt - fixing the problems - ends up costing much more in terms of time and money than if they had been avoided in the first place. Everyone ends up jaded by the whole process of making things up as they go along - particularly as this often means continuously scrapping what they’ve just built.

This mental and physical exhaustion means that they don’t have the time or energy to reflect on the process, figure out what went wrong, and take steps to minimise this in future projects.

Some examples of design debt are:

  • Inconsistent decisions. Responding to the same problem in completely different ways. Developers don’t know which solution to use and the customer doesn’t know what to expect when they use the product.
  • Untested ideas. Rushing to solve problems without testing ideas properly before they reach customers. Once the flaws become clear, new solutions have to be designed, tested, and built all over again.
  • Forgetting the documentation. Not giving context to decisions, leaving other members of the team in the dark. Why was one idea pursued and not another? What is the long-term design strategy for the product? Trying to figure out the basis for these decisions is often exhausting and confusing.
  • Clinging on to out of date assets. As a product develops, the existing assets may no longer be suitable. It can sometimes be tempting to squeeze a little more use out of them - adding more and more options to a navigation bar, for example, until it becomes confusing and unwieldy for users.
  • Not bridging the gap between design and development. When the design team simply hands off assets to developers and moves on to work on a different project, this leaves developers having to build the product without any context or guidance. If they encounter a problem, they may come up with their own solution without the designers knowing anything about it.

Many of our customers have experienced this endless cycle in the past. If design decisions are made with speed rather than quality in mind, then sub-optimal decisions gradually accumulate until the whole experience feels ‘off’ for their customers.

It can happen gradually, almost imperceptibly, but it has a huge impact on how customers perceive a company and its products. Fixing it costs time, money, and the product’s credibility.

The Qrious design system

Some of our own design assets, including colours, typography, and image guidelines.

Using design systems to address design debt.

It is only fair to acknowledge that some degree of design debt is inevitable. In a large organisation with many designers and developers - sometimes working in completely different locations – it’s unrealistic to expect a completely flawless design process.

The solution?

A robust design system is a powerful tool to manage projects and minimise design debt.

Design systems collect together all the components used to build a product. No two systems are the same - they vary according to the needs of each organisation - but they typically include:

  • A pattern library. Containing all the User Interface elements - colours, buttons, menus, animations, and so on.
  • A style guide. Containing information about the product’s look and feel, including practical examples of how to use the User Interface elements, typographic principles, and guidance about tone of voice.
  • Documentation. Explaining how to add and edit content, and providing detailed explanations where required.
the New York City Transit Authority Graphics Standard System, 1970, by Unimark

Design systems can trace their origins to the graphic standards manuals popular in the mid- to late-twentieth century. In this sense, they aren’t a novel idea - but, in the digital space, they become an immensely powerful resource for collaboration.

As your organisation grows, the design system evolves alongside to provide context and structure. In particular, we find that it helps everyone to understand the wider context of a project while not losing sight of the seemingly “minor” issues.

Design systems are not a magic fix for design debt. They have "a finite tolerance for adaptation" (Amy Hupe, 2020) and, if they aren’t kept up to date, they will eventually fall into the same process of gradual degradation discussed earlier.

We like this neat analogy for design systems.

Think of design systems as a big box of Lego pieces that can be assembled in near-infinite ways.

Like Lego, they offer a structure of shared rules that free people to think creatively. Also like Lego, they can be used to build brilliant outcomes or a confusing mess, depending on how they are applied.

Like any complex project, design systems take time to build and maintain, but this investment is vital to keep your brand consistent, useable, and trustworthy.

At Qrious, they’re a crucial part of our process and make life easier for ourselves and our own customers - which translates into better outcomes for their customers.

Sound familiar? Let us help, get in touch today. Contact us .