Here's something you've probably experienced 👇
You're scanning a packet of crisps for your meal deal, and then the self-checkout stops you. It’s telling you what to do next: scan it again, remove the unexpected item, or wait for a member of staff.
As annoying as it is to stand there like a wet lemon while someone walks over to tap the screen, it is at least useful. A lot of software knows something failed, but leaves you to work out who can actually sort it.
This week's issue looks at what good recovery should make clear: who needs to act, who controls the blocked state and whether an override should exist at all.
Top comments (1)
The self-checkout example lands because the machine names an actor, not just a state. Most error states get designed as messages — the screen knows something failed and says so — but "who can act on this" is a product decision, and it's usually the one nobody wrote an acceptance criterion for.
One reason it stays undesigned: failure states never make it into the artifacts that get reviewed. A mockup shows the sunny day, the demo walks the happy path, so the recovery logic ends up decided at implementation time by whoever hits the case first. Which is exactly how you get "something went wrong, try again later" with no owner and no override.
The three questions in your framing — who acts, who controls the blocked state, should an override exist — are effectively a spec template. If a screen can block, those three answers belong in the ticket, not in the error copy.