An edge case is a scenario that falls outside the typical way people use a product. It sits at the limits of what the team planned for, such as a 60-character surname or a payment that fails halfway through.
The opposite is the happy path, where everything goes as planned. A corner case is 2 or more unusual conditions happening at once, such as a slow connection during a failed payment.
Use cases
Edge cases help teams account for situations that standard user flows often miss.
Broken layouts: A card built for "Anna Lee" wraps and overlaps when a user's name is 4 words long.
Rejected users: A signup form requires a last name, and users with a single name can't create an account.
Silent failures: A search with zero results shows a blank screen, leaving users unsure whether the app crashed.
Stress cases: A photo-memories feature resurfaces a painful moment with a celebration banner.
How it's used in practice
Map screen states: Document empty, loading, error, partial, and overloaded states alongside the default state.
Test boundaries: Use extreme values and unusual combinations to expose failures.
Map unhappy paths: Identify what happens when each step fails, times out, or produces unexpected input.
Prioritize cases: Focus on scenarios based on user impact, frequency, and severity.
🪄
Pro-tip: Before handoff, ask, "What does this screen look like with no data and with too much data?" If neither state is designed, someone else will have to decide what happens.
Challenges & limitations
Endless possibilities: Teams can't design for every scenario, so they must decide which cases are worth addressing.
Rare doesn't mean trivial: A case affecting 1% of 10 million users still affects 100,000 people.
