Stop 05 · Requirements & DocumentationTopics · 5/9

Edge Case Thinking

In short

Users rarely follow the happy path you designed. Edge case thinking means asking "what if…?" before users find the answer the hard way.

Systematically asking 'what happens when...' — empty states, network failures, permission errors, concurrent edits — before engineers discover them mid-sprint.

The purple blob holds a lift door open while balancing a tall stack of boxes.

Think of it like this

The apartment lift

A lift works fine on a normal trip. But what if it's overloaded, the power cuts mid-floor, or a child holds the door open? Good lifts have an alarm, a backup and a door sensor. Someone thought "what if" in advance.

Watch it happen

"What if" for a signup form

Happy path

Empty field

Very long name

No network

Double tap

Already exists

1/5The happy path: user types valid details and taps Sign up once. Easy to design. Now go through the rest.

The big ideas

What you need to know

Ask "what if" by category

Empty, too much, wrong type, slow, offline, repeated, no permission. Run every feature through the list.

Think of different users

New users, power users, users on old phones, users with screen readers. Each hits different edges.

Write them down

Each edge case becomes an acceptance criterion or a deliberate "not handling now" note.

Not every edge needs a fix

Weigh how often it happens and how bad it is. Some can wait; say so explicitly.

Save yourself the pain

Common mistakes

Oops

Leaving edge cases for engineers to discover while coding.

Do this instead

List common ones in the spec. Engineers will find more, but shouldn't have to find all.

Oops

Trying to handle every possible case before launch.

Do this instead

Fix the frequent and harmful ones. Log the rare ones and revisit with real data.

Your mission

Break a form

~20 min

Quick check

A user taps "Pay" twice quickly on a slow network. What's the key edge case?

Go deeper

1Take a feature idea and list 10 edge cases across empty, error, and boundary states.
2Learn the categories: empty state, error state, loading state, permission state.
3Practice this on a feature you've used that clearly missed an edge case.