The part that doesn’t get cheaper

Two waves#

The separation of ideation from implementation is the normal evolution of a knowledge industry. It happened to architecture, to fashion, to film. In software it has happened twice.

The first wave was cheaper labor: tight specs handed to lower-cost teams, long turnaround, little iteration, no design judgment expected on the building side. The second wave is automation. Execution gets cheap, small teams iterate fast, and the bottleneck moves upstream to whoever decides what should exist.

What the machines are bad at#

Agents write code well and implement against a spec well. They struggle with ambiguity. They don’t bring judgment, domain knowledge, or a relationship with the people who will use the thing.

Which means the half of the work that’s holding its value is the half that resolves an under-specified corner using intent, precedent and knowledge of the customer. Good design isn’t automated by this shift. It’s amplified by it.

The seam this describes#

There are two seams in any product organization where complexity can be passed along instead of absorbed. Outward, from the product to the person using it. Backward, from whoever is building to whoever set the intent.

The first seam is what the complexity piece is about. This is the second one, and the principle turns out to be symmetric: when an under-specified detail comes back as a question rather than as a proposal, the cost has moved upstream in the same way a settings screen moves it downstream. Both are worth noticing.

What closing it looks like#

The difference isn’t politeness. It’s who holds the next decision.

• Instead of “if this is unchecked, how does the user select the source?” — “we’re making it required, because the feature is meaningless without a source. Confirm?”
• Instead of “which pages does this apply to?” — “we inferred the rule from where the pattern already appears, and we will apply it there unless you say otherwise.”
• Instead of “what should the default be?” — “we’re defaulting to the modal case, which the data says is 85 percent of accounts.”

Especially the defaults#

Choosing the default is the design decision that most shapes the experience, since most people never change it. Of everything that gets handed across this seam, that’s the one I’d keep.

Sources

• Marty Cagan, Empowered Product Teams
• Fred Brooks, No Silver Bullet (1986)
• Joel Spolsky, Choices (2000)
• The Linear Method
• Nielsen, The Power of Defaults