---
title: "UX patterns for AI features | Optimize All Academy"
description: "Designing for probabilistic output Traditional UX assumes the software does what it says every time. AI features are sometimes wrong, variable and hard…"
url: https://optimizeall.com/learn/building-ai-products-and-workflows/ux-patterns-for-ai-features
updated: 2026-10-05
---

Building AI Products & Workflows · Unit economics and UX patterns for AI features · lesson 14 of 18 · 12 min

# UX patterns for AI features

## Designing for probabilistic output

Traditional UX assumes the software does what it says every time. AI features are sometimes wrong, variable and hard to predict. Good AI UX helps users **get value when the AI is right, notice when it's wrong, and recover easily**, building *calibrated* trust: not blind trust, not reflexive distrust.

## Core patterns

**1. Draft, don't decide (by default).** Present outputs as editable drafts or suggestions, with clear ownership: the user sends, publishes or approves. Examples: suggested replies, draft summaries, proposed categories.

**2. Show sources and evidence.** Citations, highlighted source passages, links to records. Users can verify claims quickly, and trust grows where it is earned.

**3. Communicate uncertainty and limits.** Flag low-confidence outputs ("I couldn't find this in your documents"), and state what the feature can't do. Avoid fake precision (confidence percentages users can't interpret).

**4. Make correction easy.** Inline editing, regenerate with guidance ("shorter", "more formal"), and one-click feedback. Capture corrections as evaluation data (with consent and privacy controls).

**5. Preview before action.** For actions (sending, updating records, booking), show exactly what will happen and require confirmation. Include undo where possible.

**6. Progressive disclosure.** Show the answer first, then reasoning, sources and details on demand.

**7. Set expectations at the entry point.** Example prompts, capability descriptions, and suggested starting points reduce the "blank box" problem where users don't know what to ask.

**8. Graceful failure.** When the AI can't help, say so and offer a path: search, a human, a form. Never leave users in a loop.

**9. Latency design.** Stream output; show progress for multi-step tasks ("Searching policies... Drafting reply..."); allow cancelling.

**10. Transparency about AI.** Make it clear when content is AI-generated and when users are interacting with an AI rather than a person. Some regulations and platform policies require such disclosure.

## Choosing the right interface

Not every AI feature should be a chat box.

- **Inline assistance** (in the document, form or ticket) often beats a separate chat window, because context is already present.
- **Structured outputs** (filled fields, tags, tables) fit workflows better than prose.
- **Background automation** with review queues suits high-volume operations.
- **Chat** fits open-ended exploration and questions where users don't know the exact path.

## Worked example: CRM call summaries

A sales team gets AI call summaries in their CRM.

- v1: a long prose summary in a chat panel. Reps rarely read it.
- v2: structured fields filled automatically (pain points, budget signals, next steps, competitors mentioned), each with a timestamp link to the call recording, editable inline, with a "confirm" button that logs the activity.
- Adoption rises; edit rates show which fields need improvement (budget signals are often wrong, so they are shown as "suggested" with the quote).

The model didn't change; the UX did.

## Anti-patterns

- **Overclaiming:** marketing copy and UI that imply the AI is always right.
- **Hidden AI:** users can't tell what is AI-generated.
- **Dead ends:** "Sorry, I can't help" with no alternative.
- **Anthropomorphism that misleads:** personas that encourage users to over-trust or share inappropriately.
- **Confirmation fatigue:** asking users to approve trivial steps, so they stop reading important ones.

## Accessibility and inclusion

AI features should work with assistive technologies, support the languages your users speak, and be tested with diverse users. Streaming text, dynamic updates and chat interfaces need particular attention for screen-reader users.

## Writing UI copy for AI features

Microcopy shapes trust. Prefer plain, honest labels such as "Suggested reply (review before sending)" over "Perfect reply". Explain what the feature used ("Based on the last 3 emails and your returns policy") so users understand its limits. Keep error messages specific and actionable.

## Hands-on: streaming, progress and sources in the interface

**Streaming** is the single cheapest UX upgrade for text generation: users see progress immediately instead of staring at a spinner. With the Anthropic Python SDK:

```python
import os
import anthropic

client = anthropic.Anthropic()
with client.messages.stream(
    model=os.environ.get("ANTHROPIC_MODEL", "claude-opus-5"),
    max_tokens=2000,
    messages=[{"role": "user", "content": "Draft a polite reply confirming the delivery date of 29 September."}],
) as stream:
    for text in stream.text_stream:          # forward each chunk to the browser (e.g. via server-sent events)
        print(text, end="", flush=True)
    final = stream.get_final_message()       # full message for logging and post-checks
```

