Most projects have design debt. Like technical debt, design debt is the natural decay that accrues as a project matures—new features are added, old features grow stale, and the codebase starts to get unwieldy.
Maybe there’s a perfect, debt-free project out there. If so, I’ve never seen it.
How does design debt happen? There are many possibilities:
- As a website or app gets larger and the design language evolves, it may start to reflect different design thinking than older ones
- The original design may be stretched beyond its original intentions, resulting in elements that feel shoehorned in or taken past their intended capabilities (menus that were designed to accommodate 5 items suddenly have to accommodate 8, etc.)
- Technical requirements change, and now markup that was originally in vanilla HTML is being implemented in React JSX, etc., where best practices are different
- The design team changes and new leadership advocates for a different set of design or front-end standards, rendering some of the old style obsolete. Style sheets that were originally written using the SMACSS methodology may now be living alongside stylesheets using BEM, etc.
Image from Inside Design: Rent the Runway.
For those of us with perfectionist tendencies, it’s tempting to want to scrap the front end and start over. But the same traits that give a project debt make it impractical to start fresh with a blank slate.
So, how do we eliminate design debt without halting forward progress?
Programmers talk about refactoring code—restructuring existing code to be better, more efficient, and more readable without changing its outward behavior. We can do similar in our design work—as we iterate and ship new features, we can go back and tweak existing elements to reflect everything we’ve learned since. By doing this, we can smooth out rough edges and apply our latest design thinking to earlier parts of a website or app.
Here are some techniques that I’ve found helpful.
Find common elements that can be unified
One common sign of design debt is similar elements that use different code—either identical elements that don’t share code or design assets, or similar elements that should be unified but aren’t. If you have 2 content blocks with paddings or border widths that are 1px different, for instance, you can probably simplify things.
“There’s no shame in a project having design debt.”
Identify disparate elements that are similar and then unify them throughout your project. Your design will be more cohesive, your code will be leaner, and future changes will be that much simpler.
Tackle small pieces at a time
It’s much easier to clean up individual elements than entire screens. Have a spare hour? Redesign some buttons, or clean up the site footer. Feeling more ambitious? Refactor the code for your site’s modals or dropdowns.
Focusing on individual elements rather than whole chunks of a design will give you a more tangible sense of forward momentum, too. Working on an entire screen at once can easily balloon into an unmanageable time-suck of a project—smoothing out some rough edges on the homepage can easily lead to redoing the header, and then the footer, and then the calls to action, and on and on. Individual elements are finite and less likely to cascade into a redesign of epic proportions. Better yet, because they probably appear throughout your site or app, users will see positive changes on a shorter release cycle.
Image from Inside Design: GoPro.
Give yourself a platform on which to iterate
No matter how dedicated you are to paying off the design debt of individual pieces or your project, eventually you’ll find something that requires a more comprehensive refactor.
I encountered a recent example of this while working on a web project. Several pages of the site had similar, but not identical, inner widths. It was a quirk of how the pages had evolved; they started out with different layouts, but they’d grown towards each other until it clearly made sense for them to share the same code. Unfortunately, since the underlying markup was different, it’d take some work under the hood to unify the pages.
In cases like this, sometimes you just have to bite the bullet and set aside some time to repay a larger part of the balance of your design debt. By doing so, you can give yourself a platform from which to work on more focused pieces later on—by tackling a big piece of design debt like the layout, for instance, you can unlock the ability to work on some smaller elements that are layout-dependent. Doing this larger work up front can make you more productive in your refactoring work later on.
Work from most visible to least visible
Every digital project has dark corners, outside the usual path that users take. It might be an infrequently accessed settings screen, or a sub-page of a sub-page hidden behind a footer link. While these edges might be the first elements to show signs of decay, they aren’t necessarily the first that should get attention.
“Tackling design debt? Fix the most visible elements first.”
To get the most bang for your buck, start with the most visible elements that are showing decay. Buttons and form elements are often the best candidates—even if they aren’t showing their age as much as some other parts of your site or app, they’re so frequently used that any design improvements will cast a glow on the whole project.
Collect feedback to avoid losing sight of the big picture
It’s easy to get bogged down in the minutia of fixing design debt. You may find yourself perpetually finessing the same form elements, or tweaking an endless stream of modals and dropdowns and popovers.
Image from Inside Design: Netflix.
It’s important to pick up your head occasionally and refocus on the entire project. Ask yourself which pieces of design debt are the most egregious, and what improvements you can make that would create the most value for users. Remember to keep your eyes on the overall experience—maybe a particular screen is really showing its age, but hasn’t been a hindrance to your users, while something more recent looks slick but provides a sub-par user experience.
“The best defense against design debt is a constant stream of feedback, both internal and external.”
User flows can decay just as quickly as visual design, but they’re often invisible. Solicit feedback from your users, and spend time regularly testing your project as if you were a user. The best defense against design debt is a constant stream of feedback, both internal and external.
Related: How to give good feedback
There’s no shame in a project having design debt—it’s the natural result of having too much work to do and not enough designer-hours in which to do it. Facebook has design debt, as does Google; LinkedIn and Twitter are practically drowning in it.
No project has infinite resources, regardless of whether it’s built by a corporate behemoth or a fledgling startup. Design debt often means you’re iterating quickly and have to triage your time to favor building new features rather than polishing old ones.
You’ll love these posts, too
Jordan Koschei is the lead product designer at Agrilyst, where he helps build the intelligence platform for indoor agriculture. He was previously the managing editor of The Industry, a digital publication that helped pioneer design-oriented coverage of the startup scene. When not designing, writing, or coding, Jordan can be found enjoying life in New York’s beautiful Hudson Valley.
