Principles of AI UX
What changes when the software is probabilistic: set expectations, show the work, make correction cheap, and keep the human in charge of outcomes.
Traditional software makes a quiet promise: press the same button with the same data and you get the same result, and if the result is wrong, that's a bug someone will fix. AI features break that promise. The same request can produce two different answers, an answer can be 90% right, and a wrong answer looks exactly as polished as a right one.
Users feel this even if they can't name it. Interfaces designed for deterministic software leave them guessing how much to trust the output, so they either check everything (and the feature saves no time) or check nothing (and the first serious mistake ends the relationship). This lesson gives you four principles for designing around a probabilistic component, applied to real Deskmate features, plus a review you can run on any AI feature before it ships.
What changes for the people using it
Thinking Like an AI Builder in Module 0 covered what a probabilistic component changes for you as a builder. This lesson is about what it changes for your users. Most of what you know about UX still applies. What changes is a handful of assumptions that ordinary interfaces rely on without saying so:
| Assumption in ordinary software | What's true with an AI feature | Design consequence |
|---|---|---|
| Output is right or it's a bug | Output is a spectrum from wrong to excellent, and "mostly right" is common | Users need a way to judge and repair output, not just accept it |
| Same input, same output | Outputs vary between runs and between model versions | Never make users depend on getting the exact same wording twice |
| Errors look like errors | Wrong answers look as confident and fluent as right ones | You have to surface evidence, because tone carries no signal |
| Capabilities are visible in the UI | What the feature can do is fuzzy and hidden behind a text box | Users need help forming an accurate picture of what works |
| Actions do what the button says | The model interprets the request, sometimes differently than intended | Consequential actions need a checkpoint between intent and effect |
Every principle below answers one of these rows. If you remember nothing else, remember the third: fluency is not evidence. A model writes a wrong refund policy in the same calm voice as a right one, and your interface is the only thing that can give users a reason to believe one over the other. The lesson Why Models Get Things Wrong covers the failure modes themselves; this module is about designing the product around them.