Design Debt & UX Debt is Technical Debt

Hey! Let’s all work together, please.

Technical Debt is a term which captures sloppy code, unmaintainable architecture, clumsy user experience, cluttered visual layout, bloated feature-sets, etc.  My stance is that the term, Technical Debt, includes all the problems which occur when people defer professional discipline — regarding any/every technical practice such as product management, visual and UX design, or code.

I assert that the change we need to catalyze in the business community is larger than any one discipline and I am worried that I have seen an increase in blog articles in recent years about concepts like “Design Debt”, “UX Debt”, “Experience Debt” — these articles unfortunately are not helping and have served only to divide the community. They are divisive, not because we shouldn’t be discussing the discreet facets in which Technical Debt can manifest, but because authors often take a decidedly combative approach in their writing.  Take these phrases for example:

  • “Product Design Debt Versus Technical Debt” written by Andrew Chen
  • “User Experience Debt: Technical debt is only half the battle” written by Clinton Christian
  • “Design debt is more dangerous because…” written by James Engwall.

I agree with Andrew Chen that Product Design Debt is a problem — I just don’t like that he chose to impose a dichotomy where there is none.  Why must he argue one “versus” another?  Clinton Christian has implied that we’re in a “battle”.  James Engwall has compared the “danger” of Design Debt relative to Technical Debt.  These words are damaging, I argue, because they divert attention to symptoms and away from root causes.

The root cause of Technical Debt is that people forget this simple principle of the Agile Manifesto: “Continuous attention to technical excellence and good design enhances agility.”

The root solution to Technical Debt — all of its forms — is to help business leaders realize there is a difference between “incremental” development and “iterative” development so they may understand the ROI of refactoring.  No technical expert should ever have to justify the business case for feature-pruning, refreshing a user interface, refactoring code, prioritizing defects.  Every business leader should trust that their technical staff are disciplined and excellent.

Yes, please blog about UX Debt and Product Development Debt, etc.  But please do so in a way that encourages cohesion and unity within the Product Development community.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

2 thoughts on “Design Debt & UX Debt is Technical Debt”

  1. Many agile practices are dismissive of any upfront design activity, and as such are based on starting every project with a massive design debt. They steadfastly refuse to do spend any upfront time to think about the system, the mental models, etc.. In this way they institutionalise design debt for any project that is not trivial.

    This is the main reason they don’t like the distinction between design debt and technical debt. It highlights the weakness of their practice.

    Whether you like it or not, design *is not* construction. They are both necessary and they require very different skills. Therefore a design debt exists as well as a technical debt.
    See for example git, that for historical reasons due to how it came about, is both fantastic from a technical point of view, and awful from a design point of view.

    1. Hello RJ, thank you for your comments.

      I think you’ve painted “they” with a very wide brush yet there certainly are examples in real life that validate the stereotype you’ve described.

      Perhaps, for the sake of our dialogue, it will help that I explain that I consider design to be both an art and a technical practice (and profession). To compare other professions, I believe musical composition is an art and a technical practice; architecture, storytelling, magic are art forms and technical practices; writing code is an art and a technical practice. When professional discipline in any technical field of practice (design included) is deferred or negated, then technical debt is the consequence.

      I wonder, do you consider design to be an art as well as a technical practice?

Leave a Reply

Your email address will not be published. Required fields are marked *