Tips to manage design debt in enterprise applications

Phil Haddad
UX for Enterprise
Published in
4 min readJul 26, 2019

More and more, product and design teams are talking about design debt.

What is design debt? Similar to its counterpart/namesake, technical debt, design debt is created when corners are cut to get to production at the expense of the user experience.

While your team may decide any one of these design elements or steps is acceptable to skip, over time these add up to significantly degrade your users’ experience.

Michal Mazur has a great Medium post further defining and exploring the concept here.

Why do enterprise apps suffer from design debt?

All too often, enterprise apps maintain an extensive backlog of design debt — whether or not that debt has been identified. This is a challenge particularly for teams building tools in-house, but it can plague SaaS companies as well when UX is not a priority.

Why is this a challenge to enterprise teams?

  • Sometimes just getting the job done is the goal. As long as the tool is ‘good enough’, the buyer or executive sponsor may not care about design & usability. Their primary concern is basic competency and cost to develop/purchase. As a result, time may not be given to the research, validation, and implementation of user-centered designs and practices.
  • Teams often work under tight timelines driven by business constraints. Depending on the context, there may not be time to spend on design improvements or user research when operating under tight timelines or other external factors.
  • Visual design may take a back seat. If the engineers working on an application are not frontend specialists, visual design may be a low priority in favor of speed and simplicity to implement. Small deviations in UI over time can lead to a clunky, inconsistent user experience throughout the app.

Here are some ways to manage design debt

Start writing UX bugs

One of the challenges to addressing design debt is communicating the impact it is having on your users and getting your team aligned on priority to fix them. If you need to get engineers on board, speak in a language they already use.

Calling out design improvements/fixes as bugs can help to contextualize the way we view them as designers. Although your product may be technically functional without addressing them, labeling them as a design or UX ‘bug’ helps communicate how crucial you feel it is to address them.

I opt for the terminology of ‘UX bug’ to avoid possible pigeonholing. Often in others’ minds design = UI, but sometimes a UX bug might address loading times or other points of friction to the user experience.

Create a design debt backlog and work with engineers to devote regular time to it

Another approach to use with or without categorizing debt as bugs is to track these design debt items on an ongoing basis. Again, part of the reason corners get cut is when elements are deemed too trivial to devote time to. By tracking these on an ongoing basis, you can build up a backlog of design debt your team should address.

On some teams I’ve been on, we had two hours a week that an engineering pair spent with designers going through this backlog and tackling whatever would fit in that time window. Treating these elements more as chores allowed us to continually improve the user experience without spending too much time away from more critical stories.

Pairing with engineering like this also enabled more communication between our disciplines and helped us understand each others’ constraints and what drove the decisions we made.

Photo by Ruth Enyedi

Be willing to compromise

In the end, any approach you take to resolving design debt will require compromise. Be prepared to thoroughly communicate the value of the design work you are asking the team to completed and prioritize which items have the biggest impact on the user experience. Not every UX bug will get addressed, and you have to be okay with that.

The best products are made on balanced teams who trust each other enough to have healthy conflict from the viewpoints they represent. By building trust in your team through compromise, you will help ensure the success of your product or application.

--

--