Designing an AI feature people can trust

Trustworthy AI UX starts with three visible things: the source of the answer, the limit of what it can know, and an easy way to change it. The model can be impressive and still be unfit to ship if those three are missing.

A confident wrong answer is a product defect. Tone does not repair a figure, a date, or a promise a customer might act on. Design the feature so doubt is legible and repair is ordinary.

Put the source beside the claim

If the feature summarizes a document, names a record, or drafts from the customer's own files, show that material next to the sentence it produced. "Based on the last invoice" is a start. A link or a quoted line the person can check is better. A badge that only says "AI" tells them the genre, not the evidence.

People do not go looking for a footnote after they have already trusted the number. Nielsen Norman Group's 2011 piece on how long people stay on web pages found that users often leave within 10–20 seconds, and that a value proposition has to be clear inside about 10 seconds if you want them to stay. A trust note buried under the answer arrives after the decision. Put the source in the same view as the claim.

Keep the source specific to this answer. A general help page about "how our model works" is not a source. The person needs to see which email, which row, or which policy the sentence used. If you cannot point at one, the feature is guessing, and the interface should say so in the same size of type as the guess.

When several sources disagree, show the disagreement. Collapsing them into one smooth paragraph is how a product manufactures false confidence. Two dates on screen are more honest than one date that averaged them.

State the limit in the same view

Every feature has a boundary: it cannot see messages after a certain day, it cannot know inventory, it cannot give legal advice, it cannot see another customer's account. Write that boundary where the answer sits, in one sentence, not in a policy page linked from the footer.

The limit should change the control. If the feature cannot know live stock, do not let it speak in the voice of a warehouse. Offer a draft the person can send to the system that does know, or stop. A limit that is only a disclaimer, while the button still says "Confirm order," is decoration.

Say what the feature did not do. "This draft did not check the contract" is more useful than "AI can make mistakes." The second sentence is true of every tool and teaches nothing. The first sentence tells the person which check is still theirs.

The W3C's WCAG 2 overview says the guidelines apply to AI web interfaces, under the same four principles as other web content: perceivable, operable, understandable, and robust. A limit the person cannot perceive is a failure of the first principle. A control that looks final when the answer is provisional fails the third. You do not need a certification project to use that as a design bar. You need the answer, the source, and the limit to be readable in the interface itself.

Make editing the normal path

The person should be able to change the result without starting over. If the feature wrote a paragraph into a field, the field stays editable. If it proposed a status, the status menu still works. Accept and edit are neighboring actions, not a rescue flow hidden behind "regenerate."

Regenerate is a weak repair. It throws away the part that was right and asks the person to gamble again. Prefer a cursor in the sentence. Prefer a field they already know how to change. The feature did a chore. The person still owns the document.

Show what will be saved. A preview that differs from the sent result is a trust bug, the same as a checkout total that changes after the button. If a later system will rewrite the tone, say that before they accept.

Keep a plain undo for the last accept. People try a suggestion to see it in place. If undo is gone, they stop trying, and the feature looks unused when it was only scary.

Treat a wrong answer as a defect

When the answer is wrong, write it up the way you would write up a broken total. What did the person see, what did they do next, and which source was missing. "The model hallucinated" is a category, not a fix. The fix is usually in the interface: the source was absent, the limit was unspoken, or the edit was harder than accepting the mistake.

Track a small set of failures you are willing to name:

• The answer cited a source that does not contain the claim.
• The answer stated a number the product does not have.
• The person could not tell a draft from a sent message.
• The only repair was to ask again in different words.

If those four keep happening, stop adding capabilities. Tighten the ones you have. A narrower feature that is checkable will earn more use than a wide one people work around.

Do not hide the error behind a friendlier voice. A warmer wrong answer is still wrong. The repair is structural: source, limit, edit.

What the first version should refuse

Refuse anything that sends, charges, or deletes on the strength of an unchecked answer. Those belong to a later step with a person, which is a different decision from how the suggestion looks. The first version can draft. It should not act.

Refuse private data the task does not need. If the feature writes a support reply, it does not need the customer's payment method in the prompt. Less material in view means fewer ways to leak a detail into a sentence the customer will read.

Refuse a chat box as the only face of the feature if the person was already in a form. The suggestion belongs on the form. A new blank conversation asks them to learn a second product before they can finish the first.

Hanabi's services cover product interfaces for early software, including an AI feature when the workflow is specific enough to design this way. The work is the screen around the model: source, limit, and an edit a person will actually use.

The next question is which moments still need a person even after the interface is honest. Where a human still has to review the work draws that line: anything a customer will see, pay, or be unable to undo.