Designing with AI. Probabilistic tools that people can trust, steer and switch off.

Warm-up

You already have strong intuitions about AI features, because you use them daily: autocomplete in your editor, smart replies in mail, a chat assistant in a browser tab. Some of those features feel like magic and some feel like a nag. Before reading, answer three quick questions. Do not look anything up. The point is to notice what you already believe so the chapters can confirm or correct it.

Traditional software does the same thing every time; AI features do something plausible every time. Designing for AI means designing for variation, for error as a normal state, and for time and money spent on every call.

Everything you learned about interaction design assumes a deterministic machine. Press Save and the file is saved. Type 2+2 and you get 4. The user forms a mental model once (see The Human Mind) and the system keeps honouring it. A language model breaks four of those assumptions at once, and each broken assumption becomes a design problem.

Property 1: the same input can give different outputs

Ask a model to summarize the same note twice and you can get two different summaries. Sampling settings can reduce this, and structured output can constrain it, but you should design as if variation is always possible. The consequence is that users cannot build a stable mental model from one try. They learn the feature as a distribution: "it is usually good at this, sometimes odd at that." Your interface has to help them learn the shape of that distribution quickly, and has to make a second try cheap.

Property 2: errors are normal, not exceptional

In classic software an error is a bug, and you fix it. In an AI feature, a wrong answer is a known rate: 3%, 10%, 25% depending on the task. You can push the rate down, but not to zero, and the errors are not flagged. A hallucinated date looks exactly like a real one. So the design job moves from "prevent errors" to "make errors visible, cheap and recoverable". Lisanne Bainbridge's 1983 paper Ironies of Automation warned about the same thing in factories and cockpits: the more reliable automation gets, the less practised and attentive the human who must catch its rare failures.

Property 3: it is slow

A database lookup returns in milliseconds. A model call typically takes from under a second for a short completion to tens of seconds for a long answer, and minutes for a multi-step agent. That puts most AI features above the 1-second line where people lose the feeling of direct manipulation, and many above the 10-second line where they lose attention (the classic Nielsen response-time limits; see Motion & Feel for perceived speed). Latency is not an engineering detail you fix later. It shapes which patterns are even possible: ghost text needs a fast, small model; a research report can take a minute if it runs in the background.

Property 4: every call costs money

A button in normal software is free to press a thousand times. An AI button has a marginal cost per press, paid by you, in tokens. A feature that runs automatically on every keystroke or every page load can cost a hundred times more than the same feature run on request. As a solo creator on a ₹500 or $8 monthly plan, this is a design constraint as real as screen size. Chapter 16 turns it into a calculator.

In the wild

• Gmail Smart ComposeGoogle, 2018
  Suggests the rest of a sentence in grey as you type; you press Tab to accept or keep typing to ignore it. The suggestion costs you nothing when wrong. The cheaper an error is to ignore, the higher an error rate users will tolerate.
• GitHub CopilotGitHub, 2021 preview
  Inline code completions that are often wrong in small ways. Developers accept them anyway because the suggestion sits in the editor where tests, types and their own reading catch mistakes. Put model output where the user's normal checking habits already operate.
• PerplexityPerplexity AI, 2022
  Answers come with numbered citations to web sources. When the answer is wrong, the user has a path to find out. Grounding turns "trust me" into "check me".

You do not need to invent AI design from scratch. Three free, well-researched sources already cover most of it: Microsoft's 18 Guidelines for Human-AI Interaction, Google's People + AI Guidebook, and Apple's machine learning guidance. Learn their shape, then use them as checklists.

Much of the AI design advice you will read online in 2026 is a rediscovery of work published in 2019. That year a Microsoft Research team led by Saleema Amershi published Guidelines for Human-AI Interaction at CHI, the main academic conference on human-computer interaction. They collected more than 150 recommendations from two decades of research and industry, distilled them to 18, and tested them against 20 real AI products with 49 designers. The same year Google's People + AI Research group (PAIR) released the People + AI Guidebook, a practical workbook organized around the product process. Apple's Human Interface Guidelines have long had a section on machine learning, covering feedback, corrections, confidence and limitations.

These were written before large language models went mainstream, and that is exactly why they are valuable: they describe the human side, which has not changed. People still need to know what a system can do, how well it does it, how to correct it and how to turn it off.

Microsoft's 18 guidelines, by moment

The guidelines are grouped by when they apply in the user's relationship with the feature: at first contact, during each interaction, when the system is wrong, and over time. That grouping is the useful part. It reminds you that a feature has a life, not just a screen.

Six guidelines you will use every week, drawn

Eighteen is a lot to hold in your head. These six do most of the work in small products. Here they are as before-and-after mockups.

The other three you will meet constantly: G9 efficient correction (edit the output in place, do not re-prompt from scratch; Chapter 11), G15 granular feedback (a thumbs-down that asks "what was wrong?" in one tap; Chapter 13) and G17 global controls (one setting to turn the feature off or change how it behaves everywhere; Chapter 14).

Google's People + AI Guidebook

Where Microsoft gives you promises to keep, PAIR gives you questions to work through, in six chapters that follow the product process:

1. User needs and defining success. Is AI adding unique value here? Should it automate or augment? What does a good outcome look like, and what is the cost of each kind of error?
2. Data collection and evaluation. What data shapes the behavior, and how will you know if it is good?
3. Mental models. What will users believe the system can do, and how do you set that belief accurately from the start?
4. Explainability and trust. How much explanation does a user need to calibrate trust, not maximize it?
5. Feedback and control. How do users teach and steer the system, and what do they get back for it?
6. Errors and graceful failure. What kinds of failure exist, and how does the user recover from each?

