Traditional interfaces are built on predictable rules. A button saves the record or it doesn't. The same inputs give the same result.

AI breaks that. Output can be plausible and wrong. The same request can produce different answers. Quality depends on context the system might not have. And a confident tone hides weak evidence beautifully.

I've been designing interfaces for AI products and working with teams shipping AI features into existing tools, and the lesson is the same every time. Good AI UX doesn't paper over uncertainty with reassuring copy. It helps people understand what the system can do, judge the output, fix it, and control the consequences.

The short answer

Use AI where it creates real value, then design around its limits. Set expectations before use. Show sources and context. Give people easy ways to edit, retry, compare, dismiss, or undo. Require review before high impact actions. Explain errors in a way that leads to recovery.

Test the full range of outputs, not just the demo. Ambiguous requests, missing context, sensitive data, unsupported claims, slow responses, partial failure, and moments where the user and the system disagree.

Start with the job, not the chatbot

AI is a capability, not automatically a product experience. A chat box works for open ended, conversational tasks. It's usually a poor default for repeated structured work.

Define the user's goal, the part that needs judgment or generation, the information the system needs, the cost of a wrong output, who owns the final decision, and the safe fallback when AI isn't available.

A support agent summarizing a long case benefits from a generated draft inside the workflow they already use. They don't need a separate assistant that makes them describe the case again.

Look beyond chat. Suggested values inside a form. A draft beside its source material. Ranked recommendations with filters. An explanation attached to an alert. A review queue for generated actions. Inline rewriting with accept and reject. A comparison between current and proposed content.

The best placement reduces work without making people learn a new interaction model.

Pattern 1: Make the scope clear before use

Tell users what the system helps with and where it struggles. Specific example tasks, required inputs, data sources it can reach, important exclusions, whether output is a draft or a decision, whether it can take actions, and how user data is handled.

Skip "Ask anything" when the system only works well for a narrow set of tasks. Microsoft's Guidelines for Human AI Interaction start exactly here: make clear what the system can do and how well. Clear scope helps people calibrate their trust before the first result appears.

Pattern 2: Collect context progressively

AI quality depends on context, but a blank prompt asking for everything creates effort and doubt.

Use examples based on the current task, structured options for important constraints, suggested source files or records, a preview of what the system will use, and a follow up question when a missing detail materially changes the answer.

Only ask for information the system can use. If audience, country, or time period changes the result, expose it. Keep recent context visible and editable. Hidden memory produces surprising output. Let people remove irrelevant context or start fresh.

Pattern 3: Show uncertainty where it changes action

A generic confidence score isn't always meaningful. "92% confident" creates false trust if the number isn't calibrated for the task.

Show uncertainty as information people can act on: missing sources or incomplete coverage, conflicting evidence, assumptions made, freshness limits, alternative interpretations, areas needing review, or a clarification request when intent is ambiguous.

Put the warning beside the affected output, not in a general disclaimer at the bottom. Interrupt harder when the consequence is higher. A headline draft needs a light nudge. A recommendation affecting money, health, safety, access, or employment needs stronger verification and a named human owner.

Pattern 4: Attach evidence to claims

When the system summarizes documents, searches knowledge, or recommends an action, let people inspect the basis. Source links beside the relevant sentence. Short quoted excerpts. Highlighted passages in the original. A list of records used in a calculation. Data date and owner. A visible distinction between sourced fact and generated inference.

Don't hide all sources behind one "Learn more" link. A user should be able to connect a consequential claim to its evidence without reverse engineering the response.

Evidence needs quality signals too. A source can be real but outdated or irrelevant. Show enough context to judge it.

Pattern 5: Make correction easier than starting over

AI will be wrong sometimes. Recovery is part of the primary experience, not an edge case.

Provide ways to edit the output directly, retry the whole result, regenerate one section, add missing context, change tone or length or format, replace a weak source, compare versions, restore the previous version, and dismiss the suggestion.

Microsoft's HAX guidance explicitly calls for efficient dismissal, correction, and recovery. Don't make people rewrite the entire prompt to fix one paragraph.

When someone corrects the system, explain whether that affects only this result, the rest of the session, or future behavior. Don't imply every correction trains the model if it doesn't.

Pattern 6: Separate generation from commitment

Creating a draft and taking an action are different risk levels. Use a staged flow:

1. The system proposes an output or action

2. The user reviews the content, target, and scope

3. The interface shows the expected consequence

4. The user edits or approves

5. The system performs the action

6. The interface confirms what happened

7. The user can undo when appropriate

This matters for sending messages, changing records, publishing content, modifying permissions, making purchases, and bulk updates.

Don't use a cheerful conversational confirmation for a serious action. Show the exact recipients, records, amount, permissions, or destination before approval.

Pattern 7: Match human approval to risk

"Human in the loop" means nothing if the person can't understand the recommendation, has no time to review it, or is expected to approve hundreds of items blind.

Design approval around consequence of error, reversibility, number of affected people or records, quality of evidence, reviewer expertise, time pressure, and legal or policy requirements.

