What the Prototype Conveniently Forgot
The prototype completes a customer request in four elegant clicks. The payment clears, inventory changes, confirmation appears, and everyone can see the product working. Then someone asks what happens if the payment succeeds but the inventory update fails. The room goes quiet—not because the question is obscure, but because the prototype has reached the edge of the world it was designed to show.
This is where polished prototypes can become misleading. They are excellent at making an idea tangible, aligning people around a workflow, and exposing awkward interactions. Yet their fluency can imply that the underlying problem is equally smooth. A convincing happy path compresses uncertainty into a few screens. Development has to expand it again.
Reality enters between the screens
Return to those four clicks and introduce an ordinary interruption. The customer closes the browser after payment but before confirmation. Now the interface needs to determine whether the request completed, whether retrying would create a duplicate, and what the customer should see on returning. The missing screen is only the visible part. Behind it sit questions about idempotency, transaction boundaries, persisted state, and support access.
Change the disruption again. Inventory is available when the flow begins but unavailable when payment completes. A user has permission to submit a request but not to view one field in the result. An external service responds slowly, then succeeds after the interface has declared failure. Each variation alters more than the error message. It changes ownership: which system holds the truth, which action can be reversed, and who is allowed to resolve the mismatch.
This is why exception states often create disproportionate implementation effort. The happy path demonstrates intent; recovery requires policy. A prototype may show that cancellation exists without deciding when it is permitted, what happens to dependent records, or whether a completed external action can actually be undone. Those are product and business decisions expressed through software, not technical details that developers can safely invent later.
A short failure-path review
The review does not need to become a catalogue of every imaginable disaster. We can keep the same prototype on screen and disturb it gently. Pause the flow halfway through. Remove a permission. Reject an input after submission. Let one system succeed while another fails. Then follow the user forward: what do they know, what can they safely do next, and who can repair the state if they cannot?
The useful output is not a larger collection of polished screens. It is a record of decisions: what counts as complete, which operations may be retried, where status is stored, when manual intervention begins, and how users regain confidence. Some answers will simplify the product. Others will reveal genuine complexity that belongs in the estimate. Either result is preferable to discovering the decision inside a sprint.
For teams moving from concept toward implementation, testing the awkward middle is part of making the design credible. It gives nontechnical stakeholders a practical way to challenge assumptions without debating architecture, while giving engineers enough clarity to avoid encoding accidental policy.
When we return once more to the elegant four-click request, it may look less complete than it did at first. That is progress. A prototype becomes more valuable when it stops performing perfection and starts helping the team decide what should happen when reality refuses to cooperate.