Two PAIR ideas are worth stealing outright. First, calibrated trust: the goal is not that users trust the AI as much as possible, but that their trust matches its actual reliability, high where it is good and low where it is weak. Second, the cost of false positives versus false negatives: a spam filter that hides a real job offer (false positive) is worse than one that lets a spam mail through (false negative). Decide which error is worse for your feature, then tune and design for that.

Apple's machine learning guidance

Apple's HIG treats machine learning as a set of decisions about the role of the feature (is it critical or complementary? proactive or reactive? visible or invisible?) and about inputs and outputs. On the input side it distinguishes explicit feedback (the user tells you, like a "Not interested" button) from implicit feedback (you infer from behavior, like skips), and asks you to be careful with implicit signals because people did not knowingly give them. On the output side it covers showing multiple options, confidence, attribution ("Because you read…") and limitations. The tone is typical Apple: quiet, low-drama features that blend into the task. Its newer guidance on generative AI adds expectations about transparency and responsible content. Read the current pages directly; they change between OS releases.

In the wild

• Spotify recommendationsSpotify, ongoing
  Shelves are labeled with reasons such as "Because you listened to…", and many surfaces offer a way to hide or skip suggestions. Attribution (G11) plus dismissal (G8) make recommendations feel steerable rather than imposed.
• Apple Photos MemoriesApple, 2016 onward
  Automatic memory collections can be trimmed, and you can ask to feature a person or day less. Proactive features need a quiet way to say "less of this" (G13, G17), especially for sensitive content.
• GrammarlyGrammarly, 2009 onward
  Each suggestion is a small card with the change, a short reason and one-click accept or dismiss, grouped by category. G8, G9 and G11 in one component: dismiss, correct, explain.

Start from the problem, not the model. Use AI where the input is open-ended and an imperfect answer is still useful; use plain code wherever a rule can do the job, because rules are instant, free, private and always right in the same way.

There is pressure in 2026 to add AI to everything. Investors ask about it, competitors announce it, and it is genuinely fun to build. But the best AI features in shipping products are narrow, and most of the best features in any product are not AI at all. iA Writer's focus mode, Things' Quick Entry and Linear's keyboard shortcuts are deterministic, and they are loved for being predictable. Before you reach for a model, run the problem through a short test.

Good fits and poor fits

Models are strong at turning messy, unstructured input into something structured (a pasted receipt into fields), at producing a first draft people will edit (a reply, a summary), at matching meaning rather than exact words (search that finds "invoice" when you typed "bill"), and at transforming text between forms (shorter, friendlier, translated). They are poor at exact arithmetic over many numbers, at facts that must be correct with no checking step, at tasks where a person's own voice is the point, and at anything where the rule is known and simple.

Automation versus augmentation

PAIR's guidebook asks a sharp question: should this feature automate the task (do it so the user does not have to), or augment it (help the user do it better)? People want automation for tasks that are boring, repetitive or that they cannot do well, such as filing receipts or transcribing audio. They want augmentation for tasks they enjoy, feel responsible for, or that express who they are, such as writing, designing or choosing what to read. Ben Shneiderman's Human-Centered AI (2022) adds that the two are not one slider: the best systems give high automation and high human control at the same time, like a modern camera that auto-focuses and still lets you pick the subject.

In the wild

• FantasticalFlexibits, 2010s
  Became famous for natural-language event entry ("Dinner with Sam Friday 8pm") with a live preview of the parsed event, long before the current AI wave. Natural input with a visible interpretation is the pattern; the engine behind it is a detail.
• Arc MaxThe Browser Company, 2023
  Included small, ambient features such as renaming pinned tabs to tidy titles and renaming downloaded files. Narrow automation of a chore people do not enjoy, with results that are trivial to check.
• Otter, Whisper-based transcribers2016 onward
  Transcription is a strong automation case: tedious for humans, open-ended input, and errors are visible when you read the text against the audio. Automate when checking is easy and doing is tedious.

"How much should the AI do on its own?" is a dial, not a switch. Four settings cover most products: suggest, draft, act with approval, act and report. Pick the level from the cost of a mistake and the ease of undoing it, and let it rise only as trust is earned.

Automation researchers have studied this question for decades. Sheridan and Verplank's 1978 scale described ten levels of automation, from "the computer offers no help" to "the computer decides everything and ignores the human". Parasuraman, Sheridan and Wickens (2000) added that automation can sit at different levels for different stages: gathering information, analyzing it, deciding, and acting. For software products you can simplify this to four useful levels.

How to choose the level

Two questions decide it. How bad is a wrong action? And how easy is it to undo? A spam filter can act on its own because a misfiled email is mildly bad and fully reversible (it is in the spam folder). Sending an email on the user's behalf is moderately bad and irreversible: once sent, it is gone. Paying an invoice is severe and irreversible. Map your action on these two axes and the level follows.

That last point is the most practical trick in the chapter. You can often raise autonomy safely by making an action more reversible. Gmail's "Undo send" holds a message for a few seconds before it really leaves. A soft delete with a 30-day trash makes deletion reversible. Once an action is reversible, the system can be allowed to do it with less ceremony.

Let autonomy rise with trust

A good pattern is to start a feature one level lower than you think it can handle and let users raise it. Email clients that learn filing rules often begin by suggesting a folder ("Move to Receipts?") and only offer "Always do this" after the user has accepted the suggestion a few times. That is Microsoft's G13 and G14: learn from behavior, adapt cautiously. The setting should be per action type, not global, because a user may happily let the AI file receipts while never letting it reply to clients.

