August 2026 · 8 min
AI UX is a behavior specification, not a visual style
Most of what's published about designing AI interfaces is about how they should look. For a product where trust is the product, that's the wrong layer entirely.
The glow. The gradient. The sparkle icon. Where the chat box goes. An AI interface that looks trustworthy and isn't is worse than one that looks like nothing at all. It has spent the user's confidence on a signal it can't back.
So the specification has to be about behaviour. Here's the one I use.
Nine stages
- Signal
- Analysis
- Recommendation
- Action
- Approval
- Execution
- Verification
- Evidence
- Recovery
Most AI product design covers the first three stages carefully and treats the rest as engineering. That's exactly backwards. The first three show capability. The last four are where trust is earned or destroyed.
Signal. Something changed. Does the user see the detection, or only the notification? Showing the detection teaches them what the system watches, which is the start of being able to predict it.
Analysis. What the system inferred, and from what. This is where most interfaces go quiet. "We found an issue" without "because these three checks have disagreed since Tuesday" is a claim the user has to take on faith.
Recommendation. With the reason visible, not tucked into a tooltip. A tooltip is where you put information you've decided is optional. Reasoning never is.
Action and approval. The stage that decides the interface. See the five classes below.
Execution. Progress shown honestly, including what hasn't been done yet. A progress bar that only shows completion is a small lie that gets discovered at the worst moment.
Verification. Did the intended change actually happen? "I ran the command" and "the state is now correct" are different claims. Conflating them is how automated systems lose credibility in one incident.
Evidence. What supports the verification. In compliance that's literal: the artefact an auditor will read. Everywhere else, it's what the user needs when they have to defend the decision to someone else.
Recovery. Undo, with history kept. A working undo changes behaviour before anyone uses it. People try things they'd otherwise avoid. Recovery isn't a safety net. It's an adoption mechanism.
Five automation classes
Every AI surface has to declare which class it is, and the declaration decides the interface. It's a routing rule, not a taxonomy for a slide.
| Class | The system may | The interface must show |
|---|---|---|
| Informational | Surface a finding. Nothing else | The finding, its source, how recent |
| Suggested | Propose. A person starts it | The proposal, the reason, the option to do nothing |
| Auto-executable | Act reversibly, then report | What changed, when, and how to undo it |
| Approval-required | Prepare. A person authorises | The exact action, its reach, who's approving |
| Blocked | Nothing, at any confidence | Why it's blocked, and what would change that |
Plot these on risk against reversibility and they stop being arbitrary. Easy to undo and low risk is where auto-execution belongs. Hard to undo is where approval belongs, however confident the model is. Confidence isn't the axis that matters when the action can't be undone.
The class teams skip is blocked. Every system needs actions it will never automate, declared up front, with the reason. A system with no blocked class is telling you it hasn't thought about its own limits, and users notice faster than you'd expect.
The trust model, as a required field
In the pattern documentation, the trust model isn't a section people write if they have time. It's one of sixteen required points, with six sub-fields: evidence, source, timestamp, confidence, history and reversibility. Making it required is the whole mechanism. Optional documentation describes what a thoughtful designer did. Required documentation is a specification other people have to meet.
What this rules out
Never define AI UX only with a magic button, a sparkle, a gradient, or a chat surface.
Also no anthropomorphism, no motion that exists to make the product feel like AI, no permanent alert styling, no unexplained automation, and no hidden irreversible actions. Each of these signals intelligence instead of demonstrating it. They're cheap to build and they work once.
One principle that shouldn't be domain-specific
A system that watches all the time will find something all the time. If every finding is styled as an alert, the interface teaches users to ignore it, and the one that mattered arrives looking exactly like the eleven that didn't. In a monitoring product, calm isn't an aesthetic. It's what keeps the signal readable.
The portable checklist
- Which of the nine stages does our interface actually show? Name the missing ones.
- What automation class is each AI surface? Is it written down where a reviewer can check?
- Is verification a separate state from execution?
- Is there a working undo, and does the user know about it before acting?
- What's in our blocked class? If the answer is nothing, that's the finding.