Reducing design debt: how to fix the tracks while the train is running
If you’re a designer in technology I am fairly certain you know design debt. It’s that insight that never made it to the implementation phase, that solution that was deemed not important enough to build, or the ever-growing number of styles within the application due to the lack of a UI style guide. The list goes on and on. To my knowledge the term was coined by Ward Cunningham who said:
“Design debt is all the good design concepts or 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”.
Designer Austin Knight says that design debt occurs “where the cohesion and consistency of a design deteriorates over time as new experiments are run and new elements are introduced into the design.” If you want to learn more about this concept, Michał Mazur discusses the definition and the perils of design debt more in-depth, and Kight has a great essay on the subject. However, this article is not about the definition of design debt per se, it’s about practical ways of getting rid of debt while you keep building, particularly in a fast-paced environment such as a technology startup.
Four practical steps to reduce and pay up the debt
1 Accept that debt will happen
Design debt will happen. In fact, the most common scenario is that it will already be there by the time you arrive at the organization. Similarly to how designers should aim to manage complex systems instead of reducing them, we should strive to make debt visible so that we can tackle it instead of brushing it under the rug. This leads us to…
2 Audit (at least part of) your service
Again: to make debt visible we must identify it. A good way to do this is to run audits of the service to understand where debt exists. It’s relatively easy to look at the interface of digital service and start auditing the different inconsistencies that are shown; you should look for inconsistencies in:
- Typefaces
- Colors
- Visual styles
- Interaction patterns
- States (e.g. errors, warnings)
- Copy, language, and tone
- Navigation flows and IA patterns
These are usually easy to spot, although you might end up with a large inventory (which means there is a lot of debt to tackle!).
There is another type of design debt that is harder to spot, and in my opinion, addressing this is the key to long-term debt reduction: remember that Cunningham said that “Design debt is all the good design concepts or solutions that you skipped in order to reach short-term goals”?. Well, why were they skipped? What decisions led to bypassing critical steps? Why where there no checks and balances to make sure patterns were consistent before handing off the design to the next person? Debt is partly generated because our processes are ill-defined and the organization is not mature enough. I have talked about how to mature the design culture at an organization before, but what is critical here is that by identifying how the debt came to be, we can address the processes and the systems that allow it to happen in the first place.
3 Bring in (or create) a set of UI-X primitives
Now that you have audits, you can see which areas require attention first. If you identified 15 typefaces you might want to start there and create a typeface style guide with a sensible number of fonts and weights.
If the interaction and UI patterns for forms are day and night depending on what part of the service you visit, then consider creating a guide for how to build forms by keeping in mind the corner cases and specific needs of the service. The key here is to start somewhere, not to design solutions for every problem because who really has the time for that?
Pro tip: devs are your best friends
In my most recent experience when I arrived to TriNetX, a fast-paced startup in the digital health and clinical research space, I was one of two designers for a team of about 50–60 engineers. This painful designer-to-engineer ratio made it clear that we needed UI primitives in place but we had no time to build one from scratch, so instead the devs and I audited a series of React-based UI systems and chose BlueprintJS. Over two years in this is one of the best decisions we ever made as an organization.
4 Decide when and how you want to fix things
Now it’s time to bring your findings to the rest of your team. Present your audit and some solutions to Product Managers, Engineers, and other stakeholders that have an influence on how and when software gets built.
This is when you put the ball in their court and say: “Look, we have identified a problem, this costs us money because engineers don’t have sensible patterns to build from, and our users sense the lack of cohesiveness in our service. How can we start to address it?”
Ideally, you can brainstorm solutions together and you reach some consensus. After all, designers are great at aligning different people around a common goal! At TriNetX we decided that any new piece of the platform was going to be built using Blueprint primitives combined with whatever guidelines my fellow designer and I created and that any refactoring or fixes of existing elements would also require to use the new patterns. This introduced some inconsistency in the short term but has created considerably more consistency and less debt in the longer term.
This arrangement allowed us to continue to build new parts of the service without having to fully stop to fix all the existing issues, and it also helped us introduce a more intentional and consistent visual style.
5 Stay accountable
Make sure the decisions that were agreed upon by the team on Step 4 are actually enforced during the development cycle. From my previous example, if a feature refactor is happening next sprint, introduce designs that remove debt and if there is pushback remind both engineering and developers about what they agreed upon, and about their commitment to design cohesiveness. While in my experience there might be some initial resistance, most stakeholders will soon understand the benefits of reducing debt because they will spend less time guessing what to do and more time building and shipping.
Takeaways
- Design debt is something we have to live with, like taxes and robocalls.
- This doesn’t mean we should become complacent. Work hard to identify your existing debt, and also to identify and put a stop to the processes that heavily contribute to the creation of more debt.
- Create or adopt a set of Interface and Interaction primitives that let you get off the ground quickly. There is a large number of wonderful and robust systems out there if you can’t afford to build one yourself. (Check out Adele)
- Work with your engineers, PMs, and others to agree on a way to tackle the debt. Remind the team of the cost debt has for the company and for your users.
- Make sure your organization stays accountable
- Aggressively address debt. The initial effort you put into creating audits and pushing for change will outweigh the pain of accumulating debt in the long term.
