Why AI products need a different UX framework

Almost everything we know about interaction design was worked out for deterministic software. Press the button, the thing happens. The same input produces the same output. If it does not, that is a bug, and the user is right to report it.

AI products violate that contract at the foundation. The same input can produce different outputs. The system's competence varies by case in ways the user cannot predict from the interface. It fails without knowing it has failed. Applying deterministic UX patterns to a probabilistic system produces interfaces that are confidently, quietly wrong, and users who either over-trust or abandon them.

It is worth being precise about what changes, because the answer is not 'everything'. Most of interaction design survives intact. Three assumptions do not.

1. Predictable output

In deterministic software, a user builds a mental model through repetition: this control does this thing. That model is stable, and stability is what makes an interface feel learnable. With a probabilistic system, repetition produces a model that is roughly right and occasionally badly wrong, which is more dangerous than no model at all.

The design response is not to pretend consistency. It is to make the shape of the variability visible: what kind of case this system handles well, what kind it struggles with, and which one the user is currently looking at.

2. Visible failure

Conventional software fails loudly. The request errors, the page breaks, the validation fires. Users notice and respond. An AI system's characteristic failure is a plausible, well-formatted, incorrect answer delivered with exactly the same presentation as a correct one.

This is the single biggest departure, and it means the interface has to carry information that deterministic interfaces never needed to: what this output rests on, and how the user would check it cheaply.

3. Bounded scope

A form has fields. A menu has items. Affordances communicate the boundary of what is possible. An open input box communicates no boundary at all, so users either ask for far less than the system can do or far more, and both experiences read as failure.

The framework we use instead

Five questions, answered in order, before any AI feature gets designed. They are ordered deliberately: each answer constrains the next.

Start with the cost of being wrong

Every other decision follows from this one. An AI that suggests a playlist and an AI that suggests a dosage are not the same design problem wearing different colours. Ask who absorbs the error, how long it takes to surface, and whether it is reversible.

In practice this produces a tiered autonomy model rather than a single setting. Low-consequence, high-volume, well-precedented work can be drafted and routed automatically. High-consequence work should be organised and cited but not concluded.

Design evidence before you design output

Professional users cannot act on conclusions they cannot verify, particularly where they carry the liability. An assistant that says 'estimated reserve: £12,400' saves nobody any time if the reader has to check the file anyway.

Citations do a second job that is easy to miss. When every finding points at its source, a section with nothing to point at stands out, and users notice gaps they would otherwise have read straight past.

Make disagreeing cheaper than ignoring

If correcting the system takes longer than working around it, every user works around it, and the product team loses its only source of real-world failure data. Correction is not a feedback nicety; it is the mechanism by which the product improves.

Deterministic interfaces have loading states. AI interfaces need something else: a way to express partial competence. 'I found this clearly, this is ambiguous, and this section I could not parse' is far more useful than a single confidence percentage, which users either ignore or over-read.

Express confidence in words, per finding, with the reason attached. 'Uncertain, the policy wording in section 4 is ambiguous about flood exclusion' tells a user exactly where to look. '73% confident' tells them nothing they can act on.

It is worth saying plainly, because AI product work attracts a lot of unnecessary reinvention. Information architecture still matters. Typography and density still matter. Empty, loading and error states still matter. Accessibility still matters, and in fact matters more, because generated content is harder to make navigable.

The novel part of AI UX is narrower than the discourse suggests. It is the handling of uncertainty, evidence, autonomy and correction. Everything else is the craft you already have.

Nearly every AI adoption failure we have seen was an experience failure wearing a model-performance costume.

If a capable model is being ignored by the people it was built for, the model is rarely the thing to fix. Look at what the interface asks the user to take on faith, and how much it costs them to disagree.