How to add ai to a product without eroding trust

I add ai without eroding trust by making its role visible, keeping consequential actions reversible or subject to approval, and giving users a reliable manual route. Users also need to correct the output without repeating their work, with clear explanations of what those corrections change.

Choose ai tasks by the cost of being wrong

I start with the mistake, not the model. For each proposed feature, I write down what happens if its output is wrong, who notices, and who pays to fix it. A poor suggested label is cheap to correct. An incorrect payment instruction isn't. Both might arrive through the same tidy chat box, but they need different controls.

Consider a product that reads supplier invoices. Extracting a due date into a draft field is a reasonable starting point. Scheduling a payment from that date is a separate permission. I would ship extraction first, keep the source invoice beside it, and require approval before anything moves money. Accuracy alone doesn't justify combining those steps.

Google's People + ai Guidebook grounds product decisions in user needs and the limits of the technology. I translate that into a release boundary: one useful task, a visible review point, and an ordinary way to finish without the model. I skip open-ended assistants until a narrower interaction proves insufficient.

Disclose ai where it changes the user's decision

I put disclosure next to the output or action it qualifies. A notice in settings doesn't help someone deciding whether to send a generated reply. A label such as 'ai-generated draft. Check details before sending' tells them what produced it and what responsibility remains. It doesn't pretend that a label makes an unreliable feature acceptable.

The explanation should match the task. For an account summary, I would show which records were included, when they were last updated, and whether anything was excluded. For a suggested reply, I would distinguish facts taken from the conversation from wording generated by the model. Those details help people judge the result.

Nielsen Norman Group's usability heuristics call for visible system status and language people recognise. I apply that here rather than inventing an elaborate transparency panel. If content leaves the product for external processing, explain that before submission. Keep the essential limitation visible; put processing and retention details one step away.

Separate generated suggestions from committed actions

I draw a hard line between producing something and doing something with it. A generated email is a draft. Sending it is an action. A proposed account change is a suggestion. Saving it changes the record. The interface should preserve those distinctions even when the model can perform the whole sequence in one request.

For a batch of 40 proposed record changes, I would show the changed fields, the affected records and the exceptions before confirmation. I wouldn't ask users to reread 40 complete records. Review needs to expose differences. Otherwise, the approval button becomes ceremony, and responsibility shifts to the user without giving them a workable check.

My default is explicit approval for actions involving money, permissions or external communication. Lower-consequence changes can sometimes run automatically if users can inspect and reverse them. I specify what undo restores and how long it remains available. If an email has already been sent, I don't offer an 'undo' that merely removes the local history.

Let users correct ai output without starting again

A thumbs-down button isn't a correction mechanism. It may collect a signal for the product team, but it doesn't fix the user's task. I provide direct editing for text, replacement controls for extracted values, and a way to reject individual suggestions. Regeneration is useful when the whole approach is wrong, not when one date needs changing.

In the invoice example, changing a due date should leave the verified supplier and amount intact. If the model runs again, I would preserve that correction unless the user explicitly asks to replace it. Otherwise, the product teaches people that checking its work is wasted effort. User edits need a clear priority over later generated suggestions.

Google's guidebook treats feedback and control as design concerns, not just training inputs. I make the scope explicit: 'Changed for this invoice' differs from 'Use this rule for this supplier'. Neither means 'The model has learned this permanently'. I also separate operational corrections from optional feedback that may be retained for product improvement.

Design manual fallbacks for errors and outages

I design the failure state before polishing the successful response. There are several distinct failures: no response, incomplete output, unsupported input and a plausible answer that is wrong. Each needs a different recovery. A generic 'Try again' is only useful when another attempt has a reasonable chance of changing the outcome.

If invoice extraction fails, the uploaded document should remain available beside an empty manual form. If a summary times out, users should still reach the underlying records. Preserve entered values and completed checks. Google's guidance on graceful failure is useful here: the recovery should help someone finish their task, rather than merely explain the technical fault.

I also define a stopping rule. After one unsuccessful retry, I would offer the manual route prominently rather than keep people waiting through repeated attempts. That's a starting design choice, not a universal threshold. Where manual completion isn't safe or possible, show a support route and explain what information carries forward with the handover.

Show uncertainty through evidence, not decorative scores

I avoid percentage confidence labels unless the team can demonstrate what they mean for this task. '92% confident' looks precise, but precision isn't the same as a dependable probability of correctness. Before displaying a score, I want evaluation showing how often outputs at that score are actually correct on representative cases.

Task-specific evidence is usually more actionable. Show the invoice line used to extract the amount. Link a summary claim to its supporting record. Mark a missing source as missing rather than filling the gap with plausible prose. A citation still needs checking: its presence doesn't establish that the source supports the claim.

I use uncertainty to change behaviour, not just styling. An ambiguous date can trigger a request to choose between two interpretations. Missing payment details should block scheduling. Routine wording suggestions need less interruption. This follows the guidebook's emphasis on helping users form an accurate understanding of the system, without making them decode technical model terminology.

Measure correction effort and recovery before expanding automation

I measure the whole task, including review and repair. Generation speed is a poor success measure if users spend longer checking the result than they previously spent creating it. For invoice extraction, I would compare time to a verified record, field-level correction rates, abandoned attempts and errors discovered after approval against the manual workflow.

Acceptance rate needs context. People may accept suggestions because they're correct, because checking is difficult, or because the interface makes rejection awkward. I pair behavioural data with observed usability sessions. Can someone identify an incorrect value, fix it, and continue without help? Can they explain what will happen when they approve the result?

Before release, I set task-specific limits and an owner who can pause automation. One possible release condition is that every tested payment instruction remains blocked until approval; that is a proposed guardrail, not a research benchmark. I also track successful manual recovery separately. Feedback records should capture the failure category without retaining sensitive documents by default.

Questions people ask

Do users need to know when a product uses ai?

I disclose ai when it affects how users should judge an output, approve an action or understand data processing. I prioritise information at the point of use over a general notice.

Should ai features always have a manual alternative?

I provide one when the underlying task can be completed manually. If that isn't possible, I offer a clear stop or support route rather than another uncertain generated answer.

How do I let users correct ai mistakes?

I make the affected text, value or suggestion directly editable and preserve everything already verified. I explain whether the correction applies to this result, a saved preference or future model improvement.

Should I show ai confidence scores to users?

Only when the scores have a validated meaning and help users make a decision. Otherwise, I show supporting evidence, missing information and the specific details that need checking.

Where I checked my thinking

• Google: People + ai Guidebook
• Nielsen Norman Group: 10 usability heuristics for user interface design