For multi-step features, send **progress events** your UI can render ("Searching policies... Found 3 relevant sections... Drafting reply..."), and allow cancel.

**A sources contract.** Agree a response shape between backend and frontend so every AI answer can show evidence consistently:

```json
{
  "answer": "Travel claims must be submitted within 14 days of the travel date.",
  "status": "answered",
  "sources": [
    {"id": "S1", "title": "Employee Handbook 2026 > 4.2 Travel reimbursement", "quote": "Requests must be submitted within 14 days of the travel date.", "url": "/docs/handbook#4-2", "updated": "2026-01-01"}
  ],
  "limits": "Based on the Dubai office policy.",
  "actions": [{"type": "open_ticket", "label": "Ask HR"}]
}
```

`status` can be `answered`, `not_found` or `needs_human`, each with its own honest UI state instead of a generic apology.

**A microcopy kit** to adapt:

| Situation | Copy |
|---|---|
| Draft label | "Suggested reply: review before sending" |
| What it used | "Based on the last 3 emails and your returns policy" |
| Not found | "I couldn't find this in your documents. Try searching, or ask the team." |
| Uncertain | "I may be wrong about the date; please check the order record." |
| Action preview | "This will email 1 customer (Sara K.) from support@. [Review] [Send] [Cancel]" |
| AI disclosure | "You're chatting with an AI assistant. A person can take over at any time." |

Test these with users in failure scenarios, not just happy paths.

## Going further

Run usability tests specifically on failure scenarios: show users wrong outputs and observe whether they notice and recover. A design that works only when the AI is right is not finished.

## Video lecture: UX patterns for AI features

Lecture coming soon · 15 chapters · about 9 minutes. Read the full transcript below.

1. UX for AI features
2. Analogy: an assistant who shows their workings
3. Patterns 1–5
4. Patterns 6–10
5. Choose the interface
6. Simple example: suggested replies
7. Worked example: CRM call summaries
8. Business example (illustrative)
9. Anti-patterns
10. Hands-on in the lesson
11. How you'll know it works
12. Design for 'wrong'
13. Watch me do it: stream + contract + copy
14. Recap
15. Try this now (30 minutes)

## Lecture transcript

### UX for AI features

Traditional software does what it says every time. AI features are sometimes wrong, often variable and hard to predict. That changes the design job. Good AI UX helps people get value when the AI is right, notice when it's wrong, and recover easily. The goal isn't blind trust or reflexive distrust. It's calibrated trust. In this lesson you'll learn ten core patterns, how to choose the right interface, the anti-patterns to avoid, and a practical kit for streaming, sources and microcopy.

### Analogy: an assistant who shows their workings

Here's an analogy. Good AI UX is like working with a capable new assistant who shows their workings. They hand you a draft, point to where they found each fact, flag the bit they weren't sure about, and never send anything on your behalf without asking. You trust them more over time because they make checking easy, not because they claim to be perfect.

### Patterns 1–5

The first five patterns. Draft, don't decide: show outputs as editable drafts, and let the user send, publish or approve. Show sources and evidence: citations, highlighted passages and links, so users can verify quickly. Communicate uncertainty and limits honestly, without fake precision like confidence percentages nobody can interpret. Make correction easy: inline editing, regenerate with guidance such as shorter or more formal, and one-click feedback. And preview before action: for sending, updating or booking, show exactly what will happen, require confirmation, and offer undo where you can.

### Patterns 6–10

The next five. Progressive disclosure: the answer first, then reasoning, sources and details on demand. Set expectations at the entry point with example prompts and capability descriptions, which solves the blank-box problem. Fail gracefully: when the AI can't help, say so and offer a path, like search, a human or a form. Design for latency: stream output, show progress on multi-step tasks, and let people cancel. And be transparent: make clear what's AI-generated and when someone is talking to an AI rather than a person, which some regulations and platform policies require.

### Choose the interface

Not every AI feature should be a chat box. Inline assistance, right inside the document, form or ticket, often wins because the context is already there. Structured outputs, like filled fields, tags and tables, fit workflows better than prose. Background automation with review queues suits high-volume operations. And chat fits open-ended exploration, where people don't know the exact path. Pick the interface that matches the job.

### Simple example: suggested replies

A simple example. An AI feature suggests replies in a help desk. Version one shows a single reply with no context. Agents often ignore it. Version two labels it suggested reply, review before sending, shows the two help articles it used, highlights a date it wasn't sure about, and offers shorter and more formal buttons. The model is identical. Usage and trust both rise, because checking takes seconds.

### Worked example: CRM call summaries

