Verified against ChatGPT · 2026-08-10
Map a mobile app flow that accounts for the exits and error branches, not just the happy path
Maps out a mobile app user flow as a full branching diagram in text, forcing every error state, permission denial, and abandonment point to be an explicit named screen instead of an implied dead end.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Map the user flow described below as a full branching diagram, in text form. Most flow diagrams only show the happy path and leave every error, denial, or abandonment as an implied dead end that nobody actually designs; I want those made explicit. FLOW TO MAP Uploading a profile photo during onboarding: tap upload, choose camera or library, take/select photo, crop, confirm, photo appears on profile. ENTRY POINTS From the onboarding wizard (new user, forced step) and from the profile edit screen (existing user, optional). SYSTEM DEPENDENCIES INVOLVED Camera permission, photo-library permission, an upload API call to cloud storage, image-size validation. For every step in the happy path, identify at least one thing that plausibly goes wrong at that exact step given the system dependencies involved (a permission the user denies, a network call that times out, a payment that's declined, a required field left empty), and add it as a named branch, not a footnote. Every branch must end in one of three explicit terminal states: recovery (the user is routed back into the happy path with the problem addressed), graceful exit (the user leaves the flow but in a state that doesn't corrupt data or block a future attempt), or dead end (the flow genuinely has nowhere for the user to go from here) — if you find a dead end, flag it explicitly as a design gap rather than silently omitting it, since a real dead end in a shipped flow is a bug, and naming it is more useful than pretending the happy path is the only path. For each entry point listed, note whether the flow behaves identically regardless of entry point or whether a specific step needs to change (for instance, a flow entered via a deep link may need to handle a user who isn't logged in yet, differently from a flow entered from inside the app where login is already established). WHAT NOT TO DO Do not invent error states that aren't plausible given the actual system dependencies listed — a flow with no payment step doesn't need a "payment declined" branch. Do not resolve every branch into a recovery state just to make the diagram look complete; some genuinely are dead ends, and disguising that as a soft recovery is worse than flagging it honestly. OUTPUT FORMAT A numbered step list for the happy path first, then for each step, an indented list of its error/exit branches with their terminal state labeled (recovery / graceful exit / dead end), then a short section on entry-point-specific differences, then a final list of every flagged dead end as a standalone "design gaps found" section.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
When asked to map a flow without a forcing function, GPT-5.1 defaults to narrating the happy path in prose because that's the shortest, most coherent completion of "describe this flow" — error and denial states get mentioned in passing, if at all, since nothing in an open-ended request obligates the model to enumerate them systematically. Requiring at least one plausible failure per step, tied specifically to the listed system dependencies, converts this from a narrative task into an enumeration task, which changes the completion strategy entirely: the model now has to check each step against the dependency list rather than just continuing the story forward, which is what actually surfaces the permission-denial and timeout branches that a prose description would skip past. The three-terminal-state requirement, and specifically the instruction to flag genuine dead ends rather than resolve everything into a recovery path, matters because models under an implicit pressure to produce a "complete-looking" diagram will tend to invent a plausible-sounding recovery for every branch even when a real dead end exists in the underlying system — asking explicitly for honesty about dead ends removes the incentive to paper over an actual design gap, which is exactly the kind of gap that ships silently in a real app because no one ever forced it into a diagram where its absence would be visible. The per-entry-point differencing step exists because flow diagrams are frequently drawn once for the most common entry point and then silently assumed to generalize, when a deep-link entry with no established session is a materially different flow than one reached from inside an already-authenticated app, and that difference has real consequences (a login-wall interruption mid-flow) that only surface if asked for directly.
What you get back
Step 3: Take/select photo. Branch — camera permission denied: recovery, route to a screen explaining why the permission is needed with a 'try again' or 'choose from library instead' option. Branch — photo library empty: graceful exit, let the user skip photo upload and return to onboarding without a photo, flagged for later. Design gaps found: if upload succeeds but the crop-confirm screen crashes before saving, there's currently no path back to the photo — this is a dead end and needs a retry mechanism.
Verified against
ChatGPT GPT-5.1 · 2026-08-10
Changelog
- 2026-08-10 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — branding & design, built and maintained for you — that's Scult's day job.
EXPLORE BRANDING & DESIGN
