Every product review I've been in has a moment where an edge case comes up and someone says: "that's a rare scenario, let's handle it later."
I've said it too.
The problem is that "rare" is usually measured from the product team's perspective, not the user's. For the user who hits a failed payment screen, or tries to access an account that's been locked, or uploads a file in a format we didn't anticipate — that's not a rare scenario. That's their experience of the product.
The math we're doing wrong
When we call something an edge case, we're usually doing frequency math: if 2% of sessions hit this state, it's low priority. But the user in that 2% is having a 100% bad experience.
In fintech especially, the edge cases are often the highest-stakes moments. The payment that fails. The identity verification that bounces. The transaction that lands in a state the user didn't expect. These aren't moments when users are browsing casually. These are moments when they're stressed, confused, and deciding whether to trust the product.
Handling those moments well isn't a nice-to-have. It's core to what the product promises.
The empty state is a designed experience
I've started thinking about empty states, error states, and loading states as designed experiences in their own right — not fallbacks or footnotes.
An empty state is often a user's first experience with a feature. If the first thing they see is a blank container with no context, no guidance, and no next step, we've missed an opportunity to orient them. A good empty state tells the user where they are, what's expected, and what to do next. A bad one just tells them nothing.
An error message is often the most important copy in the entire flow. Not the marketing headline, not the onboarding tooltip — the error message. Because the user reads it at the exact moment something has gone wrong, when they're most primed to decide: is this product worth trusting?
"Something went wrong. Please try again." is a failure of craft.
What good edge case design looks like
For any non-happy-path state, I try to ensure:
- Orientation — Where am I, and what happened?
- Explanation — Why did this happen (in plain language, not error codes)?
- Action — What can I do next?
- Reassurance — Has anything been lost or broken that I need to worry about?
Not every error state needs all four. But all four should be considered, even if most get ruled out.
The other thing I try to do is design edge cases at the same time as the happy path, not after. When the edge case is designed late, it's designed by a tired brain with no time, and it shows. The error screen that's obviously an afterthought damages the product's overall coherence.
The frame shift
The shift I've found useful is to stop thinking about edge cases as exceptional states and start thinking about them as different user journeys. The user whose payment declined is on a specific journey. So is the user whose account is under review. So is the new user whose first action fails.
Each of those journeys deserves the same design attention as the primary flow. The users on them are no less real, and their experience of the product is no less consequential.
The edge case that's rare from our side of the dashboard is someone's whole interaction on theirs.
Credits & further reading
- The Design of Everyday Things — Don Norman. The framework for thinking about error states as part of the designed experience — not accidents — comes from Norman's work on affordances, feedback, and discoverability. His chapter on human error reframes error design completely: the system failed the user, not the other way around.
- Don't Make Me Think — Steve Krug. His chapters on error states and help documentation are short but pointed. The principle that error messages are often the most important copy in a product is consistent with his broader argument about treating users as people who are "muddling through," not reading carefully.
- Nielsen Norman Group, writing on error messages — their research on what makes error messages usable (specific, actionable, non-blaming, plain language) is the empirical backing for the orientation/explanation/action/reassurance framework in this note. nngroup.com has a searchable archive.
- Luke Wroblewski, Web Form Design — specifically useful for the "what did the user expect vs. what happened" framing in form validation errors. Though focused on forms, the principles apply broadly to any state where the system needs to communicate what went wrong.