How to use AI for user flows without losing the edge cases

What is AI actually good at in a flow?

Producing the happy path, fast. Describe a task in a sentence and you get back an ordered list of steps that is usually structurally sound and occasionally exactly right. That is real value, because the blank page is the slowest part of flow work and a plausible eight-step draft is a better thing to argue with than an empty document.

It is also the easy half. Nielsen Norman Group's definition of a user flow is a set of interactions describing the typical or ideal steps needed to accomplish a common task. Typical or ideal is the whole problem: the definition itself excludes everything that goes wrong, and a model trained on documentation that describes products working will reproduce that bias faithfully every time.

Draft the happy path first, deliberately thin

Ask for the shortest version. Name the user, the trigger that starts the task, the goal state that ends it, and demand no more than ten steps. A thin first draft is easier to check and easier to branch from than a detailed one, and detail generated before the spine is agreed is detail you will throw away.

Two constraints improve the draft more than any prompt wording does. First, give the model the actual screens or routes that exist in your product, because otherwise it will invent a plausible settings page you do not have and every later branch will hang off a fiction. Second, tell it to mark any step it is guessing at rather than smoothing over the gap, which turns invention into a visible list rather than a hidden one.

Then read the draft for one thing only: does the spine match how the task really runs today. Branch complexity added to a wrong spine is wasted work, and the spine is cheap to fix while the document is still ten lines long.

The six branches a model will not add on its own

Once the spine holds, stop asking open questions and start naming categories. "What edge cases am I missing" produces a generic list about validation and empty states. Naming the category produces the specific branch. Six cover most of what goes wrong in product flows:

No permission. The user is on the right screen in the wrong role. What do they see, and does the flow dead-end or offer a request-access path?

No data. First run, empty account, or a filter that matches nothing. A flow written against a populated account silently assumes a state most new users are not in.

No money. The trial lapsed, the card failed, the seat limit is reached, or the plan does not include this feature. Payment state is invisible in a flow diagram and decisive in a real session.

No network. The request times out halfway, or the user hits back mid-submit and arrives at a screen the flow never anticipated.

No second actor. Someone else is editing the same record, the invite was accepted by an address that already has an account, or the admin who owns the workspace has left the company. Nielsen Norman Group's own writing on edge cases makes the point that shared accounts and changed identities are ordinary life rather than rare failures, and this is the category models omit most reliably.

No patience. The user abandons at step four and comes back tomorrow. Does the flow resume, restart, or lose the work?

Run those six against the spine one at a time and you will typically double the length of the document. That expansion is the deliverable. The happy path was the setup.

Is a generated flow worth reviewing at all?

The honest objection is that a draft you have to check line by line saved you nothing, and for a flow you already know cold that is true. If you can write the eight steps from memory, write them. The model's draft will be a slightly worse version of what is already in your head and you will spend longer correcting it than composing it.

The value shows up on flows you do not own. A PM inheriting a checkout, a payments integration or an admin permission model faces a task where the blank page is genuinely expensive, because getting to a first draft means reading code or interviewing three people. There a generated spine that is seventy percent right and visibly marked where it is guessing is a real head start, and the checking step you would resent on a familiar flow is the work you were going to do anyway.

The other case where it earns its keep is breadth. Enumerating every combination of three conditions across a flow is mechanical, error-prone by hand and completely reliable by machine. Ask for the full matrix, then delete the rows that cannot happen. Deleting is faster than remembering.

Write the branches as sentences, not as a picture

Keep the working artefact in text. A numbered list of steps with branch conditions written plainly reviews faster than a diagram, shows up as a readable diff when someone changes it, and pastes into a ticket without an export step. Generate a diagram when a stakeholder needs one, and treat it as a rendering of the text rather than the source of truth. Nielsen Norman Group's wireflow format is the exception worth knowing, because it pairs a layout with the flow between layouts, and that pairing catches problems neither artefact catches alone.

Text also lets you attach the thing a diagram has no room for: what the user should see at each branch, in words. "Error" is not a branch outcome. "The card was declined, with a retry button and a link to update the payment method" is.

What stays your call

Which branches are worth building now. A model asked to prioritise will produce an ordering that sounds confident and rests on nothing, because it does not know your traffic, your support queue or your next quarter. You do. The branch that fires for eleven users a month and generates four support tickets each is worth more attention than the one that fires for four hundred users who recover on their own.

Also yours: whether the flow is the right flow at all. A model will faithfully optimise the six-step onboarding you described and will never ask whether the task should take six steps. That question belongs upstream, in the same place as the decision about what to prototype, which Prototyping for Product Managers covers over 1 week with 1 live session and 7 microlessons. Product Manager Foundations sets the wider frame, from finding the problem through shipping and iterating, across 2 weeks with 4 live sessions and 7 microlessons.

Once the flow holds, the layout question follows, and an AI wireframe generator handles that cheaply. If the flow is going to be tested rather than discussed, Figma for product managers covers assembling the clickable version, and writing acceptance criteria with AI covers turning the branches you just found into something an engineer can build against.

Walk it against a real account before you ship it

The check that catches the most invention costs fifteen minutes: open the product, log in as a real user, and try to perform every step and every branch exactly as written. Steps that cannot be performed, screens that do not exist and branches that turn out to be impossible are your list of what the model made up, and they are usually clustered in the same two places.

Builders Camp's Prototyping with AI bootcamp covers the flow and information-architecture generation directly, over 1 week with 2 live sessions and 9 microlessons, and names Lovable, Figma and GPT in its syllabus.

See the Prototyping with AI bootcamp

Keep the branch list after the feature ships and compare it against three months of support tickets. The categories where reality produced tickets you never wrote a branch for are the ones to name first in your next prompt, and that list is specific to your product in a way no general checklist can be.