Map a User Flow Before Drawing Screens

Define the task and its boundary

Choose a task that a person can recognize as complete, such as booking a room for a team meeting. “Manage rooms” is too broad because it hides searching, reserving, changing, and cancelling. Write the starting condition and the final evidence of success. A booking confirmation must mean that availability was checked and the reservation was saved, rather than merely that a button was pressed.

For a hypothetical office tool, start the flow when an employee already knows the meeting date. Keep discovering a suitable date in a separate flow. This boundary reduces diagram noise while making the assumption explicit. Record which nearby tasks can interrupt the user and which information should survive that interruption.

Represent decisions before screens

List the decisions in plain language: is the employee allowed to book, is the room available, and are required details present? Then map the information needed to answer them. A decision can happen inside a screen, across several screens, or entirely on the server. Avoid equating every box in the diagram with a page; that prematurely locks the interface to a product rule.

Use separate labels for user choices and system checks. In the room example, choosing a room is a user choice; detecting a conflicting reservation is a system check. This distinction helps designers specify messages and helps engineers identify where authoritative checks belong. Mark any unanswered policy questions beside the branch instead of quietly choosing a convenient behavior.

Add recovery and interruption paths

Walk through the flow as someone who makes a mistake or loses connectivity. Consider unavailable rooms, expired sessions, duplicate submission, and navigating back after editing details. Recovery should lead to a useful state with clear information about what was saved. A retry that silently creates a second booking is worse than a slower confirmation that explains the result.

Decide what the person can change at each failure point. If a room becomes unavailable at submission, retain the meeting title, participants, and date while offering alternatives. If permission is missing, explain how to request access without implying that the booking succeeded. Include a route back to the task after permission is granted, subject to a fresh availability check.

Review the flow with a realistic walkthrough

Read the diagram aloud with product, design, and engineering colleagues. Follow one ordinary path and two recovery paths using concrete sample data. Ask each participant to describe what the user believes at every transition. Disagreement often reveals an unclear state or an unspoken rule more effectively than an abstract review of arrows.

Turn unresolved branches into decisions with an owner and a deadline. Then prototype only the transitions that remain uncertain or carry significant consequences. A mature diagram is not necessarily large; it is understandable enough to guide implementation and small enough to update when a rule changes. Keep the diagram beside acceptance criteria so future changes can be checked against the same task boundary.

• State one objective and a verifiable completion signal.
• Separate user choices from authoritative system checks.
• Preserve useful input through recoverable errors.
• Assign an owner to every unresolved branch.

The flow explains how the task progresses. Organize the information people must find along that route before choosing navigation categories or polishing screens.Organize Information Architecture Around User Tasks