Drawing the flow
Lesson 5 of 24, level 01Index
Signup is “four simple steps”. Most people who start it never finish. Nobody can tell you which step loses them, because nobody has drawn it.
A flow is states, not screens
Screens are what design draws. States are what actually happens: logged out, verified, partially complete, expired, errored. Most drop off lives in a state nobody drew.
The rule of thumb is that each additional required step costs you roughly 10 to 20 percent of the people still in the funnel. Compounding across four steps is how “four simple steps” becomes a 38 percent completion rate.
For every arrow in your flow, write the analytics event that would prove someone travelled it. If you cannot name the event, you will not be able to answer “where do we lose them” after launch either.
A useful flow describes state transitions, including what happens when the expected action fails. It becomes a shared contract for design, engineering and analytics.
Use your chosen course project throughout. The additional examples below are fictional practice cases; transfer the method to your own evidence.
Name states precisely
“Bank screen” is not a state. “No bank connected,” “connection pending” and “provider callback failed” are different conditions that may share one screen. Give each state an entry condition and the actions it permits. This exposes states that cannot be reached or escaped with the current design.
Label transitions with evidence
For each arrow, write the trigger, the success condition and the event that would prove it happened. A click on Connect is an attempted transition, not proof of a connection. Distinguish the user's action from the provider's response and the persisted result so analytics does not count intent as success.
Design the return path
Add timeout, retry, cancellation and returning-later paths. Ask whether retrying duplicates work, whether the person's input survives and where they land after reopening the product. A recoverable failure is part of the product experience; it should not exist only in an engineer's exception handler.
A click is not a completed connection
- Intent: Connect clicked
- Pending: Provider handoff
- Result: Callback received
- Saved: State persisted
A delayed response changes the flow
Interactive teaching example · All numbers and tickets are fictional.
The server confirms completion before the product shows a saved result. A button click alone is not confirmation.
How Amazon handled it
Amazon
1999
Standard ecommerce checkout in the late nineties was five to seven steps, and every step lost customers.
Amazon patented removing all of them. The insight was not clever design, it was that they already had your address and card, so every step after buy existed only because the flow had been designed around the company's data model instead of the customer's intent.
Most flows are long because of how the company is organised, not because the user needs the steps. Drawing the flow is how you find those.
Doing it with AI, and where it breaks
Describe the flow in prose, have a model turn it into Mermaid diagram code, render it, then hunt specifically for the edge states it invented and the real ones it dropped.
Models produce clean happy paths. They silently omit “user closes the app and comes back tomorrow”, “code expires”, and “email already registered”, which is exactly where your drop off is.
Your AI workbench
Start with your own notes or clearly labelled practice data. Remove private details before sharing. Replace the placeholders, run the prompt in your chosen AI tool, and keep the output beside its source.
Convert my state list into a Mermaid state diagram. Preserve my state names. For each transition include trigger, success evidence and analytics event in a separate table. Ask about missing retry, timeout, cancellation and return paths. Do not equate a clicked button with a successful provider response. State list: [paste].
Before you use the output
- Walk every arrow using a concrete scenario
- ensure every failure has a recovery or explanation
- validate event semantics with engineering.
Stuck? Try this next
Render the generated diagram and trace it aloud. If the model cannot explain a transition without introducing a new state, add that state explicitly.
Keep a brief AI log: input used, useful output, what you checked, and what you rejected. The decision remains yours.
Build it
A rendered flow diagram with every edge state, and the event name for every arrow.
Mermaid Live EditorFigma or Excalidraw
The flow I thought I understood
Publish a 500–800 word project teardown. Show your original flow and a revised version with one recovery path. Explain a mistaken assumption, the evidence behind your revision, and what you would test next.
Include: A readable before-and-after flow with captions explaining the changed state.
- Write in your own voice for someone facing the same product problem.
- Use AI to critique the structure and find unsupported claims. Verify every source, number, and quotation yourself. Add a short note describing how you used AI.
- Remove private customer, company, and participant information. Label practice scenarios and synthetic data clearly.
- Publish on Medium, Substack, or a relevant Reddit community that permits project write-ups and links. Follow its posting rules; share a useful account of the work.
Include this plain attribution with a clickable link:
I developed this project while learning product management at pmcademy.com.
Checkpoint
If you did the build, these take two minutes. If you cannot answer one of them, that is the part to go back to.
Moving on marks this lesson complete. Finish the build first, it is the part that counts.