One sentence, one map.
Sign-in, browse, checkout, reader, library, settings each get their own sentence and their own state map. Run the four steps once per sentence.
A way of designing software where the conditions it can be in are treated as the work, not as edge cases to handle later.
Use it for a feature, a surface, or a single screen. For a whole product, run it once per feature and share a short cross-cutting inventory across the results.
The method came out of a video on Interface Studies: The Happy Path Doesn't Exist ↗.
Software behaves. It runs, pauses, fails, sits idle, returns to itself days later, shows up on surfaces the user doesn't open. A wireframe captures one of those conditions. A flow diagram captures one path through them. What you ship lives in all of them.
The vocabulary we use puts the work in order: happy path first, edge case later, user journey flattened to a line. An edge case, by its name, is what the ideal displaced. That's why it ends up at the bottom of the backlog.
States aren't deviations from the system; they are the system. A paused timer is no less real than a running one. The screen a user sees on coming back to a half-finished task two days later is no less the system than the one they started with.
Once a thing has a name, it gets a place in the project. Renaming edge case to state moves the work from the residue phase to the structural phase.
The method runs on a system sentence, and a sentence works best where states are dense: a feature or a surface, not a whole product. A sentence for an entire app abstracts too hard to generate anything.
Sign-in, browse, checkout, reader, library, settings each get their own sentence and their own state map. Run the four steps once per sentence.
States that recur across features (unauthenticated, offline, subscription expired, sync conflict, first-run) are listed once for the whole product. Each feature's triage references the list rather than re-listing.
Four steps. Each one's test for done tells you when to proceed. The full reference is in Practice.
Write one sentence about what the system is as an object that exists over time, not what it does for the user.
List the states across four categories: active, failure, interruption, surface.
For each state, scope it: in, out-with-implication, or out. The practitioner's call; a tool can recommend.
For each in-scope active state, describe what happens when it's entered from somewhere other than the canonical path.
The four steps in detail, with a worked example, patterns for finding states, and the optional layers and cause dimensions.
Nothing here needs special tools. Run it on a whiteboard, or hand the legwork to an agent and make the decisions yourself.
A notebook and a pen will do. Best for greenfield work, where you're building the picture from a feature brief or a product idea.
Seven skills in the Anthropic Agent Skills format, installable in Claude Code, Codex, Antigravity, Warp, and Cursor (with adaptation). The agent does most of the legwork while you make the decisions. For auditing an existing codebase the agent path is the practical option.
See the skills ↗Walk a medication tracker through the four steps, end to end. 52 states, 45 in-scope, with layers and cause annotated.
Version 0.1. Offered as something that might help. Not yet tested at scale.
Written content
CC BY-SA 4.0
· Code (schema.json)
MIT