AI product design is designing the experience around a feature whose output is a guess: it can be wrong, it can give different answers to the same request, and people cannot see how it reached them. So the work is less about the model and more about everything around it: setting expectations, showing how sure the system is, letting people check, correct and undo, and designing what happens when it fails.
This guide covers what is different about designing for AI, eight principles with examples, and a worked case. The usual toolkit still applies. A UX audit or a heuristic evaluation against Nielsen's 10 usability heuristics catches many AI problems, and most bad UX examples turn up in AI features too. Each principle links to the UX law behind it, and redesigning one AI feature makes a strong UX case study.
| A regular feature | An AI feature | |
|---|---|---|
| Output | The same every time | Can vary for the same request |
| When it fails | It breaks, visibly | It can be confidently wrong |
| How it works | Easy to explain | Hard to see how it reached an answer |
| Errors | Bugs to fix | Part of normal behaviour, to be designed for |
| Acting alone | Rare | Common: it suggests, fills in, sends and books |
Microsoft's Guidelines for Human-AI Interaction and Google's People + AI Guidebook both organise the work around these differences: what to show before people use the feature, during use, when it is wrong, and over time. The eight principles below follow the same path.
Many AI features exist because the team had a model, not because users had a problem. Ask first whether AI is the best way to solve this one. If a rule, a better default or a clearer form would do the job reliably, use that. AI earns its place where the task is genuinely fuzzy: summarising, drafting, sorting, finding patterns. Where people just want the result fast, Time-to-Value still decides whether the feature gets used.
People bring wildly different ideas of what AI can do, so tell them. Say what the feature is good at, what it cannot do, and how often it gets things wrong, in plain words and at the moment they first meet it. Example prompts help more than a paragraph of text: they show the scope by example. Expectations set early are cheaper than trust repaired later.
A confident tone is not the same as a correct answer. Link claims to their sources so people can check them, mark the parts that need checking, and say so plainly when the system is unsure. Avoid precise-looking confidence percentages that people cannot interpret. The aim is Calibrated Trust: people should trust the output exactly as much as it deserves, no more and no less.
The more an action costs, the more the person should see and approve it first. A suggested reply can appear instantly. Moving a meeting, sending an email, spending money or deleting photos should be previewed and confirmed, and easy to undo. Always offer a way out, including a way to reach a person when the AI cannot help.
A calendar assistant that moved meetings by itself to optimise the week: helpful in theory, but the person only finds out afterwards.
Assume the first answer will often be close but not right. Let people edit the output directly, try again, or narrow the request, without starting over. Ask for feedback where it is cheap to give, such as a thumbs down with a reason, and make it visibly change something. A specific request gets a specific answer, which is the Specificity Principle, so help people refine what they ask.
AI is slow and fallible, so its states carry more of the experience than usual. Show progress while it works, or stream the answer as it arrives. Design the moment it has nothing useful to say: "I could not find that" is better than a made-up answer. When it fails, say what happened and offer the next step. This is Design Every State, with higher stakes.
Proactive AI can notice things and speak up: a possible fraud, a scheduling clash, a better way to write a sentence. Each interruption costs attention, and an assistant that cries wolf gets ignored or switched off. Interrupt for what is urgent and important, batch the rest, and let people tune how often it speaks. Interruption Cost explains the trade-off.
Say when content is generated, when people are talking to a bot, and how their data is used. Using people's messages to train a model, or showing them a personalised price, should never be a default hidden in settings. Ask, explain the trade, and make the choice easy to change. Over time, honesty is what keeps people willing to rely on the feature at all.
A traveller asks an assistant to book a flexible morning train to Berlin. It picks the cheapest ticket, a non-refundable 06:12 departure, and pays straight away. The traveller wanted mid-morning and the option to change. The money is now stuck on a ticket they cannot use.
The confirmation screen from the example: the earliest, non-refundable fare, already charged, for a request that asked for flexibility.
This is a free Beginner challenge in UX Quest's AI trust track. The rule it teaches carries over to every AI feature: when a request is ambiguous and the action is hard to undo, confirm first.
AI can already produce screens, copy and research summaries quickly, and it changes how designers work. What it does not do well is the judgment this guide is about: deciding what should be built, noticing when an output is misleading, and weighing speed against trust and control. Those decisions are becoming a bigger part of the job, not a smaller one, as more products include AI.
UX Quest has a track of AI trust challenges built on real scenarios: an assistant that books the wrong train, a calendar that moves meetings on its own, a research tool with a confident fake citation, a support bot with no way to reach a person. Each asks you to make the call and explains the law behind it. Start with Calibrated Trust, then Design Every State and Interruption Cost. Each law page says whether its challenge is free or part of Pro.
Three laws behind the principles above. Open one to see the scenario and the challenge.
AI product design is designing the experience around features powered by AI. Because the output can be wrong, vary and act on its own, it focuses on setting expectations, showing confidence and sources, keeping people in control, and designing for errors.
Start from a real problem, set expectations before first use, show how sure the system is and where answers came from, keep people in control of costly actions, make outputs easy to correct, design waiting and failure states, interrupt only when it matters, and be honest about data.
A regular feature behaves the same way every time and fails visibly. An AI feature can give different answers to the same request and can be confidently wrong, so errors and trust have to be designed for from the start.
Aim for calibrated trust, not maximum trust. Show sources and uncertainty, confirm before irreversible actions, make it easy to undo and correct, and be open about how data is used. People should trust the output exactly as much as it deserves.
Reusable solutions for common AI moments, such as example prompts on first use, cited sources, a confirm step before the AI acts, regenerate and edit controls, streaming answers, and a clear way to reach a human.
AI already speeds up producing screens, copy and summaries. The judgment about what to build, whether an output can be trusted and how to keep people in control is still human work, and it matters more as products add AI.