In my last post, I talked about design debt — a common byproduct of experiment-driven, user-centered design processes. All of those efforts to learn and improve over time can result in visual inconsistencies which in turn, can have a negative impact on your User Experience.
Again, some believe that you can prevent design debt. Though in all my years of designing digital experiences, I have yet to meet a product that’s truly debt free.
I’ve also never met a product team who wiped their debt clean and kept it that way.
They have, however, found ways to pay it down and keep it down.
So the key, then, is to expect design debt, then work to minimize it.
Before we begin, let me clarify that there is no right or wrong way minimize design debt. And it could take you weeks or months to come into a system that works.
I know, I know… digital.
Updated Design System
Before you do anything else, make sure you update your Design System – a set of standards, documentation, and principles, plus UI patterns and code components (toolkit) to maintain it.
A complete Design System defines your Building Blocks (colors, type, grids, icons), Pattern Library (templates, modules, components, elements), Rules (design, implementation, editorial) and Styleguide (static document that describes the system itself).
‘Cause it’s hard to tidy things up without a baseline to measure against.
If you don’t have a Design System, then I would create standards for your basic Building Blocks and commonly used UI elements at the very least, and go from there.
Depending on where you are in your product lifecycle, you can choose to eliminate a lot of design debt at once, then schedule in smaller maintenance intervals, or evenly spread the work over time.
Either way, design refactoring must occur on a regular basis, no matter what.
Typically, a small team of designers (designer-developers) and developers will meet weekly or bi-weekly to prioritize items in the design backlog and perform cleanups. If there is no backlog, then the team will conduct their own audit before prioritizing and refactoring.
Once you’ve gone through several refactoring cycles, you’ll want to organize your commonly used UI components in a way that makes it difficult to produce one-offs.
An example of a one-off is a form plus CTA button that’s created at the last minute. In such cases, it’s easy for a developer to quickly write their own code, and a stakeholder to approve the result, without referencing the Design System.
It’s near impossible to eliminate last minute requests. So a better way to ensure quality, without sacrificing speed, is to implement a UI framework that renders the correct element every time. The most popular of those being React.js and Vue.js.
UI frameworks are another topic altogether, so I’m going to leave it here. I’m pretty sure I’ve given you enough to start thinking about minimizing your own design debt. If you have any questions, feel free to ping us at studio (at) ksd-creative (dot) com. We’d love to hear from you.
Until next time,