Interface patterns for AI products

In short

In a classic interface, everyone who presses the same button gets the same result. With AI, that isn’t the case. Google’s People + AI Guidebook (PAIR) says it plainly: AI is based on probability and uncertainty, so it is sometimes wrong.

Every pattern on this page builds on that fact. Users should see how reliable an answer is. They should be able to correct a wrong answer and switch to a person when needed.

I draw on two sources. One is PAIR. The other is Microsoft’s 18 guidelines for human-AI interaction (HAX). They were published at the CHI conference in May 2019. In the authors’ user study, 49 designers tested the guidelines against 20 widely used AI products.

Four patterns on one answer card

The card below is a single answer from a fictional store assistant. At first, all features are off. Turn one on, and the card changes, and below it you see the principle the feature is based on.

Try it: the answer card

You: I received the coat 20 days ago. Can I return it?

AI assistant

Confidence: medium

I’m not entirely sure about this. Sale items have a different return window.

Yes. Your return window is 30 days from delivery, so you have 10 days left. The tag must still be attached.

Sources

1. Return and exchange policy, item 2: 30-day return window
2. Your order: delivery date and item details

If this answer is wrong, users correct it here with one tap.

If this answer doesn’t help, continue with a support agent. They get a summary of the conversation, so you don’t have to start over.

Active patterns on the card and their principles

• Confidence indicator. Above the answer are the level of confidence and the reason for it. HAX G2: Help users understand how often the system may make mistakes. PAIR: Show confidence in categories.
• Show sources. It lists which document and which order data the answer is based on. HAX G11: Explain why the system did what it did. PAIR: Say which data you rely on.
• Wrong? Correct it. Users correct the answer with one tap, and the card says what has changed. HAX G9: Make correction easy when the system is wrong. G15: Make it easy to share preferences during normal use. PAIR: Show what the feedback changes.
• Hand off to an agent. If the answer isn’t enough, the conversation goes to a person with a summary. PAIR: Return control to users when the AI fails.

The assistant of a fictional store and a fictional return policy. Turn the features on and off, and the answer card changes right away. Below, you see which PAIR section or HAX guideline each active feature is based on.

With every box off, the answer sounds certain. But if the customer bought the coat on sale, the return window closed long ago. The confidence indicator names this risk, and the correction pattern repairs the answer.

Chat interface

The first job of a chat interface is to tell users that they are talking to a program. According to the PAIR chapter on mental models, presenting AI as human sets unrealistic expectations. The recommendation is clear: make it clear to everyone that the product isn’t a person.

The second job is to show what the assistant understands. The first HAX guideline (G1) asks you to make clear what the system can do. One of its patterns is demonstrating possible inputs with examples. A few sample questions above the empty chat field, such as “Where is my package?” or “What is the return policy?”, do just that.

This start screen is really an empty state. Before the first message, it tells users what they can write here.

PAIR also advises against promising “AI magic”. Say what the product can and can’t do. Keep the introduction short, and let users try it with low-risk tasks that can be undone. I describe the introduction flow in the onboarding pattern.

Recommendations

With a recommendation, the real question is why users are seeing it. HAX G11 asks for access to an explanation of why the system behaved as it did. A one-line reason such as “You bought running shoes last month” can be enough.

If you offer a control such as “Show less of this”, state its effect. According to PAIR, a control like this sometimes only filters content and doesn’t train the model. If users expect something else, they are disappointed. HAX G16 points the same way: show right away how users’ actions affect the system’s future behaviour.

When confidence is low, show several options instead of a single recommendation. PAIR calls these N-best options and writes that they help especially when confidence is low.

Uncertainty and confidence indicators

HAX G2 asks you to help users understand how often the system may make mistakes. PAIR calls this calibrating trust. Users should trust the system neither too much nor too little.

The way you show it matters. PAIR recommends showing confidence in categories such as “high, medium, low” and deciding for each level what users should do. PAIR is cautious about percentages, because they assume users understand probability well. If the confidence indicator doesn’t affect the decision, not showing it at all is also an option.

Page Laubheimer of NN/g recommends expressing uncertainty in the first person for low-confidence answers. The sentence “I’m not entirely sure about this” in the demo is an example. Laubheimer also warns that a fixed disclaimer under every answer turns into background noise over time. Show the warning at the moments when an error is more likely.

Source attribution

A source gives users the chance to check the answer themselves. PAIR asks you to say which data the system uses: data from this user only, or data collected from all users? When data is missing, also tell users that they need to use their own judgement.

Link the source to the document the sentence is based on. A general list of links under “Sources” doesn’t tell users which sentence comes from where.

Laubheimer sees a risk here. Visible sources can give users the impression that the answer is correct and lower their attention. That is why the source doesn’t replace the confidence indicator. The two work together.

