Design debt and how to pay it off

“Debt is beautiful only after it’s repaid“ — Russian proverb

Public Domain Images — Arctic Plane Crash Blue Grey

Entropy is defined in many dictionaries as the “the lack of order or predictability” and “gradual decline into disorder.” It affects most things in life. Everything needs some level of maintenance to avoid this decline. Nothing exists on its own but inside a context that affects it. This is systems thinking.

So this is nothing new. What I want to look at is this concept of entropy from a perspective I have only recently heard being discussed — interaction design*. You might already recognize its sibling terms: “technical debt”, “deferred maintenance,” and a little something called “not brushing your teeth”.

Design and debt

As a designer of mostly digital experiences, I create systems of patterns used for applications: a retail site, an intranet for knowledge sharing, or a native payment app. One of the first steps I take is creating a space for these patterns to exist. Then the space needs to be maintained, labeled, communicated, and stabilized. It is when things get messy, disorganized and inconsistent that design debt trickles in.

It is healthy to realize that we often miss important things in the beginning of projects. Call it the “honeymoon” phase, or simply a lack of perspective. The project feels romantic and simple at first. This makes it hard to spot those small ripples of early decisions that turn into huge waves later on. For example, not spending enough time on content strategy upfront masks big issues in the design work and conceptual models that underpin everything with the project, and this ends up causing major rework.

When creative decisions are deferred, debt piles up. When files are not maintained and different design patterns are implemented to solve the same problem, debt piles up. It shows its face when strategy and scope are poorly defined upfront and your stakeholders question fundamental design decisions or decide to add features in the 11th hour. Debt is easy to anticipate but uncomfortable to deal with. Just like real debt. Every project has it.

What can cause design debt is different for each project and product, but here is a high-level list:

• Deferred design decision making and design maintenance
• Poorly organized deliverables
• Not documenting design decisions
• Ignoring asset management
• Late sign-off from the product owner
• Scope creep without adjusting timelines
• Not accounting for changes to key requirements
• No context from design principles and insights to guide decision making
• Less experienced talent tackling complex challenges

From the trenches

To give you an example of how design debt accumulates and can be resolved, a team I was working with started a great project, and after a couple of weeks we had to respond to an unforeseen issue. Our group went from a handful of people to several dozens in a short amount of time. We had no other option but to scale past what we were comfortable with. It meant that small things fell through the cracks. We had to cut some corners, and our debt racked up. We hustled and finally got to a point where not only did the creative work look great, but the project had been stabilized and, as a result, was better understood by our client. The project was something we were proud of, especially in the midst of challenging circumstances.

In order to get there, we executed on multiple explicit and implicit tactics for paying off design debt. Here are some of them:

• We established a foundation. Before the project got messy, we worked with the client to align on what the primary insights and design principles were that would drive the work. We also prioritized key tasks we would support and showed directional work for consideration.
• We logged every design decision. We made sure someone emailed meeting decisions to the stakeholders and recorded the decisions on our ongoing list. This was important for transparency, considering the speed at which we worked and the number of stakeholders involved.
• We established single sources of truth. Does that sound like an oxymoron? With complex projects, there exists a vast set of deliverables and documents that simply cannot be in one place. One of the ways our UX designers addressed this was to publish work on AxShare.com, which allowed them to maintain one URL where they consistently pushed all updates.
• We held weekly internal design reviews. In order to align between disciplines, we made sure we all saw the work of the other teams. These reviews were expensive in terms of time, but entirely crucial.
• We maintained a living style guide. Our front-end engineers created a style guide on day one and maintained it throughout the project. This guide served as a consistent reference point, allowed us to maintain fidelity to the project goals, and aided our discussions about feasibility.

When debt starts piling

The hardest situation to overcome is when debt becomes so big that it is hard to get past the hump. The cost of debt that piles up is higher than if it is dealt with consistently. Some research on deferred building maintenance points to a 4:1 ratio in cost. This means that $1 saved by not performing regular maintenance costs you $4 later on. Probably the most tangible, yet hard to quantify, results of design debt is the high cost of dealing with it once left unattended for a while.

Several things will happen when too much debt is racked up:

• Red flags go up. Stakeholders start raising red flags about design quality and/or the accuracy of delivery.
• Problems compound. Small inconsistencies or lack of a maintained foundation of design decisions result in greater problems later as they affect larger parts of the experience.
• The effects impact others. Neighboring teams get frustrated with unfinished work being passed on to them, or incorrectly implement designs due to poor communication of design decisions and intent.
• Technical debt increases. Refactoring code causes technical debt that compounds issues further. Any design decision now made is more heavily constrained by a foundation of code that has already been poured.
• Edge-cases are feared. Accounting for edge-cases will often break the design or cause inconsistency. Because they weren’t accounted for in the original work or documented from the start, details get missed and now cause issues.
• Poor quality. Ultimately, a sub-par product is launched, and users, as well as clients, will turn elsewhere for future work.

Preventing and paying off design debt

Here are several suggestions to consider to prevent or pay off design debt:

• Invest time at the start. The beginning is where there is the most risk for missteps that ripple throughout the project. Make sure you invest time and effort into a plan for documenting, maintaining, and communicating design decisions from the start.
• Pick documentation format and location. Use a style guide implemented in code, a collaboration app like Zeplin, or many of the suggestions by smart folks such as Nathan Curtis on how to create a design system.
• Set expectations upfront. Communicate assumptions with the client or stakeholders about when and why creative debt is expected so that they understand the nature of what they are about to see. Some projects will have a lot of debt (e.g., quick MVPs).
• Design personal and team rituals. Just as with monetary debt, the best approach is to track debt systematically and periodically hack away at it. Letting it pile up or expecting there not to be debt is never a good idea. Play the long game by designing rituals that support this way of working.
• Bring key stakeholders along. Certain things are best understood by experiencing them. Allow your stakeholders to be involved and see the path you take so they are equipped with an understanding of why things are the way they are.
• Communicate design intent and decisions. Design is intent made real. Communicate the intent behind design for a non-designer audience and document the design decisions that have happened over time to support those decisions.
• Be tactical in documenting design decisions. Decisions should be communicated over email in detail after every meeting, logged at the executive level for those that don’t want to read all the details, discussed at in-person milestone presentations, and added to a living style guide or design system that everyone has access to.
• Print it out, cut it up. If you are currently inheriting a hugely inconsistent project where it is hard to make sense of what the source of truth is between all the deliverables, then you can make it physical. Print all artifacts out, cut them up, organize them from atomic elements, and group them as it makes sense.

Design debt is something that needs to be dealt with intentionally to prevent it from getting in the way of designing great experiences. By understanding how regular practices and intentionality can help you pay it off, you get a more predictable way forward that builds trust with your clients, your stakeholders, and your own team.

What stories about design debt do you have and how have you deal with it, either in your individual work or on large scale projects? Leave a comment below.

* Entropy and debt in interaction design has been discussed more in the last year. Here are examples of that.

Jeroen van den Eijkhof is an Associate Creative Director at the Deloitte Digital studio, Deloitte Consulting LLP in Seattle. He’s a Dutchman who was born and raised in Sweden with a heavy influence of European design. Jeroen leads creative execution of digital experiences with a clear point of view and has had the privilege of leading user experience work for several global brands from the ground and up.