In the wild

• Gmail spam and Undo sendGoogle
  Spam filtering acts and reports, with the spam folder as the log. Undo send adds a short delay so a permanent action becomes briefly reversible. Two classic, quiet examples of level 4 done well.
• Claude Code, Cursor agentsAnthropic, Anysphere, 2024–2026
  Coding agents typically ask before running shell commands or editing files, and let users allow specific actions to run without asking. Approval granularity per action type, with trust raised by the user, not assumed by the tool.
• Smart ReplyGoogle, 2015 onward
  Short reply chips under an email. Tapping one fills the reply; the user still sends. Level 2 at its smallest: the AI drafts three words, the human owns the send.

A chat box asks the user to describe their work instead of doing it. For most tasks inside a product, AI belongs in the work itself: in the text, on the selection, in the field, where the context already is and the result lands without copying.

Chat became the default AI interface by accident: it was the simplest way to expose a general-purpose model to the public in 2022. It is great for open exploration, for questions you cannot phrase as a button, and for learning what a model can do. But as a feature inside a product, chat has three costs. In her 2023 essay Why Chatbots Are Not the Future, Amelia Wattenberger argued that a text box gives no hint of what the system can do, puts the whole burden of expression on the user, and pulls them out of the work they were doing. Maggie Appleton made a similar case in her language model sketches the same year, sketching interfaces where AI appears as margins, lenses and annotations instead of a conversation.

Jakob Nielsen framed the deeper shift: classic software is command-based (you tell the computer how), while AI is intent-based (you tell it what outcome you want). Intent is powerful, but writing intent in prose is hard. Many people are not good at articulating what they want in words, and they should not have to be in order to use your product.

When chat is the right answer

Chat is not wrong; it is a specific tool. Use it when the task is genuinely conversational (tutoring, brainstorming, support), when the user's question cannot be predicted (open-ended Q&A over a knowledge base), or as an escape hatch next to more structured features. A good test: if you can list the top five things users will ask, those five deserve buttons, fields or inline actions, and chat can handle the long tail.

In the wild

• GitHub CopilotGitHub, 2021 onward
  The defining ghost text pattern for code: grey completions inline, Tab to accept, Esc to dismiss, and keyboard shortcuts to cycle alternatives. A chat panel was added later for the long tail. Inline first for the frequent case, chat second for the rare one.
• Notion AINotion, 2023
  AI is reached from within the page: from the space key on an empty line, or from the menu on a selected block, so the result lands as blocks in the page. The document is the context and the destination.
• GranolaGranola, 2024
  You type rough notes during a meeting in a plain notepad; afterwards the app enhances them using the transcript, and visually distinguishes your words from the generated additions. AI amplifies something the user already does, in the user's own document.

Most good AI features are one of about eight patterns. Each has a natural latency budget, a tolerated error rate and a place in the interface. Choose the pattern from the task, then tune the details.

Patterns are useful because users already know them. Once someone has learned that grey text means "press Tab to take this", every product that uses ghost text gets that knowledge for free. Inventing a new AI interaction is expensive for you and for users; reach for a known pattern first.

Two more patterns get their own chapters: agents with plans and checkpoints (Chapter 7) and chat (Chapter 5). And one quiet pattern deserves a mention: ambient AI, where a model improves something without any UI at all, such as better search ranking, smarter defaults or auto-cropped thumbnails. It needs no sparkle; it needs a way to override it.

Pattern by pattern: the details that matter

In the wild

• Apple Writing ToolsApple, 2024
  System-wide transforms on selected text across apps: Proofread, Rewrite, tones such as Friendly or Professional, and Summary, Key Points, List or Table. Proofread lets you step through the changes it made. A short, concrete verb list, available wherever text is selected.
• Photoshop Generative FillAdobe, 2023
  Selection plus optional prompt produces variations on a new generative layer, leaving the original pixels untouched. Non-destructive by construction: the safest kind of AI edit.
• Raycast AIRaycast, 2023 onward
  AI sits alongside instant deterministic commands in the same launcher, and users can save their own AI commands that run on selected text. AI as one row in a fast, familiar surface, not a separate destination.

An agent is an AI that takes several steps on its own toward a goal. Design it like delegating to a new assistant: agree on a plan first, set what it may do without asking, check in at risky moments, and leave a clear record of what it did.

Agents are the most autonomous pattern and the hardest to design. They run for minutes, touch real things (files, calendars, inboxes, code), and fail in new ways: they can go confidently in the wrong direction for ten steps before anyone notices. The design job is to keep the human oriented and in control without making them watch every step.

The four surfaces of an agent

1. The brief. Where the user states the goal. Help them be specific with fields, examples or a short clarifying question from the agent before it starts.
2. The plan. A visible list of intended steps the user can read, edit, reorder or reject before work begins. A plan is the cheapest place to catch a misunderstanding.
3. The run. Progress through the plan, with the current step, what has been done, and checkpoints where the agent pauses for approval before risky or irreversible actions.
4. The report. What was done, what changed (as a diff), what failed, what needs attention, with undo or rollback where possible.

Permissions: scope, not just yes or no

Before an agent acts, users need to understand what it is allowed to touch. Good permission design borrows from operating systems: name the resource, the action, and the duration. "Allow once", "Allow for this task" and "Always allow for this folder" are different promises, and the user should choose. Destructive or external actions (delete, send, pay, publish) deserve their own prompts even when other actions are pre-approved.

