Button 1

Staying on top of Design Debt Mountain

Aug 11, 2021

Design debt mountain: Understanding what it is and keeping the designer involved is one of the key characteristics of a 'UX minded dev'.

When you receive mockups from the designer or perhaps a sketch from your client and something doesn’t feel quite right, you have one of two options: you can ignore the “smell” and build exactly what they asked for OR you can poke the bear and probe the design rationale. 

Which option do you usually go for?

If your answer is that it depends on (a) the designer and the quality of the designs (b) the importance of the feature or just (c) your existing backlog of things to work through - you’re right! Your capacity to engage with the designers head on depends a lot on the processes, people and context. 

Out of all the developers I’ve worked with, there are some that have really great design sensibilities / enjoy working alongside me as we’re prepping designs (and throughout the implementation process). There are a couple of things that I consistently noted: 

  • The seniority of the dev wasn’t always correlated to how good their design skills were.
  • They asked a lot of good questions about the rationales behind the design before accepting the ticket.
  • They always checked with me before deviating from the mockup and specs to see what the wider UX implications would be.
  • If I wasn’t available, they were able to propose decent design alternatives.

I started referring to devs like this as being, “UX minded” (like being “product minded”) because while they definitely weren’t doing my job, they were always ensuring that what was being implemented added up to the best possible user experience.

Habit #1: Diagnosis

UX-minded devs diagnose or review designs in a consistent way

Designs are typically evaluated on two levels: 1) how the screen looks, i.e on a component level, and 2) how intuitive it is to find and execute the main actions, i.e. how to navigate the screen.

We found it’s helpful to think about a design from a more nuanced perspective. Here are some examples:

  • The design itself looks off or a little inconsistent → this is a sign of visual hierarchy issues. 
  • The flow between screens, especially when an action is completed successfully or unsuccessfully, does not feel right → probably an interaction issue. 
  • It’s not clear where to go and how to find specific information or the content needs explanation → seems like the issue is on an information architecture level.
  • We’re using new components on this screen and they're not consistent with the rest of the app → we might be creating unnecessary UI complexity.


Everyone has their radars tuned slightly differently but when a design feels “off” it’s rarely one issue that’s throwing things off: it’s more likely to be a combination of these 4 things. It’s usually helpful to have a checklist that helps you systematically narrow down where the problem is.

Habit #2: skilling up on UX

You have brushed up on your UX basics

Hopefully your designer has prepped a solid design system that you can refer to when you’re implementing designs but if that’s not the case for you, you’ll need to have a decent foundation in some UX fundamentals so that you can make a few design decisions autonomously.

Information architecture

When things are fundamentally well organized i.e. intuitively organized, many ux problems can be eliminated up front. Navigation issues often come up when things are organized without a clear logic, navigational labels are confusing, or the organization of information doesn’t match the user's idea of how things relate to each other.


This is a pretty broad term but in its simplest form, it lets the user know what happens when an action is completed. Attention to interactions will mean that the user understands why something is or isn’t happening and it moves the user forward in their journey.

Visual hierarchy

We like it when things look balanced and when it’s easy for the eye to follow a design. Our brains get cranky when we have to focus too hard on a screen in order to take the next step in the flow. There are several variables that contribute to this: colours, contrast, proximity to the edge of the screen, alignment, whitespace, separation of sections etc. Having the right balance of all these variables make things aesthetically pleasing to look at and use. 


Establishing the right colour palette is really important for the overall perception of the product. Knowing how to make the best use of your darks, neutrals, accent colours and system colours without going overboard, is low hanging fruit for designs that are a little too adventurous or not exciting (or polished) enough. Sometimes all it takes is a coat of paint for people to be more open.


Having the right words is important for user experience but how the words are read depends on typography. Font choice, font weight and font size will all influence how users react to a screen giving them directions to do something.  

Habit #3: Design debt awareness and collaboration

As a dev, you get what design debt is and you keep the designer involved during implementation.

With technical debt there’s a very direct correlation to undesirable outcomes such as the time it takes to develop a screen, the amount of bugs experienced, the motivation of devs to work on a messy codebase etc. When it goes unaddressed for too long, it is very detrimental to performance and the motivation of working on the product. 

 However with design debt, it’s less obvious but no less detrimental and frustrating in the long term. It’s normal that designs aren’t implemented pixel for pixel but everytime there is a deviation from designs that are part of a larger design logic, you are potentially going to be creating issues for users down the line (as ‘weirdness’ creeps in here and there). Inevitably, it makes life more complicated for designers and developers alike as the team begins to expend further energy rationalizing and accommodating the deviations each cycle. As these deviations add up, the larger design logic can erode, leaving a user experience that feels wrong.

The best you can do is make sure that for bigger design deviations, that the designer can account for the change throughout the user experience. This will involve not taking shortcuts on discussion time with the designer to find an alternative way to fulfil the specs within the technical restraints you're working with. The result will be a justification of the extra dev effort or to highlight which aspects of the user flow will need a corresponding update.

In summary...

It’s important to underline that your role as a dev is to implement and build the software to the best of your ability - the goal is not to become a UX Designer AND Developer. However, with a few of these habits, you’re putting yourself in a better position to build the best possible software regardless of the environment you’re in. Not to mention that having a little bit of UX under your belt will help you have some additional common ground with your designer or PM.

Great user experiences are only possible when you feel like you’re building software that’s been designed well which is all the more possible thanks to UX minded devs.

Since you made it all the way till the end, you might be interested in what we’ve been working on here at Pencil & Paper. We’re here to increase the standards of good design and good software but we can’t do it without developers. We talk more about it in our Design SOS course and on Twitter of course. 

📬 Join the crew

Sign up for the latest:
hot takes 🌶 ,  fireside chats 🔥 & early access 📣 

We won't send spam. You can unsubscribe at any time.