Most product design is organised around the value of being right.
We design for the best version of the journey: the user who understands, chooses well, activates, returns. We measure the upside and optimise toward it. The interface is tuned for the moment things go well. The moments they go badly are handled later, if at all, as an error state added near the end, an empty screen, a message that says something went wrong.
For most products this is a reasonable bet. A mistake is small and recoverable. Someone mistypes a search, picks the wrong filter, abandons a basket, and nothing of consequence follows. The worst case is mild friction.
Some products do not get to make that bet.
Consider an ordinary screen from a clinical trial: a patient reporting how they feel. The difference between no symptom, not sure, and left unanswered carries the weight of the study. One is an absence of symptoms, one is uncertainty, and one is missing evidence. A layout that blurs them produces a dataset that looks complete and isn’t. Nobody is harmed in the moment. The screen looks fine. The consequence arrives later, quietly, when the data says something the study cannot honestly support.
That is the register some products operate in, where the dominant fact is the cost of being wrong. In that register the design problem inverts. The work becomes making the worst case legible, survivable, and recoverable.
I think of this as designing for consequence.
What moves when consequence leads
When the cost of being wrong is high, the centre of the work shifts.
The ambiguous case, the over-trusted case, the case where a tired person at the end of a long shift misreads a screen: these become the substance of the design. In consequential systems the failure modes are the product. The question changes from how to make the good outcome more likely to what happens when this is wrong, and whether the person knows in time to do something about it.
This reorders almost everything. It changes what goes on the screen and what is deliberately left off, how much certainty the interface is allowed to project, and where a flow is slowed down on purpose. A product designed for consequence is often quieter and more careful than one designed for delight, and the restraint is the design. The friction you remove for speed is sometimes the friction that was protecting someone.
Where the instinct comes from
I learned this designing systems for clinical trials and patient research, where being wrong has a patient at the other end of it.
In that world a field is part of the evidence, a timestamp may later have to explain what happened, and an instruction can sit between a patient in discomfort and the thing they were trying to report. The work carries requirements most software never meets: traceability, reliability, comprehension under stress, a record of who knew what and when. These requirements exist because someone has to be able to reconstruct what happened.
Designing there develops particular instincts. You design the error case before the success case. You make the system’s confidence legible, so a person can tell a result it is sure of from one it is guessing at. You preserve the override, because the moment a person most needs to disagree with the system is often the moment the system is most likely to be wrong. All of it is ordinary design discipline, applied where the stakes demand it.
For a long time those stakes were a niche concern. Healthcare, aviation, finance, and safety-critical systems had to think this way. Mainstream digital product culture mostly did not, because most digital products did not need to. Human factors, medical-device usability, and resilience engineering are deep traditions, and they have lived at the edges of how consumer and SaaS teams are trained, which is around growth, activation, and the upside.
That boundary is now dissolving, because products are increasingly able to act.
Why this is becoming general
When a product can generate, recommend, decide, or do something on a person’s behalf, it inherits the question regulated environments have lived with for decades: what happens when it is wrong, and does the person know?
A tool that drafts the message, approves the expense, summarises the case, flags the risk, or suggests the diagnosis is a participant in the work. Its mistakes propagate, and its confidence is a different thing from its accuracy. Many products are now arriving at a problem healthcare has had to work with for years: a system’s mistake can travel further than the screen where it began.
A small discipline
Designing for consequence mostly means giving up a few comfortable defaults. Five hold up across very different products.
Design the failure mode first. Failure is where the product’s real promises are tested, so it should get your first and clearest thinking.
Make uncertainty visible. The interface should project only as much certainty as the system has earned. A confident screen on top of a shaky result is an overclaim the person will believe.
Preserve human disagreement. In consequential systems override is a core path, and it deserves the best design in the product.
Slow down the right moments. Some friction is protection you would regret removing.
Make recovery inspectable. When something goes wrong, people need to reconstruct what happened: who changed what, when, and what was known at the time.
Interfaces make claims
Evidence work meets the same problem in another form, where a metric without a clear claim is a number waiting to be overinterpreted. Interfaces carry claims too.
Every screen implies this is true, this is safe, you can rely on this. Most of the time the claim is harmless, because the cost of it being wrong is small. As products take on the ability to act, the claims get larger, and so does the cost of overstating them. Designing for consequence is, in large part, the discipline of making sure the interface claims only what the system can support.
Holding both
The value of being right and the cost of being wrong belong in the same product. The best products make the good outcome more likely and the bad outcome visible and recoverable. Optimising only for the upside produces products that are delightful right up until the moment they quietly aren’t.
Most teams are fluent in the first half. The second is usually under-designed, and it is starting to matter in places that once got to ignore it. As more products gain the capacity to act, more of them become products where being wrong has consequences, and the open question is whether their teams know how to design for that.
These instincts were worked out in fields that needed them long before digital product teams did: the study of human error, after Reason, and resilience engineering, in Hollnagel, Woods and Leveson, both of which treat failure as something to design for; the use, misuse and disuse of automation, in Parasuraman and Riley, and calibrated trust, in Lee and See, which together describe the over-trusted case; and IEC 62366, the usability engineering standard for medical devices, which formalises designing for use error.
My addition is narrower. Products able to act are carrying this register into mainstream product work, and the certainty an interface projects is where it shows first.