Design debt must be handled like engineering debt
Aliases: debt parity · same tracker · off-board debt · engineering-debt equal
What it is
Design debt has to enter the same work system as engineering debt: the same ticket type, the same capacity conversation, the same explicit status for “not this time”. Debt that lives only in a designer’s memo or a file comment does not exist at planning, and loses every time to whatever already sits on the board. Parity is not a nicer metaphor. It is occupying the same slots.
The unequal shape is familiar: engineering debt has an id, an estimate, someone saying at standup “we are not touching that file”; design debt is “we’ll swap the empty state later”, with no id, and later does not arrive.
Why it happens
Capacity is allocated inside the work system. Items that enter the tracker enter a comparison: features, defects, other people’s debt, one calendar. Items that cannot enter never compete; they lose before the door. If design debt is stored as comments in a design tool, the planning tool that actually assigns capacity cannot read it. A spoken consensus that “it matters equally” then coexists with a result in which it never took the field.
Parity also requires that “not handling this” be a visible status, not silence. When engineering debt is explicitly deferred, a card remains on the board and the next planning still sees it. Design debt that lives in memory cannot tell deferral from forgetting. An explicit deferral does not license forgetting; it makes forgetting step over a card that is still there.
Where it stops holding
Dissatisfaction inside a personal exploration file that was never delivered is not yet debt and should not enter the team tracker, or the tracker fills with undecided taste. Shared system surfaces (a component library, a global empty) belong on the shared tracker; an inconsistency a single feature can replace inside one iteration belongs on that feature’s board and need not be promoted to organisational debt. A small team that plans in one chat can still do parity by writing design debt and engineering debt in the same column of the same list, not in a document only design reads. An interface issue already tracked as engineering debt should not be cloned as a second “design debt” card — parity is one item, not two shadows.
Applying it
- File design debt as the same ticket type, in the same tracker, with a title that can be read aloud at planning, not as a link to a design comment.
- Compare design debt and engineering debt in the same capacity segment of planning; do not park design debt in a “when we have time” appendix.
- “Not this time” must be a tracker status that reappears by default at the next planning; it may not live only as a chat promise to come back.
- How to check: open last cycle’s planning board. Count design-debt tickets and engineering-debt tickets that entered the capacity talk. If design debt exists only as file comments and zero tickets took the field, parity failed. Pick one deferred design-debt item: if the tracker can no longer find it, deferral has already become disappearance.