Correction and feedback

HAX G9 asks you to make it easy to edit, refine or recover when the system is wrong. G15 asks that users can share their preferences during regular use. The “Wrong? Correct it” button in the demo combines both: users choose what is wrong, and the answer changes right away.

Say what happens after the feedback. PAIR compares two thank-you messages. Saying only “Thanks for your feedback” doesn’t reveal what changes. If a running app says “Your next recommendation won’t include hills”, on the other hand, the scope is clear.

According to PAIR, feedback options shouldn’t overlap and should cover all possible cases. Users should be able to delete earlier input later and reset the system to its non-personalised state. PAIR describes this under the heading of editability.

Handoff to a person

When the assistant can’t answer, users shouldn’t hit a dead end. The PAIR chapter on errors asks that users can easily take over the task when the AI fails. Users should know the situation and what to do next, and how.

In chatbot design, this means a button to hand off to a support agent. It doesn’t have to sit under every answer. But it should be visible when the assistant has misunderstood twice, or when money or health is involved.

Send a summary of the conversation along with the handoff. Anyone who has to explain their issue to an agent from the start feels that the assistant has wasted their time.

HAX G10 recommends scoping down the service when the system is uncertain. One of its patterns is to disambiguate before acting, another is to fall back to other strategies. Handing off to a person is one of those strategies.

Errors and wrong answers

In AI, an error doesn’t always mean an error screen. PAIR adds a third kind to the familiar user and system errors: the context error. In a context error, the system works as intended but misjudges what users want at that moment.

There are also cases where the system has no correct answer at all. PAIR calls them failstates. The message should describe the system’s limit as concretely as possible. Instead of “An error occurred”, write “I can’t access your order history. If you send me your order number, I’ll look it up.”

PAIR has a short rule for error messages: be human, not machine. Admit the error and invite users to carry on. I cover the wording of the message in more depth in the error messages pattern.

When the input is unclear, ask before you guess. PAIR recommends confirming intent with “Did you mean …?”. The first pattern of HAX G10 says the same: disambiguate before acting.

Privacy notice

If an AI product learns from users’ behaviour, they should know from the start. For this implicit feedback from product logs, PAIR asks you to inform users in advance and get their permission. Users should be able to opt out of parts of this sharing.

Give the notice in context. As an example, PAIR names a short text that shows, at the right moment, where users can see their data and change settings. HAX G17 also asks that users can globally customise what the system monitors and how it behaves.

One line under the chat field is enough: “Your conversations are stored to improve the service. You can turn this off in settings.” Hiding this setting deep in menus would be a misleading dark pattern.

Patterns and their principles

The table below maps each pattern to the matching HAX guideline and PAIR chapter. The section numbers are the numbered headings within the PAIR chapters.

Pattern	HAX guideline	PAIR chapter
Chat interface and expectations	G1: Make clear what the system can do	Mental Models, sections 2 and 4
Recommendation	G11: Make clear why the system did what it did; G16: Convey the consequences of user actions	Feedback + Control, section 2
Uncertainty and confidence indicator	G2: Make clear how well the system can do what it can do	Explainability + Trust, section 4
Source attribution	G11	Explainability + Trust, section 1
Correction and feedback	G9: Support efficient correction; G15: Encourage granular feedback	Feedback + Control, sections 2 and 3
Handoff to a person	G10: Scope services when in doubt	Errors + Graceful Failure, section 3
Errors and wrong answers	G10	Errors + Graceful Failure, sections 1 and 2
Privacy notice	G17: Provide global controls	Feedback + Control, section 1

The HAX guidelines are grouped into four phases: initially, during interaction, when the system is wrong, and over time. G1 and G2 belong to the start, G9, G10 and G11 to the moment of error. G15, G16 and G17 belong to the over-time phase.

How to test

Don’t sign off an AI interface after a single try. Raluca Budiu of NN/g writes that a single output isn’t an evaluation, only an example. Language models can answer the same question differently each time.

Budiu recommends setting up the test like a quantitative study. Pick many questions and run each one several times. Then look at which questions the errors cluster around.

Try the interface with real users as well. Do they read the confidence indicator correctly, do they click the source? A usability test shows you. PAIR also recommends planning plenty of time to test whether the confidence indicator really helps users.

My note

What I see most often in products with a new AI feature: the answer always sounds equally sure. Whether the model is confident or not, the tone stays the same. And after the first wrong answer, users trust none of them.

I always start with the screen for the wrong answer. Everyone draws what the right answer looks like. Few draw what users see when the answer is wrong, and where they go next.

My second recommendation: don’t hide the button for handing off to an agent. Some teams bury it to cut support costs. But an assistant with no way out only sends users to the agent more annoyed. How AI is changing designers’ work is covered in my post AI and UX designers.