Interrupting and steering

Long runs need a way in. Users should be able to pause, stop, and add guidance mid-run ("skip the newsletters") without starting over. Stopping must be safe: the agent finishes or rolls back the current atomic step and reports where it stopped. If the agent hits ambiguity, it should ask a short, specific question with options instead of guessing, and keep working on unrelated steps while it waits.

In the wild

• Claude CodeAnthropic, 2025
  A terminal coding agent that can show a plan, keeps a visible to-do list as it works, asks before running commands or editing files unless the user has allowed them, and lets the user interrupt to redirect. Plan, progress, permissions and interruption as first-class UI.
• Deep research modesOpenAI, Google, Perplexity, 2024–2025
  Several assistants added research modes that may ask clarifying questions first, then work for minutes and return a cited report. Clarify the brief before a long run; make the wait worth it with sources.
• LinearLinear, 2025
  Lets AI agents be assigned issues in the same way as teammates, so their work shows up in the familiar issue, comment and activity views. Agents fit best when their work flows through surfaces people already review.

People decide how to use an AI feature in their first few tries. Show them what it is for, what it is bad at, and what good input looks like, through examples rather than promises, and keep its personality modest so they judge it as a tool.

Norman's idea of the conceptual model (see The Human Mind) matters more with AI, because the feature's abilities are invisible. A button labeled "Save" explains itself. A text box with a sparkle explains nothing. Users fill the gap with whatever they have heard about AI: either that it is magic (and then they over-trust it) or that it is useless (and then they never try it twice). Your job is to replace both myths with an accurate, specific picture.

Three tools for setting the model

Show, do not tell. One concrete example of input and output teaches more than a paragraph of capability claims. Prompt starters (clickable example requests) do double duty: they teach scope and lower the blank-box anxiety. Make them specific to the user's own data when you can ("Summarize the 3 notes you edited today" beats "Summarize notes").

State the limits plainly. Microsoft's G2 asks you to make clear how well the system does what it does. A short line under an input ("Works best with English meeting notes under 1 hour. May miss names.") is honest and protects trust when the feature fails exactly as warned.

Teach at the moment of need. A tour on first launch is forgotten. A tip that appears the first time a user selects text ("Tip: press ⌘J to rewrite this") arrives when it is useful.

Personality: less is more

In 1966 Joseph Weizenbaum built ELIZA, a simple program that mirrored users' statements back as questions. He was disturbed by how quickly people attributed understanding and empathy to it; this became known as the ELIZA effect. Modern models are vastly more fluent, so the effect is much stronger. Human names, faces, "I feel", exclamation marks and fake typing pauses all push people to treat a probabilistic tool as a person who understands them. That raises trust beyond what the system has earned and can encourage emotional dependence.

This does not mean AI text must be robotic. It means: write like a good tool (see Words), not like a friend. Plain, polite, brief, first person only where it helps clarity ("I couldn't find a date in this note"), no claims of feelings, no flattery.

In the wild

• ChatGPT, ClaudeOpenAI, Anthropic
  Both show a short note near the input that the assistant can make mistakes and that important information should be checked. A permanent, quiet limit statement beats a one-time disclaimer dialog.
• PerplexityPerplexity AI
  The empty home screen offers example questions and the answer layout itself (sources first) teaches that this is a search tool, not an oracle. Layout sets expectations as strongly as copy.
• ClippyMicrosoft Office, 1997
  The animated paperclip assistant interrupted with guesses about what users were doing and became a cautionary tale about intrusive, over-personified help. Personality multiplies the annoyance of being wrong.

When an AI states something, show where it came from. A citation turns a claim into something the user can verify in one click, and grounding answers in the user's own data reduces hallucination at the source.

