UX Patterns Guide
UI + UX AI And Automation UX emerging

Correction feedback

Provide a correction feedback flow that binds feedback to the exact AI output or claim, captures the error reason and expected correction, lets users choose scope and consent, confirms receipt, routes review when needed, and keeps feedback history visible without exposing private notes.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users can identify wrong, unsupported, stale, unsafe, biased, irrelevant, or wrongly sourced AI output after it is generated.
  • The product can preserve correction context and route feedback to answer repair, source review, reviewer triage, product quality, or model improvement workflows.
  • Corrections may be sensitive enough to require consent, private notes, retention boundaries, review status, or appeals.
  • Users need trust that their correction was received and will not silently disappear.

Avoid when

  • The only need is a lightweight satisfaction signal that will not be used to correct AI behavior or output.
  • Users are editing a generated draft directly rather than reporting what the AI got wrong.
  • Users want another answer version and do not need to describe a correction.
  • The product cannot preserve answer identity, scope, consent, or privacy around the feedback.
  • Feedback would create unsafe expectations of immediate model learning or source correction that the system cannot honor.

Problem it prevents

AI products need user correction when generated output is wrong, unsafe, unsupported, stale, or mis-scoped, but vague feedback controls often lose the corrected claim, user intent, consent, privacy boundary, and follow-up status.

Pattern anatomy

What a strong implementation has to make clear

User need

A user may need to correct a factual answer, cited source, generated recommendation, tool-derived value, safety-sensitive suggestion, outdated policy answer, tone, scope, or missing caveat.

Pattern promise

Provide a correction feedback flow that binds feedback to the exact AI output or claim, captures the error reason and expected correction, lets users choose scope and consent, confirms receipt, routes review when needed, and keeps feedback history visible without exposing private notes.

Required state

Initial AI answer state with feedback entry points attached to the answer, individual claims, citations, recommendations, or tool-derived values.

Recovery path

Users cannot tell what AI answer, claim, source, or version their correction refers to.

Access contract

Expose selected claim, selected source, reason, scope, privacy choice, submission state, receipt, review state, and outcome as text.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • An assistant answer lets a user select a suspect claim, choose Wrong answer, add the expected answer and corrected source, opt out of training use, and see Feedback received with review routing.
  • A policy answer card shows Missing source and Harmful suggestion feedback choices, keeps the private note out of the shared transcript, and records reviewer outcome in feedback history.
  • A user flags a wrong eligibility answer, attaches the correct policy source, applies the correction to the current answer only, and receives a reviewer-routed status.
  • A support analyst marks an AI suggestion as outdated, keeps the feedback private, opts out of training use, and later sees the correction accepted in the answer history.
Weak implementation

Vague, hidden, hard to recover from

  • A thumbs-down icon accepts feedback with no selected answer, reason, expected correction, privacy choice, receipt, or indication of whether anything will change.
  • A correction box secretly rewrites the hidden prompt, trains on private feedback without consent, and never tells the user whether the correction was reviewed.
  • A user reports that a cited source is wrong, but the feedback is stored as an undifferentiated dislike and future answers keep using the same bad source.
  • A user writes sensitive context in a correction note and the product exposes it in the public conversation transcript.
UI guidance
  • Render correction feedback as an AI-output control that anchors feedback to a specific answer, claim, source, recommendation, tool result, or message instead of a detached thumbs signal.
  • Show selected claim, feedback reason, expected correction, source correction, privacy note, scope choice, training or review consent, submission state, and follow-up status in the same flow.
UX guidance
  • Use correction feedback when users need to tell the product that an AI answer is wrong, missing evidence, harmful, outdated, wrongly sourced, irrelevant, or should not be repeated.
  • Separate correction capture from regeneration and manual editing: users should know whether their feedback updates this answer, future answers, reviewer queues, model improvement data, or none of those.
Implementation contract

What the implementation must handle

States

  • Initial AI answer state with feedback entry points attached to the answer, individual claims, citations, recommendations, or tool-derived values.
  • Wrong answer, missing source, wrong source, harmful suggestion, outdated answer, irrelevant answer, biased or unsafe answer, hallucinated value, and incomplete answer reasons.
  • Selected claim, selected source, expected answer, corrected source, private note, attachment, and reviewer-needed states.
  • Scope choices such as apply to this answer, apply to future answers, review only, update source, do not train on this feedback, and keep feedback private.

Interaction

  • A correction feedback action preserves answer ID, response version, claim span, source ID, user reason, expected correction, submitter, timestamp, and chosen scope.
  • Reason choices remain specific enough to route feedback: wrong answer, missing source, wrong source, outdated answer, harmful suggestion, unsafe or biased output, irrelevant answer, and other correction.
  • Users can add expected answer text, corrected source, or a private note, and the UI states which of those fields may be used for review, source improvement, prompt improvement, model improvement, or current-answer repair.
  • Scope controls distinguish this answer, future answers, reviewer triage, source update, and training use; defaults must not hide consequential data use.

