Screen Flow / Wireflow

A screen flow shows the sequence of ACTUAL screens a user moves through, with the interaction that causes each transition. Where a user flow abstracts steps ("Enter payment"), a screen flow shows the screen itself and what on it was tapped. The mature form is the wireflow — NN/g's term for a deliverable that "combines wireframe-style page layout designs with a simplified flowchart-like way of representing interactions" ("Wireflows: A UX Deliverable for Workflows and Apps," Laubheimer, 2016, nngroup.com/articles/wireflows/).

When to use

After wireframes exist. A screen flow without screens is just a user flow with boxes renamed — do the task flow and user flow first, wireframe the steps, then wire the frames.
NN/g's fit guidance: wireflows shine for apps built around a few core screens that change dynamically with interaction; they work poorly for large sets of relatively static linked pages (use a flowchart or sitemap there — same article).
Before handoff: a wireflow is the spec that tells engineering what happens between the mockups, which static mocks never say.
For usability-test planning: the wireflow is the clickable-prototype shot list.

What it answers

Which screen comes next, triggered by what? What does the user see during the transition (spinner? skeleton? nothing?)? Which changes happen on the same screen vs. a new one? How many screens is this task on a phone, really?

What it includes

Actual screens (wireframe or higher fidelity), in sequence, with arrows annotated with the triggering interaction ("tap Save").
Transient states, not just destinations — this is where screen flows earn their keep. Loading states (spinners, skeletons, disabled-while-busy buttons), modals and sheets, toasts/snackbars, inline validation, empty states, keyboard-open layouts, permission dialogs. Each is something the user sees; if it's not in the flow, it won't be designed and engineering will improvise it.
Same-screen changes (a panel expands, a list filters) drawn as arrows that loop back to a modified version of the same screen.
Error and abandonment branches with their actual UI (the error toast is a screen state, not a footnote).

Mobile screen-count reality

What is one page on desktop is routinely three to five screens on mobile: small viewports split forms into steps, master–detail becomes list → detail, and modals become full screens. Add system surfaces the flow must survive — permission prompts, share sheets, the keyboard — and a "simple" mobile task can be a dozen distinct screen states. (Convention/observation, not a study finding.) Count them in the wireflow before committing to "it's just one screen"; the count is a scoping tool.

How to build one

Take the agreed user flow and the wireframes for its steps.
Lay screens left-to-right in happy-path order; annotate every arrow with its trigger (tap/swipe/submit/auto).
For each transition ask: what fills the gap? Add the loading state.
For each screen ask: empty, error, and success variants? Add the ones users will actually see.
Add error/abandon branches with their real UI (modals, toasts).
Number screens for reference in tickets ("see wireflow S4").

Common mistakes

Only ideal navigation — no loading, no failures, no empty states. The gaps get invented in code review instead of design.
Using a wireflow for a 60-page mostly-static site (NN/g's anti-case; use a sitemap + a few targeted flows).
Too high fidelity too early — polished mocks make people critique colors instead of sequence.
Toasts and modals missing because "they're not screens." They're what the user sees; they're in scope.
Letting the wireflow rot after screens change — a stale wireflow actively misleads engineering.

Example — update notification preferences (mobile app)

S1 [Login]
  tap "Sign in" → (S1a: button spinner, fields disabled)
    ├─ success → S2 [Dashboard]
    │             (S2a: skeleton list while data loads)
    │             (S2b: empty state if no projects — see 20)
    └─ failure → S1 + inline error, entered email preserved   [error]

S2 [Dashboard]
  tap avatar → (S2c: account sheet slides up) → tap "Settings"
    → S3 [Settings]  (S3a: brief skeleton on slow connections)

S3 → tap "Notifications" → S4 [Notification Preferences]
S4 → toggle "Processing complete" ON → tap "Save"
  → (S4a: Save disabled + spinner)
    ├─ success → (S4b: toast "Preferences saved", auto-dismiss ~4 s;
    │             user stays on S4)                            ✓ GOAL
    └─ failure → (S4c: toast "Couldn't save — Retry" with action;
                  toggles keep the user's chosen values)       [error]

Abandon: system back from S4 with unsaved changes
  → (S4d: modal "Discard changes?" — Keep editing / Discard)  [abandonment]

Transient states S1a, S2a–c, S4a–d are the difference between a screen flow and a slideshow. Combine with a state flow when one screen (S2's list) has enough states to deserve its own map, and an error flow for the login-failure branch.

Checklist

Built from existing wireframes, ordered by the agreed user flow.
Every arrow labeled with its triggering interaction.
Every transition gap filled: loading/skeleton/disabled states.
Modals, sheets, toasts, and keyboard-open states drawn.
Error and abandonment branches show their actual UI.
Empty states included for any list/data screen.
Screens numbered for reference in tickets and test plans.
Mobile screen count tallied and sanity-checked against scope.
A named owner keeps it current as screens change.

Sources

Nielsen Norman Group — "Wireflows: A UX Deliverable for Workflows and Apps" (Laubheimer, 2016), nngroup.com/articles/wireflows/ — definition, fit, and anti-fit cases cited above.
Nielsen Norman Group — "UX Mapping Methods Compared: A Cheat Sheet" (Gibbons), nngroup.com.
Mobile screen-multiplication and the S-numbering scheme are working conventions, not published standards.