The first result takes minutes: what onboarding should show while the product works
Design honest progress, useful waiting states and clear recovery for a new user's first import or generated result, grounded in Carbon and W3C guidance.
In this article
The new user has done their part. They uploaded a file or asked the product to generate something, and now a spinner occupies the place where the first result should be. Carbon’s progress-bar guidance draws a useful line: a determinate indicator belongs to progress the system can calculate; an indeterminate indicator shows activity without claiming a known completion point. The rest of the waiting experience needs the same honesty.
For a first task that takes minutes, the interface should explain what has happened, what remains and whether the person can leave. A moving shape answers only a small part of that problem.
Separate submitted, working and usable
A request being accepted is different from processing starting. Processing finishing is different from a result being available to open. These distinctions become especially important when the task involves a queue, several services or an additional save step.
Consider an illustrative product that creates a report from an uploaded document. A useful state model could look like this:
| Actual state | Suggested message | What the user can do |
|---|---|---|
| Request accepted | “Your document is saved. The report is waiting to start.” | Return to the document or leave if background processing is supported. |
| Processing started | “Creating your report.” | Inspect the status and any supported cancellation control. |
| Part of the output is ready | “A preview is available. The full report is still processing.” | Open the preview with its incomplete status visible. |
| Result saved and available | “Your report is ready.” | Open the result. |
| Processing failed | “The report could not be completed. Your document is still saved.” | Retry from the saved document if the system supports that recovery. |
| Cancellation confirmed | “Report creation stopped.” | Return to the document and choose another action. |
These are proposed messages for the stated conditions. Each promise depends on real product behavior: the document must be saved before the interface says so, and cancellation must be confirmed before the status changes to stopped.
Design the meaningful transitions first. Then choose which ones belong on screen. A person waiting for a report rarely needs every internal processing step, but they do need to know whether the request is progressing, blocked or finished.
A percentage needs a meaningful denominator
A file transfer of known size can have measurable progress. A generation task with unknown duration may not. Carbon recommends using an indeterminate bar when progress cannot be calculated and allows it to become determinate when sufficient information becomes available.
Do not let the first measurable phase stand in for the whole task. A fully uploaded document might still need processing. If the upload reaches its endpoint, name that phase as complete and explain the next phase. Otherwise, a user sees a completed bar beside a result that does not yet exist.
A time estimate needs similar care. If your system can produce a useful estimate, communicate its uncertainty and update it when conditions change. If it cannot, describe the current state and available options. Inventing a precise countdown creates a second failure when it expires.
The same principle applies to stage labels. “Analyzing your document” is appropriate only if analysis is actually underway. Decorative sequences that rotate through plausible activities make it harder to distinguish genuine progress from a stalled request.
Answer whether the user can leave
For a long first task, “Can I close this?” may be more important than “How far along is it?” Answer it near the status, in concrete language.
If work continues in the background, explain where the result will be available on return. If leaving cancels the operation or loses unsaved input, say that before the person leaves. If the product sends a notification, distinguish a configured delivery channel from a guaranteed notification: a useful return path should exist inside the product as well.
For the illustrative report, the result can have a stable home under the saved document. A returning user can then see whether it is still processing, ready or needs attention. The guide to resuming abandoned setup covers preserving progress; here the extra requirement is reconciling the stored task state with what happened while the user was away.
An unchanged browser tab should not be the only record of a job that runs for several minutes.
Make status available without demanding constant attention
W3C’s explanation of WCAG 2.2 Success Criterion 4.1.3 includes waiting, process progress, results and errors within the definition of status messages when they do not change context. Those messages need to be programmatically available so assistive technology can present them without requiring focus to move to the message.
The guidance includes intermittent progress announcements. That is a useful distinction for design: an accessible waiting experience does not require a stream of announcements for every visual update. Decide which changes matter to the task, such as processing beginning, a recoverable problem appearing or the result becoming available.
Keep a readable status on screen as well. Avoid relying on color or animation alone to distinguish failure from activity. For an error, name what failed and what remains usable. “Something went wrong” is especially unhelpful when the person does not know whether submitting again would duplicate work.
Cancellation and retry deserve their own states
A cancel button can create a new period of uncertainty. If the product has asked a background service to stop but has not received confirmation, show that request as pending. Do not immediately replace the work with an empty state that implies the operation never happened.
For retry, preserve the input and explain what will run again. In the illustrative report flow, a failure during generation should not automatically force the user to upload the document again if the original is intact. If a previous result remains available, distinguish it from the new attempt.
Those choices belong in the interaction design before error copy is written. Copy cannot resolve a product that does not know whether it saved the input, started a second attempt or canceled the first.
Review the experience under delay and failure
A fast successful run hides most of the waiting design. Test deliberately delayed, failed and interrupted tasks in a controlled environment. Leave the page and return. Inspect what happens if the result arrives while the user is elsewhere, and whether the first meaningful action is still easy to find.
For a usability session, ask the participant to explain the current state and decide what to do next. Their answer tells you whether the interface communicates enough to act. Separately measure the actual processing time and the time from result availability to useful action. A better status display can make the task clearer; it does not make the underlying processing faster.
The useful ending is the result and its next action. Let the waiting interface give way to that work as soon as the result is available.
Sources
- Carbon Design System: Progress bar guidelines.
- W3C: Understanding Status Messages, WCAG 2.2 SC 4.1.3.
