Flow 101: From Three Screens to Product Behavior

Session 11 teaches the learner to turn a selected and critiqued option into product behavior. The output is not three disconnected mockups. It is a 3-screen wireflow and feature brief that show screen jobs, actions, transitions, states, branches, recovery, accessibility notes, system rules, success signal, risks, and next prototype.

The session sits between critique and product brief. Session 10 established what must be true. Session 11 shows how the experience behaves. Session 12 will expand that into a fuller product brief, scope, priority, and handoff.

The main teaching move is simple: every screen exists to do a job in a task. Every arrow means something happened. Every state is part of the product promise.

The learner should leave with a working vocabulary: flow, journey, user flow, wireflow, screen job, entry point, exit point, transition, state, branch, edge case, recovery path, system rule, data dependency, feature brief, scope, and success signal.

A flow is not a visual theme. It is behavior over time. The learner should be able to explain what the user sees, what the user does, what the system does, and what happens next.

This vocabulary makes the learner sound like a Product Owner with design capability. Instead of saying then there is another page, she can say: this transition happens after the user selects two items; if the count is lower, the flow shows an empty guidance state.

The learner should understand the artifact choice. A journey map is broad and contextual. A user flow is narrower and task-specific. A wireflow combines enough screen structure with flow arrows to show how an interaction works.

For this course, the correct artifact is a beginner wireflow: three low-fidelity screens plus annotated transitions and states. It is not a full service blueprint, and it is not a final design file.

The lecturer can say: journey maps help us understand where this product moment sits; wireflows help us design this product moment.

Task analysis keeps the flow grounded. The learner should ask what the user is trying to accomplish before deciding how many screens exist.

A useful task is specific enough to design. Choose a laptop is broad. Compare recommended laptops and save a shortlist is workable.

The success signal should connect to the task: comprehension, comparison, saved shortlist, reduced confusion, or prototype learning.

A flow boundary protects the exercise from expanding into the whole product. It also helps the learner think about entry and exit conditions.

For the course project, the flow might start after a student answers a needs questionnaire and end when she saves a shortlist. Checkout, payment, account creation, returns, and long-term support are out of scope.

This does not mean those areas are unimportant. It means the current artifact has a clear review boundary.

A screen job is the screen purpose in the flow. It should answer the question: what must this screen help the user understand or do?

Screen jobs prevent duplicate screens. If two screens have the same job, the learner should decide whether they need both. If a screen has no job, it is probably decoration or filler.

A strong screen job is user-centered and action-aware. It does not say show data; it says help the user compare options using the criteria that matter for the task.

The default state is only the beginning. Many weak flows fail because they ignore loading, empty, error, confirmation, and saved states.

State design affects trust. If the user saves an item and nothing clear happens, the flow becomes uncertain. If comparison cannot load and the product loses the shortlist, the flow becomes fragile.

The learner should annotate state notes for each screen, even if she does not draw every state in detail.

Every arrow in a flow should have a label. The label should say what causes the transition: user action, system event, validation result, timeout, selection count, or error.

For example: tap Compare is not enough. The system may need to check whether at least two laptops are selected. If yes, open comparison. If no, show guidance.

This is where product behavior becomes visible. The learner starts to see that a flow is a set of decisions, not a decorative line between pages.

The happy path is useful because it explains the intended experience. It is not enough. Real users hesitate, change their mind, make mistakes, run into missing data, and leave the task.

For this course, the learner should include at least two branch or edge-case paths. One should involve error or recovery.

Recovery paths should preserve progress where possible. They should say what happened, what the user can do, and what the system will remember.

Accessibility belongs across the whole flow. A single accessible screen is not enough if the transition loses focus, the saved state is color-only, or recovery is unclear.

Use the WCAG principles at beginner level: perceivable, operable, understandable, and robust. Then translate them into this flow.

The learner should add one accessibility note per screen and one note for transitions or state changes.

NN/g defines wireflows as combining wireframe-style page layouts with a simplified flowchart-like way of representing interactions. In this course, the learner creates a low-fidelity version.

The wireflow should not try to be visually polished. Its job is to communicate behavior. A teammate should be able to follow what the user sees, what she does, what the system checks, and what happens next.

The most common failure is unlabeled arrows. The tutor should ask: what action or system event makes this arrow happen?

AI can quickly draft a flow, but it often gives clean screens without behavior. The Session 11 prompt is designed to force connected behavior: jobs, transitions, states, branches, rules, dependencies, and readiness.

The learner should compare AI output against the acceptance criteria from Session 10. If the flow does not satisfy those criteria, the flow is not ready.

The tutor should push the learner to ask AI follow-up questions such as: what state is missing, what happens if this data is unavailable, and what would a keyboard or screen-reader user experience during this transition?

The feature brief in this session is intentionally small. It explains the flow so a team can review it. It is not yet the fuller product brief and handoff package of Session 12.

Atlassian PRD guidance is useful because it keeps requirements collaborative and concise: goals, assumptions, user stories, designs, scope, and success criteria.

The feature brief should make the flow understandable without requiring the viewer to infer everything from the sketch.

Use the course project as the worked example. The learner designs a flow from recommendation results to comparison to saved shortlist.

The screen jobs are deliberately plain. Results helps the user understand options. Compare helps the user evaluate them. Shortlist confirms progress and gives a next step.

Add at least two branches: if fewer than two items are selected, show guidance before comparison; if comparison data fails, keep the shortlist and offer retry.

The worked example feature brief should be concise but complete enough to review. It should say what problem the flow solves, what user story it supports, what screens are included, what states matter, and what remains unknown.

The brief should include system rules and dependencies. For example: comparison requires at least two selected laptops; each laptop needs price, battery, weight, required software fit, and availability.

The open questions are part of the value. A good brief does not pretend everything is known. It makes the unknowns visible for Session 12.

The studio output is a 3-screen wireflow and feature brief. The artifact should be low-fidelity but behaviorally rich. It should make the user path, system response, state changes, and unanswered questions visible.

For home study, the learner should repeat the flow exercise on one small task from another familiar product. The emphasis should be on labeled transitions and state notes, not visual polish.

Close by previewing Session 12. The next session turns this flow-focused brief into a fuller product brief with scope, priority, acceptance criteria, risks, and handoff notes.