frontend
Tech Debt vs UX Debt: Spot the Difference
Thoughts from the intersection of code, craft, people, and progress.
They both hurt, but only one is invisible.
Technical debt gets tickets, estimates and concerned conversations about velocity. UX debt often sits quietly in the product making every task slightly harder for users, which is less visible but no less expensive.
Debt is a useful metaphor only when it leads to a useful decision. Naming a compromise is not enough; the team needs to know what it costs, when that cost will matter, and what signal should trigger repayment.
The answer is rarely a universal rule. It is a way of looking at the decision clearly enough to choose on purpose.
Consistency is a conversation
A design system is often described as a collection of components, which is true in the same way that a kitchen is a collection of cupboards. The useful part is how people use it together and what decisions it helps them avoid repeating.
The strongest systems make the preferred path the easy path. They explain intent, show real examples, expose sensible constraints and leave a clear route for exceptions. A component without that context is only a reusable shape.
Consistency should reduce decision fatigue, not reduce thought.
A practical way to start
A few questions help me decide what to do next:
- What problem are we actually trying to remove?
- Who will have to understand this after us?
- What evidence would make us change direction?
None of those questions produces an automatic answer. They do make the trade-offs visible, which is usually the point where a team can stop arguing from instinct and start making a decision together.
Good systems do not remove judgement. They preserve attention for the decisions that genuinely need it.
There will always be exceptions. The trick is to make them deliberate exceptions rather than habits nobody remembers choosing.