Every product has edge cases. Some deserve a thoughtful design solution, and some should be cut from scope entirely. The ones that hurt you are the ones nobody ever made a call on.
In my experience, teams tend to fail in one of 2 ways.
Teams that design for every edge case end up with bloated UIs, overbuilt error states, and features that nobody but the engineering team can explain. Teams that ignore them entirely end up with products that fall apart the moment a real user shows up.
Neither is a strategy. Here’s the framework I use.
Start with 2 variables: frequency and severity.
High severity, low frequency: design for it. A rare scenario that causes real harm (lost data, a broken flow for a vulnerable user, a compliance issue) doesn’t get a pass because it’s uncommon.
Low severity, low frequency: consider backlogging it. Write it down, make the call explicit, and move on. That’s prioritization, not neglect. You can always pull it back in if there is time before a release.
High frequency, any severity: stop calling it an edge case. If a meaningful portion of your users hit it regularly, it’s a use case you haven’t fully designed for yet.
Then apply 2 overlays.
First: will it result in data loss? Design for it regardless of where it falls in the matrix. Frequency doesn’t matter when the consequence is permanent.
Second: does a design and code solution already exist somewhere else in the product? Then address it. The cost to implement is low, and inconsistency has its own UX tax.
The real failure mode isn’t cutting edge cases. It’s cutting them without deciding to.
Teams skip past edge cases because they’re awkward to design, nobody wants to own them, or they slow down sprint velocity. Then they surface in QA (or worse, in production). Make the call deliberately, even if the answer is “we’re not designing for this right now.” Say it out loud and document the decision. If something breaks later, you’ll know exactly why it broke and whether that original decision still holds.