Design Debt.

Design debt rarely comes from a single bad decision but from many reasonable ones. A campaign page quickly needs a new button style. A developer rebuilds a form because the existing one does not fit. A new feature gets its own pattern for notifications. Each deviation is small on its own, but after two years there are five shades of blue, four button sizes, three kinds of error message and no shared understanding of what actually applies.

The term deliberately borrows from technical debt but describes a different layer. Technical debt sits in the code and mainly affects the development team: changes become slower and more error-prone. Design debt sits in the interface and affects users first: identical things look different, different things look the same, and operation has to be relearned at every turn. The two are often linked, because inconsistent design usually also means duplicate code.

The costs are hard to quantify but easy to observe. New pages take longer because each time someone debates which pattern applies. Errors pile up because changes to a button style do not take effect everywhere. Accessibility can hardly be enforced when colours and components are not defined centrally. And users lose trust when operation changes from page to page. Design debt becomes measurable, for example, in usability testing when people hesitate at points that work without trouble elsewhere on the website.

Design debt is paid down with the same means that prevent it: a design system with centrally defined design tokens for colours, spacing and type, reusable components following the principle of atomic design and clear rules on who may introduce new patterns. A complete rebuild is rarely needed; an inventory followed by step-by-step clean-up is usually enough. How we design consistent interfaces is described on the page UX agency Zurich.