Skip to content

UX Design Debt

May 23, 2011

I’ve recently been toying with the idea of whether the same concept behind Technical Debt can also be applied to UX Design Debt.

My rudimentary understanding of the Tech Debt concept was improved recently when I had the good fortune to see Martin Fowler present on the concept. This is how he describes it on his blog:

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy -you are sure that it will make further changes harder in the future.The other results in a cleaner design, but will take longer to put in place.

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor,doing things the quick and dirty way sets us up with a technical debt,which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

I believe that the same principle holds true for UX Design. A little bit of investment in upfront design can save taking on design debt that needs to be worked off later.

The main difference between the two is the impact of this debt. Tech Debt affects further coding work, making it more time-consuming and technically challenging to refactor. UX Design debt imbeds poor value propositions and design patterns in to a product which become increasingly baked-in to the product. At the end of the day, both become more costly to fix as time goes on.

What I find the most interesting about the idea of UX Design Debt is that it helps explain to technically minded people in their own language why some up-front design is a good thing. This doesn’t mean I’m selling my soul and advocating for Big-Upfront Design, but simply explaining that sometimes that upfront investment is necessary to get a non-debt ridden user-experience.

Thinking further outside the Tech and UX side of things, the ‘Debt’ principle can probably be applied to other areas, such a Business planning where some upfront planning of business propositions and process can help avoid organisational efficiencies further down the track.

7 Comments leave one →
  1. Dan permalink
    June 2, 2011 8:14 pm

    Good way of framing this. Nice blog, too – going to send your post on personas to coworker David, who’s interested in what makes good personas.

  2. Dan permalink
    June 2, 2011 8:19 pm

    Ha, I guess I used the wrong wordpress email and you get to see my friend April’s face.

  3. Triz permalink
    March 14, 2012 9:40 am

    The concept of UX debt is a big concern. When I first started doing User Experience some 13 years ago, there was lots of research bandied about to make User Experience an easy sell to the business. For example, for every dollar spent on UX, you save ten dollars in development effort.

    Having UX debt as a result of not being able to do thoughtful design upfront erodes the value proposition of doing User Experience in the first place. So how do we sell agileUX?

  4. March 26, 2012 10:08 am

    UX debt is a way of communicating the value of doing an appropriate amount of UX investigation and envisioning at the start of a project. Its aim to is to use existing software development concepts and language to communicate the value of what we do, not provide an argument that it isn’t necessary.

    The reality is that despite the field of UX becoming better at communicating and explaining the benefits of what we do, there are still plenty of projects that go forward without any consideration of the users.

    Having said all that, I would argue that we as a field we do far too much work upfront and in isolation form the development team who will actually be building what we design. The core value of Agile UX is that we work collaboratively and iteratively with the dev team, making design a continuous activity, not just a phase. There is still some upfront work required, but the more that is done upfront the more there is an opportunity to waste time designing solutions that don’t work or focussing on activities that don’t add value.

    The big challenge is figuring out what the least amount of work that needs to be done upfront before starting to building something that can be tested and learnt from.

  5. ben b permalink
    May 13, 2014 2:20 am

    Wotcha Ben. And so it came to pass… I’m hearing and using it more often these days (and we are 3 years after the post now so shows your instincts were right :). Agree its a very useful concept.

    You have probably noticed but this idea of ‘figuring out what the least amount of work that needs to be done upfront before starting to building something that can be tested and learnt from’ is being called the MVP (Minimal Viable Product) by Lean proponents these days in a semantic recast of the term i.e. the minimal slice for learning, not launching.

    Good post sir.


  1. From Designer to Product Owner: The pleasures and pains of being given control of the product vision « Melbourne, as in the city.
  2. Adjusting to the Agile UX Workflow | coreDevX

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: