AI UX Design: Keep Control

AI UX design starts with one visible job

Start with a person, an input, a decision, and a visible finish. "Add AI to the support platform" is not a design brief. "Help an agent turn a customer's message and order history into a cited reply draft" is. The second version exposes the data, the reviewer, the evidence, and the point where responsibility stays human.

Write the current workflow beside the proposed one. Record how long people wait, where they search, what they copy, which mistakes matter, and what they already distrust. Google's People + AI Guidebook begins with user needs and success because even strong model output is useless when it removes no meaningful friction.

For example, a marketing manager does not need a magical campaign machine. They may need five source documents summarized into a draft brief, with every claim linked back to a passage. That smaller job is easier to understand, test, correct, and buy.

Choose autonomy from consequence, not ambition

The model's capability does not decide how much control it receives. The cost and reversibility of a mistake do. A weak product gives every task the same chat box. A stronger one changes the interface when an action moves from suggesting words to changing a customer record, publishing a page, or spending money.

OpenAI's guidance on guardrails and human review separates automatic validation from approval decisions. That distinction should be visible in the product. A policy check can run quietly; a consequential side effect should pause with the exact action, target, evidence, and options shown to the reviewer.

The objection is predictable: approvals add friction. They do, which is why every click should not become a tiny customs checkpoint. Put review where an error is costly or hard to reverse. Let low-risk drafting remain fluid, and make repeated safe actions eligible for narrower permissions later.

Design the five states users actually need

The useful AI interface is not one response box. It is a connected sequence of five states: request, progress, evidence, correction, and recovery. Each state answers a different question. What will happen? Is it still working? Why should I trust this result? How do I fix it? What happens when it fails?

Imagine invoice extraction. The request state shows which files and fields are in scope. Progress identifies the current file instead of displaying a theatrical spinner. Evidence links every amount to a page region. Correction lets the reviewer change a supplier or total without rewriting a prompt. Recovery preserves accepted rows when one document fails.

These states also give engineering a sharper contract. The backend must return citations, stable item identifiers, validation errors, partial status, and retry boundaries. AI UX design is therefore architecture work in ordinary clothes. If the interface needs a recovery path, the system needs resumable state behind it.

• Request: show inputs, scope, permissions, and expected output.
• Progress: expose meaningful stages, not invented certainty.
• Evidence: connect claims or actions to inspectable sources.
• Correction: let people repair the smallest wrong unit.
• Recovery: preserve good work and explain the next safe step.

Evidence beats a confidence badge

A percentage can look precise while telling the user almost nothing. Confidence may describe a model's internal score, a classifier threshold, or a product rule. Unless the number has a tested interpretation for this task, show the evidence a person can inspect and the limitation they need to act on.

In a research assistant, place the source beside the sentence it supports and mark unsupported synthesis as analysis. In a document review tool, highlight the clause that triggered a label. In an image workflow, keep the original and generated asset comparable. The goal is not to reveal every tensor. It is to help the right user judge the result.

NIST's human and AI interaction guidance stresses clear roles and responsibilities. A product should name who verifies, who approves, and who owns the outcome. "AI generated" is a label, not a responsibility model.

Prototype the failure path before the model

Prototype the experience with representative user content before building the full model pipeline. Google Design describes a Wizard of Oz approach, where a human or simple script produces realistic output behind the interface. This isolates the product question: can people understand and use the result?

A procurement team could test a contract comparison with ten anonymized documents and manually prepared differences. Include a missing page, an ambiguous renewal clause, two conflicting values, and one clean document. Watch whether reviewers notice the warning, find the source, correct a field, and continue after a partial failure.

This method has a limit. It can validate language, control, comprehension, and workflow fit, but it cannot prove model quality, latency, security, or operating cost. Those belong in the next technical slice and in an AI proof of concept with representative evaluations.

Measure recovery, not just completion

Task completion hides whether the user fought the system for ten minutes. Measure accepted output, correction rate, time to verify, approval reversals, abandoned runs, recovered failures, and unsupported claims caught before use. Segment results by task type and consequence, because formatting a paragraph and updating a contract do not share a sensible success threshold.

For a reply-drafting tool, compare the old workflow with the assisted one. Count drafts accepted after light editing, citations opened, critical errors, and cases escalated to a specialist. Read the changed text as well as the dashboard. A lower edit count is not automatically good if reviewers simply stopped checking.

Bring product, design, engineering, domain operations, security, and legal or accessibility expertise when the stakes require them. A focused product discovery workshop can turn those perspectives into one workflow, a failure set, and a prototype plan instead of six parallel wish lists.

AI UX design buying checklist

• Name one user, job, input, output, decision owner, and explicit exclusion.
• List costly mistakes, irreversible actions, sensitive data, and required approvals.
• Map request, progress, evidence, correction, recovery, and empty states.
• Use real or safely anonymized content, including difficult and failed cases.
• Specify what the interface must receive from the model and surrounding system.
• Define task, verification, correction, recovery, accessibility, latency, and cost measures.
• Separate what the prototype proves from what production engineering must still prove.

Send Seuil one workflow, its expensive errors, and the actions that should never happen silently. We can scope the smallest AI product experience that lets real users judge value and control before the integration becomes the expensive part.