Design the failure screen first

Every product deck opens with the happy path. The user taps, the thing works, a green tick appears, everyone in the room nods.

Then it ships, and the support inbox fills up with the other path.

The failure screen is the product

A user who taps a button and gets what they expected learns nothing about you. They got what they paid for. Trust is not built there.

A user whose payment failed is paying full attention. Their money is somewhere they cannot see it. In that ten seconds they decide whether your product is careful or careless, and they decide it based entirely on what the screen says.

That screen deserves more design time than the success one, and it usually gets less.

Three things a failure screen has to do

Say what happened, in the words the user would use. Not "transaction declined by issuer". Something closer to "Your bank did not approve this. Nothing has been taken from your account."

Say where the money is. This is the actual question. If the amount has returned to a wallet, say so and show the balance. If it is still moving, say how long it usually takes. If you genuinely do not know yet, say that — it is a better answer than a confident wrong one.

Say what happens next, and who does it. Either the user needs to do something, or they do not. If they do not, tell them so explicitly, because otherwise they will phone you to check.

Automatic beats apologetic

The strongest thing a failure screen can say is that the problem has already been handled.

In our own product, a failed payout returns to the user's wallet automatically. The status changes, the balance goes back up, and nobody has to raise a ticket. The screen does not apologise at length; it reports.

Building that took longer than building the successful payout. It is also the difference between a product people use twice and a product people use.

Where to start

Take your main flow and write down every way it can end badly. Not the ones you find interesting — all of them. Timeouts. Wrong details entered. The third-party service being down. The user closing the app halfway through.

Then design a screen for each. You will find that several collapse into one honest message, and that two or three of them are genuinely different situations you were about to handle identically.

That exercise takes an afternoon. It removes months of support load.