How to create a user flow that includes recovery
Draw a useful user flow for submitting artwork by separating actions, decisions, system responses, and recovery routes instead of documenting only the successful path.
Define a completed artwork submission
A user flow explains how a task progresses through decisions and states. For an artwork submission, the important question is not how many screens exist. It is whether an artist can provide a suitable file, understand the submission conditions, correct a problem, and recognize completion. Define that outcome before drawing boxes and arrows.
Label actions and branching conditions
Use boxes for meaningful steps and diamonds only where the route genuinely branches. Label arrows with conditions such as file accepted or deadline passed. Distinguish an artist's action from an automatic response. Keep a separate note for information that must survive a return visit, including a draft title and selected file. Separate what the system knows from what the person has actually been told. A technically valid operation can still look unsuccessful when its confirmation is delayed or ambiguous. Describe the state before the action, while work is pending, and after it completes. Then name the information that remains available if the person leaves and returns. These notes become concrete requirements for the eventual implementation.
Draw the submission and recovery routes
Draw a flow for submitting one image to a community exhibition. Begin with eligibility, continue through upload and details, and end with a receipt. Add routes for an unsupported file, an interrupted connection, and a person who changes their mind before submission. Give each route an explicit destination. Work through the example once without a pointer, once on a narrow screen, and once after an interruption. These passes examine different assumptions; none replaces research with people who use the finished service. Preserve the same task and content across passes so that changes reveal weaknesses in the design rather than unrelated differences in the scenario. Capture each weakness as a specific revision, not a general impression.
Split complexity without losing context
If the diagram grows into a wall of tiny boxes, split it by task while retaining clear entry and exit points. If every error returns to the first screen, ask which values can be preserved. A diagram that omits recovery often forces those decisions into hurried implementation rather than considered design. Distinguish a missing cue from a missing capability. Copy can explain an available recovery path, but it cannot create a recovery path the system lacks. Annotate where the interface needs a different state, a preserved value, or an operational response. Give each case a visible outcome. Otherwise an apparently helpful message may simply send someone around the same unsuccessful loop with more words to read.
Walk every arrow with a realistic file
Walk through the flow with a realistic file and read every arrow label aloud. You should be able to tell what triggers the next state and what the artist sees there. Record unresolved policy decisions separately. The finished diagram should help someone implement or critique the task without needing the designer to narrate missing transitions.
Worked decision
After an unsupported image is rejected, keep the title and artist statement while offering Replace image; route a successful replacement back to review.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
