D1.13.1Staged progressdesignresearch

A multi-stage task needs to show its current phase, not only total progress

Aliases: phase indicator · multi-stage task · progress stages · task status

What it is

Staged progress separates a long task with qualitatively different steps into user-comprehensible phases and marks the current one—for example, “prepare files → upload → validate → publish.” Total progress says how far overall work came; a phase indicator says what the system is doing now. In import, installation, generation, payment, publishing, and synchronization, that distinction determines whether people can understand waiting, diagnose abnormality, anticipate next steps, and know when intervention is possible.

Why it happens

Stages differ in unit cost and failure mode: upload depends on network, validation may be brief but mandatory, and review may wait for an outside system. A single total bar compresses these into one number, leaving people unable to interpret a pause or speed change. Phase labels supply causal explanation and local reference points, connecting present behavior to reasonable uncertainty and preventing a slow step from looking like total failure. A phase is a user process model, not a technical log.

Studying it

Compare total-only, phase-plus-total, and phase-plus-actionable-state versions of the same task. Measure judgment of current work, next step, cancellability, and abnormal location. Inject delay or error into individual phases to see whether people identify the problem and choose recovery. Ask mid-task “what is it doing, why could it be slow, and what can you do now?” rather than only asking whether the UI is liked.

Where it stops holding

Not every internal step deserves exposure. Over-segmentation turns implementation detail, fleeting moments, and unstable retries into noise. Split where task meaning, waiting experience, or actionability changes—not by service-call count. If phases may be parallel, reversible, or dynamic, describe current scope honestly rather than drawing a falsely linear pipeline.

Applying it

  • Divide phases by user-comprehensible work purpose and define each start, finish, failure, cancellation, and leave condition.
  • Show current phase with overall scope; explain or provide remaining information for phases with very different durations.
  • Locate recoverable errors to a phase with its own retry, back, or alternative action instead of a generic failure.
  • Test slow, failed, and background-resume cases in every phase. People should identify where work stopped and what to do next.

Related

  • Within the group: D1.13.2 Linear bars mislead with unequal phase duration · D1.13.3 Phase names should describe real work · D1.13.4 Identify a stuck phase specifically
  • Adjacent: D1.08 Loading and progress · D1.11.4 Intervening state for long tasks
  • Search terms: staged progress · phase indicator · multi-stage task

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/D1.13.1