Breaking flows into steps with one task per screen

What it is

Breaking a complex flow into multiple steps with a single task per screen is really a judgment call about granularity — how far to split, and how much belongs on one screen. The test is whether a screen contains two or more independent actions where completing one has nothing to do with completing the other, not a rule that every flow must be mechanically chopped into many steps.

Why it happens

When a single screen carries several pending tasks at once, the user has to hold "what's done, what's left, which one am I on" simultaneously in mind, and that maintenance burden steepens as the number of tasks grows — once it exceeds what a person can currently keep track of, items get skipped or repeated. Splitting a complex flow into one task per screen shifts the burden of tracking task state from the user's head to the interface itself: the current screen is the current task, and the act of moving to the next screen marks progress on its own, with no extra attention required to track it.

Where it stops holding

Splitting is not better the finer it gets — over-splitting stretches the total step count, forcing users to additionally remember roughly how many steps remain, and paging itself becomes a burden. For experienced users who want to move quickly, an over-decomposed multi-step wizard can turn what used to take seconds into a dozen taps. This adaptation targets complex, infrequent flows containing multiple independent decisions; it doesn't apply to actions that are already a single step, and not every older user wants finer decomposition — users who read and decide quickly may prefer seeing all the information at once.

Applying it

• The concrete test for whether a screen should be split: if it contains two or more independent actions where neither depends on the other for completion (say, "change shipping address" and "change payment method" appearing on the same screen), split them into separate screens or clearly delineated steps.
• Give a clear progress indicator on every step (step N of M) rather than requiring the user to judge how much remains on their own.
• Show information that needs to carry over between steps directly, instead of requiring the user to recall it — if a later step needs something entered earlier, bring that value forward and display it.
• Verification: record users completing the flow and count how often they page back to re-check earlier information. Frequent back-paging means the current split granularity or information display hasn't actually reduced the memory burden — it has just relocated content across screens — and the split points or cross-step information display need to be reworked.

Related

• Same group: A11.03.3 adjustable or dismissible timeouts · A11.03.5 persistent, visible undo affordance
• Nearby: A11.01 age-related capability change · A6.02 limits on working memory capacity
• Search terms: single-task screen · wizard flow · progressive disclosure