Designing AI features users can trust

Every AI feature ships with a trust budget, and the first wrong answer spends most of it. We've watched it happen in usability sessions: a participant asks the assistant something, gets a confident, fluent, fabricated answer, and their posture changes. They stop delegating. They start double-checking. Some never come back. The model didn't get worse in that moment — the interface failed to earn the benefit of the doubt.

Trust is not a brand value you state on a page. It's an interface property you design, the same way you'd design empty states or error handling. After shipping AI features across health, fintech and commerce engagements, we've settled on a working set of five moves. None of them require a better model. All of them require admitting, in pixels, what the model is.

1. Show provenance, not vibes

The single highest-leverage trust pattern is the citation. When an AI feature draws on retrieved material — policy documents, product catalogues, the user's own data — it should show its working. Not a decorative "sources" footer with three generic links, but inline, inline-adjacent provenance: this sentence came from this document, and here it is.

We built this into the support assistant for a fintech client last year. Every answer carried numbered references that expanded to the exact passage used. Two things happened. First, support escalations about wrong answers dropped, because users could verify before acting. Second — and this surprised the client — users started trusting answers more when citations were present and correct, and the presence of the apparatus itself made them more forgiving of the occasional miss. Provenance converts "the computer said so" into "here's the receipt". People forgive a system with receipts.

Where there's no retrieval to cite, provenance becomes a statement of basis: "Based on your last 90 days of transactions" or "Drawing on your stated preferences". The principle holds. Say what you looked at.

2. Communicate confidence in sentences, not percentages

Slapping "87% confident" on an answer is a category error. Users can't calibrate against a number they have no reference for, and the percentage implies a precision the system doesn't have. Confidence is better expressed in the texture of the response itself.

We use three registers:

• Declarative — for high-confidence, verifiable answers: "Your subscription renews on 4 July."
• Qualified — for inference: "It looks like this charge is from your annual plan — the merchant name matches last year's renewal."
• Offered — for low confidence or creative territory: "One possibility is… want me to check that against your statements?"

The register is set by the same confidence signal the pipeline already computes, but the user experiences it as a colleague choosing their words carefully, not a machine emitting a probability. The design work is in the copy system: define the three registers, write exemplars for each, and hold the line in review the way you would with a voice chart.

3. Build the correction affordance before the feature

Every AI feature needs an obvious, low-friction way to say "that's wrong" — and the interface must visibly act on it. A thumbs-down that vanishes into a logging pipeline teaches users that feedback is theatre. A correction that updates the answer, the record, or the future behaviour of the feature teaches them the system is governable.

On a healthcare engagement — adjacent to the work we described in the Pylon Health case study — the intake-summary feature let clinicians edit any AI-drafted line before signing. The edit was one tap, and edited fields were marked as reviewed. Clinicians told us the edit affordance was the reason they were willing to use the feature at all: they weren't trusting the model, they were trusting their own ability to override it. That's the reframe. Users don't need to trust the AI. They need to trust that they remain in charge.

Design the correction path first, in wireframes, before anyone fine-tunes anything. If you can't draw where "that's wrong" goes on the screen, you're not ready to ship the feature.

4. Write honest capability statements

The worst trust-destroyer we've audited isn't hallucination. It's marketing copy. "Ask me anything!" promises a capability the system doesn't have, guarantees a mismatch, and then blames the model for the interface's lie.

Honest capability statements do three things: they name what the feature is for ("Summarises your unread support threads"), they name what it draws on ("Using this workspace's tickets and docs"), and they name a boundary ("Can't access billing — ask the team"). Boundaries are the counterintuitive part. Teams resist stating them because it feels like advertising weakness. In testing, the opposite happens: stated boundaries raise trust in the stated capabilities, because users believe you about both.

This is a copy problem before it's a machine-learning problem, and it belongs in the same review as your error messages and empty states. The standard we hold: a new user, reading only the interface, should be able to form an accurate mental model in under a minute. If they can't, the copy is over-promising, and over-promising is a design defect.

5. Measure trust, not just usage

Usage metrics will lie to you about trust. A user who asks the AI a question, then opens the source document to verify, counts as engaged — but they're telling you they don't believe the answer yet. Instrument for the trust signals specifically:

• Verification rate — how often users open citations or source material after an answer. High early on is healthy; it should decay over weeks as the system earns its keep. If it never decays, users haven't formed trust.
• Correction rate and persistence — how often "that's wrong" is invoked, and whether those users come back. Correction followed by return is trust being built. Correction followed by silence is trust being spent.
• Delegation depth — are users asking the feature to do things, or only to find things? Action requests are a higher trust denomination than lookups.

Track these cohort by cohort. Trust is a stock that accumulates per user, not a flow you can average. We go deeper on the instrumentation in our companion piece on analytics for AI features, and the broader discipline of honest numbers in activation metrics that mean something.

The uncomfortable bit

All five moves make the feature look, superficially, less impressive. Citations add chrome. Qualified language reads less confident than a chatbot that never hedges. Stated boundaries undersell. Teams worry the demo will land flat.

Ship it anyway. The uncanny valley of AI isn't visual, it's epistemic: a system that sounds certain and is sometimes wrong is worse to live with than a system that sounds careful and is mostly right. Careful compounds. Certain spends. And when you're scoping what an AI feature should even attempt, that decision belongs upstream — in the same kind of honest review we run before any AI engagement writes a line of code.

Key takeaways

• Trust is a design property with a budget: one confident fabrication spends most of it. Design for recovery, not just accuracy.
• Inline citations and statements of basis convert "the computer said so" into a receipt users can check — and make correct answers more believable, not less.
• Express confidence through language registers — declarative, qualified, offered — not percentages users can't calibrate.
• Build the correction affordance before the feature. Users trust their ability to override the system more than they'll ever trust the system.
• Stated boundaries raise trust in stated capabilities. Over-promising copy is a design defect, not a marketing win.
• Measure verification rate, correction persistence and delegation depth. Usage alone cannot tell you whether users believe what the AI says.

FAQ

Won't citations and hedged language make our AI look weak next to competitors? Only in the demo. In week six, the product with receipts has retained users and the product with bravado has support tickets. The competitive frame is also backwards: as AI features commoditise, trustworthiness becomes the differentiator precisely because most teams won't pay the superficial-impressiveness tax.

How do we decide the thresholds between declarative, qualified and offered registers? Start conservative: qualify everything that isn't directly retrieved and verifiable, then relax thresholds as your evaluation data accumulates. The thresholds should be set per action class — a wrong answer about a refund policy is cheap; a wrong answer about a medication interaction is not. Different registers per risk tier is a feature, not an inconsistency.

Our model doesn't produce confidence scores. Can we still do this? Yes. Retrieval coverage (did we find good source passages?), answer-class rules (is this a factual lookup or a generative task?) and simple self-consistency checks (ask twice, compare) all give you usable signals. Perfect calibration isn't the goal; honest rough signals beat false precision.

**When should we not show provenance?** When there is none to show — pure generation tasks like drafting or brainstorming — and when surfacing sources would leak something the user shouldn't see. In generation, the honest move is framing: "here's a draft" rather than "here's the answer". Never fabricate a citation apparatus for a system that isn't citing anything. Users will check.

How long does trust take to build? In our measurements, verification behaviour typically starts decaying after four to eight successful sessions, faster for low-stakes tasks. But one high-stakes failure resets the clock entirely. This asymmetry — trust builds slowly, collapses fast — is why the failure states and correction paths deserve more design time than the happy path.