News & Articles

On UXDebt: The Nature and Nuance in Product Design


“In the beginner’s mind there are many possibilities, but in the expert’s there are few” – Zen Saying

Recently within the user experience design community, there has been some discussion and questions regarding the term “UX Debt,” especially what it means; under what conditions it arises; and what strategies may be employed to understand and mitigate the risk of acquiring and retiring UX debt during the software development process, mostly within the context of [Agile] or [Lean] teams charged with delivering quality software.

Last week, in a conversation initiated by Jabe Bloom, he brought up the fact that most people were unaware of the original meaning of the term Technical Debt. He went on to explain under what conditions debt arose, and the relationship between technical debt and failure demand. This article is my attempt to synthesize some of the ideas he covered in those conversations and how they might apply to the notion of ux debt. As Jabe would say, “Any violence done here is unintentional and entirely my fault…”

“No one gets angry at a mathematician or a physicist whom he or she doesn’t understand, or at someone who speaks a foreign language, but rather at someone who tampers with your own language.” – Jacques Derrida

I think that for the most part, the generally understood definition of UX debt is only telling part of the story, but I won’t go so far as to say it’s wrong. (I will clarify this later.)  Given its etymological roots in the term Technical Debt, I don’t think that is the fault of those ux practitioners who’ve sought to employ the term “ux debt” in the fashion that is currently gaining some traction.

If we return to the origin of the term, first explicated by Ward Cunningham, we must re-state the definition, because if the agile and lean [communities] don’t have a shared understanding of what the term means, then any derived term suffers a ‘fruit of the poisonous tree’ problem.

It is natural, however, to understand why the definition has drifted since Cunningham chose to employ the metaphor – but I think that metaphors by their nature have a greater semiotic distance between signifier and signified and through natural semantic drift, the word can take on new meanings never intended by the author. This is not to say that some of the new definitions of technical debt are dead wrong – merely that they have become models which, while not true, can at least be useful.

Different ontologies, or systems understood in the context of their underlying causality, require different approaches to epistemology: the way that we know things and thus the way that we make decisions. This apparent simple concept is revolutionary in its nature; most approaches to management science assume a single ontology, namely that of order.

~ Dave Snowden, Strategy in the context of uncertainty.

So how is the term Technical Debt currently used and how does that differ from the way the Cunningham intended when he employed the debt metaphor?

One well-written explication of two types of technical debt comes from Simon Baker in the post, “Inevitable and Avoidable Rework,” in which he states,

“Without really thinking about it until now, I’ve been seeing two types of technical debt. The first is the quick solution implemented with dirty code. I consider this to be irresponsible. That’s not to say I won’t do it, just that if I decide I should do it I make sure the necessary people understand the consequences and that it’s an irresponsible action to take.

The second is a natural byproduct of emergent design andYAGNI (yet) decisions. It’s the debt that surfaces when a system outgrows implementations resulting from previous decisions, which were the right ones to make at the time based on the information available (because they did not compromise quality or the health of the code in any way).”

This is different from the description of two types of technical debt that Steve McConnell writes about in this post on 10x Software Development,

“The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future.”

As we can see, there are now three different definitions of technical debt. The first kind of technical debt arises in an ordered domain when the development team or engineer understands the nature of the problem, and presumably understands how to build the software, but through incompetence, or sloppiness, writes bad code which I will label O.1. This is avoidable technical debt that the team accrues with no strategic benefit.

The second type of technical debt also occurs in an ordered domain when the engineer understands the nature of the problem, as well as how to design and build a solution that solves for that problem, but for various strategic reasons, decides to take shortcuts – we can refer to this as O.2 to distinguish it from the former. This can be for a number of reasons, for instance, when there is some uncertainty in the marketplace as to whether the given feature is actually desirable by the target customer, or because of market pressure to release something fast and gain a foothold on the competition, or resource constraints which prevent the team or engineer from building the most elegant solution.

These two mentioned above are what have become the common ways in which most people are using technical debt, and the second definition described above is the one that has insinuated its way into the LeanUX community. This definition isn’t wrong per se, but it only addresses the kinds of ux debt that arise under one set of conditions within one ontology (this is where the reference to Snowden above starts to make sense). To understand, and thus mitigate ux debt requires that we first understand which context we are confronted with, what constraints we have, and what kinds of debt we are incurring.

The third type of debt described above by Baker is the one that very few people are aware of, which is ironic since it is at least the closest to Ward Cunningham’s original definition when he leveraged the debt metaphor which Jabe brought to my attention. [This kind] “is a natural byproduct of emergent design and YAGNI(yet) decisions.” This I have labeled U1. It might be useful at this point to watch Cunningham’s explanation of debt right now before we continue any further.

