The Curb-Cut Effect and the Marginal Cost of Building a Constraint In

A curb cut is a ramp cut into the edge of a sidewalk at a crossing. The requirement that produced it was narrow: a person in a wheelchair cannot climb a six-inch step, so the step must be replaced by a slope at the points where pedestrians cross. The observed consequence was wider. The same ramp is used by people pushing prams, wheeling luggage, pulling a delivery cart, riding a bicycle, and walking with a stick. A feature specified for a small group turned out to serve a large one, at no additional cost, because the cost had already been paid to satisfy the requirement.

That pattern is worth taking seriously as an engineering argument, because it is the argument that usually wins the budget conversation. It is also frequently overstated, and the overstatement damages the case. The effect is real but conditional, and the conditions are specific enough to state.

Where the marginal cost actually sits

The reason a constraint is cheap at design time is that the expensive part of an interface is not the pixels, it is the dependency graph. A layout decision constrains what a component can do; a component constrains what a page can do; a page constrains what a navigation model can do. Adding a constraint early means it propagates through decisions that have not been made yet. Adding it late means it must be satisfied by changing decisions that other decisions already depend on.

The cost curve therefore looks like a step function rather than a slope. While the design is still being decided, a constraint such as “no target smaller than a stated minimum” costs a design token and a review rule. Once the layout is built around a dense toolbar, the same constraint costs a re-layout of the toolbar, which costs a re-layout of the header, which costs a change to the information architecture that assumed the toolbar could hold everything. None of those later costs are about the constraint itself. They are about the rework of everything that assumed its absence.

cost of satisfying a constraint, by phase

  requirements   ▏
  layout         ▏▎
  component      ▏▎▎
  integration    ▏▎▎▎▎▎
  after release  ▏▎▎▎▎▎▎▎▎▎▎▎

The diagram is qualitative on purpose. The shape is the claim: the multiplier grows with the number of downstream decisions that encoded the assumption, not with the size of the requirement. This is also why retrofit accessibility work so often produces the wrong fix. A retrofit is constrained by everything already built, so it tends to produce a special path: a separate “accessible version”, a parallel route, a modal that duplicates content. The special path satisfies the letter of the requirement and creates a second thing to maintain, which is where the maintenance cost of accessibility work usually comes from.

What the reuse argument does and does not establish

The reuse argument says: build for the constraint, and the resulting capability serves users beyond the ones who motivated it. That claim holds when the capability is a property of the interface that others can use directly, and fails when the capability is a bespoke accommodation.

Directly reusable: enlarged targets, text that scales, content that reflows, state conveyed without colour, keyboard operability, captions, generous timeouts, clear error messages with a recovery action. Each of these is a property of the interface itself. Any user can benefit, and users do, in the situations described by the duration axis of constraints: a commuter on a moving train benefits from large targets exactly as a user with a tremor does.

Not directly reusable: a screen-reader-only alternative document, a phone number to call instead of using the form, a separate simplified mode reachable only through a settings page nobody visits. These are accommodations, and their benefit is confined to the people who find them. They are sometimes necessary, and they are always more expensive per user served, because the accommodation must be maintained in parallel with the main path and diverges from it over time.

The distinction gives a usable rule for design review. When a requirement is satisfied by changing a shared property of the interface, the reuse argument applies and the cost is amortized across every user. When it is satisfied by adding a parallel artifact, the argument does not apply, and the requirement should be re-examined: usually the parallel artifact is a symptom of a shared property that was too expensive to change, and the honest response is to say so rather than to bank a reuse benefit that will not arrive.

The benefit is not the justification

There is a failure mode in the reuse argument that is worth separating from the argument itself. If the case for a constraint rests on the number of people who will incidentally benefit, then a constraint whose beneficiaries are few and hard to count becomes hard to defend, and the defence collapses toward “this helps everyone”, which is a claim about marketing rather than about engineering.

The curb cut was justified by the people who needed it. The wider use was a discovered benefit, not the reason the ramp was built. In design terms: a requirement stands on the constraint it removes, and the reuse is a return on the cost, not the grounds for incurring it. Stated the other way round, the argument becomes a trap, because it invites the question “how many users does this actually help”, which is unanswerable in advance and which has a wrong answer built into it: the users who need the constraint are the ones for whom the alternative is not a degraded experience but no experience.

The practical consequence is that the requirement should be written as a bound, and the economics should be discussed separately as a scheduling matter. The bound is what the interface must accept. The schedule question is when to pay for it, and the answer is early, for the reason in the cost curve above.

Cases where widening costs real money

Honesty about the pattern requires the cases where it does not hold, and there are three that recur.

The first is when the widened capability changes the product’s core interaction. A drag-and-drop file manager is a good interaction for a precise pointer. Making it fully operable without a pointer is not a widening of an existing property; it is a second interaction model, with its own selection semantics, its own feedback, and its own state machine. The cost is a design and a maintenance burden, not a token. The reuse argument does not cover it, and pretending otherwise produces an estimate that will be wrong.

The second is when the constraint multiplies across a large surface. A single component with a stated minimum target size is cheap. Ten thousand instances of that component across an estate of screens is a programme, because each instance must be found, checked, and in some cases re-laid-out. The marginal cost per instance is small and the aggregate is not. This is the case where a design system pays for itself, because the constraint is applied at the definition rather than at the instance, which is the argument for encoding constraints in the system rather than in review.

The third is when the constraint conflicts with another constraint that is also being widened. A design that must support very large text and a design that must keep a control visible without scrolling will collide on a short viewport, and something has to give. The resolution is a priority order, and the priority order is a design decision that cannot be derived from the cost model. It has to be made, written down, and applied consistently.

Measuring the right thing

The measurement that supports this argument is not a count of users who benefit. It is a count of the decisions that would have to be revisited if the constraint were added later. That is a number a team can actually estimate: how many components encode the assumption, how many layouts depend on those components, how many downstream decisions depend on those layouts. A constraint that touches one token and no layout is cheap. A constraint that touches a navigation model is not, and knowing which one it is before the work starts is the whole value of the exercise.

The corollary is that the cheapest moment to evaluate a constraint is before the layout exists, when the answer is still “one token”. After the layout exists, the evaluation is a change proposal with a blast radius, and it competes with every other change proposal on the same terms. This is why the constraint inventory belongs in requirements rather than in a post-release audit, and why the capability list is worth producing before the first wireframe rather than after the first bug report.