Every scaling product reaches a point where the work starts pulling in two directions. Customers ask for features. Sales needs confidence in the roadmap. Leadership wants visible momentum. Engineering needs clear scope. Meanwhile, design can see the product beginning to bend under its own weight.
Tables behave differently across screens. Statuses mean slightly different things in different workflows. Forms are inconsistent. Settings expand without a clear information architecture. Users ask for what sound like small changes, but those requests are often symptoms of something deeper.
That is the design-debt trap.
Nobody in this situation is really wrong. The customer may need the feature. The business may need to keep selling. Engineering needs a buildable scope. Design may be right that the product is becoming harder to use and harder to scale. The real challenge is not choosing between shipping features and fixing design debt. It is deciding when design debt has become expensive enough that ignoring it will slow future delivery, weaken the experience or make the product harder to grow.
I ran into this tension regularly while working on the Aerios carrier marketplace redesign. Aerios supports charter teams across requests, quotes, bookings, invoices, contracts, documents, integrations and operational activity. The customer requirements were real and commercially important, so the product needed to move quickly. But as capability increased, the need for stronger foundations became impossible to ignore.
Design debt is not the opposite of delivery
Teams often treat design debt as if it competes with delivery: features create value, while debt work slows things down. I think that is the wrong model.
Design debt is part of the cost of delivery. If there is no reusable table pattern, every data-heavy feature takes longer to design, build and QA. If the status model is inconsistent, every workflow that depends on status becomes harder to understand. If documents, records and actions are not clearly connected, every new document feature asks users to reconstruct more context for themselves.
It is accumulated decision debt: the cost of interaction, workflow and system decisions that were reasonably deferred because the team needed to ship. Over time, it appears everywhere. Designers recreate patterns. Engineers ask more clarification questions. QA finds more edge cases. Users become less confident because familiar actions do not always behave in familiar ways.
Nielsen Norman Group’s design-system overview is useful because it frames systems as reusable components, patterns and standards for managing design at scale. In complex B2B products, that is not just a design concern. It is commercial infrastructure: solve a recurring problem once, reuse it confidently, and future work becomes safer and faster.
What the debt looked like at Aerios
Aerios is not a simple product with one linear journey. A commercial movement may begin as a request, become a quote, move through negotiation into a booking, generate documents, trigger invoicing, require contract activity and eventually support operational handover.
That means supporting dense tables, complex forms, formula-based pricing, manual overrides, aircraft data, booking states, document statuses, customer records, team and profile configuration, integrations, notifications, historical references and auditability. A busy feature roadmap was natural. The issue was that the UX debt was becoming more expensive at the same time.
Similar workflows used slightly different layouts. Related records did not always feel connected. Quote, booking and document journeys could become more fragmented than they needed to be. Settings were expanding faster than the underlying structure. Design and engineering were repeatedly solving versions of the same interface problem from scratch.
That did not mean the product was broken. It meant Aerios had reached a familiar point in a product’s life: early speed comes from improvisation; sustainable speed comes from systems.
Why “we’ll clean it up later” becomes expensive
Sometimes deferring debt is absolutely right. Not every inconsistent icon deserves a planning meeting, and a team that makes every imperfection urgent will struggle to ship anything useful. The issue begins when the same weak pattern affects several roadmap items.
At Aerios, apparently separate work increasingly depended on the same unresolved foundations. Contract generation needed robust document status patterns. Currency conversion needed clearer quote-line and value-display behaviour. Notifications depended on reliable events and status logic. Booking improvements needed a clearer relationship between quotes, bookings and documents. Team and profile configuration needed a stronger settings model.
On the surface, those were separate features. Underneath, they were different expressions of the same system. Solving each in isolation might have been quick in the moment, but it would have made the next feature more complex. That is the trap: the product keeps moving, while each movement makes the next one harder.
Ask the right prioritisation question
The question is not, “Should we prioritise the feature or the design debt?” A better question is: is this debt now blocking our ability to deliver valuable features safely, consistently and repeatedly?
That framing turns a matter of preference into product economics. A messy component is not urgent because a designer dislikes it. It becomes urgent when it slows delivery, causes user confusion, increases support effort, creates QA risk or makes future roadmap work more expensive.
Likewise, a design-system pattern is not valuable because it looks neat in Figma. It is valuable when it reduces the cost and risk of future product work.
Use a matrix to make the trade-offs visible
A prioritisation matrix does not make decisions for a team. It improves the conversation around judgement. Without a shared model, prioritisation becomes a contest of urgency, seniority or volume: sales wants the customer feature, engineering wants technical clarity, design wants system quality, and leadership wants speed. All are valid perspectives, but each is partial.
Frameworks such as RICE help teams consider reach, impact, confidence and effort. WSJF adds cost of delay relative to job size. For design debt, I add two questions:
User and business impact: does this affect adoption, trust, operational accuracy, customer confidence or day-to-day usability?
System leverage: will fixing it make future work faster, safer or easier across more than one product area?
The strongest candidates for action are high on both. They solve a current customer or business problem and reduce the cost of future delivery.
A practical way to compare feature work and debt
I would assess a piece of work across six dimensions: user impact, business value, delivery drag, reuse potential, risk if delayed and effort. The scoring itself is less important than the discussion it creates.
A customer request may have high user impact and business value, with low reuse potential. It may be right to build quickly.
A shared table pattern may have modest immediate visibility but high delivery drag and reuse potential. If multiple upcoming features need tables, filters or bulk actions, it becomes enabling work.
A visual polish issue with little effect on trust, usability or future delivery can wait.
A status-model redesign may be significant effort, but it deserves roadmap attention if it affects bookings, documents, notifications and contracts.
This gives design a more useful argument than “we need more time”. It becomes: “This system issue affects three roadmap items, adds delivery ambiguity and makes the workflow harder to understand. Here is the smallest useful improvement we can make while delivering the feature.”
The best compromise is often fixing the system through the feature
In most organisations, the answer is not to halt the roadmap and spend months cleaning up the design system. Commercial reality will rightly object. The better approach is usually to fix the system through the feature.
When a new capability needs a table, improve the shared table pattern. When it needs a status, improve the status model. When it needs a document list, define a reusable related-documents pattern. When it needs settings, improve the settings information architecture. When it needs overrides, define source, edited and overridden states properly.
At Aerios, this was a powerful way to create momentum. The feature created the need; the system work created the leverage. Improvements were attached to live customer value, so they were easier to justify, test and adopt than an abstract clean-up project.
Aerios example: contract generation
A simple feature description might read: “Allow a user to generate a contract from a booking and send it to DocuSign.” It sounds contained. It is not.
It raises product-level questions: what is the document lifecycle? Where does the contract sit in relation to the quote and booking? What data is inherited? What can be edited? What happens when the contract is signed, declined or voided? What does the user see if the signature service fails? Who gets notified? Where is the signed document stored? Can the same pattern support invoices later?
If the team designs only the contract feature, it can ship quickly but risks becoming a one-off workflow. If it defines the underlying document pattern at the same time, the feature still ships and the product gains reusable infrastructure for contracts, invoices, quote documents and future document types. The skill is not turning every feature into a grand redesign; it is identifying the smallest system improvement that creates meaningful leverage.
Know which kind of debt you are dealing with
I find five categories helpful:
Visual debt: inconsistent spacing, colour, type, icons or layout.
Interaction debt: similar actions behave differently, increasing cognitive load and error.
Workflow debt: the journey does not match how users think about their work, so they create workarounds.
System debt: recurring behaviours lack reusable patterns, making each feature more expensive.
Conceptual debt: the product has not clearly defined core objects, relationships, lifecycle states or mental model.
The deepest and most consequential debt in the Aerios work was system and conceptual debt: strengthening the way requests, quotes, bookings, invoices and documents related to one another. Without that, every new feature risked adding more fragmentation.
Measure whether the investment worked
If design debt is prioritised, measure it. Otherwise it can look like an internal housekeeping exercise rather than a product investment. Depending on the problem, useful signals include design cycle time, engineering clarification questions, QA issues, component reuse, the delivery time for related roadmap work, task success, support questions and usability-test results.
For operational products, I also watch context recovery: the effort users spend working out where they are, what has happened and what they can do next. When people have to click through tabs, compare references, ask colleagues or check external documents to understand their work, the product is making them recover context manually. Good UX reduces that burden.
Make room for design debt deliberately
A practical way to stop the constant conflict is to create a design-debt budget. Most capacity can go to customer features, with a defined portion for enabling system work and a smaller portion for quality improvements. The split will depend on the product stage, but the principle is stable: quality work should be planned, not begged for.
That does not mean treating all debt as equal. A local spacing inconsistency can be fixed locally. A workflow problem should be fixed with that workflow. A structural issue that affects multiple roadmap items deserves system-level attention. This is the smallest useful rule I have found for removing some subjectivity from the debate.
The lasting Aerios lesson
The feature-versus-quality argument cannot be won by talking about design quality in the abstract. The more effective approach is to show how debt affects delivery, customer experience, roadmap confidence and future product economics.
At Aerios, that meant mapping repeated UX issues across product areas, identifying the foundations blocking multiple roadmap items, creating reusable patterns rather than one-off fixes, and connecting that system work directly to active customer features. The aim was never to slow the product down. It was to create enough structure to keep moving quickly without making the product harder to use and harder to build.
Design debt is not a moral failure. It is usually evidence that a product has been learning quickly and adapting to real demand. But unmanaged debt eventually becomes a growth constraint. In complex products, design quality is not the opposite of speed. It is what makes sustainable speed possible.
