AI UX patterns cheat sheet
A one-page summary of AI UX patterns, covering streaming, editable output, citations, uncertainty, approvals and the states every AI feature needs.
2 min read Updated
On this page
The patterns
| Pattern | Use when | Avoid when | Full article |
|---|---|---|---|
| Streaming | Users read prose and partial output helps | Your code needs the complete result | Streaming and loading states |
| Meaningful progress | Waits longer than a second, or multi-step tasks | Steps you can’t actually report | Streaming and loading states |
| Stop button | Any streamed output | Never: always offer it while streaming | Streaming and loading states |
| Editable suggestion | Output is a draft the user owns | Output is consumed only by code | Editable outputs and undo |
| Apply with undo | Cheap, reversible changes | Costly or irreversible actions | Editable outputs and undo |
| Inline citations | Users act on or repeat answers | Pure drafting with no factual claims | Citations and showing sources |
| Quoted passages | High-stakes answers users must verify | Low-stakes, glanceable answers | Citations and showing sources |
| Status instead of confidence % | Answers may be partial or unsupported | You have no way to determine status | Communicating uncertainty |
| Helpful abstention | Sources don’t contain the answer | Never skip it: always design this state | Communicating uncertainty |
| Approval card | Actions that are harmful or hard to undo | Low-risk reversible actions (fatigue) | Approval flows |
| Batched approval | Many related low-to-medium risk actions | Each action needs separate judgment | Approval flows |
| Suggested prompts | Empty states and first use | Suggestions that produce weak results | Onboarding and setting expectations |
| Stated limits | Always, briefly, where they matter | Walls of disclaimers | Onboarding and setting expectations |
The states every AI feature needs
Design each of these before launch, and force each one in testing:
| State | Trigger | The user sees |
|---|---|---|
| Idle | Nothing requested yet | The entry point, named by the job it does |
| Waiting | Request sent, nothing back yet | Immediate feedback and real progress |
| Streaming | Output arriving | Text as it arrives, and a Stop button |
| Ready | end_turn |
The result, with edit, accept and source controls |
| Cut off | max_tokens or context window full |
The partial result, labelled, with a shorter or Continue option |
| Declined | refusal |
A neutral message and a manual path |
| Nothing useful | No source, no result | What’s missing and a next step |
| Busy or unavailable | Rate limit or server error | Plain language, saved work, Try again |
| Stopped | The user pressed Stop | The partial result, marked as stopped |
| Error | Bugs, invalid requests | Plain language and a manual path, never raw codes |
The typed state table puts these into code so a missing state is a compile error.
Three rules that apply everywhere
- Nothing important happens without a clear user action.
- The user’s edits always win over regenerated output.
- Every AI feature leaves a path to the non-AI way of doing the job.