Field note 02

Live-Model UX: Uncertainty, Feedback, and Control

The model is never fully certain. The hard part of designing for it is resisting the urge to hide that, to dress a guess up as an answer. Most of the work in live-model UX is about showing the system's real state honestly, and giving people enough control to act on it.

A traditional interface is deterministic: the same input gives the same output, and the screen can speak with total confidence. A model-backed one is probabilistic. It's usually right, sometimes wrong, and rarely sure. If the interface pretends otherwise, it teaches people to either over-trust it and get burned, or distrust it and stop using it. Neither is what you want.

I keep coming back to four things: confidence, feedback, permission, and recovery.

Make uncertainty legible

The system knows more about its own confidence than it usually lets on. A model that's nearly sure and one that's barely guessing tend to look identical on screen. Surfacing that gap (not as a raw percentage shoved in everyone's face, but as a calibrated signal) lets people calibrate their own trust. When the system is confident, get out of the way. When it isn't, slow down, ask, and show the reasoning.

Don't display certainty you don't have. An honest “I'm not sure” beats a confident wrong answer.

Show the work

When the system does something, people should be able to find out why: the inputs it used, the options it weighed, where an answer came from. Not a full audit log on every screen, but a reliable path to “why did it do that?” That's what turns a black box into something a person can reason about, trust, and correct.

Keep people in the loop

The model proposes; the person decides, especially when the action has consequences. That's a permissions question as much as a UX one: what the system may do on its own, what needs a confirmation, and what it should never do without you. Reversible, low-stakes actions can run automatically. Costly or irreversible ones earn a moment of friction. The line moves as trust is earned, not before.

Design for being wrong

The model will be wrong sometimes, and the interface should make that cheap. Undo, correct, override, and try-again belong in the foreground, not buried three menus deep. A system that's easy to correct is one people will actually let act, and the safer the recovery, the more autonomy you can responsibly hand it.

The easier it is to undo, the more you can afford to automate.

Put together, none of this is an “AI feature” bolted on. It's the same trust-building work good products have always done (surfacing state, explaining decisions, asking before it matters, forgiving mistakes), only now it's load-bearing. The model's job is to be useful most of the time. The interface's job is to keep the rest of the time survivable, and to keep the person reading what the system is doing and able to step in.