A stuck task must identify the specific phase rather than merely ask users to wait
Aliases: stuck phase · progress stall · diagnostic feedback · task recovery
What it is
Phase-specific stall feedback identifies the work phase that exceeded normal waiting or cannot continue, what already completed, and what a person can do next, instead of offering only “please wait” or a continuing spinner. People must distinguish slow upload, failed validation, approval wait, disconnection, and system fault because their waiting value, recovery method, and responsible party differ. Generic waiting compresses all problems into one black box and supports neither trust nor action.
Why it happens
A stall breaks not only speed but process explainability. With a motionless total indicator, people cannot decide whether to wait, retry, inspect input, change network, contact support, or cancel; uncertainty produces refreshes, duplicate submission, and abandonment. Phase labels and status evidence localize an anomaly, turning “the system is broken” into a diagnosable work node. Even without automatic repair, a known point prevents actions that worsen the problem.
Studying it
Inject delay, disconnection, rejection, and recoverable failure into upload, validation, server work, review, and publication separately. Compare generic waiting with phase-specific feedback for waiting decisions, recovery, duplicate submission, and quality of support requests. Record whether people identify the current point and available options, and whether they blame the wrong object. Error display alone is insufficient; information must produce a correct, safe next action.
Where it stops holding
Do not invent a precise cause while diagnosis is uncertain. If the system only knows it lacks a next-phase signal, say what it waits for and provide safe checking or exit. Nor must every user see a full technical stack: retain object and work meaning in phase labels and put codes in expandable detail. Brief normal variation should not repeatedly alarm people, which creates anxiety and notification fatigue.
Applying it
- Define normal duration range, timeout detection, visible evidence, and transition to stalled/failed state for each phase rather than freezing total progress indefinitely.
- On stall, show the phase, completed work, possible external wait, and choices such as wait, retry, check connection, save and leave, or contact support.
- State retry safety, cancellation loss, and whether work continues after exit so recovery is not guessed.
- Validate through failure drills: users should locate the stall, choose a safe remedy without duplicated side effects, and provide useful phase information to support.