User feedback in AI: thumbs, corrections and what they really mean
User feedback in AI includes thumbs, reports and corrections. How to design it so it is useful, read it without fooling yourself, and pair it with sampling.
What types of feedback exist?
It helps to separate three groups, because each one says something different:
| Type | Examples | What it reveals | Limitation |
|---|---|---|---|
| Explicit | Thumbs up or down, content report, survey | That something did not work, sometimes why | Few people use it |
| Implicit | Copying, regenerating, editing, closing without using it | Whether the response helped in practice | Ambiguous: regenerating may be curiosity |
| Correction | Rewriting a part, changing a category, undoing | Exactly what was missing | Only appears when the person uses the output |
Corrections are the most useful for design. When someone changes the category of an expense or rewrites the first sentence of an email, they are telling you what should have been different, without you having to ask.
Why is the thumb not enough?
A thumbs down without a reason is a weak signal. It does not distinguish between “the answer was wrong”, “it was not what I wanted” and “I pressed the wrong button”. Besides, explicit feedback only comes from people who take the time to give it.
Hamel Husain’s recommendation is to use feedback to find traces to review, not as the final measure. He is clear about it: feedback helps narrow down problems, but it leaves out the ones nobody reports. For that reason he suggests keeping random traces in every review batch, to discover failures the current signals do not describe.
Anthropic reaches a similar conclusion in its guide to agent evals: user feedback surfaces problems you did not anticipate and comes with real examples, but it is sparse and self-selected, skews toward severe issues, and rarely explains why something failed. Its advice is to combine it with production monitoring, manual transcript review (for example, reading a sample every week) and A/B testing.
This has a design consequence: if you rely only on thumbs, your product only improves on what its most vocal users find annoying.
How do you design useful feedback?
Microsoft’s HAX Design Library, which covers human-AI interaction, has a guideline called “Encourage granular feedback”. Its patterns are especially useful here:
- Request explicit feedback on individual outputs, or on selected outputs, rather than on the whole conversation.
- Report inappropriate content through a separate path.
Translated into concrete decisions:
- Ask for the reason on thumbs down. A short menu with three or four categories: incorrect, incomplete, does not apply, other. It should take five seconds.
- Tie the feedback to the response. Each thumb should be linked to a specific message, with its context.
- Make correcting cheap. Edit inline, change a category with one click, undo. Every correction should be saved next to the original version.
- Explain what happens to the feedback. One line that says whether the response gets reviewed or whether the system learns from it. If you do not know, do not promise it.
- Clarify privacy. If feedback is used for training or evaluation, say so and offer an opt-out. That topic has its own page: consent to train on user data.
How do you read it without fooling yourself?
There are four common traps:
- Expressiveness bias: users who press thumbs are not all users.
- Ambiguity of implicit signals: regenerating a response may mean they wanted another one, or that the previous one had a minor error. Look at what happened next.
- Bias toward the severe: according to Anthropic, user feedback tends to flag severe problems and lets small ones pass.
- Accumulation without categories: ten thousand thumbs down without reasons do not tell you what to fix.
The correct reading combines three sources: explicit feedback to narrow the field, corrections to understand, and random sampling to discover what nobody reported.
When should you NOT ask for feedback?
- When the user has to interrupt their task to give feedback on every response. That becomes noise.
- When you are not going to read the feedback. A button that changes nothing erodes trust.
- When the feedback can expose personal data without the person knowing.
Example
Illustrative example: an assistant that drafts replies to customers of an online store has thumbs on every reply. At first, 4% of the replies get a thumbs down, with no reason. The team adds a three-option menu to the thumbs down: “wrong data”, “tone”, “not what I asked for”. In two weeks, 60% of the thumbs choose “wrong data”, and almost all of them are shipping dates. The team also reviews 40 random replies each week, because feedback does not capture cases where the customer simply never answered. They find that the assistant promises discounts that do not exist, something no user reported because they did not notice it. That finding only came from random sampling.
For the technical record of traces and how they relate to feedback, read LLM observability. To decide what to measure with that feedback, quality metrics for an AI feature. And for how the uncertainty shown to users can trigger corrections, how to show uncertainty.
Common mistakes
- Adding thumbs without asking for the reason, and then not knowing what to fix.
- Treating feedback as the only source of quality.
- Letting corrections get lost, without keeping the original version.
- Using feedback for training without telling the user.
- Showing the button on every response, including trivial ones, and creating noise.