The Screen Nobody Designed: Auditing Error States Before They Cost You Customers
Every product team spends its design budget on the route where everything goes right. The customer arrives, searches, finds what they need, pays, and leaves satisfied. Yet the moments that decide whether that customer comes back are usually the ones nobody storyboarded: the card that fails verification, the session that expires mid-checkout, the search that returns nothing on a busy Tuesday afternoon.
For a UK SME these screens are not cosmetic. They sit directly on the revenue line, and they are frequently the last impression a customer has of the business. What follows is a practical method for finding them, judging them, and fixing the ones that matter.
Why the unhappy path is left undone
Error handling rots for understandable reasons. It is written last, usually by whoever is closest to the code at the end of a sprint. It is specified vaguely, if at all, in the ticket. It is tested by engineers who know how to make it appear, which is not the same as testing whether a customer can recover from it.
There is also a quiet optimism bias in how work is scoped. A story that reads customer completes checkout implicitly assumes the payment succeeds. The declined card, the abandoned 3D Secure challenge and the address lookup that times out are treated as exceptions rather than as features in their own right. Over time the product accumulates a set of screens that no one owns and no one has reviewed.
The commercial consequence is straightforward. A broken error state rarely generates a complaint; it generates an exit. The customer closes the tab, tries a competitor, and the business never learns why.
Three families of neglected state
Empty states. A first-run account with no data, a search with no matches, a filtered list narrowed to zero, an inbox after everything has been cleared. Each needs different language and a different next step. Collapsing them into a single no results screen is one of the most common mistakes, and it leaves new users staring at a blank page with no idea how to begin.
Error states. Form validation, payment failure, authentication and session expiry, loss of network, permission denied, rate limiting, and dependency outages in third-party services such as address lookup, VAT number validation or CRM sync. The generic something went wrong screen is the symptom to look for: it usually means a dozen distinct failures have been merged into one unhelpful message.
Edge states. Names too long for the table column, missing logos, partially loaded records, request timeouts, two staff editing the same booking, a customer on a slow connection in a rural area, text at 200 per cent zoom. These are the states that reveal whether the build was stress-tested or merely demonstrated.
A five-pass audit you can run in a fortnight
- Inventory. List every screen that fetches data, submits a form or gates access. A route list plus analytics on page views is usually enough to build it. Expect the list to be longer than you think.
- Trigger deliberately. Use the payment provider's test cards for declined, insufficient funds and authentication-required scenarios. Revoke a session in another tab. Toggle the browser offline. Throttle the connection. Seed an account with no data and one with ten thousand records.
- Capture. Record the screen, the exact copy, the action offered, whether entered data survives, and whether any reference is shown for support. A short screen recording is worth more than a written description.
- Score. Rank each finding using the rubric below so the list becomes a decision rather than an argument.
- Assign. Every finding gets an owner and a ticket. States with no owner are the ones that stay broken for years.
Ranking fixes by commercial impact
Score each state from one to three on four factors, then weight them.
| Factor | Question | Weight |
|---|---|---|
| Frequency | How many sessions a month reach this state? | 3 |
| Revenue proximity | Does it interrupt a purchase, a renewal or a booking? | 3 |
| Recoverability | Can the customer resolve it without contacting you? | 2 |
| Support load | How many tickets does it generate per month? | 1 |
A payment failure affecting two per cent of twelve hundred monthly checkouts will outrank an empty state on an internal admin screen used by four people, and the arithmetic makes that visible to a finance director. Where the data is thin, estimate and say so; an approximate ranking beats no ranking.
What a good error state actually contains
Four elements, in this order. What happened, in plain English and without a bare error code. What it means for the customer — were they charged, is their data safe, is the order still live. What to do next, expressed as one clear primary action. And how to get help, including a reference the support team can trace.
Beyond the copy, three behaviours matter. Entered data should survive wherever possible; clearing a form after a validation failure is a needless insult. The screen should never be a dead end, so always offer a route back. And the failure should be logged with enough context to diagnose it later, which means correlation identifiers rather than a screenshot from the customer.
It is also worth treating error copy as interface content rather than as a string literal written at the end of a long day. It belongs in the design system, reviewed alongside the happy path, and versioned like any other component.
Accessibility is part of the same work
Error handling and accessibility overlap almost entirely. Messages need to be announced to screen readers, focus needs to move to the field or summary that failed, and colour alone must never carry the meaning. The Web Content Accessibility Guidelines are explicit about error identification and suggestion, and for public sector work the accessibility regulations make the point non-negotiable. For private companies the users are the same people, and the standard is a reasonable one to hold.
Turning the audit into a habit
A one-off sweep will improve things and then decay. Three habits prevent that. Add state coverage to the definition of done, so a story is not complete until its failure paths are designed. Keep a shared catalogue of states with their approved copy, so the next developer reuses rather than reinvents. And review the catalogue quarterly against support tickets, because the highest-value fixes are usually hiding in the complaints already being logged.
Good error handling is the cheapest retention tool available to a UK SME. It requires no new acquisition spend, no additional headcount and no marketing budget. It simply requires someone to design the screen that nobody wanted to design — and a customer who is helped through a problem is often more loyal than one who never had one.
