Designing under uncertainty
You cannot guess better, but you can decide in a better order
Thesis
Here is the actual situation, most weeks. You are designing a screen. You have spoken to four people, two of whom were being polite. You do not know what the primary action is, you are not sure the object model is right, and something has to ship.
The standard advice at this point is to reduce the uncertainty: run research, test with users, validate. Good advice, frequently unavailable. Research costs time you may not have, and on a genuinely new product it often cannot resolve the question, because the thing you would need to observe does not exist yet.
So here is the alternative, which is not a substitute for research but works when research is not on offer.
Stop trying to make better decisions and start making them in a better order. Design decisions differ enormously in what they cost to undo. Copy is nearly free. Layout is cheap. Navigation is expensive. The object model is close to permanent. Under uncertainty the winning move is to spend your ignorance on the reversible decisions and defer the irreversible ones until something has taught you.
Most teams do the opposite. They settle the object model in week one, because it feels like the foundation, and then spend nine months arguing about copy.
Context
There is a distinction from economics that product work would benefit from importing. Frank Knight drew it in 1921: risk is a situation where you do not know the outcome but you know the distribution, and uncertainty is where you do not know the distribution either. Risk is a roulette wheel. Uncertainty is a new market.
Nearly every early product decision is Knightian uncertainty and nearly every early product process treats it as risk. Confidence estimates, weighted scoring frameworks, prioritisation matrices with numeric inputs: all of these assume a distribution you can approximate. When the distribution is unknown, the arithmetic launders a guess into a decision and hides the fact that it was a guess.
The consequence is not that teams are wrong more often. It is that they lose track of which of their beliefs were evidenced, and by month four the design rests on a stack of assumptions nobody remembers making.
Research
Knight, 1921, on risk versus uncertainty. The distinction above. Its practical value is diagnostic: before choosing a method, ask which situation you are in, because the methods that work under risk are actively misleading under uncertainty.
Simon, 1956, on satisficing and bounded rationality. Simon's argument was that under realistic constraints on information and computation, organisms do not optimise, they satisfice: they take the first option that clears a threshold. This is usually presented as a concession to human limitation. It is better read as a strategy. When the optimum is not knowable, defining a threshold and taking the first thing that clears it is not laziness; it is the correct procedure, and it is much faster.
Gigerenzer and Brighton, 2009, "Homo Heuristicus". This is the finding that should change how you think about design process. Simple heuristics with few parameters frequently outperform complex optimising models when data is scarce or the environment is unstable, and the reason is the bias-variance tradeoff: a complex model fits the noise in a small sample.
Translated: an elaborate design derived from three user interviews is an overfitted model. It will look rigorous and it will encode the idiosyncrasies of three people. A simpler, more conventional design is the more robust prediction, and this is a statistical claim rather than an aesthetic preference.
Dixit and Pindyck, 1994, on investment under uncertainty. Their contribution is that irreversibility plus uncertainty creates value in waiting. If a commitment cannot be undone and information is arriving, then delay has a quantifiable worth. McGrath applied the same reasoning to entrepreneurship in 1999, arguing that small, cheap, abandonable bets are the appropriate structure under high uncertainty.
The design translation is direct. An irreversible design decision made early destroys option value. A reversible one costs almost nothing to get wrong.
Buxton, 2007, on sketching versus prototyping. Buxton's distinction is that sketches are deliberately ambiguous and disposable, made to propose and to invite revision, while prototypes are made to refine something already chosen. Confusing the two is the most common process error in design, because a high-fidelity artifact produced under low evidence functions as a commitment device: it looks decided, it accumulates stakeholder attachment, and it becomes expensive to abandon precisely because it took a week.
And the professional convention argument, which is Nielsen's consistency heuristic doing unfashionable work. Under uncertainty, a convention is other people's validated evidence, available free. Choosing the boring pattern is not a failure of imagination. It is importing a large sample when you have a small one.
Argument
Sort every decision by cost of reversal before deciding anything.
An approximate ladder, cheapest first:
Copy and microcopy. Almost free. Change it on Tuesday.
Visual treatment, spacing, colour. Cheap, contained in a stylesheet.
Component behaviour, states, transitions. Moderate.
Layout and hierarchy within a screen. Moderate, and it costs a redesign rather than a rewrite.
Navigation and information architecture. Expensive. It touches every screen, every URL, and every user's learned mental model.
The object model, meaning what things exist in the product and how they relate. Nearly irreversible once data exists in it, because migration is a project and users' saved work depends on the shape.
Pricing structure and the account model. Irreversible in a different way, since existing customers have expectations you cannot unilaterally revise.
Now the point. You should be fast and loose at the top of that ladder and slow and evidence-hungry at the bottom. Ship copy you are unsure about. Do not ship an object model you are unsure about if you can avoid committing to it.
Which means the real skill is buying information cheaply.
Information is the thing that resolves the expensive decisions, and it is available at prices most teams never check.
Watching someone do the job without your product, for a day, is close to free and will tell you more about the object model than any amount of internal discussion. What objects do they already name. What do they count. What do they file. Existing vocabulary is the strongest available evidence about the object model, because the model is a claim about how the domain is structured and the practitioners already know.
Competitive teardown is nearly free. Where five products have converged on the same structure, that convergence is evidence, and where they all differ, you have found a genuinely open question rather than an unsolved one.
Wizard of Oz is cheap. Manually perform the operation your product will automate, for five users, before you build the automation. You learn the failure distribution, which is what you need to specify the thing.
Support and sales transcripts are free and unread. If any exist, they contain the vocabulary problem already solved.
Design the parts that do not depend on the answer.
There is always a large set of decisions that are invariant to what you are uncertain about. Error handling. Empty states. Loading behaviour. Accessibility. Keyboard interaction. Responsive breakpoints. None of these depend on whether the object model turns out to be right.
Doing that work first has a second effect worth more than the first: it produces a shippable product without settling the open question, which keeps the option alive. Teams that stall under uncertainty usually stall because they believe nothing can proceed until the central question is answered. Most things can.
Make the interface capable of admitting ignorance.
Every state machine designed under confidence has two states where it needs three. Not on and off but on, off and unknown. Not loaded and loading but loaded, loading and stale.
The unknown state is the one that gets omitted, and it is the one that occurs in production. An interface with no way to say "I am not sure" will assert something false at the first network failure. Designing the ignorance state is design work about uncertainty in the most literal sense, and it is nearly always skipped.
Match artifact fidelity to evidence level, deliberately.
If you have low evidence, sketch. Ambiguous, disposable, cheap to argue with. If you have moderate evidence, build a rough interactive version. Save high fidelity for decisions you have reason to believe are correct.
The reason this matters is social rather than technical. A polished artifact changes the conversation from "is this right" to "which shade of this is right", and it does so silently. Fidelity is a claim about certainty, and if you make that claim before you have earned it, you will be believed and then you will be stuck.
Examples
A dashboard with no users yet. You do not know which metric matters. The reversible version is a flat list of metrics with no hierarchy and no committed primary. It looks unfinished, ships in a day, and its usage data tells you the hierarchy. The irreversible version picks a hero metric, builds the whole layout around it, and then requires a redesign when the hero turns out to be the third most looked-at number.
Onboarding for a product whose audience is unclear. The expensive commitment is a branching flow with segment-specific paths, which encodes a segmentation you have not validated. The cheap version is one linear path with an escape hatch, plus a single question at the start whose answers you record and do not yet act on. You have bought segmentation data without building for a segmentation.
Naming the central object. This is the decision that most deserves delay and least often gets it. Whether the thing is a project, a workspace, a board or a document determines the URL structure, the permission model, the navigation and the database. It is worth several days of watching people work before choosing, and it is typically chosen in the first hour by whoever opened the design file.
An interface for a domain you are not part of. Accessibility work for people in their sixties, to take a case from my own archive, does not depend on the product hypothesis at all. Contrast ratios, target sizes, plain state labels, no reliance on hover. All of it survives any pivot the product makes, and all of it can be done before the central question is resolved.
Counterargument
"This is analysis paralysis with a citation list. Great products come from conviction, not from preserving options."
The strongest version of this objection has real evidence behind it. Products with a strong point of view tend to beat products designed to keep every path open, and the reason is not mystical. A committed object model produces coherence. Coherence is legible to users as clarity, and it makes every downstream decision faster because most options are already excluded. Deferring the expensive decisions produces a product with no spine, and the flexible version frequently loses to the opinionated one.
There is also a formal objection, and it is worth more than the informal one. Adner and Levinthal argued in 2004 that real-options reasoning applies to business strategy only under specific boundary conditions, and that the critical missing condition is a genuine ability to abandon. Where the option to exercise is not clearly bounded, the framing becomes a licence for indefinite continuation: everything is an option, nothing is ever killed, and "preserving flexibility" is what people say about a decision they are avoiding. That criticism lands directly on the argument above.
Where this is right. Conviction beats optionality when you have domain knowledge. A founder who has done the job for a decade should commit on day one, because their prior is not ignorance, it is evidence held in a form that does not fit in a research plan. My argument is addressed to the case where you genuinely do not know the domain, and it should not be applied to the case where you do.
And Adner and Levinthal's warning is the correct failure mode to watch. Deferral is only a strategy if the deferred decision has a date and a trigger. Otherwise it is procrastination with a framework.
Where I think it is wrong. Conviction about the object model and conviction about the interface are different things, and the objection conflates them. You can hold a strong point of view about who the product is for and what it refuses to do while remaining genuinely uncommitted about whether the central object is a project or a document. The first is the spine. The second is a schema decision, and being uncertain about a schema is not the same as having no opinions.
The other thing: reversibility ordering is not a slower process. It is faster, because the top of the ladder ships immediately. What it slows down is one specific class of decision, and only the ones that would cost a migration.
Practical implications
Keep a decision ledger. Three columns: the decision, cost to reverse, evidence behind it. Anything expensive with no evidence is the highest-priority item in your week, and it is usually invisible without the list.
Set a trigger for every deferred decision. "We decide the object model when we have watched five people work, or on 30 September, whichever comes first." Deferral without a trigger is the failure Adner and Levinthal describe.
Buy information at the cheapest available price before spending on the expensive decisions. A day of observation, a teardown, five manual runs of the thing you plan to automate.
Take the convention when you have no evidence. It carries a larger sample than you do. Deviate where you have a specific reason, and be able to name the reason.
Build everything the open question does not touch. Error states, empty states, accessibility, loading, keyboard. It ships, and it preserves the option.
Design the unknown state everywhere. If the interface cannot say it does not know, it will say something false.
Match fidelity to evidence, and say so out loud. "This is a sketch, the layout is not a proposal." Otherwise the polish will be read as a decision.
Adopt the practitioners' vocabulary. If your users already have a word for the thing, that is your object name, and disagreeing with them is a cost you have to justify.
My perspective
Opinion, and specific to my own work.
The two projects in my archive where I bought information cheaply are the two whose design reasoning I still trust. For a smart-home interface I ran usability observation with users over fifty and benchmarked against two established products. For a cafe ordering system I spent three days on the floor with baristas, mapped the physical layout and timed the queue at peak. Neither cost anything but time, and in both cases the observation changed the object model. The smart-home design ended up organised around rooms and routines rather than devices, and the cafe design ended up being about the barista's interruptions rather than the customer's queue. I would not have reached either conclusion in a design file.
The failure was the next step. For the smart-home project I produced high-fidelity screens for something that was never built, and then published outcome numbers for it. Both errors follow from the same mistake: I let fidelity run ahead of evidence, and once the artifact looked finished it started attracting claims that matched its finish. The screens were good work. The finish was a claim I had not earned, and the numbers were the debt coming due.
The thing I would tell anyone designing under uncertainty: your most expensive decisions are the ones you will make fastest, because they arrive disguised as defaults. Nobody deliberates over what to call the central object or which column goes first. Those are exactly the decisions that cost a migration eighteen months later, and the only reliable defence I have found is a written list of which choices are cheap and which are permanent, made before the design starts.
Conclusion
Uncertainty is not a temporary condition to be cleared before design begins. It is the normal condition, and the skill is not better guessing.
Sort decisions by what they cost to undo. Be fast where reversal is cheap and slow where it is not. Buy information at the cheapest price available, which is usually watching someone work. Build everything the open question does not touch, so that you ship without committing. Design the state where the system does not know. Match fidelity to evidence, because polish reads as certainty whether you meant it to or not.
And give every deferred decision a date, because otherwise this whole argument becomes a way to avoid the hard part.
Sources
- F. H. Knight, Risk, Uncertainty and Profit, Houghton Mifflin, 1921.
- H. A. Simon, "Rational choice and the structure of the environment", Psychological Review 63(2), 1956, 129–138.
- G. Gigerenzer and H. Brighton, "Homo Heuristicus: Why Biased Minds Make Better Inferences", Topics in Cognitive Science 1(1), 2009, 107–143.
- A. K. Dixit and R. S. Pindyck, Investment Under Uncertainty, Princeton University Press, 1994.
- R. G. McGrath, "Falling Forward: Real Options Reasoning and Entrepreneurial Failure", Academy of Management Review 24(1), 1999, 13–30.
- R. Adner and D. A. Levinthal, "What Is Not a Real Option: Considering Boundary Conditions for Applying Real Options to Business Strategy", Academy of Management Review 29(1), 2004, 74–85.
- B. Buxton, Sketching User Experiences: Getting the Design Right and the Right Design, Morgan Kaufmann, 2007.
- J. Nielsen, "10 Usability Heuristics for User Interface Design", Nielsen Norman Group, 1994. https://www.nngroup.com/articles/ten-usability-heuristics/
Related reading in this archive
- Hublix: the fidelity mistake described above
- Cafe ordering: three days of observation and what it changed
- Cognitive load is the real SaaS design problem
- Shipping MVPs with AI coding tools