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 is not a data-quality nicety. 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 now says something the study cannot honestly support.
That is the register some products operate in, where the dominant fact is not the value of being right but 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 happy path stops being where the effort concentrates. The ambiguous case, the over-trusted case, the case where a tired person at the end of a long shift misreads a screen: these stop being edge cases and become the substance of the design. In consequential systems the failure modes are the product. The question changes from how do we make the good outcome more likely to what happens when this is wrong, and does the person know 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 that restraint is the design, not a failure of it. 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 is not a metaphor.
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, and the consequences of failing to are real.
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. None of it is exotic. It is ordinary design discipline applied where the stakes are high enough to 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. There are deep traditions here, including human factors, medical-device usability, and resilience engineering, but they have lived at the edges of how consumer and SaaS product teams are trained to work, which is around growth, activation, and the upside.
That boundary is now dissolving, and the reason is that 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 no longer a neutral surface a user acts through. It is a participant whose mistakes propagate, and whose confidence is not the same thing as its accuracy. Many products are now arriving at a problem healthcare has been forced to work with for years: what to do when a system’s mistake can travel further than the screen where it began.
A small discipline
Designing for consequence is mostly the refusal of 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 not project more certainty than the system has earned. A confident screen on top of a shaky result is an overclaim the person will believe.
Preserve human disagreement. Override is not an escape hatch for power users. In consequential systems it 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
This is the same problem that appears in evidence work: a metric without a clear claim is just a number waiting to be overinterpreted. Interfaces have the same problem.
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 the cost of overstating them stops being small. Designing for consequence is, in large part, the discipline of making sure the interface only claims what the system can actually support.
Holding both
The value of being right and the cost of being wrong are not opponents. The best products hold both. They make the good outcome more likely and make 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. The question stops being whether a team should design for that, and becomes whether they know how.