How do I write a progress indicator label that explains where users are in a flow?

Start with what the person is doing at each stage, not what your team calls the page or system. A useful label is brief, recognizable, and distinct from neighboring labels. For example, “Your details” tells a user more than “Step 1,” while “Review” is more informative than “Step 3.”

Write down the sequence users actually follow, including any optional or conditional stages. Then name each stage using a consistent pattern: task phrases such as “Choose items,” “Enter details,” and “Review order,” or concise names such as “Selection,” “Details,” and “Review.” Avoid mixing styles without a reason, such as a noun like “Account” beside an instruction like “Enter payment.”

Describe the stage, rather than promising an outcome. If users can still edit information during review, “Review” may fit better than “Final confirmation.”

Choose the style that suits the space and the amount of explanation users need, then use it consistently. Short names can work when the task is familiar and the screen gives more context. Action labels can help when the stage is less obvious. Keep labels compact, but not so abbreviated that users need insider knowledge to understand them.

Make the current position identifiable in the interface, not just inferable from the label’s place in a row. Keep the level of detail similar across stages; avoid making the current stage unusually descriptive while the others are cryptic. If you use numbers, check that they correspond to the stages on that user’s path.

For example, a simple order flow might use “Cart,” “Delivery,” “Payment,” and “Review.” When the user is on the payment screen, the indicator should identify “Payment” as the current stage. Don’t assume that position alone will make this clear.

Map each meaningful path before settling on the indicator. Mark stages that are optional, skipped, or revisited, and ask whether a fixed linear sequence would mislead users. If paths differ, don’t force them into one numbered sequence merely for visual uniformity. A label can name a stage, but it cannot by itself explain a complicated route change.

Copy this worksheet and add a row for each stage on each relevant path:

Flow or task: [name] Path: [describe who follows it]

1. Order on this path: [number]

What the user does: [task or decision] Draft label: [short label] Optional, skipped, or revisited: [note] Does the label fit this path and screen? [yes / revise]

Example, assuming a simple order flow:

1. Choose items — “Cart”
2. Arrange delivery — “Delivery”
3. Pay — “Payment”
4. Check the order — “Review”

If some users don’t need delivery, record that as a different path and check whether the indicator remains accurate for them.

Read the labels in sequence without looking at the screens. They should sound like stages of one journey, not unrelated page titles. Then compare them with the actual screens and routes: each label should match what users do there, and the current-stage treatment should match the screen being shown.

Use this consistency check:

1. Put stages in the order users encounter them on each path.
2. Use one naming style throughout: task phrases or concise names.
3. Replace internal terms, vague labels, and near-duplicates.
4. Check optional, skipped, branched, and revisited stages against each path.
5. Confirm the current-stage wording and visual treatment match the user’s position.

For the handoff, include the label list, the path or paths it applies to, and any assumptions that still need confirmation. This gives reviewers context to catch a label that sounds clear alone but doesn’t fit the user’s sequence.