Make AI tools show their work before asking for trust
A fluent answer can hide missing evidence. Design AI interfaces to expose the source, the transformation and the uncertainty behind consequential outputs, so users can verify the part that matters.
On this page 6 sections
- Show evidence next to the claim it supports, not in a separate audit screen.
- Distinguish source material from the model's interpretation and recommendation.
- Make uncertainty actionable by telling users what to inspect or do next.
A polished answer can feel more reliable than it is. That is a dangerous interface property: fluency is visible immediately, while missing context may only become obvious after a user acts. If an AI feature asks people to trust a consequential recommendation, it should also give them a practical way to inspect how that recommendation was formed.
Explainability is a user task#
“Explain the model” is too broad to guide a product decision. A user usually has a narrower question: Which document supports this claim? What changed between the source and the summary? What assumption drove this recommendation? Can I correct the input?
The interface should answer the task, not offer a vague promise of transparency. Consider a tool that summarizes a policy and flags a possible exception. A useful result might show:
- Source: the exact passage and document date.
- Interpretation: the condition the system believes the passage expresses.
- Application: why the current case appears to match or differ.
- Next step: inspect the cited section, provide missing context, or route for review.
These parts should not collapse into one confident paragraph. A quoted passage is evidence; the interpretation is a transformation; the recommendation is a decision aid. Keeping them distinct lets the user challenge the right layer.
Put evidence beside the claim#
A source link at the bottom of a long response is technically available but often practically disconnected. The user has to guess which source supports which sentence, then reconstruct the reasoning themselves.
Instead, attach evidence at the smallest useful unit. In a generated summary, each material claim can open its supporting passage. In a classification result, show the input fields that influenced the category. In a draft, mark which sentences are extracted facts and which are proposed language.
This does not mean exposing every internal step or dumping a chain of thought. The product needs to present verifiable inputs and outputs, not private reasoning traces. Evidence should be selected for user inspection: source locations, relevant values, timestamps, and transformations that can be checked.
A practical design test is to hide the main answer and ask a reviewer to find the support for one claim. If the reviewer cannot do that without searching the entire source set, the evidence is not close enough to the decision.
Show the transformation, not just the citation#
A citation can be correct while the conclusion is wrong. The source may say that a condition applies only after a date; the summary may omit the date. The document may describe a proposed rule, while the interface presents it as active. A matching phrase may be irrelevant to the user’s specific case.
So show the transformation in a compact form. For example:
| Stage | What the interface can show |
|---|---|
| Source | Passage, page or record, and its date |
| Extracted fact | The specific value or condition identified |
| Applied rule | The rule or criterion used for this case |
| Result | The conclusion, with any unresolved condition |
The table is not a demand to reveal model internals. It is a way to let the user inspect the product’s observable reasoning: what information was used, what rule was applied, and what conclusion followed.
When a result depends on a missing field, say so directly. “Needs review” is less useful than “The effective date is absent; check the original record before applying this rule.” The latter makes uncertainty actionable.
Design for correction#
Inspection without correction can become theater. If users can spot an error but cannot fix its input or route it to someone who can, the interface has exposed a problem without providing a safe path forward.
For each kind of evidence, define an appropriate correction:
- Wrong source: remove it or select the correct record.
- Wrong extracted value: edit the value or mark it as unavailable.
- Wrong interpretation: choose the correct condition or request review.
- Incomplete context: add the missing information before rerunning.
Keep these edits explicit. A user changing an extracted value should be able to see whether the final result updates, and whether the correction is local to this case or changes a reusable source record. Those are different permissions and consequences.
A useful design exercise is to write one error-recovery path for each visible evidence element. If a cited passage is outdated, what can the user do? If a field was misread, what changes downstream? If the system cannot decide, who receives the case and what information arrives with it?
Match confidence language to evidence#
A percentage can look precise without telling a user what to do. Unless the number is calibrated for the relevant task and population, “92% confident” may communicate more certainty than the product can justify.
Prefer confidence language tied to observable conditions: “Two required fields are present,” “The source documents disagree,” or “No supporting passage was found.” These statements point to the basis of the result and can be checked. If a score is needed for ranking, explain what it measures and avoid presenting it as a probability unless that interpretation is warranted.
The same principle applies to visual hierarchy. Do not style an unverified suggestion like a completed action. A recommendation awaiting confirmation should look and behave differently from a transaction that has been confirmed by the destination system.
A review checklist for the interface#
Before shipping an AI-generated answer that could change a user’s decision, test it with a reviewer who did not build the feature. Give them a realistic example and ask them to locate the evidence, identify what the system inferred, correct a wrong input, and explain what remains uncertain.
Use this checklist:
- Can the user connect each important claim to its supporting source?
- Can they distinguish source facts from system interpretation?
- Can they identify missing, conflicting, or stale information?
- Is there a safe correction or escalation path?
- Does the interface distinguish a suggestion from a confirmed outcome?
If the reviewer cannot answer those questions, adding a longer explanation probably will not fix the core problem. Change the interaction so the evidence is inspectable and the next action is clear. Trust should be earned at the point where the user needs to decide.