Design Debt: how it accumulates, and what it costs to repay

BCG’s research found that roughly 70% of digital transformations miss their objectives. In public and development programs the pattern is consistent enough to be predictable: the system was delivered but never adopted, the platform was deployed but not used, the investment was made and the project declared complete while nothing changed on the ground.

The cause is rarely the technology. It is that work belonging at the start of a program was compressed, deferred, or skipped — and that deferral carries a price. We call the accumulated price Design Debt.

Our approach defines the term briefly. This article is about the part that matters operationally: where the debt is actually incurred, why nobody sees it accumulating, and what it costs to repay once it is on the books.

It is not technical debt

The borrowing is deliberate, but the two are not the same thing. Technical debt is a shortcut taken inside a system that has already been designed — a workaround in the code, a schema that will need refactoring, a dependency someone will have to upgrade. It is bounded, usually documented, and the team that created it generally knows it exists.

Design Debt is incurred before the system exists. It sits in the decisions about what is being built, for whom, against which process, on whose data, and under whose authority. That makes it structural rather than local: you cannot refactor your way out of a solution built against a misunderstood problem. And unlike technical debt, it is rarely written down, because at the moment it is taken on it does not look like a shortcut. It looks like progress.

Where the debt is actually incurred

It is almost never one decision. It accumulates through a series of individually reasonable ones:

• Inception is compressed to fit a disbursement calendar rather than the complexity of the problem.
• Requirements are gathered from managers and project documents rather than from the people who will operate the system daily.
• A platform is selected before the requirement is understood, so the requirement is subsequently written to fit the platform.
• Integration is treated as a later phase rather than a design constraint, on the assumption that systems which must exchange data will somehow be able to.
• Governance — who approves what, who owns the data, who authorizes a change — is left to be “agreed during implementation”.
• Sustainability is scheduled as an annex to be written at handover, rather than as a requirement the design must satisfy.

Each of these is defensible in isolation, and each is usually taken under real pressure. The debt is the sum, not any single item.

Why it is invisible while it forms

Because every incentive in a program rewards visible motion. Discovery produces documents; development produces screens. A steering committee shown a working prototype in month three feels reassured, and a steering committee shown a stakeholder analysis in month three often feels the program is slow — even though the second is the one reducing risk.

Vendors have their own reason not to raise it. A firm that will build the system has little commercial interest in a long design phase that might conclude the system should be smaller, or bought rather than built, or not built at all. This is why we treat design as a formal, vendor-neutral phase, and why, where we supervise a build, we do not bid on it.

The interest

Design Debt compounds in three ways, and the compounding is what makes it expensive rather than merely inconvenient.

Rework multiplies with distance from the decision. A requirement corrected during design costs a conversation. Corrected during build, it costs a sprint and everything already built on top of it. Corrected after go-live, it costs a data migration, retraining, and a release cycle — with users watching.

Integration surprises surface at the worst moment. Interfaces that were never designed for are discovered late, by the team with the least authority to change either side of them. What would have been an architectural decision becomes a negotiation between two institutions mid-delivery.

Non-adoption is the most expensive outcome available. A system that does not match the real working process is not used. The investment has been spent in full and the benefit is zero — and because the system is technically live, the failure is often not recorded as one.

What early Design Debt looks like

It is detectable well before a build finishes, if you know what to look for. Any of the following, on a program that has already started development, is worth treating as a signal:

• Requirements documents revised more than twice without a corresponding change in scope.
• “We will confirm that during implementation” appearing against questions of data ownership, approval authority, or hosting.
• No named individual with the authority to approve a design decision — only committees that review.
• Acceptance criteria that describe features delivered rather than outcomes achieved.
• No agreement on who funds recurrent costs — hosting, licenses, support — after the program closes.
• Integration shown in a diagram but not written as a specification either side has agreed to.
• A pilot repeatedly extended rather than either scaled or stopped.

Repaying it without restarting

Programs carrying Design Debt rarely need to start again, and advising a restart is usually a way of avoiding the harder work. What they need is triage — establishing which decisions are still reversible and which are now load-bearing.

In practice that means three things. Establish an honest current state, including what has actually been built rather than what was planned. Separate the decisions that can still be revisited — screens, reports, workflow detail — from those that cannot be changed without significant cost, which is usually the data model, the integration architecture, and the hosting and security posture. Then re-baseline against the outcomes the program was funded to achieve, not the feature list it accumulated.

That work is uncomfortable, because it makes visible how much was assumed. It is still cheaper than continuing.

The cheapest correction is the earliest one

The most useful moment to address Design Debt is before it exists — while the terms of reference are still being drafted, and the scope, budget, and success measures are still open. A needs assessment or readiness assessment is often the entire first engagement, and it frequently changes the problem statement the program was about to commit to.

If a ToR is being drafted, that is the moment to talk. Start with a conversation.