AI UX design patterns for product teams: what a PM specifies for each AI feature

Start AI UX work from a 2019 research paper, not a gallery of screenshots. Saleema Amershi and colleagues at Microsoft Research propose "18 generally applicable design guidelines for human-AI interaction" in Guidelines for Human-AI Interaction, and the paper says they were validated through "a user study with 49 design practitioners who tested the guidelines against 20 popular AI-infused products." Forty-nine practitioners and 20 products is a small, 2019-era sample. It was still tested against real products, and every guideline maps to a decision a PM has to write down.

Google's People + AI Guidebook, Nielsen Norman Group's research on generative AI interfaces, and Apple's Human Interface Guidelines for generative AI fill the gaps the 2019 paper could not see. The seven patterns below combine all four sources. If you are trying to fix a feature people stopped using, start with how to increase adoption of an AI feature; this page is the spec you write before launch.

Which UX patterns does every AI feature need a decision on?

Every AI feature needs an explicit decision on seven patterns, and "not needed" is a valid decision as long as someone wrote it down. The guideline numbers refer to Microsoft's HAX Design Library, which lists all 18.

Pattern	What the user sees	Use it when	Downgrade or skip when	Closest guideline
Expectation setting	What the feature does, what it is bad at, example inputs	Always, at first use	Never skip; shorten for repeat users	HAX G1, G2
Confidence display	A label or a change in tone on uncertain answers	The user can act differently on a low-confidence answer	The label would not change what the user does	PAIR Explainability + Trust
Citations and sources	A link next to each claim, pointing to the passage	The answer is factual and checkable	Creative or drafting output with nothing to check	HAX G11
Editable output	A draft the user can change in place	Almost always	One-tap actions where retry is cheaper than editing	HAX G9
Feedback capture	Thumbs, corrections, a reason picker	You have a named owner who reads it	Nobody will act on the signal	HAX G15, G16
Graceful failure	A manual path, a clarifying question, a partial answer	The model can be wrong, slow or down	Never skip	HAX G10
Human control	Approval before actions, global on and off settings	The AI acts, sends, buys or deletes	Pure suggestion with no side effect	HAX G17

Two questions decide each row: how much a wrong answer costs the user, and how fast the user can check it. A wrong autocomplete costs a second and is visible at once, so it needs editing and almost nothing else. A wrong refund policy costs money and looks right, so it needs sources, a confidence signal and a human path.

How do you set expectations before the first output?

Set expectations by telling users what the feature does, what it does badly, and how to get a good result, at the moment they first use it. Microsoft's guidelines put this first: G1 is "Make clear what the system can do" and G2 is "Make clear how well the system can do what it can do", which the HAX Design Library explains as helping "the user understand how often the AI system may make mistakes."

Apple's generative AI guidelines give the practical version: "If your feature has known limitations, let people know up front, show them how to get good results, and explain why inferior results occur." In a spec, that means three pieces of copy: a one-line capability statement, two or three example inputs that show the feature at its best, and one sentence naming the case it handles worst.

What does not work is the permanent footer. Page Laubheimer of Nielsen Norman Group writes in AI Hallucinations: What Designers Need to Know that "A generic disclaimer is unlikely to change users' information-seeking and verification behaviors, especially when its salience is reduced through repetition." Keep a short disclosure for legal reasons if you need one, but put the real warning where the risk is.

When should an AI feature show confidence or uncertainty?

Show confidence only when a low-confidence answer should change what the user does next, and say what that action is. Google's Explainability + Trust chapter puts the trade-off plainly: "Displaying model confidence can sometimes help users calibrate their trust and make better decisions, but it's not always actionable." It also warns that "A misleadingly high confidence, for example, may cause users to blindly accept a result." The chapter advises teams to "Clearly indicate what action a user should take under each category of confidence."

For language model features, the confidence number is often itself generated text. Laubheimer's NN/g article recommends labelling answers High, Medium or Low rather than showing percentages in that case, and cites a study by Sunnie Kim and colleagues finding it was important to express uncertainty in the first person ("I'm not sure") rather than in general terms. The spec line is short: which signal decides low confidence (retrieval found no source, repeated answers disagree, the model said so), what the user sees, and what the next step is.

How should citations and sources appear in an AI answer?

Put each source next to the claim it supports and link to the exact passage, because users rarely check a list of links at the bottom. Megan Chan of Nielsen Norman Group reports in Explainable AI in Chat Interfaces that "people rarely click citation links" and recommends teams "Place sources directly next to the specific claim or sentence they support." The same article warns that citations are often hallucinated, and that showing a source regardless of its validity "gives users a false sense of reliability."

Misattribution is common enough to plan for. Laubheimer's NN/g article cites a Columbia Journalism Review study in which ChatGPT "falsely attributed 76% of the 200 quotes" it was asked to identify, and indicated uncertainty in only 7 of the 153 cases where it erred. That study tested one chatbot on one task, so it does not give you an error rate for your feature. It does show why a citation should come from a document your system retrieved, never from the model's memory. If your feature answers from your own content, RAG for product managers covers the retrieval side, including what to show when retrieval finds nothing.

