Designing for trust when the interface is intelligent.
I’ve been applying Nielsen heuristic audits for years. Visibility of system status, match between system and real world, error prevention — my audit checklist has help my redesigns survive.
Then AI showed up in the products I was auditing. They matter more than ever. But they were written for interfaces that do what you tell them. An AI-powered interface does what it thinks you meant. That’s a different design problem, and it deserves a different layer of scrutiny.
This article is about that layer — the experience layer between a probabilistic system and a person who just wants to get something done. What changed in the UX fundamentals, how I design for a product that “might” be right, what I added to my heuristic checklist.
The Interface Used to Be a Mirror. Now It’s a Guess.
Classic UX rests on a quiet contract: the user acts, the system responds predictably, and the interface reflects the system’s state back honestly. Press save, the thing saves. Delete a file, you get a confirmation dialog that means what it says.
AI breaks that contract in a very specific way. The system now produces output, not just state. And that output is generated, probabilistic, and occasionally wrong with total confidence.
That shift hits three fundamentals directly.
Feedback loops.
In a deterministic product, feedback confirms what happened. In an AI product, feedback has to do double duty: confirm what happened and teach the system what “good” looks like next time. A thumbs-down isn’t a dead-end gesture anymore — it’s training data, an undo request, and a trust signal all at once. If your feedback loop doesn’t close visibly — if the user corrects the AI and nothing seems to change — you’ve designed a product that appears not to listen. Appearing not to listen is fatal.
Error handling.
Traditional errors are binary and ownable: 404, invalid email, payment declined. The system knows it failed and says so. AI errors are different. The system usually doesn’t know it failed. A hallucinated answer arrives formatted exactly like a correct one. “Error prevention” as a heuristic used to mean guardrails on user input. Now it also means guardrails on system output — and a recovery path for failures the system itself can’t detect.
Mental models.
Users build mental models from consistent behavior. AI is not consistent. Ask twice, get two answers. So the mental model we need to teach isn’t “this is a smart machine.” It’s closer to “this is a very fast, very well-read junior colleague whose work you should review.” Every design decision — onboarding copy, empty states, button labels — either reinforces a realistic model or inflates a magical one. Magical models convert well in demos and collapse in week two.
The old contract was “the interface shows you the truth.” The new contract is “the interface shows you its confidence.” Those are not the same design problem.
Designing for “Might Be Right”
Most AI features don’t fail loudly. They fail plausibly. So the core design question of the experience layer is: how does the interface behave when the product might be right?
A few patterns I’ve landed on after getting this wrong a few times.
Confidence has to be visible, but calibrated. The instinct is to show a confidence score — 87% sure, a little meter, a color. Be careful. A number implies precision the system doesn’t have, and users read “87%” as a promise. I’ve had better results with behavioral confidence: the interface acts differently at different certainty levels rather than announcing a statistic. High confidence? Present the output directly. Medium? Present it with sources or a quick verify path. Low? Ask a clarifying question instead of answering at all.
The best confidence indicator isn’t a percentage. It’s a product that’s willing to say “I’m not sure — did you mean this?”
Progressive disclosure is your trust budget.
Don’t spend the system’s credibility all at once. Show the answer first, the reasoning on demand, the raw sources one tap deeper. Users who trust the output move fast; users who don’t can drill down without leaving the flow. This is the inverted pyramid applied to machine output — and it mirrors how we handle human expertise. You don’t make a colleague recite their sources for every sentence. You ask when it matters.
Make correction cheaper than abandonment.
If fixing the AI’s mistake is harder than doing the task manually, users will do the task manually and quietly conclude the feature is decoration. One-tap undo, inline editing of generated content, “not this — more like that.” The recovery path is the feature.
Design the empty-wrong state.
Everyone designs loading states and empty states. AI products need a third one: the state where the system produced something and it’s wrong. What does the user see? What can they do about it? What does the product learn? If your answer is “a regenerate button,” you have designed a slot machine, not a tool.
What I Added to My Heuristic Checklist
Nielsen’s ten heuristics still run the table. But when the product contains AI, my audit now has a second pass — an eleventh category, informally, that I run against every AI touchpoint. Here’s what’s on it:
• Calibrated trust. Does the interface communicate uncertainty proportionally, or does a guess look identical to a fact?
• Visible provenance. Can the user see where an answer came from, or at least that it was generated?
• Cheap correction. Can the user fix, undo, or redirect AI output in one or two actions?
• The system learns visibly. When the user corrects the AI, does anything acknowledge it — or does the same mistake come back tomorrow?
• Human fallback. Is there a non-AI path to the same outcome when the AI path fails or the user opts out?
• Failure honesty. When the system is wrong and knows it, does it say so plainly? When it can’t know, does the design assume review?
• Scope honesty. Does onboarding set a realistic mental model of what the AI can and can’t do — or does it promise magic?
• Automation consent. Does the AI ever take consequential action (sending, deleting, publishing, purchasing) without an explicit human gate?
That last one is where I’ve seen the most damage. Teams ship “helpful” automation that acts on the user’s behalf, and the first time it acts wrongly on their behalf, the trust account doesn’t just empty — it goes negative.
A heuristic audit for an AI product isn’t done when the flows pass. It’s done when the failures pass.
Exactly how I use AI in my own workflow is another story — one I’ll write next.
The Experience Layer Is the Product Now
Here’s what I’ve come to believe. When the underlying AI is roughly available to everyone — same models, same APIs, similar capabilities — the model is no longer the differentiator. The experience layer is: how honestly the interface communicates uncertainty, how cheaply it lets people recover, how visibly it learns, how much it respects the human’s authority over consequential action.
The teams that get this wrong will ship products that demo beautifully and erode quietly. Teams that get this wrong ship products that demo beautifully and erode quietly. Teams that get it right earn the most sought-after word in product design: reliable.
My checklist got longer. My audits got slower. And I can’t promise the products I ship will earn trust faster — no checklist can promise that. What I can say is that I catch more of the failures before users do, and the ones that slip through fail more honestly. That’s a trade I’ll take every time.
Thanks for reading! 💗