Language models can produce fluent text that is not supported by anything. The most effective design defence is grounding: give the model specific source material (the user's notes, a document, search results) and ask it to answer from that, then show the link between each claim and its source. This changes the user's task from "do I believe this?" to "does this source say that?", which is a question people can actually answer.

Anatomy of a good citation

Explanations: why did it do that?

For recommendations, rankings and classifications, the equivalent of a citation is a reason. Good reasons are short, specific and checkable: "Suggested because you saved 3 articles from this author." Bad reasons are vague and unfalsifiable: "Based on your interests." PAIR's advice is to explain enough for the user to act: to decide whether to trust, correct or ignore. You rarely need to explain how the model works internally; you need to explain which of the user's inputs mattered.

In the wild

• PerplexityPerplexity AI, 2022 onward
  Numbered inline citations with source cards shown above or beside the answer, making sources part of the layout rather than a footnote. Citations as primary UI, not fine print.
• NotebookLMGoogle, 2023 onward
  Answers questions only from documents the user uploads, with citations that jump to the passage in the source. Limiting the model to the user's sources is both a trust feature and a scope statement.
• Readwise Reader GhostreaderReadwise, 2023
  AI actions in a reading app work on the document or passage the user is reading, keeping the source text right beside the output. When the source is on screen, verification costs a glance.

Uncertainty is useful information, but raw percentages rarely help. Show confidence in a form that changes what the user does: highlight the parts that need checking, ask for confirmation below a threshold, or offer alternatives.

Many models and pipelines can give you some signal of how sure they are: probability scores from a classifier, agreement between several samples, whether a retrieved source was found, or whether a parsed field passed validation. The temptation is to print the number ("87% confident"). But most people cannot use "87%": is that good? Should they check? Research on numeric probability displays shows people interpret them inconsistently. The useful question is not "how confident is the model?" but "what should the user do differently because of it?"

Five ways to show it

1. Nothing. Fine when errors are cheap and obvious (ghost text).
2. A number. Use for experts who understand calibration (radiologists, analysts), and only if the number is actually calibrated: an "80%" must be right about 80% of the time.
3. Words or levels. High, medium, low, with a defined behaviour for each. Easier to act on than numbers.
4. Highlight the uncertain parts. Mark only the fields or phrases below a threshold. Directs attention exactly where checking is needed.
5. Alternatives. Show the top two or three candidates when the model is torn ("Starbucks or Starbucks Reserve?"). Turns uncertainty into a quick choice.

In the wild

• Google TranslateGoogle
  For some words and phrases it shows alternative translations you can pick, especially where a term is ambiguous or gendered. Alternatives make uncertainty actionable in one tap.
• Apple Photos search and Live TextApple
  Recognized text and objects are presented as selectable results without scores; when recognition fails, results are simply absent rather than shown as low-confidence guesses. Sometimes the right display of low confidence is not showing the result.
• Bank and expense appsvarious
  Many apps that read receipts or cheques ask the user to confirm amounts and dates before saving, often focusing on fields that failed validation. Confidence drives the review step, not a badge.

Never let AI change the user's work invisibly. Show what will change before it happens, let the user accept or reject each change, make the result editable like anything else, and keep one-step undo for whatever was applied.

Shneiderman's principles of direct manipulation from the 1980s still hold: visible objects, rapid reversible actions, and immediate feedback. AI edits threaten all three. A rewrite can change forty things at once, invisibly, in a way that feels hard to reverse. The diff is the antidote. Programmers have reviewed changes as diffs for decades; the same idea works for prose, data and settings. A diff turns "trust the whole output" into "review a few specific changes", which is a task people are good at.

The review ladder

Match the review tool to the size and risk of the change.

Make output editable, not just acceptable

Microsoft's G9 (efficient correction) means the user can fix the output directly, the same way they edit anything else in your product. If the AI fills a form, the fields are normal fields. If it writes a paragraph, the paragraph is normal text. If it builds a filter, the filter shows up in the filter UI. The worst pattern is output that can only be corrected by re-prompting ("No, make the date Tuesday"), which turns a two-second fix into a negotiation.

Undo and versions

Every applied AI change should be one undo step (not twenty), labeled in the undo history ("Undo AI rewrite"). For generated artifacts, keep versions: when a user regenerates, the previous result should still be reachable, because the first one is often the one they wanted. A simple "1 of 3 ‹ ›" switcher is enough. See Structure & Interaction for undo fundamentals.

In the wild

• CursorAnysphere, 2023 onward
  AI edits to code appear as inline red and green diffs that can be accepted or rejected, including per change, before they become part of the file. The developer's diff habit, brought to the moment of AI editing.
• ChatGPT Canvas, Claude ArtifactsOpenAI 2024, Anthropic 2024
  Generated documents and code open in a separate editable surface with version history, so a user can edit directly or ask for targeted changes and step back to earlier versions. Output becomes a document with history, not a message to copy.
• Google Docs suggestionsGoogle
  Long before AI, suggestion mode let collaborators propose edits others accept or reject one by one. The best AI edit UI may already exist in your product's collaboration model: treat the AI as a collaborator who suggests.

AI is slow, so design the wait. Show something useful fast (stream text, show steps), let people stop or leave, and move long tasks to the background with a notification when they finish.

Three numbers from decades of response-time research still guide the design: around 0.1 seconds feels instant, around 1 second keeps the user's flow of thought, and around 10 seconds is the limit of attention before people switch tasks. Most AI calls land between 1 and 30 seconds, right in the zone where waiting hurts. You usually cannot make the model faster, but you can change what the wait feels like and what the user can do during it. See Motion & Feel for the broader topic of perceived speed.

Time to first useful thing

The single most effective technique is streaming: show output token by token as it is generated. The total time is the same, but the user sees words within a second, starts reading, and judges early whether the answer is going well. The metric to design around is not total time but time to first useful content.

Progress for multi-step work

When a task has phases (search, read, analyze, write), name them as they happen. Real steps are better than a fake progress bar: they are honest, they show the work is happening, and they let the user notice a wrong turn ("Searching for 'Apple fruit'… no, I meant the company"). Keep step labels short and concrete, and avoid theatrical "thinking" text that does not reflect real work.

Cancel, leave, come back

Every AI wait longer than a second or two needs a Stop. Stopping should keep partial output where it is useful, and should not charge the user's quota for work they rejected if you can avoid it. For tasks longer than about a minute, let the user navigate away: show the task in a small tray, send a notification on completion, and badge the place where the result lives. If the work fails in the background, the notification must say so, too.

In the wild

• ChatGPT, Claude, Gemini2022 onward
  Streaming responses with a stop button became the standard for chat interfaces, and many show a short status line for tool use or search steps. Streaming plus stop is now the baseline users expect.
• Research modesseveral assistants, 2025
  Long research tasks run for several minutes while showing the sources being read, and users can leave and return. Long work is acceptable when it is visible and does not hold the user hostage.
• Granola2024
  Enhancement of notes happens after the meeting ends, a natural pause where the user expects to wait a moment. Place slow AI at moments when the user is already pausing.

AI fails in more ways than ordinary software, and some failures look like success. Name the failure types, design a recovery path for each, and make feedback specific enough that you can actually learn from it.

A taxonomy of AI failure

Graceful degradation

When the AI part fails, the product should still work. If smart search times out, fall back to keyword search and say so in a small note. If the model provider is down, the editor still edits; only the AI actions grey out with a short reason. Never lose user input because a model call failed: keep the prompt, the selection and any partial output so retry is one click. This is Microsoft's G10 (scope services when in doubt) in practice: do less, honestly, rather than fail completely.

Refusals that respect the user

Models sometimes decline requests, occasionally for good reasons and sometimes by mistake. A bare "I can't help with that" is a dead end and feels like an accusation. A good refusal says briefly what it cannot do, why if it can, and what it can do instead. If your product's own policy limits a feature (for example, no generating images of real people), state the policy in plain words and link to it.

Feedback that teaches you something

The thumbs up and down under AI answers is everywhere, and on its own it is nearly useless to a small team: you learn that something was bad, not what or why. Microsoft's G15 asks for granular feedback. Follow a thumbs-down with one tap of structured reasons (wrong facts, too long, wrong tone, did not follow instructions, unsafe), an optional text box, and a clear note about what happens to the feedback. Make giving feedback also fix the user's problem: "Too long" should offer a shorter version right away. Feedback that helps the user now gets given far more often than feedback that only helps you later.

Regenerate and report

Regenerate is the universal "try again" for probabilistic output. Make it obvious, keep earlier versions (Chapter 11), and consider "regenerate with…" options (shorter, more formal, with sources) so the second try is directed rather than random. Separately, offer a way to report harmful or offensive output that is clearly distinct from quality feedback, and actually read those reports.

In the wild

• ChatGPT, ClaudeOpenAI, Anthropic
  Thumbs feedback on answers can open a short form for details; regenerate keeps previous responses reachable with a version switcher. Feedback with detail, and versions instead of replacement.
• GrammarlyGrammarly
  Dismissing a suggestion is itself a feedback signal, and the product can learn from repeated dismissals of a type of suggestion. The cheapest feedback is the action the user takes anyway; design it to be captured honestly.
• Search with AI overviewsvarious, 2024–2025
  Public examples of confidently wrong AI-generated answers in search results showed how a fluent summary at the top of a trusted page magnifies hallucinations. The more authoritative the placement, the more grounding and humility the output needs.

An AI that remembers can be far more useful and far more unsettling. Make memory visible, editable and optional; tell people what data goes where in plain words; and never surprise them with what the system knows.

Personalization ranges from small (remembering your preferred summary length) to deep (a long-term memory of facts about your life used across conversations). The usefulness grows with depth, and so does the risk of feeling watched. The philosopher Helen Nissenbaum's idea of contextual integrity is a good test: information flows feel acceptable when they match the norms of the context where the information was shared. A user telling your notes app about a medical appointment expects it to help schedule the appointment, not to tailor ads or bring it up in an unrelated chat with a work colleague's document open.

Four principles for memory

1. Visible. When the system uses something it remembered, it says so ("Using your preference: short summaries"). There is a page listing what it remembers.
2. Editable. Users can correct, delete or add memories individually, not only "clear all".
3. Optional. Memory can be turned off globally (G17) and paused for a session (an incognito-style mode).
4. Scoped. Memories stay in the context they came from unless the user says otherwise. Work stays in work, personal stays personal.

Data use disclosure

Users increasingly ask three questions about any AI feature: Where does my data go? Is it used to train models? How long is it kept? Answer all three in plain words near the feature, not only in a privacy policy. If you use a third-party model provider, say so, and say what their terms are for your API usage. If content is sent off-device, consider a quiet indicator. Where possible, process sensitive data on device or offer a mode that does. See Honest & Calm for privacy as a design value.

In the wild

• ChatGPT memoryOpenAI, 2024 onward
  Memory can be viewed and individual items deleted in settings, turned off, and avoided with a temporary chat mode; the interface notes when a memory is updated. Visible, editable, optional, with a pause mode.
• Apple IntelligenceApple, 2024
  Apple emphasizes on-device processing and describes a Private Cloud Compute system for larger requests, and asks before sending a request to an external model. Where data goes is part of the product design and the product story.
• Netflix and Spotify profileslong-running
  Separate profiles and ways to remove items from viewing or listening history let people keep one person's or one mood's behavior from shaping another's recommendations. Scoping personalization is an old problem with known solutions.

The prompt is part of your interface, whether you show it or not. Write the hidden instructions as carefully as UI copy, and give users controls (buttons, sliders, presets) for the things they would otherwise have to write prompts to ask for.

Every AI feature has two prompts: the one the user writes (if any) and the one you write, usually called the system prompt or instructions, which sets role, tone, format and rules. Jakob Nielsen has called the difficulty of writing good prompts an "articulation barrier": many people struggle to express what they want precisely in prose. Your design job is to lower that barrier by moving as much of the prompt as possible into your instructions and into controls.

Hidden versus exposed prompts

Hidden prompts keep the interface clean and let you encode expertise ("write at a grade 8 reading level, keep the user's terminology, never invent numbers"). Exposed prompts let power users customize and learn. A good middle path: hide the prompt by default, offer presets as buttons, and let advanced users view or edit the instruction behind a preset, as Raycast does with its editable AI commands.

Writing the hidden prompt like UI copy

Treat your instructions as a design artifact under version control. Good instructions are specific (format, length, what to do when information is missing), include one or two examples of ideal output, state what the model must never do in your product (invent prices, give medical advice), and specify how to handle uncertainty ("if the date is unclear, leave the field empty and set needs_review to true"). Each change to the instructions is a design change: test it against your eval set (Chapter 16) before shipping.

In the wild

• ChatGPT CanvasOpenAI, 2024
  Shipped with shortcuts such as adjusting length and reading level using a slider, alongside free-form requests. The slider is a prompt the user never has to write.
• Raycast AI CommandsRaycast
  Preset AI commands (fix spelling, change tone and so on) are visible, editable prompts that users can duplicate and customize, then run on selected text. Hidden by default, open on demand.
• Midjourney and image tools2022 onward
  Image generators grew from prompt-only to include style references, aspect-ratio and variation controls, reducing the need for long, technical prompts. Mature AI tools move expressiveness from words to controls.

You cannot design an AI feature you have not seen fail. Build a small set of real test inputs, judge the outputs against criteria you write down, look at them with your own eyes regularly, and price every feature before you ship it.

In ordinary software, a test either passes or fails. AI output is graded, varied and context-dependent, so you need a different habit: evaluation, or "evals". Big teams build elaborate pipelines; as a designer you need only the core. Hamel Husain's widely shared 2024 essay Your AI Product Needs Evals argues that the most valuable step is simply looking at lots of real outputs and writing down what good means. That is design work, and you are well placed to do it.

A 30-example eval set in one afternoon

1. Collect 30 inputs. Real ones if you have users, realistic ones if you do not. Include 20 typical, 5 hard (long, messy, ambiguous, other languages, Hinglish), and 5 adversarial (empty, off-topic, attempts to make the feature misbehave).
2. Write 3 to 5 criteria. Specific and binary where possible: "No facts absent from the source", "Under 80 words", "Keeps the user's names and numbers", "Asks for review when the date is unclear".
3. Run and grade. Put inputs, outputs and a pass/fail per criterion in a spreadsheet. Grade them yourself; do not outsource your taste.
4. Read the failures. Group them by cause. Each group is a design or instruction change.
5. Re-run on every change. Model upgrade, prompt tweak, new control: run the 30 again and compare. This catches regressions you would otherwise ship.

You can later add automated checks (code that tests length, format, required fields) and use a model to grade fuzzier criteria, but calibrate any model-as-judge against your own grades on a sample first. Never stop reading outputs yourself; it is where design insight comes from.

Cost-aware design

Model pricing is usually per token (roughly, pieces of words), with separate prices for input and output tokens, and prices vary widely between large and small models. Prices change often, so the numbers in the lab below are illustrative only; use your provider's current price sheet. The design levers are the same regardless: how often a feature runs (on request versus automatically), how much context you send, how long outputs are, which model size each feature needs, and whether you can cache repeated work.

In the wild

• Cursor, GitHub Copilot plans2024–2026
  Coding tools have repeatedly adjusted plans, request allowances and model choices as the cost of heavier models became clear, and users notice and react strongly to such changes. Cost shapes pricing, and pricing changes are product changes users feel.
• Notion AINotion
  Began as a paid add-on and later became part of higher plans, a common path as AI costs and positioning change. Decide early whether AI is a feature of the product or a separately priced service.
• Model routingcommon practice
  Many products send simple requests to small, cheap models and hard ones to large models, sometimes letting users choose. Model choice per task is a design and cost decision, not only an engineering one.

An AI feature is a set of choices about what the system says, to whom, and in whose name. Design so people know when they are dealing with AI, are treated fairly by it, keep control of their own data and voice, and come away more capable rather than more dependent.

Bias

Models learn from human text and images, so they carry human patterns, including unfair ones: defaulting to one gender for "doctor", rating some names or dialects as less professional, generating images that reflect narrow beauty or cultural norms. Microsoft's G6 asks you to mitigate social biases. You cannot fix the model, but you can test for bias in your own feature: add eval cases that vary names, genders, dialects (including Indian English and Hinglish), and regions, and check that outputs do not change in ways they should not. Avoid features that judge people (hiring screens, "professionalism" scores) unless you can measure fairness seriously.

Disclosure

People have a right to know when content was generated and when they are talking to a machine. Label AI-generated text, images and voices where they appear, especially when they might be shared beyond your product. For images, support provenance standards such as C2PA Content Credentials where your tools allow. Never let an AI pose as a human in support, sales or social contexts. Regulation is moving in this direction too; the EU AI Act, for example, includes transparency obligations for AI systems that interact with people and for some generated content. Treat disclosure as a design default rather than a legal checkbox.

Dependence and deskilling

Bainbridge's ironies apply to everyday software: when a tool does a task for you, your own skill at it can fade, and you become worse at catching the tool's mistakes. For some tasks that is fine (few people miss doing long division). For others, such as writing, reasoning, learning a language or coding while you are still learning, the skill is the point. Kathy Sierra's Badass: Making Users Awesome (2015) argues that great products are judged by what users become able to do, not by how much users like the product itself. Applied to AI: design features that coach as well as do.

Consent

Ask before using someone's content to train or improve models, and make "no" easy and free of penalty. Ask before cloning a voice, using a person's likeness, or processing someone else's data that the user uploads (a colleague's messages, a client's documents). Do not use AI to manufacture urgency, fake reviews, or personalized manipulation; those are dark patterns with a model behind them (see Honest & Calm).

In the wild

• Content CredentialsC2PA, Adobe and others, 2021 onward
  An open standard for attaching provenance information to media, including whether AI tools were used; Adobe attaches it to Firefly-generated images. Disclosure can travel with the file, not just sit in your UI.
• DuolingoDuolingo
  Added AI features such as explanations of why an answer was wrong, in a product whose whole purpose is building the user's own skill. In learning products, AI should explain, not answer for you.
• Air Canada chatbot case2024
  A Canadian tribunal held the airline responsible for incorrect refund information its website chatbot gave a customer. What your AI says, you say. Ground it and scope it accordingly.

AI is a superb assistant for the wide parts of design work: gathering, drafting, prototyping, generating options, critiquing. Keep the narrow parts human: choosing, judging, verifying, and deciding what the product stands for. AI widens; you narrow.

For a solo creator, AI is like hiring a fast, tireless junior who has read everything and experienced nothing. It can draft forty headlines, sketch three prototypes in an afternoon, summarize twenty interview transcripts, and critique your layout against heuristics. It cannot know what your users felt, which of the forty headlines is true to your product, or when something is technically fine but soulless. Ethan Mollick's Co-Intelligence (2024) suggests treating it as a collaborator you always check, which is the same calibrated trust you design for your users.

Where AI helps, and the trap in each

The sameness problem

Generative tools produce the most likely output given their training. Ask for "a modern SaaS landing page" and you get the average of every modern SaaS landing page: a gradient hero, three feature cards, a pricing table and testimonials. The products Rohit admires (iA Writer, Things, Kindle) are memorable because they made unlikely choices with conviction. Use AI to get past the obvious quickly, then push away from it: give it your constraints and references, ask for options that break a convention, and treat the first output as the thing to avoid.

In the wild

• Prototyping toolsv0, Claude Artifacts, Lovable, Bolt, 2024–2026
  Tools that turn descriptions into working interface code made interactive prototypes fast enough to test ideas the same day. Prototype speed is no longer the bottleneck; deciding what is worth prototyping is.
• Figma AI featuresFigma, 2024 onward
  Figma added AI features for tasks such as renaming layers, generating placeholder content and drafting designs, and adjusted its first-draft feature after users noticed outputs closely resembling an existing app. Generated designs drift toward what already exists; originality is your job.
• Your own support inboxevery solo product
  Summarizing a month of support emails into themes is one of the highest-value uses of AI for a one-person company, as long as you read the original emails behind each theme. Synthesis speeds you to the right emails; it does not replace reading them.

Wrap-up

You started with three diagnostic questions. If you answer them again now, you should be able to say not only which option is right but which chapter, guideline and pattern explains why. That is the shift this guide aims for: from "AI features are magic or hype" to "AI is a material with known properties, and I know how to design with it."

Practice assignment for the next two weeks

Take one AI feature in your product (or the one you most want to add) from idea to a tested prototype, using the guide as a sequence. About 45 minutes a day.

1. Days 1–2. Four-property audit (Ex. 1.1) and four-question test (Ex. 3.1). Decide whether to build at all. If not, pick the next candidate.
2. Days 3–4. Severity–reversibility grid (Ex. 4.1) and pattern choice (Ex. 5.1, 6.1). Sketch the feature in its chosen pattern.
3. Days 5–6. Build the 30-example eval set and cost estimate (Ex. 16.1). Write your hidden instructions and controls (Ex. 15.1).
4. Days 7–9. Build a code prototype with the trust layer: diff or preview (Ex. 11.1), confidence policy (Ex. 10.1), sources if it makes claims (Ex. 9.1).
5. Days 10–11. Design latency, failure and feedback states (Ex. 12.1, 13.1). Simulate a timeout and a provider outage.
6. Day 12. Data-use card, memory if any, and the ethics pass (Ex. 14.1, 17.1).
7. Day 13. Run the trust and control checklist from Chapter 14 and the 18 guidelines. Fix the two biggest gaps.
8. Day 14. Watch two people use it (see Testing & Iteration). Write a one-page reflection: what surprised you, what you would change, and which choices were yours rather than the AI's.

Reading list

• Guidelines for Human-AI Interaction
  Saleema Amershi et al., CHI 2019 · the 18 guidelines with examples; read the paper's tables of real products passing and failing each one.
• People + AI Guidebook
  Google PAIR, 2019, updated since · six chapters of worksheets on user needs, mental models, trust, feedback and errors.
• Human Interface Guidelines: Machine learning, Generative AI
  Apple · quiet, platform-native patterns for feedback, corrections, confidence and limits. Read the current version.
• Human-Centered AI
  Ben Shneiderman, Oxford University Press, 2022 · the argument that high automation and high human control can coexist.
• Ironies of Automation
  Lisanne Bainbridge, Automatica, 1983 · four pages that predict most of the supervision problems of AI agents.
• A Model for Types and Levels of Human Interaction with Automation
  Parasuraman, Sheridan and Wickens, 2000 · the source of "levels of autonomy" thinking, by stage of work.
• Why Chatbots Are Not the Future
  Amelia Wattenberger, 2023 · the clearest short essay on why text boxes are a weak default interface.
• Your AI Product Needs Evals
  Hamel Husain, 2024 · practical, designer-friendly case for looking at data and writing criteria.
• Badass: Making Users Awesome
  Kathy Sierra, 2015 · not about AI, but the best frame for designing AI that makes people more capable.
• Computer Power and Human Reason
  Joseph Weizenbaum, 1976 · ELIZA's creator on what we should and should not hand to machines.
• Co-Intelligence
  Ethan Mollick, 2024 · a practical view of working alongside AI, useful for your own design practice.
• Shape of AI
  Emily Campbell · an online collection of AI interaction patterns with real product examples; use it for pattern hunts.