Why should AI output be editable instead of accept or reject?

AI output should be editable because most wrong answers are near misses, and a near miss the user can fix is still a useful result. Microsoft's guideline 9, Support efficient correction, reads "Make it easy to edit, refine, or recover when the AI system is wrong" in the HAX Design Library, and guideline 8 asks products to "Make it easy to dismiss or ignore undesired AI system services."

Apple's guidelines add the undo layer: "Give them the ability to dismiss new content they don't want, and revert or retry content transformations or other actions they don't agree with." In a spec, list the three verbs your feature supports (edit, retry, revert) and the one it supports best. The research on why editing keeps users coming back is covered in the adoption guide; the design point here is that an edit is also your best feedback signal, because it shows exactly what the right answer looked like.

What feedback should an AI feature capture, and where does it go?

Capture only the feedback someone will act on, and tell users what happens to it. Google's Feedback + Control chapter notes that "Simply acknowledging that you received a user's feedback can build trust, but ideally the product will also let them know what the system will do next, or how their input will influence the AI." It also notes that feedback is sometimes not connected to the model at all: a "show more/less of this" button "may not be used to tune the AI model" and could simply be a filter on what content is shown.

Write the destination into the spec next to the control. A thumbs-down with a reason picker can feed a weekly review of failing traces, and a user's edit can become a new test case in the eval set described in how to write evals for AI products. Explicit feedback is sparse, so pair it with implicit signals such as edits, retries and abandonment, which how to measure AI feature success turns into metrics.

How should an AI feature fail gracefully?

An AI feature fails gracefully when the user can still finish the task: by asking a clarifying question, giving a partial answer, or handing over to a manual path. Google's Errors + Graceful Failure chapter says "When an AI system fails, often the easiest path forward is to let the user take over." Microsoft's guideline 10 in the HAX Design Library asks systems to "Engage in disambiguation or gracefully degrade the AI system's services when uncertain about a user's goals."

Apple's guidelines make the fallback a general rule: "When possible, consider offering a non-AI fallback." Spec three failure states separately, because each needs different copy: the model is unsure (ask or narrow), the model is wrong (correct and report), and the model is unavailable or slow (manual path with nothing lost).

The Errors + Graceful Failure chapter adds a caution worth copying into the spec: "In some cases, reverting to manual control could be risky or dangerous." For those cases, the fallback is a person, which is a launch gate in the AI feature launch checklist.

How much control should users keep when the AI takes actions?

Users should approve any action that is costly or hard to reverse, and keep a global way to change what the AI does. Microsoft's guideline 17, Provide global controls, asks products to "Allow the user to globally customize what the AI system monitors and how it behaves" in the HAX Design Library. Google's Explainability + Trust chapter gives the rule for how far to automate: "Automate more when trust is high, or risk of error is low."

For agent features, write an action list with three columns: actions the AI takes alone, actions it proposes for approval, and actions it never takes. The human in the loop glossary entry covers where the approval step belongs.

Can too many AI UX patterns make a feature worse?

Too many patterns do make a feature worse, and the objection deserves a straight answer. Every confidence label, citation chip and warning competes for attention. Google's Explainability + Trust chapter admits that "Counterintuitively, showing more granular confidence can be confusing" when users cannot tell what the number means for them. NN/g's point about generic disclaimers shows what happens to any signal that appears on every answer: users stop seeing it.

The guidelines also show their age. Microsoft validated them on 2019 products, before long generated answers and agents, so none of the 18 tells you how to show uncertainty inside a 500-word draft. The answer is to apply the stakes and checkability test to each pattern rather than shipping all seven at full strength. A low-stakes drafting tool might ship expectation copy, editing and a fallback, and nothing else. A support assistant answering billing questions needs all seven.

How do you turn the patterns into a spec your team can build?

Write one line per pattern in the PRD: the trigger, what the user sees, the copy, and the metric that tells you whether it works. A confidence line might read: when retrieval returns no passage above the threshold, show "I couldn't find this in our help centre" with a link to contact support, and track how often users take that link. The PRD template for AI features has a section for this.

Then test the spec against real failures before you build anything new. Pull the last 20 wrong answers from your traces or support tickets and mark, for each one, which of the seven patterns would have caught it or limited the damage. The pattern that appears most often is your first build priority, and a pattern that catches none of them can wait.

Where do you practise designing AI features users trust?

Builders Camp's AI Product Management bootcamp, led by its own programme director, a working practitioner, runs for 2 weeks with 4 live sessions and 7 self-paced microlessons, one of which asks "How do you design user experiences in AI products?" Its stated focus is to design AI-native experiences, evaluate model behavior, manage risk, and deliver AI features users trust. It is open to product managers at all levels and is part of the AI Product Expert Track. If you want to test these patterns in a prototype first, the Prototyping with AI bootcamp covers using AI for UX flows and prototype creation.

See the AI Product Management bootcamp