The error state
Everyone designs the happy path. The screen that appears when something breaks is where a person decides whether to trust you.
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.
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.
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.
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.