Accessibility

  • Expose selected claim, selected source, reason, scope, privacy choice, submission state, receipt, review state, and outcome as text.
  • Do not rely on thumbs color, reaction icons, or animated confirmation alone to communicate that feedback was captured.
  • Make claim selection, reason choices, source correction, expected answer entry, privacy controls, Submit feedback, Cancel, View history, and Appeal keyboard reachable.
  • Announce status changes such as feedback submitted, failed to submit, reviewer routed, accepted, rejected, appealed, or private note kept out of transcript without moving focus unexpectedly.

Review

  • What exact answer, claim, source, recommendation, or tool result is being corrected?
  • Can the user state whether the problem is wrong answer, missing source, wrong source, harmful suggestion, outdated answer, biased output, or another correction?
  • Does the user know whether the correction affects this answer, future answers, review only, source quality, prompt behavior, or training use?
  • Where does private correction text appear, and what prevents it from leaking into shared transcripts or generated output?
Interactive lab

Inspect the states before you copy the pattern

Correct an AI result without losing scope

Inspect correction feedback, wrong answer, missing source, wrong source, harmful suggestion, outdated answer, user correction, feedback reason, selected claim, source correction, expected answer, private note, send feedback, feedback received, apply to this answer, apply to future answers, reviewer routed, training opt-out, appeal decision, feedback history, mobile feedback, and compare thumbs-only, no-scope, silent-learning, prompt-confusion, lost-correction, public-leak, and no-follow-up failures.

Correction feedback
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Initial AI answer state with feedback entry points attached to the answer, individual claims, citations, recommendations, or tool-derived values.

Keyboard / Access

Tab reaches answer-level feedback, claim-level feedback, reason options, expected answer, corrected source, private note, scope controls, training opt-out, submit, cancel, history, and appeal in order.

Avoid Generating

Using a thumbs-down or smiley reaction as the only mechanism for correcting wrong AI output.
Evidence trail

Source-backed claims behind this guidance

People + AI Guidebook

Google PAIR - checked

Supports human-centered AI feedback, expectations, explanation, and trust decisions.

OpenAI conversation state guide

OpenAI - checked

Supports preserving conversation, message, response, and tool identity for attaching correction feedback.

Full agent/debug reference

Problem Context

  • A user may need to correct a factual answer, cited source, generated recommendation, tool-derived value, safety-sensitive suggestion, outdated policy answer, tone, scope, or missing caveat.
  • The same feedback can mean apply a fix to this answer, avoid repeating the behavior, route to a reviewer, improve retrieval sources, update prompt instructions, improve model data, or simply record user dissatisfaction.
  • Feedback may contain private, sensitive, regulated, customer, patient, legal, financial, or internal business information that must not appear in shared transcripts or training data without consent.
  • AI corrections are valuable only when they preserve answer ID, claim span, source ID, conversation context, model response version, user reason, expected answer, and outcome.
  • Some corrections require human review, audit trails, appeals, retention limits, or disclosure that the current answer will not change immediately.

Selection Rules

  • Choose correction feedback when users need to correct AI output, source use, assumptions, recommendations, safety behavior, or answer quality after an AI response is shown.
  • Use query correction when the product rewrites or suggests a search query before results are returned.
  • Use inline validation when the product flags a single form field, input value, format, or constraint violation.
  • Use comments when the main task is human discussion, annotation, approval, or durable collaboration around an object rather than feeding back to an AI system.
  • Use regenerate / retry when users want another AI attempt or response version without necessarily supplying a correction reason.
  • Use editable AI output when users directly edit the generated draft itself and need change tracking or apply controls.
  • Use source grounding display, citation display, or confidence uncertainty display when the task is inspecting evidence or uncertainty rather than sending a correction.
  • Capture selected answer, selected claim, selected source, feedback reason, expected answer, corrected source, privacy note, scope, consent, and receipt before treating correction feedback as actionable.
  • Do not use thumbs-only, sentiment-only, star rating, or undifferentiated reaction controls as the only path for correcting materially wrong or unsafe AI output.
  • Do not silently train on correction text, rewrite hidden prompts, publicize private notes, or imply the current answer changed unless the user can see the corrected output.

Required States

  • Initial AI answer state with feedback entry points attached to the answer, individual claims, citations, recommendations, or tool-derived values.
  • Wrong answer, missing source, wrong source, harmful suggestion, outdated answer, irrelevant answer, biased or unsafe answer, hallucinated value, and incomplete answer reasons.
  • Selected claim, selected source, expected answer, corrected source, private note, attachment, and reviewer-needed states.
  • Scope choices such as apply to this answer, apply to future answers, review only, update source, do not train on this feedback, and keep feedback private.
  • Submitting, feedback received, failed to submit, duplicate feedback, queued for review, accepted, rejected, partially applied, appealed, and feedback history states.
  • Permission, authentication, rate limit, abuse-prevention, moderation, sensitive-data warning, and retention-disclosure states.
  • Mobile correction sheet state that keeps the selected claim, reason, scope, consent, and receipt visible without losing the answer context.

