The edge case trap
I see this pattern constantly, especially among thorough, well-intentioned designers: they start a new feature by cataloging every possible edge case. What if the user has no data? What if there are ten thousand items? What if the network drops? What if the label is 200 characters long?
These are valid questions. But they are the wrong starting point.
Why it matters
When you design for edge cases first, you end up with a product shaped by its exceptions rather than its purpose. The core experience -- the thing 90% of users will encounter 90% of the time -- gets distorted to accommodate scenarios that may rarely occur.
I have watched teams spend weeks agonizing over empty states before they had even defined what the full state looked like. The result is always the same:
- Bloated interfaces trying to handle every possible permutation
- Delayed shipping because nothing ever feels "covered" enough
- Confused priorities where the team cannot distinguish between critical and marginal
Design the highway before you design the guardrails.
The right sequence
Here is the sequence I push my teams to follow:
- Design the ideal state first. What does the experience look like when everything works as intended? This is your north star.
- Validate the core flow. Can a user accomplish the primary task without friction? Is the information hierarchy correct?
- Identify the highest-impact edge cases. Not all edge cases are equal. Which ones will users actually encounter? Which ones have serious consequences if mishandled?
- Design for those edge cases specifically. Address them with targeted solutions, not by warping the entire interface.
- Document the rest. Some edge cases can be handled with sensible defaults, error messages, or simply logged for later iteration.
The defense context
In defense technology, this discipline is even more critical. The operational scenarios are so varied and unpredictable that you could spend years trying to design for every possible situation. You cannot. Instead, you design for the most likely and most consequential scenarios, and you build systems that are resilient enough to handle the rest gracefully.
This is not cutting corners. It is strategic design -- knowing where to invest your finite attention.
A rule of thumb
If your Figma file has more edge case frames than core flow frames, something has gone sideways. Step back. Find the spine of the experience. Make that excellent. Then handle the edges.
The core experience is not a special case. It is the case.