Low risk suggestions get quick accept and undo. Medium risk actions get a clear review screen. High risk decisions may need multiple reviewers, documented reasoning, permission checks, or a non AI fallback.

For large batches, show exceptions first. Let people inspect changed fields and filter by uncertainty or impact. Approval should be an informed decision, not a ceremonial button.

Pattern 8: Design latency and progress honestly

Generation takes seconds or minutes. A spinner with no context feels stuck.

Show that work has started, the current meaningful stage when known, a realistic time expectation, partial results when they're safe and useful, a way to cancel, what happens if the user leaves, and whether retry will duplicate the action.

Don't invent progress messages that imply work the system isn't doing. If duration is unpredictable, say so and preserve the user's place. For background work, notify on completion and give a stable place to review the result.

Pattern 9: Distinguish types of failure

"Something went wrong" hides the recovery path. Separate them:

Input failure. The request is incomplete, ambiguous, too large, or unsupported. Explain what to change.

Retrieval failure. The system couldn't reach a file, service, or source. Identify what's missing and whether the result is partial.

Generation failure. No usable response. Preserve the request and offer a safe retry or a narrower task.

Policy or permission limit. Explain what can't be done and offer allowed alternatives without exposing sensitive rules.

Action failure. The proposal was fine but the external action didn't complete. Show what succeeded, what failed, and how to retry without duplication.

Quality failure. The output completed but is wrong, irrelevant, unsupported, or biased. Make reporting and correction part of the result view.

Microsoft's HAX Playbook encourages teams to identify common AI failures early so recovery can be prototyped. Failure design belongs before production, not after the support tickets arrive.

Pattern 10: Preserve a non AI path

People shouldn't lose a reliable workflow because an AI feature is down or inappropriate.

Keep access to manual search and filters, direct form entry, original documents and records, standard editing controls, human support or escalation, and previous verified versions.

The fallback doesn't need to be equally fast. It needs to be understandable and safe. This matters most when the AI depends on an external service, a usage limit, or a data connection that can fail.

Pattern 11: Make privacy and permissions visible

Tell people what data the system receives, where it comes from, and what it can affect.

Design for permission based access to sources, clear file and record selection, sensitive data warnings, retention and history controls, removal of attached context, separation between personal and shared work, audit history for important actions, and safe handling of copied output.

An AI assistant should never reveal information the user couldn't reach through the underlying product. Test permission boundaries with real role combinations.

The NIST AI Risk Management Framework treats trustworthiness as part of design, development, use, and evaluation. UX can't replace governance, security, or policy, but it's where most controls become understandable to people.

Pattern 12: Ask for useful feedback

Thumbs up and thumbs down are easy to collect and hard to interpret.

Ask at the moment feedback can improve the experience. Which statement was wrong? Was the issue accuracy, relevance, tone, or missing context? What did the user change before accepting? Did they ignore the suggestion because it was wrong or because it arrived at the wrong time? Was the source insufficient?

Keep it lightweight. Don't interrupt every result. Combine explicit feedback with behavior: edits, retries, dismissals, approvals, reversals.

Tell people whether their feedback changes the current output, their preferences, or a future product evaluation.

Test the system, not only the interface

A static prototype can't reveal the AI experience. Test with the real or a representative system as early as you can.

Build an evaluation set with common successful requests, ambiguous requests, missing context, contradictory sources, unsupported requests, long and unusual inputs, sensitive information, biased or adversarial prompts, slow responses, partial tool failure, unsafe proposed actions, and changes in model behavior over time.

Evaluate output quality and interaction quality. Can users notice a weak answer? Do they understand the source? Can they recover? Do they approve an action they should reject?

Track acceptance, edits, retries, dismissals, undo, escalation, task completion, and downstream errors. A high acceptance rate is bad news if people are approving without reading.

Know when not to add AI

Don't use AI when a deterministic rule, normal search, a calculation, or a simpler form solves the task more reliably.

Be cautious when the outcome must be reproducible, errors cause severe or irreversible harm, the system lacks the necessary data, users can't evaluate the output, the organization can't monitor quality, the feature adds latency without reducing work, or the value depends mainly on novelty.

AI should earn its place through a better outcome, not through being present in the interface.

A practical AI UX review checklist

Before launch, confirm the capability and limits are clear, required context is visible and editable, important claims connect to evidence, uncertainty appears where it changes action, users can edit, retry, dismiss, and recover, generation is separated from high impact action, approval shows scope and consequence, latency and partial results are handled honestly, failure types have specific recovery paths, a non AI workflow remains available, privacy and permissions are understandable, feedback captures useful reasons, evaluation covers difficult and changing behavior, and product owners monitor downstream outcomes.

My recommendation

Design AI as a fallible collaborator, not an invisible authority. Let it reduce effort, surface possibilities, and prepare work while keeping evidence, correction, approval, and accountability visible.

The best AI experience isn't the one that always sounds confident. It's the one that helps people know when to rely on the result, when to question it, and what to do next.