Storyboards & User Flows

Storyboards & User Flows

Before a single pixel is placed on a screen, a systems analyst must answer a deceptively simple question: how does a user move through the system to accomplish a goal? Two complementary tools answer that question — storyboards and user flows. Storyboards borrow from film and UX design: they tell the emotional story of a user encountering a problem and using the system to resolve it. User flows, by contrast, are precise maps of every screen-to-screen transition, decision point, and termination state. Together they bridge narrative requirements and engineering-ready specifications.

Storyboards: Telling the Human Story

A storyboard is a sequence of annotated panels — typically quick sketches or rough wireframes — that shows a persona moving through a real-world scenario. Each panel captures: the context (where the user is, what device they hold), the action (what they do), and the system response (what they see). Storyboards are deliberately low-fidelity; their value lies in communicating intent, not aesthetics.

Consider a clinic appointment booking system. A typical storyboard might show:

1. Panel 1 — Trigger: Salma, a working mother, feels her daughter has a fever. She opens the clinic app on her phone while waiting at a bus stop.
2. Panel 2 — Entry: She taps "Book Appointment" and sees a calendar with highlighted available slots.
3. Panel 3 — Decision: She picks a same-day slot; the system warns that only one slot remains and asks her to confirm.
4. Panel 4 — Confirmation: A confirmation screen shows appointment details and offers to add the event to her phone calendar.
5. Panel 5 — Resolution: Salma arrives at the clinic, the receptionist's tablet shows her check-in status, and she is seated quickly.

Each panel reveals requirements that a purely textual use case would miss — the confirmation nudge, the calendar integration, the receptionist tablet view. Storyboards are excellent stakeholder communication tools precisely because non-technical stakeholders can read them without training.

User Flows: Precise Navigation Maps

Where storyboards are narrative, user flows are formal. A user flow uses a standardised notation — similar to a flowchart — to document every path a user can take through a screen-based interface. The key elements are:

• Screens / States — rounded rectangles representing distinct views the user sees.
• Actions / Events — arrows labelled with the user action that triggers a transition (e.g., "clicks Submit").
• Decision points — diamonds where the system branches based on a condition (e.g., "payment authorised?").
• Entry points — filled circles (start states) indicating where the flow begins.
• Exit points — double circles or thick circles indicating successful completion or abandonment.
• Error states — screens shown when validation fails or a service call returns an error.

User flows differ from the activity diagrams you learned in Tutorial 9 in one important way: they are screen-centred rather than process-centred. Every node represents something the user sees, not just something the system does.

Constructing a User Flow: Step-by-Step

Follow this repeatable process when building a user flow for a new feature:

1. Identify the goal and persona. Every user flow starts with a single, concrete goal — "Customer completes a purchase" or "Dispatcher assigns a delivery route." Anchor it to one primary persona.
2. List all screens already known. Pull from wireframes, existing prototypes, or the UI requirements backlog. Give each screen a short label (noun phrase, e.g. "Cart Review").
3. Map the happy path first. Draw the straight-line route from entry to successful exit — no branches yet. This is your baseline and is easiest for stakeholders to validate.
4. Add decision points. For each step, ask: "Can the system or user answer Yes/No here?" Insert a diamond. Trace both branches.
5. Handle error and edge-case paths. Each error state is a screen (or inline feedback) — draw it. Loops back to the originating screen are common (e.g., re-entering an address).
6. Label every arrow. An unlabelled arrow is an undocumented requirement. The label names the user action or system event that triggers the transition.
7. Validate with stakeholders. Walk through the flow in a review session. Missing paths surface quickly when someone asks "but what if the user has already logged in?"

Linking User Flows to Requirements

User flows are traceability bridges. Each screen node should map back to at least one functional requirement; each decision diamond often maps to a business rule in the SRS. In practice, analysts annotate user flows with requirement IDs (e.g., FR-14, BR-03) directly on the diagram so that a single artefact serves as both a design aid and a review checklist.

For a logistics firm onboarding new drivers, a user flow would include screens for document upload, identity verification, background-check status polling, and final approval. The decision diamond "Documents complete?" maps directly to BR-07 in the business rules document. When requirements change — say, a new regulatory field is added — the analyst updates the flow, traces the impact, and flags affected wireframes and test cases simultaneously.

Common Mistakes to Avoid

• Happy-path-only flows. A flow that shows only the success scenario misses the majority of real user behaviour. Error handling is as important as the happy path.
• Screens without entry conditions. Every screen should be reachable from at least one labelled arrow. Orphan nodes indicate gaps in the specification.
• Conflating system processes with user screens. "Send confirmation email" is a system action, not a screen. Either represent it as a note on an arrow or model it separately in an activity diagram.
• Too many flows in one diagram. A user flow covering five separate tasks becomes unreadable. Split by task or persona and cross-reference them.

Practical Deliverable Format

In a professional deliverable, user flows are typically embedded in the UI Requirements Document or the System Requirements Specification alongside corresponding wireframes. Each flow receives a unique identifier (e.g., UF-01 — Guest Checkout Flow) and a version history. Teams using agile processes often attach the user flow directly to the epic or story in their project management tool, making it instantly available to designers and developers picking up the work.

Whether your team uses dedicated tools like Figma, Miro, Lucidchart, or hand-drawn sketches photographed and embedded in a Word document, the analytical rigour — complete paths, labelled transitions, traced requirements — is what transforms a sketch into a specification.