The error state

I watched my uncle open his banking app after a long gap. The transaction password had expired, so he had to set a new one. That meant verifying his card details, then his Aadhaar number with a one-time code, and only then choosing the new password.

The new password had strength rules. The app did not show them until he had broken one. Each rejection sent him back to try again, and by the time he got a password the app would accept, the session had expired. Everything he had verified was gone. We started over from the card details.

We did that four or five times before it worked. The password he finally set will expire again in a few weeks.

What strikes me is that every single screen in that flow could pass a review on its own. The failure lives between the screens, in two decisions nobody made on purpose: the rules were kept hidden until after the mistake, and his progress was thrown away when the clock ran out. Neither of those shows up in a demo, because in a demo the person types fast and gets it right the first time.

My uncle is not a careless user. He is a patient one. A patient person on a slow afternoon is exactly who a session timer punishes.

The screen nobody plans for

Every product has a screen nobody plans for. It is the one that appears when something goes wrong: the payment that does not go through, the form that will not submit. Teams call these error states, and on most products they are written last, by whoever is closest to the code, in the language of the system rather than the language of the person looking at it.

There is a reason for that. Everything about how software gets made points at the happy path. The demo shows the flow working. The deadline is about shipping the feature, and the error screen is not the feature. So the moment when something breaks gets designed by default, which mostly means it is not designed at all.

But look at what that screen actually is. When something breaks, the product and the person have to solve a problem together, and the error state is the only conversation they get. It is the moment a user decides whether to trust the product or walk away.

What the screen should say

The difference is easy to see side by side. “Error 422: invalid input” is a true sentence about the system. “A pincode has 6 digits. This has 5.” is a true sentence about what to do next. The first asks the person to understand the machine. The second does the understanding for them. Same failure, same screen, two different products.

A good error message names the field, says what is wrong in the words the person would use, says what to do, and keeps everything else they already typed. When it does those things, the person fixes one character and carries on. When it does not, they guess, and most people stop guessing sooner than teams expect.

None of this is my invention. The GOV.UK Design System (opens in new tab) asks the same of its error messages, and the web accessibility guidelines make two parts of it a requirement: say which field is wrong (opens in new tab), and suggest the fix (opens in new tab) when you know it.

When the signal drops

The network deserves its own line, because in India it fails more often than anything the person does. A form that needs one unbroken connection from the first field to the last has quietly decided that people on a weak signal are not its users. A form that saves each answer on the phone as it goes has decided the opposite.

Nothing about that second form is advanced. It is a decision taken early, when it is cheap, instead of discovered late, when the support tickets arrive.

Why it is a business problem and a public one

On a super app, I learned to read the error state as a revenue line. A person who hits a dead end in the middle of a payment does not file a bug report. They close the app, and some of them do not come back. Nobody sees this in a demo, because demos never fail. It shows up later, quietly, in the numbers.

On a national public service the stakes change shape. The person on the other side may be on an old phone with a weak signal, filling in the first form of their life. When the screen says something they cannot understand, they do not try again with different settings. They give up, and what they give up on is not a purchase. It is help they are owed.

What I check before the happy path

Before I design the flow that works, I list the ways it can fail, and I prototype each one rather than describing it. It is the least glamorous part of the job and the part I trust most. The list is short and it rarely changes.

That is why I open projects on the error state instead of the happy path. Designing the failure first forces the honest questions: what can actually go wrong here, and what will this person need when it does. Answer those and the happy path nearly designs itself, because by then you know exactly what the form is asking of the person. Design the failure last and you inherit whatever the system happened to say.

The error state is also where you can read a team's discipline. A product whose failure screens are calm and specific was built by people who walked every path, not only the sunny one. The happy path decides how good a product feels when everything works. The error state decides who gets to keep going when it does not. The interface decides who a product is actually for, and nowhere does it decide more sharply than on the screen nobody planned.