In short
AI products fail when users cannot understand what the system is doing, cannot tell how confident it is, and cannot recover when it is wrong. Designing one means designing four things conventional software rarely needs: a way to show provenance, a way to express uncertainty honestly, a correction path that is faster than starting over, and a permission model the user actually understands. Screens are the easy part.
The problem AI interfaces actually have
Conventional software is deterministic. The same input produces the same output, and when something goes wrong there is a bug to fix. Interface design assumes this: a button does one thing, an error means something specific.
AI products break that assumption. The same input can produce different outputs. The system is confidently wrong some of the time, and it looks exactly as confident when it is right. Nothing in a fluent sentence tells the user which one they are looking at.
That is the design problem. Not "how do we make the AI feel magical" but "how does a person tell whether to trust this, and what do they do when they should not?"
The shift in 2026 is that this has become the thing clients interrogate agencies about. The question moved from should we use AI to how do we make its behaviour understandable, recoverable, and testable.
Show where it came from
Provenance is the highest-leverage pattern available, and it is chronically under-used.
When the system makes a claim, show what it is based on. A citation, a source document, the rows it read, the file it changed. This does three things at once: it lets the user verify without leaving the flow, it makes the system's reasoning inspectable, and it quietly teaches people where the system is reliable.
The common mistake is a citation that is decorative — a link that does not actually support the claim beside it. That is worse than no citation, because it buys trust it has not earned. If you show a source, it must be the source, and clicking it must land on the specific passage.
Express uncertainty without theatre
Every AI product needs a way to say "I am not sure." Most do it badly.
A raw confidence percentage is usually meaningless to users and often not well-calibrated anyway. What works better is behavioural uncertainty — the interface changes what it does rather than printing a number.
When confidence is high, present the result directly. When it is lower, present it as a draft, offer alternatives, or ask a clarifying question first. When the system genuinely does not know, say so plainly and offer a route that does not involve the model at all.
The rule: uncertainty should change the interaction, not just add a caption. A hedge in small grey text under a confident-looking answer is decoration.
Make correction cheaper than restarting
This is where most AI products lose people. The output is 80% right, and the only affordance is a regenerate button — which throws away the 80% and rolls the dice again.
Good AI interfaces let people correct at the granularity of the error. Edit the one wrong paragraph. Reject a single suggested change while keeping the rest. Pin the part that is right so the next attempt does not touch it. Adjust one constraint and re-run.
The test is simple: when the system is partly wrong, is fixing it faster than doing it yourself? If not, people will do it themselves, and your AI feature is decoration. Applied to generated code this is exactly why reviewing a diff beats accepting a rewrite; the same logic governs design-to-development handoff.
Design the permission model as an interface
Anything that acts on the user's behalf needs the user to understand what it can reach. This is interface work, not a settings screen you inherit from engineering.
Be concrete about scope: "read your calendar" not "access your data." Ask at the moment of use rather than in an onboarding wall nobody reads. Distinguish clearly between reading and writing — people are far more tolerant of the first. Require explicit confirmation for anything irreversible or outward-facing: sending, publishing, paying, deleting, deploying.
And make revocation as visible as granting. A permission the user cannot find to remove is a permission they will resent.
Design the failure states first
Most AI product design starts with the happy path demo. That is backwards. The happy path is the easy part; you should design the failure states first, because they are what determine whether the product survives contact with real users.
Work through them explicitly. Confidently wrong: how does a user notice? Refusal: does the interface explain why and offer a route forward, or dead-end? Timeout or partial result: is partial output useful, or confusing? Empty: what does the product do before it has any context to work with? Harmful or inappropriate output: what is the report path, and does anyone read it?
Our general position on empty states and error states applies with more force here, because AI failure is routine rather than exceptional.
Close the feedback loop honestly
Thumbs up and thumbs down is the default, and it mostly collects noise. It tells you someone was unhappy, not what was wrong.
Better: capture the correction itself. When a user edits generated output, that edit is a precise signal about what was wrong. When they reject a suggestion and pick a different one, that choice is data. You do not need to ask people to rate things if you are watching what they fix.
If you do ask, ask something specific — was this factually wrong, or just not what you wanted? Those are different failures with different fixes.
What good looks like
A well-designed AI product is legible: at any moment the user can tell what the system did, what it used, how sure it is, and how to change it. It fails gracefully and visibly rather than silently. It makes correction cheap. It never uses fluency as a substitute for evidence.
Our working principle is that AI should make the work easier to inspect. If a feature removes the source, the owner, or the review step, the feature needs redesigning — however impressive the demo.
If you are building something with a model at its centre, book a call. The interface questions are usually harder than the model ones, and they are much cheaper to answer before you build.
Common questions
What makes designing an AI product different from normal product design?
Conventional software is deterministic — the same input gives the same output, and errors are bugs. AI systems produce different outputs for the same input and are confidently wrong some of the time, looking identical when right and wrong. So the interface has to carry provenance, honest uncertainty, and a cheap correction path, which conventional interfaces rarely need.
How should an AI interface show uncertainty?
Behaviourally rather than numerically. Raw confidence percentages are usually meaningless to users and often poorly calibrated. Instead let uncertainty change the interaction: present confident results directly, present lower-confidence results as drafts or alternatives, ask a clarifying question when input is ambiguous, and say plainly when the system does not know.
What is the most common AI UX mistake?
Offering regenerate as the only correction path. When output is 80% right, regenerating discards the good 80% and gambles again. Users should be able to correct at the granularity of the error — edit one paragraph, reject one change, pin what is right. If correcting is slower than doing it manually, people will do it manually.
How do you design trust into an AI feature?
Show provenance for every claim, with citations that genuinely support the specific statement beside them. Make permissions concrete and scoped, asked at the moment of use. Require explicit confirmation for irreversible actions. And design the failure states before the happy path, since failure is routine rather than exceptional in AI products.
