How Do You Design AI Features People Actually Trust?

What Makes an AI Feature Feel Broken?

Not being wrong. Being wrong without warning. A model that gives a slightly imperfect answer inside an interface that set honest expectations feels useful. The same answer inside an interface that promised certainty feels like a bug, and the user stops trusting the whole product.

We design product interfaces alongside the marketing sites, and this is the pattern we keep seeing. Teams spend months on model quality and an afternoon on the surface around it, then wonder why adoption is poor. The surface is where trust is built or lost.

Here is the framework we use, grounded in research that predates the current wave and has held up unusually well.

Is There Actual Research on This?

Yes, and more than most teams realise. Microsoft Research published Guidelines for Human-AI Interaction at CHI 2019, proposing 18 generally applicable design guidelines for AI systems. The paper received an Honorable Mention Award at the conference.

The validation is what makes it worth using. The guidelines were tested through multiple rounds of evaluation, including a user study with 49 design practitioners who applied them against 20 popular AI infused products. That is a broader base than most design guidance rests on.

The authorship is broad too, running to thirteen researchers including Saleema Amershi, Jaime Teevan and Eric Horvitz. Microsoft publishes the guidelines through its HAX Toolkit, alongside a workbook, a playbook and a set of design patterns. Patterns are currently available for eight of the 18 guidelines.

How Should You Set Expectations Before Anyone Clicks?

Say what the feature does and what it cannot do, in the interface, before the first use. Not in a help article. The sentence that sits above the input is the highest leverage copy in the whole feature, and it usually gets written last by whoever is closest to the deadline.

Be specific about scope. "Summarises this document" is a promise you can keep. "Understands your data" is not. A narrow promise that holds beats a broad one that fails, because the user calibrates against what you told them.

Name the source of the answer wherever you can. An AI feature that says which documents it read is doing two jobs at once: it explains the output, and it gives the user a way to check it. That single addition prevents most of the trust damage a wrong answer would otherwise cause.

What Should the Interface Do While It Waits?

Show progress, not a spinner. AI features are slower than the interactions users are calibrated for, and an undifferentiated loading state reads as broken well before it reads as thinking. Streaming the output as it arrives is the single best fix where the interaction allows it.

Where streaming is not possible, say what is happening. Reading your document, then checking the last thirty days, then drafting. Each step is a small promise kept, and it converts dead time into visible work.

Design the empty and partial states properly rather than treating them as an afterthought. This is ordinary interface craft applied to an unusual latency profile, and we cover the general principles in our piece on loading and empty state design.

How Do You Design for the Model Being Wrong?

Assume it will be, and make correcting it cheaper than starting again. This is the phase most teams skip entirely. The happy path gets three rounds of design review and the recovery path gets a toast notification.

Three moves cover most of it. Make the output editable in place rather than regenerate only. Keep the previous version reachable, because a user who loses good work to a bad regeneration will not use the feature twice. And let people undo an AI action with the same gesture they undo anything else.

Then be careful about defaults. An AI feature that applies its output automatically has decided that being right is more likely than being wrong, on the user's behalf. Draft state is almost always the correct default, and it costs one click to accept.

Why Does the Same Prompt Give Different Answers?

Because these systems are not deterministic, and your interface should not pretend otherwise. SparkToro published research on 28 January 2026 in which 600 volunteers ran 12 prompts through ChatGPT, Claude and Google AI a combined 2,961 times, and found the same question rarely produced the same answer.

The figure is striking. SparkToro reports there is less than a 1 in 100 chance of getting the same list of brands in any two responses, and roughly a 1 in 1,000 chance of getting the same list in the same order. That was a study about brand visibility, but the underlying behaviour applies to any generative feature.

The design consequence is concrete. Never present a generated result as if it were a lookup. If a user can regenerate and get something different, they will, and an interface that implied a single correct answer has just told them it was lying. Framing the output as a draft or a suggestion is both more honest and more robust.

How Much Control Should You Give the User?

Enough to steer, not enough to configure. The failure at one end is a magic box with no controls, where a user who wants a shorter answer has no route to one. The failure at the other is a settings panel with twelve sliders that nobody touches and everybody has to scroll past.

Two or three controls, chosen from the adjustments people actually ask for, cover most cases. Length, tone and scope are usually the right three for text features. Make them visible next to the output rather than buried in preferences, because the moment someone wants them is the moment they are reading a result.

An escape hatch matters more than any individual control. There should always be an obvious way to do the task manually. A feature that traps someone in the AI path when it is not working converts a mild disappointment into a support ticket.

How Do You Collect Feedback That Is Actually Useful?

Ask a question you can act on. A thumbs down tells you something was wrong and nothing about what. A thumbs down followed by three specific options, such as inaccurate, too long, or missed the point, gives your team an actual queue to work from.

Place it where the judgement happens, next to the output, not at the end of the session. And close the loop visibly when you can, because a user who sees that their correction changed something will keep giving you corrections.

Route the serious cases to a person. Feedback on an AI feature is a quality signal, and treating it as pure telemetry wastes it. This is the same argument we make about keeping people in the process in our piece on human in the loop AI workflows.

What Happens When You Change the Model?

Your users notice, and if you say nothing they assume it broke. Microsoft's eighteenth guideline covers exactly this. Titled Notify users about changes, it advises informing the user when the AI system adds or updates its capabilities. It sits in the group of guidelines concerned with the relationship over time.

This is the guideline that gets ignored most often, because model swaps feel like infrastructure. They are not. To the person using the feature, the thing that was reliable on Tuesday behaves differently on Wednesday, and no release note reaches them.

A short in product message at the point of use is enough. Tell them what improved and what changed. It costs almost nothing and it protects the calibration you spent months building.

Where Should a Product Team Start?

With the four moments, in order. What does the user know before they start. What do they see while it works. What happens when it is wrong. What happens when it changes. If you can answer all four in one page, the feature is designed. If you cannot, the model quality will not save it.

Then write the failure states first, before the happy path. It is a deliberately awkward exercise and it surfaces the honest scope of the feature faster than any amount of prototyping. Teams that do this ship narrower features that work.

Finally, treat the first release as calibration rather than completion. The feedback mechanism is not a nice extra, it is the instrument you use to find out what your users actually expected. That is the same reasoning behind treating onboarding as a measurement problem, which we cover in our guide to SaaS onboarding flow design.

If you are designing an AI feature and want a second opinion before it ships, we are happy to walk through it with you. Find us at phoenix.studio.