Here's the power of UX. A sales team gets AI call summaries in their CRM. Version one is a long prose summary in a chat panel, and reps rarely read it. Version two fills structured fields automatically: pain points, budget signals, next steps and competitors mentioned, each linked to a timestamp in the recording, editable inline, with a confirm button that logs the activity. Adoption rises. Edit rates reveal budget signals are often wrong, so they're shown as suggested, with the supporting quote. The model didn't change. The UX did.

### Business example (illustrative)

Illustrative numbers for the CRM summaries. With the prose version, reps opened about one summary in five. With structured fields, about four in five calls ended with fields confirmed. Edit rates showed budget signals were changed in about half of cases, so the team labelled them suggested with the quote, and those edits dropped by half again. Managers also got cleaner pipeline data, because fields could be filtered.

### Anti-patterns

Avoid the anti-patterns. Overclaiming, where copy implies the AI is always right. Hidden AI, where people can't tell what's generated. Dead ends: sorry, I can't help, with nowhere to go. Anthropomorphism that misleads people into over-trusting or oversharing. And confirmation fatigue from approving trivial steps, which trains people to stop reading the important ones. Build for accessibility too: streaming text, live updates and chat need care for screen-reader users, and support the languages your users actually speak.

### Hands-on in the lesson

In the hands-on section you'll stream a response with the Claude Python SDK so users see text immediately, and learn to send progress events for multi-step work. You'll get a sources contract, a JSON response shape with an answer, a status of answered, not found or needs human, sources with quotes and dates, limits and next actions, so every answer can show evidence consistently. And a microcopy kit for drafts, not-found states, uncertainty, action previews and AI disclosure.

### How you'll know it works

How will you know your UX works? People use the feature for a high share of eligible tasks. Edit rates show they're engaged but not rewriting everything. In usability tests with deliberately wrong outputs, most people notice the error. Few users hit dead ends. And support tickets about confusing AI behaviour fall. Calibrated trust shows up as fast acceptance of good outputs and quick correction of bad ones.

### Design for 'wrong'

One more principle worth remembering: design for the moment it goes wrong. For every AI feature, ask three questions. How will the user notice this is wrong? How do they fix it in one or two actions? And where do they go if the AI can't help at all? If you can't answer all three, the design isn't finished, however good the happy path looks.

### Watch me do it: stream + contract + copy

Watch me do it. First, streaming. I open the stream call. Inside the with block, I iterate over text stream and forward each chunk, which in a web app goes to the browser as server-sent events. After the loop, get final message gives me the complete response for logging and checks. I run it and text appears word by word instead of after a pause. Next, the sources contract. The backend returns answer, status, sources with ID, title, quote, link and date, limits and actions. The front end shows a sources chip for each source, and when status is not found, it shows the honest not-found state with a search button and an ask-HR action, not a generic apology. Then the microcopy kit: suggested reply, review before sending, based on the last three emails and your returns policy, and the action preview naming the recipient. Finally, I test it with a colleague using a planted wrong date.

### Recap

To recap: design for calibrated trust, with value when right, visibility when wrong and easy recovery. Use the ten patterns, pick the interface that fits the job, and avoid overclaiming, hidden AI, dead ends and confirmation fatigue. Test with users on failure scenarios, not just happy paths. Your next step is to audit one AI feature against the ten patterns and sketch fixes for the two biggest gaps. Next: designing features where AI takes actions for users.

### Try this now (30 minutes)

Try this now. Pick one AI feature you use or build. Score it against the ten patterns, one to five each. Find the two lowest scores and sketch the fix for each, even on paper. Then show a colleague the feature with one deliberately wrong output and watch, without helping, whether they notice. What they do next tells you more than any survey.

## Key takeaways

- Design for calibrated trust: value when right, noticeable when wrong, easy to recover.
- Core patterns: drafts not decisions, sources, uncertainty cues, easy correction, previews, progressive disclosure, expectation setting, graceful failure, latency design, transparency.
- Choose inline, structured or background interfaces when they fit better than chat.
- Avoid overclaiming, hidden AI, dead ends and confirmation fatigue; test failure scenarios and accessibility.

## Try it

Audit one AI feature you use or build against the ten core patterns. Pick the two biggest gaps and sketch improved designs.

- [Previous: Unit economics of AI features](https://optimizeall.com/learn/building-ai-products-and-workflows/unit-economics)
- [Next: Designing agentic product features users can trust](https://optimizeall.com/learn/building-ai-products-and-workflows/designing-agentic-product-features)
- [All lessons of Building AI Products & Workflows](https://optimizeall.com/learn/building-ai-products-and-workflows)