Phase labels should describe real work rather than technical jargon
Aliases: phase label · user-centered language · technical jargon · progress copy
What it is
User-centered progress labels name stages with work, results, or waiting reasons people understand—“checking whether files can be used,” “uploading photos,” “preparing to publish”—rather than “serializing,” “building an index,” or “running a worker.” A phase label is not an architecture display. It helps people explain what happens, why waiting is needed, whether it relates to their goal, and what to do when it fails. Technically accurate jargon that supports none of these judgments adds no progress value.
Why it happens
People use labels to form a process model and anticipate action. Internal terms have no connection to their objects, goals, or consequences, forcing guesses about normality, risk, and intervention; technical knowledge differences yield divergent interpretation. Naming actual work translates state into action: “checking” implies issues may still emerge, while “publishing” implies impending external visibility. Good labels reduce uncertainty instead of adding a log line that must be decoded.
Studying it
Compare technical, overly abstract, and task-language labels. At each stage, ask participants what the system does, whether they should wait, what follows, and how to respond to failure. Measure correct explanation, help seeking, anxiety, and recovery, not just term familiarity. Include varied expertise and localized versions; developer-recognizable abbreviations often hide ordinary users’ gaps. Also verify that wording matches real behavior rather than using friendly wording to conceal different work.
Where it stops holding
User-centered does not mean deleting technical information. Expert tools, diagnostic views, and support flows may expose IDs, protocols, or module names, but as expandable detail rather than the sole phase label. Excessively colloquial text can obscure consequence: “processing” does not reveal whether the system uploads, deletes, or reviews. Labels should be brief yet specific, identifying user object and work intent without promising an unproduced result.
Applying it
- Write every phase so users can answer “what is the system doing to what?” Move internal services, queues, and implementation detail to diagnostic or expanded layers.
- Align labels with cancellability, failure, and result; avoid vague words that cannot guide action.
- Maintain object-and-verb vocabulary—for example, photos, orders, or reports—rather than changing to technical entity names by phase.
- In mid-task comprehension tests, ask why waiting occurs and what comes next. If people only repeat jargon or cannot judge risk, rewrite labels rather than add decoration.