As you can see, Cunningham was never referring to technical debt as the delta that arises between what the planned design for a product might be and what is actually delivered in an ordered and well-understood domain because of either poor design/engineering or because of choices to cut corners to get software out the door as quickly as possible in the situation where you already know what a good design might be. I think this nuanced difference is key. Cunningham states in this video that,

The explanation I gave to my boss is that [if] we failed to make our program to align with what we then understood to be the proper way to think about our financial objects, then we would continually stumble over that disagreement and that would slow us down which is like paying interest on a loan. With borrowed money you can do something sooner than you might otherwise, but until you pay back that money, you’ll be paying interest. I thought borrowing money was a good idea… i thought that rushing software out the door to get some experience with it was a good idea but that of course you would eventually go back and as you learned things about the software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

He is describing a new domain where you are designing and building a product in an unknown space – where the nature of the problem and the potential solutions are not yet known to you, and only through writing code can you uncover the nature of the problem as well as find out whether a potential solution actually solves for that problem.

Returning to Snowden, this is problem space in the complex domain where you need to probe, sense, respond. There are no best practices in this particular situation, and it absolutely makes sense to take on the debt to gain the learnings so that you can build a better solution that solves the problem. What it also means is that once you are finished building and releasing the software, only then do you have enough of an understanding to see the debt that you have created.

In essence, you have developed a language to understand the domain better, so that you can go back and refactor the application to now reflect your better understanding. It is this example that is most interesting, and also a strategic use of borrowing — but the kind of borrowing that you can’t start paying the interest on until you have released the product. The debt, then, is the delta between your current learnings as to the best way to implement the solution based on new language, and the way that you actually implemented the design.

In exploring this over the past few days, I have come to believe it is worth reflecting upon why Snowden’s Cynefin model is essential to understanding debt, either technical or user experience. The first two definitions above make an implicit assumption that Snowden refers to when he argues:

The dominant ideology in organizations assumes that in any system, there are underlying relationships between cause and effect. These relationships can be discovered or approximated in such a way that the future can be planned on the basis of desired outcomes. Examples include the three-year plan, the commission investigating past failures and scenario planning.

The objective is to control the future on the basis of an understanding of the past. In effect, it is assumed that there is a right answer and a failure to achieve the desired outcome is a failure of analysis, data capture/distribution or execution.

Clearly, then, when you are in an ordered domain – where you can understand the nature of the problem space as well as the ‘right answer’ to solve for it, then failure to achieve could be a result of failure to execute, or in the second type of debt described above, an understanding of the trade-offs between the right answer and a strategic decision to take a shortcut, understanding that interest will need to be paid later in terms of refactoring the code or redesigning the user experience. But this is only one of three possible ontologies. The other two which Snowden introduces are Chaos and Complexity.

The desire for order is understandable and has, historically, been contrasted with chaos as an “either-or” alternative – from the age-old battle of Zeus and the Titans to the acceptance of authoritarian government or the waterfall software development methodology.

Chaos in this sense is seen as the antithesis of order: total and absolute turbulence, without form and substance. The state of order provides structure and predictability and is the object of desire, while the state of chaos is to be avoided. In this context the function of strategy is to reduce the potential exposure to chaos by reducing uncertainty.

But we must also understand that, going back to Cunningham, there are other situations when you are dealing with an unordered ontological context, one in which you don’t understand the relationships between cause and effect, when the solution is emergent by trying various implementations. Snowden describes it best here,

Such (Complex Systems) systems are retrospectively coherent; that is to say that we can see a pattern of causality with the benefits of hindsight. However, future events do not repeat themselves except by accident. The reason for this is that order in complex systems is emergent in nature, arising from the interaction of many agents.

He goes on to explain that ‘emergent order is seen in nature, from crystal formation (Camazine et al 2001) to the flocking behavior of birds,” to the social interactions that happen on Yahoo bulletin boards or the Interaction Design Association. In this case the technical and user experience debt is of a different nature because you have no choice about borrowing . It’s a part of the discovery process, and you don’t even understand the nature or scope of the debt until you have released software into the world and learned from it. This also means that whatever you may have released could in fact solve for the customer problem without necessarily creating any failure demand – it’s simple that the debt represents the delta between what you now know to be the elegant way to implement the solution, or the most usable way to design the user experience, and the way that you actually did.

In closing, I would argue that when trying to understand either technical or ux debt, it is first important to classify the problem space being explored as well as potential solution sets into one of the three ontologies: order, chaos, or complexity. This can then inform your team’s different epistemological approaches to understanding the nature of the debt, and make a more reasoned decision as to how to first choose whether to take it on or not, and if you do choose to take on the debt, what impact that will have on future development efforts as well as the potential interest payments your team will be burdened with. One thing that Jabe makes clear, however, is that in the case of emergent design, debt (ux or technical) must be incurred, but you will not be able to understand what it is, nor will you have an ability to track it, until after you have released the software and learned through usability testing and quantitative analysis.