AI UX Design Patterns: Loading, Confidence and Undo

An AI feature changes the relationship between an action and its result. A user can request a summary and receive something plausible but incomplete, or ask for an edit that finishes after they have moved elsewhere. Good interaction design makes those uncertainties manageable instead of hiding them behind a sparkle icon.

Loading, confidence and undo belong to one system: they explain what is happening, what deserves trust and what can be reversed. Design them together around the consequences of the task, not as independent visual components added at the end.

Map states before drawing the happy path

Start with a state inventory that includes idle, validating input, queued, working, partial result, complete, cancelled and failed. Not every feature needs every state, but each state you expose should correspond to an observable event. Distinguish a failed request from a completed request that produced no useful result.

Describe what users can do in each state. Can they edit the input while generation runs? Does leaving the page cancel the job? Will the result arrive elsewhere? These decisions affect the data model and interface together. A disabled button cannot communicate the whole lifecycle of a background operation.

Write a short state contract before implementation:

Working: input snapshot is fixed; Cancel remains available.
Cancelled: no new result will be applied; original content remains.
Complete: result is a preview until the user selects Apply.
Failed: input is preserved; Retry creates a new attempt.

Use the AI UI design tools directory to explore prototypes, but keep this contract outside any generated screen. State ownership must be explicit: the application decides whether content was saved, not a language model's statement that it saved something. This separation prevents convincing text from masquerading as a completed operation.

Show honest progress without inventing precision

For short waits, a compact status can be enough. For longer work, explain the current stage and whether the user may leave. Use determinate progress only when you have a meaningful denominator, such as completed files out of a known batch. Generated token counts rarely predict how much reasoning or tool work remains.

Avoid staged messages that imply checks the system did not perform. “Reviewing accuracy” is misleading if the application simply waits for a response. Prefer “Generating a draft” and then describe the review the user should perform. If retrieval, validation or export genuinely happens, show those stages as they occur.

Offer cancellation when the underlying operation can be stopped or its result safely discarded. Explain the distinction if stopping the interface does not stop billable server work. Cancellation semantics matter especially when jobs trigger external actions. A stopped animation must not imply that an email or payment has been cancelled.

Announce meaningful status changes without repeatedly interrupting assistive technology. The W3C status-message guidance helps teams plan non-disruptive announcements. Test the actual implementation with a screen reader; a visually unobtrusive spinner may still produce an exhausting stream of repeated announcements.

Replace vague confidence with usable evidence

A percentage beside an answer looks precise, but users need to know what it measures. Model confidence, source coverage and historical task accuracy are different concepts. A model's self-reported certainty is not a calibrated probability of correctness. Do not convert reassuring language into an authoritative score.

Prefer evidence that supports the user's next decision. For a policy answer, show the relevant document passage and its date. For an extracted invoice field, show the original region alongside the proposed value. For a generated layout, label assumptions and missing requirements. The right evidence depends on the task, not on a universal confidence component.

If you do display a score, explain its basis and limitations in language appropriate to the audience. Validate any threshold against representative data, including difficult and minority cases. A high overall score can conceal poor performance on the very cases that carry the greatest consequences.

The NIST AI Risk Management Framework provides a useful basis for thinking about measurement and oversight. Translate that into review requirements: which results can be accepted quickly, which need source inspection and which must never be acted on automatically. Evidence should help people disagree with the system, not merely persuade them to trust it.

Make application and undo separate decisions

For content changes, use a preview before applying the result. Show the affected scope and, where useful, a difference view. Rewriting one paragraph should not silently replace the whole document. Bounded application lets users understand the consequence before committing and reduces the recovery burden afterwards.

Define what undo restores: text, formatting, selection, related records or all of these. Keep the original snapshot until the reversal window closes. If other collaborators can edit the same content, determine whether undo restores a historical version or applies a compensating change without erasing their work.

Some actions cannot be meaningfully undone. A sent message can be followed by a correction, but the recipient may already have read it. A published secret may remain cached even after removal. Use explicit confirmation and permissions for these operations instead of treating an undo toast as a universal safety mechanism.

The AI chat interface guide extends this separation to conversational actions. Apply the same principle outside chat: accepting a recommendation, saving it and executing it are different decisions. Label controls with the real action, such as “Apply to selected paragraph,” rather than a vague “Looks good.”

Test the awkward transitions and visual signals

Run tests where cancellation races with completion, a retry follows a timeout and a user changes the source while a result is generating. Preserve input provenance so the interface can say which version produced the output. If the source has changed, warn before applying stale suggestions or regenerate against the current version.

Use the contrast checker to test status text and action labels against their actual backgrounds, including warning banners and disabled-looking secondary controls. Then add text or icons with accessible names so colour is not the only signal. Passing contrast alone does not make a state understandable.

Follow the WCAG guidance on use of colour when distinguishing success, uncertainty and failure. Check forced-colour modes, zoom and reduced-motion preferences. An animated glow may be decorative; the operation's status must remain available when that effect disappears.

Evaluate recovery with real tasks rather than asking whether the interface feels trustworthy. Can someone identify an unsupported result, restore the original and try a better input? Record incorrect acceptance, failed reversals and abandoned retries. Those observations tell you more about effective user control than a satisfaction score collected only after successful runs.

Key takeaways

• Define observable states and the actions available in each one before styling components.
• Show measured progress only when the underlying operation supports it.
• Prefer inspectable evidence to unexplained confidence percentages.
• Separate preview, application and consequential execution, with explicit reversal rules.
• Test cancellation races, stale results and accessible status communication together.