Design the bad day first

Watch any product demo. The dashboard is full of handsome data, the transfer lands instantly, the user is called Sarah and her documents are accepted in one go. Everyone nods along. Nobody asks what Sarah sees when the transfer doesn’t land, because in the demo it always lands. Portfolios are worse: whole careers presented without a single screen that says something went wrong, as if the work only ever met people on their luckiest day.

My own Figma files used to look like that too, flows stitched together from best cases, everything green. Then Monefit put me in front of a live funnel and the illusion died in about a week. Real people upload blurry documents, lose signal halfway through a payment, and get declined for reasons the system isn’t allowed to fully explain. What I’d designed covered most of what happened on a good day and almost none of what happened on a bad one, and the bad ones were where the customers were actually deciding how they felt about us.

Since then I’ve flipped the order. The rejection screen, the failed payment, the empty first-run: those get designed first, while there’s still energy and budget and someone senior in the room. The happy path can be assembled later; it’s the easy part.

Fintech says no for a living: declined applications, blocked transactions, payments that bounce, documents that fail review. Often the law limits how much of the reason you can share. Fine. There’s still a canyon between “Application declined, error 5-104” and a no with a shape to it: what happened, what it doesn’t say about you, when trying again might make sense, and one useful thing to do in the meantime. The first version ends a relationship. The second one pauses it.

Blame direction matters more than anyone expects. “Your card was declined” points at the person; “we couldn’t take the payment” points at the system. Same fact, different defendant, and you can watch the difference show up in retries and support tickets. This is the deepest version of my habit of sweating the exact wording on a button: on the worst screen in the product, the words are the whole design.

And the cruellest no is the one that never arrives. A decision stuck on “pending” with no timeline leaves people refreshing an empty inbox, assuming the worst, telling friends. I wrote about that silence in what most fintech onboarding gets wrong; it applies double when the eventual answer is no.

Not every bad day is a rejection. Most products meet their users empty: day one, no data, a dashboard designed around charts that don’t exist yet. That first-run emptiness is the real onboarding, and a grey illustration of a folder doesn’t survive it. A good empty state is a promise: here’s what will live on this screen, and here’s the one action that starts filling it. The gentlest version I know is Oura’s “waiting for your sleep data”, which I keep coming back to in nobody wants a lab report: it holds the promise open instead of showing a zero.

Then there’s the arithmetic that makes “edge case” a lie. One percent sounds ignorable in a planning meeting. At any real scale, one percent of sessions is a crowd of actual people having an actual bad evening, every single day. Nobody who watched their payment hang at a checkout, twice, thinks of themselves as an edge case. The label is how teams give themselves permission to not design something.

The fix I push for is unglamorous: bad-day components living in the design system, next to the buttons and the cards. The error banner, the empty slot, the pending state, the retry pattern, each designed once, properly, with real words. Otherwise they get improvised at five in the afternoon by whoever is closest to the ticket. If your design system has ten button variants and no declined state, it’s not a system yet. It’s decoration.