Design for the review, not for the answer

A feature generates a draft in two seconds. The person reads it, checks two details against another system, decides the tone is wrong, edits it, and sends. Four minutes. The old way took six.

The model is impressive and the product saves two minutes. Whether it is worth building depends entirely on that second number, and almost nobody designs for it.

Accuracy is not the product metric

Accuracy determines how often review is easy. Review time determines whether the feature is worth using at all, and the two come apart in ways that surprise teams.

A system that is right ninety per cent of the time but whose output takes three minutes to verify saves less than one that is right seventy per cent of the time and can be checked in fifteen seconds. Verification cost is the thing users actually experience, and it is a design property rather than a model property.

What makes review slow

Nothing to check against. The answer appears with no indication of what it was based on, so verification means going somewhere else. This is the single largest cost and the easiest to fix.

Uniform confidence. Everything is presented in the same assured tone, so the user must check everything at the same depth. A system that flagged its own two uncertain fields would let somebody skim the rest.

Changes are invisible. A rewritten document with no diff forces a full reread. Showing what changed converts a three-minute task into a ten-second one.

Correction is expensive. If fixing one wrong field means redoing the whole thing, users stop correcting and start rejecting, and the feature loses its value quietly.

No memory. The same correction, every time, teaches the user that the system is not listening and that their effort is wasted.

Designing for the fast path

Put the evidence next to the claim. The source passage, the record, the previous invoice — one click, ideally zero. Users trust systems that show their working, and more importantly they check them faster.

Make uncertainty structural, not numerical. Not a percentage; the specific fields the system was unsure about, marked. Percentages are read as precision and almost never mean what they appear to mean.

Show the delta. Where the system modified something, show what it modified.

Make partial acceptance cheap. Accept four fields, correct one. Whole-output accept-or-reject forces users into a decision that is coarser than their actual judgement.

Let refusal be a good outcome. A system that says it does not know, and says why, is faster to work with than one that produces a plausible answer that has to be caught.

Measure it from the first prototype

Time the review. Put a real user in front of realistic output — including wrong output — and measure how long confirming or correcting takes, then compare with the current way of working.

That number is the business case. It is measurable in week one, before any engineering budget is committed, and it frequently changes what gets built.

It is the number an AI-native apps design engagement is organised around, because a feature that generates in two seconds and takes four minutes to trust has not automated anything — it has moved the work and made it harder to see.