User Experience
Improve perceived speed with honest progress feedback
Progress feedback should reduce uncertainty without inventing completion or hiding slow work. Distinguish accepted, queued, processing, and finished states, and choose indicators that reflect what the application can actually measure.
A moving indicator can confirm that an application noticed an action, but it cannot prove that the requested work is complete. Customers need to understand whether an operation is waiting, advancing, blocked, or finished. Design progress feedback around those distinctions. Treat improved confidence as a design goal, not an unmeasured claim that animation makes the underlying service faster.
Separate acknowledgement from completion
After a user starts a long operation, acknowledge the request in terms the business understands. If the request enters a queue, say that it is queued. If processing starts, identify the stage. Do not label a successfully received request as a completed export, import, or approval.
Define the authoritative completion event with the engineering team. For an export, that may mean a usable file is ready rather than a worker merely starting. Show the final result or a way to retrieve it. If the process can finish after the user leaves, explain where to check later.
Choose an indicator that matches the evidence
Use a percentage only when the product has a meaningful total and a reliable completed portion. If work size is unknown, a plain stage message can be more honest. Explain a pause when the system knows the reason, rather than advancing a decorative bar toward an unsupported finish.
WAI includes waiting and process progress within its discussion of status messages.[3] Such messages can be made available to assistive technology without moving focus.[3] Its examples include intermittent progress announcements.[3] Plan announcements around meaningful changes, and test that updates do not overwhelm the user with repetitive detail.
Hypothetical example: importing an asset register
A hypothetical office imports an asset register. The interface first confirms file receipt, then reports validation, then importing. Validation identifies rows that need correction. The result distinguishes accepted rows from rejected rows instead of presenting an unconditional success message.
If the connection drops during importing, the interface offers a status check tied to the existing operation. It does not immediately encourage uploading the file again. A cancel action appears only if cancellation is genuinely supported, with an explanation of whether already accepted records remain.
Review slow and interrupted paths
Simulate a queue, a long processing stage, partial failure, and a lost connection during acceptance. Ask users what they think the application is doing and whether they would repeat the action. Compare their interpretation with the actual system state.
Detailed feedback adds implementation work and depends on reliable backend signals. Where those signals are absent, state uncertainty plainly. Visual polish cannot replace performance investigation or a real recovery route.
- Distinguish receipt, queueing, processing, and final completion.
- Use percentages only when a meaningful total is available.
- Provide a durable place to check long-running work.
- Test progress announcements without stealing the current focus.
- Explain partial results, cancellation limits, and uncertain outcomes.
