Prototypes now cost an afternoon, so the front of the Double Diamond just lost its job

For twenty years, your process assumed one thing: building was the risky, expensive part. Research was cheap, so you front-loaded it. That price just collapsed. A working prototype used to cost a two-week sprint. Now it costs a prompt and an afternoon. When the cost of building drops that far, the whole shape of your process is running on old math. Let me catch you up.

The deep cut

• Reprice the process when the inputs reprice. The Double Diamond assumed a costly build, and Stanford HAI clocked model queries falling 280-fold in 18 months.
• Judgment is the scarce resource, not making. METR found generation got fast while the cost moved to reviewing output.
• AI speeds exploration, not the watching. A healthcare designer learned AI made six pain-data views but not which one a clinician reads mid-consult.

The diamond that lost its front half

The Double Diamond and Design Thinking were built for disciplines where a wrong build was a one-way door. Herbert Simon wrote about engineering, Rolf Faste taught mechanical engineers, Peter Rowe wrote about buildings. None of them built software. The method inherited their constraint: spend cheap research hours to protect costly build hours.

Your research repositories, insight decks, and journey maps were receipts against that build cost. They were insurance policies. When a working prototype costs an afternoon, the front diamond loses its main job. It shrinks to a one-page brief: point the work in a direction, say what counts as success, and move on.

Divergence didn't die, it moved

The strongest teams still explore. They just do it later, with working things. Among Figma survey respondents whose AI projects met expectations, 60% had explored multiple approaches, against 39% of those whose projects fell short. Building five versions now beats mapping twenty on a wall.

So the ceremonies shift. The Crazy Eights round and the sticky-note wall were cheap machines for making options in a room, built when the alternative was asking engineering. Keep the workshop for the one thing tools cannot do: getting eleven people to agree on a problem. Run it when you need agreement, not when you need ideas.

The cost moved to knowing what's good

Making cheap options is easy now. Picking the right one is the hard part. METR ran a controlled trial with experienced developers who forecast AI would cut their time 24%. Measured, tasks took 19% longer, because the cost sat in reviewing output, not producing it. Call it the judgment budget: the share of your team's capacity spent deciding what is good.

A healthcare designer put it plainly. AI can produce six representations of pain data, but it cannot tell you which one a clinician will understand mid-consultation. Twenty options with no standard to test them against does not produce twenty choices. It produces one, made by whatever the tool put on top.

Write the standard before you generate

Borrow the move engineers already made: write the test before the code. Set an outcome that holds still, one customer behavior you want to move for a quarter. Then let generation run wide and cheap. Then hold it against a written standard of good, agreed before anything gets made.

History rhymes here. Patrick Neeman traces five eras of UX, each solving the last era's problem while creating fresh blind spots. Reference matters just as much in the output. As one designer showed, a farmers-market prompt with a named reference beats the generic one every time. The tool did not change. The person operating it did.

One caveat, and it's not small

Where the build is still expensive and hard to reverse, the old order holds. Medical devices, payments rails, anything a regulator approves. A wrong problem statement there is a recall, not a rewrite. Hardware needs the whole first diamond because a mold cannot be rolled back.

But teams over-claim this. They reach for the regulated-industry argument because their work feels serious. Seriousness is not the same as irreversibility. The test is narrow: if you can undo it inside a day, you are not in the front-load case, whatever your industry is called.

Three questions for your team

• What is our real judgment budget right now, and who on the team decides which of the twenty options ships?
• For our next project, can we write the standard of good before anyone generates a single screen?
• Which of our current work is truly a one-way door, and which are we protecting with front-loaded research it no longer needs?