Interaction Contract

  • A correction feedback action preserves answer ID, response version, claim span, source ID, user reason, expected correction, submitter, timestamp, and chosen scope.
  • Reason choices remain specific enough to route feedback: wrong answer, missing source, wrong source, outdated answer, harmful suggestion, unsafe or biased output, irrelevant answer, and other correction.
  • Users can add expected answer text, corrected source, or a private note, and the UI states which of those fields may be used for review, source improvement, prompt improvement, model improvement, or current-answer repair.
  • Scope controls distinguish this answer, future answers, reviewer triage, source update, and training use; defaults must not hide consequential data use.
  • Submission creates an accessible receipt and a visible follow-up path when review or appeal is possible.
  • Private feedback does not appear in shared transcripts, public comments, copied output, generated summaries, or source snippets unless the user explicitly publishes it.
  • If a correction changes the displayed answer, the UI shows the corrected version, prior version, author or reviewer status, and what changed.
  • If the correction cannot change the answer, the UI says so and avoids implying immediate model learning.

Implementation Checklist

  • Model correction feedback with answer ID, response version, claim span, source ID, tool output ID, reason, expected answer, corrected source, private note, scope, consent, status, reviewer owner, and history fields.
  • Provide claim-level selection and source-level selection so users do not have to describe what the correction refers to in free text alone.
  • Route wrong answer, source correction, harmful suggestion, outdated answer, missing source, and sensitive feedback to different handling paths when product risk requires it.
  • Persist feedback receipts and outcomes so users and reviewers can see whether a correction is queued, accepted, rejected, partially applied, appealed, or closed.
  • Keep training consent, privacy controls, retention language, and shared-transcript behavior explicit before submission.
  • Prevent duplicate submissions, lost feedback, cross-answer attribution, public leakage, hidden prompt edits, and unreviewed automatic current-answer changes.
  • Test desktop and mobile correction capture, selected claim wrapping, long corrected source titles, private note handling, disabled submit states, failed submission recovery, review status, appeal, keyboard operation, and screen-reader status announcements.

Common Generated-UI Mistakes

  • Using a thumbs-down or smiley reaction as the only mechanism for correcting wrong AI output.
  • Collecting feedback without tying it to a specific answer, claim, citation, source, tool result, or response version.
  • Hiding whether feedback applies to the current answer, future answers, review queues, training data, retrieval sources, or prompt behavior.
  • Treating correction text as a new prompt or hidden instruction without showing the user that the answer scope changed.
  • Publishing private correction notes in a shared transcript or training on them without consent.
  • Confirming receipt with no durable status, reviewer outcome, appeal path, or feedback history for high-risk corrections.

Critique Questions

  • What exact answer, claim, source, recommendation, or tool result is being corrected?
  • Can the user state whether the problem is wrong answer, missing source, wrong source, harmful suggestion, outdated answer, biased output, or another correction?
  • Does the user know whether the correction affects this answer, future answers, review only, source quality, prompt behavior, or training use?
  • Where does private correction text appear, and what prevents it from leaking into shared transcripts or generated output?
  • What receipt, status, reviewer decision, appeal path, or history can the user inspect after submission?
  • Would query correction, inline validation, comments, regenerate / retry, or editable AI output better match the real task?
Accessibility
  • Expose selected claim, selected source, reason, scope, privacy choice, submission state, receipt, review state, and outcome as text.
  • Do not rely on thumbs color, reaction icons, or animated confirmation alone to communicate that feedback was captured.
  • Make claim selection, reason choices, source correction, expected answer entry, privacy controls, Submit feedback, Cancel, View history, and Appeal keyboard reachable.
  • Announce status changes such as feedback submitted, failed to submit, reviewer routed, accepted, rejected, appealed, or private note kept out of transcript without moving focus unexpectedly.
  • Keep focus near the correction panel after errors and near the receipt after successful submission.
  • Ensure long AI answers, claim excerpts, source titles, expected answers, reviewer notes, and privacy disclosures wrap at mobile widths and high zoom.
Keyboard Behavior
  • Tab reaches answer-level feedback, claim-level feedback, reason options, expected answer, corrected source, private note, scope controls, training opt-out, submit, cancel, history, and appeal in order.
  • Enter or Space activates reason and scope controls; submitting feedback enters a pending state that prevents duplicate keyboard activation.
  • Escape closes a correction sheet or details popover and returns focus to the feedback control for the selected answer or claim.
  • After submission succeeds, focus moves to the feedback receipt or remains in the panel with the receipt programmatically announced.
  • After submission fails, focus remains on the correction panel and exposes the failure reason and retry path.
  • Keyboard users can review selected claim, corrected source, consent, receipt, and history without losing the answer context.
Variants
  • Claim-level correction
  • Source correction
  • Wrong answer report
  • Harmful suggestion report
  • Outdated answer correction
  • Reviewer-routed correction
  • Private correction note
  • Training opt-out feedback
  • Current-answer correction
  • Future-answer feedback
  • Correction appeal
  • Mobile correction sheet

Verification

Last verified: