An AI interface often presents uncertain output with the visual confidence of ordinary software: a polished paragraph appears in the same place as a deterministic result. A small disclaimer cannot carry the full burden of explaining that the content may be incomplete, unsupported, or inappropriate for the current situation.
The interaction should make checking and correction part of the normal task.
Identify the decision around the output
Before choosing components, map what happens next:
generated draft → user reviews → user edits → user confirms → system acts
Enter fullscreen mode Exit fullscreen mode
Then ask:
- Can a weak result be detected by this user?
- What source material is available for checking it?
- Is the next action reversible?
- Who is affected if the result is wrong?
- Does the user have time and authority to review it?
A draft email and an automatically rejected application may use similar model technology but require completely different interaction safeguards.
Match presentation to the output’s role
Use a component that communicates what the result is:
- Draft: editable content with a visible unsent state.
- Suggestion: an option that does not replace the user’s existing value until accepted.
- Classification: a label plus confidence-relevant evidence and an override.
- Answer from sources: a response with passage-level references and a “not found” state.
- Proposed action: a preview of the exact effect, followed by confirmation.
Avoid placing generated text directly into a final, authoritative field. If the user is expected to review it, the design should support comparison and editing rather than hide those steps behind an “AI generated” badge.
Put evidence next to the claim
When the system retrieves sources, show which source supports which part of the answer. A list of links at the bottom makes users hunt for the relationship.
A practical pattern is a claim with an adjacent source control:
The account was upgraded on 8 July. [Source: account event 1842]
Enter fullscreen mode Exit fullscreen mode
Selecting the source opens the relevant passage, not merely the top of a long document. If no supporting passage exists, say so. Do not fabricate a citation or substitute a generic link.
Evidence display also needs access control. A source title or snippet can leak information even when the linked document later returns “forbidden.” Filter before generation and before rendering citations.
Design correction as a first-class path
Correction should preserve momentum:
- let users edit a draft in place;
- provide undo after applying a suggestion;
- keep the original value available for comparison;
- support rejecting one part without discarding the whole result;
- preserve user changes when regeneration occurs;
- ask what was wrong only when feedback is useful and optional.
Be careful with “Regenerate.” It often replaces one opaque result with another and can erase useful edits. Offer targeted controls such as “shorter,” “change tone,” or “retry this section” only when their behavior is clear.
Do not treat acceptance as proof of correctness. Users may accept because reviewing is difficult, the interface is persuasive, or they believe disagreement will be penalized.
Use confirmation to reveal consequences
Confirmation is valuable when it adds information, not when it repeats “Are you sure?”
Before a consequential action, show:
- the exact recipients, records, or systems affected;
- the generated content that will be sent or written;
- any missing required fields;
- whether the action can be undone;
- which identity will perform it.
Keep generation and execution separate. “Create a response” should not also send it. If the product needs automation, define bounded rules and a visible activity history.
Explain uncertainty locally
A permanent warning banner becomes easy to ignore. Put guidance at the point where it changes a decision:
- “Draft—review before sending” beside the send control;
- “No supporting source found” where an answer would appear;
- “Still generating” on incomplete streamed content;
- “Three records could not be classified” beside the affected rows;
- “This action cannot be undone” in the confirmation step.
Avoid vague confidence percentages unless the number is calibrated for the exact task and users understand what it predicts. “82% confident” does not explain whether the missing 18% concerns a harmless phrase or a critical account detail.
Make refusal and failure different
Users need distinct recovery paths for:
- insufficient information: add a source or clarify the request;
- policy refusal: explain the relevant boundary and allowed alternatives;
- technical failure: retry or continue manually;
- permission failure: request access or choose an authorized source;
- cancelled work: keep input and any clearly labeled partial result.
One generic error message hides the next step. It also makes research data less useful because very different events collapse into “AI failed.”
Evaluate the interaction, not only the answer
Output quality tests should be paired with task-level research. Observe whether users:
- notice unsupported claims;
- find and understand sources;
- can make a partial correction;
- know whether content is final or still streaming;
- understand what confirmation will do;
- recover after refusal, cancellation, or timeout;
- retain meaningful control under time pressure.
Include accessibility in the study. Streaming announcements, focus movement, source popovers, difference views, and drag-only interactions can change who is able to review the result.
The paper Guidelines for Human-AI Interaction reports an evidence-based set of guidelines organized around initial use, regular interaction, failure, and change over time. It is a useful prompt for reviews, but the right design still depends on the task’s consequences and the user’s ability to evaluate the system.
Uncertainty does not have to become a vague warning. It can shape the workflow: evidence near claims, edits before action, meaningful confirmation, reversible changes, and specific recovery. Those patterns make user control observable rather than ceremonial.
답글 남기기