Map a complete task before making screens.

Define the start and finish in user terms

A flow describes how someone moves from an intention to an outcome, including what the service must do along the way. Start with the scoped task rather than your preferred navigation. For Neighbourhood Classes, the starting point is looking for a suitable Saturday pottery session. The finish is understanding a simulated reservation and its next steps. This is a proposed future flow, not a map of an observed service. Label it accordingly, especially when the only inputs are your fictional brief and assumptions.

Write the straightforward path as actions

Use plain action labels before drawing boxes. Separate the person’s action from a system response, and keep the level of detail consistent. “Choose a session” is more useful at this stage than listing every tap and scroll. Add the information required to make each decision. A diagram template can organise the flow, but it does not determine which steps belong in your service.

• Browse suitable sessions and identify a possible date.
• Review level, location, access information, and the fictional class details.
• Choose one available session and review the selection.
• Submit a simulated reservation and inspect the confirmation state.

Add a useful failure and a route back

Choose one realistic interruption rather than modelling every possible exception. Ask what information remains available and what the person can do next. Draw a deliberate recovery path instead of an arrow labelled “error”. Keep previous choices when appropriate, and avoid a dead end that requires restarting without explanation. An error should not imply a booking succeeded when the system could not confirm it.

Expose rules that the interface cannot decide alone

Mark questions such as when a place is reserved, whether capacity is checked again, and what information confirmation requires. A screen cannot guarantee any of those behaviours without a supporting service. For this practice project, define only the minimum fictional rules needed to explore the task and keep them in the ledger. Do not add real contact collection, payments, or accounts to solve an imagined requirement. Use synthetic content and ensure the prototype cannot accidentally submit information to a real organisation.

Walk the diagram before committing to layout

Read each path aloud: what does the person know, what do they choose, and what happens next? Check whether every decision has an understandable exit and whether the end state answers the original task. Invite a peer to identify ambiguous labels, treating their comments as a diagram review rather than user validation. Revise the structure first. Keep an earlier version and a short decision note so your eventual case study can explain why the flow changed without claiming that the revision improved real bookings.