In the first post of this series I argued that trust isn't a quantity to maximize — it's calibration, the match between how much a user relies on the system and how reliable it actually is. That raises an obvious question: calibrate against what?
A user can only calibrate their trust if they can see something about how the answer was produced. If the AI is a sealed box that emits confident sentences, the only signal available is the output's tone — and tone is exactly the wrong thing to trust. Legibility is the fix. It's the second layer of the trust stack, and most teams get it backward.
Legibility is not explainability
The industry conversation runs to "explainable AI" — SHAP values, attention maps, feature attributions. Useful for the team debugging the model. Useless to the person deciding whether to act on an answer at 4pm on a Tuesday.
Legibility is narrower and more practical. It means: the user can see enough of what went into an answer to judge whether to rely on it, in the moment, without a data science degree.
That's a UX property, not a model property. It's about what the product chooses to surface, not what the model can theoretically expose.
What a user actually needs to see
When someone is about to act on an AI output, they're making one decision: trust this, or check it. To make that call well, they need three things — no more.
1. Inputs — what did it look at? The single most trust-building move is showing the source material. A summary with the passages it drew from. An answer with the documents it retrieved. A recommendation with the data points behind it. When the user can see the inputs, they can spot when the AI is working from the wrong context — which is where a large share of confident errors come from.
2. Basis — why this answer over another? Not the full chain of computation. The load-bearing reason. "Flagged because the invoice amount exceeds the vendor's 90-day average." "Recommended because three similar accounts converted on this offer." One sentence that names the actual driver, so the user can sanity-check the logic against what they know.
3. Boundary — what did it not consider? The most honest and most skipped element. "I didn't have access to this quarter's numbers." "This ignores anything outside the uploaded documents." Naming the blind spot is what lets a user catch the case where the missing input was the one that mattered.
Inputs, basis, boundary. If a user can see those three, they can calibrate. Everything past that is usually decoration.
The trap: post-hoc explanations that aren't true
Here's where legibility turns dangerous. A model produces an answer, and then — separately — the product generates a fluent-sounding rationale for it. The explanation reads well. It was also written after the fact and has no causal connection to how the answer was actually produced.
This is worse than no explanation. A plausible, unfaithful rationale actively manufactures over-trust. The user reads a clean line of reasoning, finds it convincing, and relies harder than they should — on machinery that didn't reason that way at all.
The rule I hold teams to: an explanation must be faithful, not just plausible. If you can't tie what you show to what actually drove the output, don't show a narrative. Show the inputs and the boundary — those are true by construction. A retrieved document is a fact about the process. A generated justification might be fiction.
Legibility has a cost, and it should
More visible reasoning means more interface, more reading, more surface for the user to process. Done badly, it becomes noise — a wall of citations nobody opens, a confidence panel everybody scrolls past.
So legibility is a budget, not a maximum. Spend it where the decision is consequential and the AI is uncertain. A low-stakes suggestion the user can undo in one click needs almost none. A recommendation that moves money or touches a customer needs all three elements, up front, unmissable.
The design question isn't "how much can we show?" It's "what's the least we can show that lets this specific user make this specific trust decision correctly?" That's the same discipline as the rest of good product work — subtract until only the load-bearing parts remain.
How this ladders into the rest of the stack
Legibility is the foundation the next layers sit on. You can't show confidence meaningfully (the next post) unless the user already sees what the confidence is about. You can't offer good correction and control unless the user understands what they're correcting. And you can't design honest failure unless the interface has been telling the truth about the reasoning all along.
Get legibility right and the user stops trusting the AI's tone and starts trusting its transparency. That's the shift the whole series is aiming at: reliance grounded in what the system actually did, not how confidently it said it.
FAQ
What's the difference between legibility and explainable AI? Explainable AI usually means technical artifacts — attributions, attention maps — aimed at people debugging a model. Legibility is a UX property: surfacing enough of what went into an answer that an ordinary user can decide whether to rely on it, in the moment, without technical training.
What should an AI product actually show to be legible? Three things: the inputs it looked at, the load-bearing reason for this answer over another, and the boundary of what it didn't consider. Inputs and boundary are true by construction, which makes them the safest to show.
Aren't AI explanations helpful even if they're approximate? Not if they're unfaithful. A fluent rationale generated after the answer, with no causal link to how the answer was produced, manufactures over-trust — the user finds it convincing and relies harder than they should. Show what actually drove the output, or show the inputs and boundary instead of a narrative.
Doesn't showing all this reasoning clutter the interface? It can, which is why legibility is a budget, not a maximum. Spend it where the decision is consequential and the AI is uncertain; keep it near zero for low-stakes, easily reversible actions.
I'm Ravi Jadav, Chief Product Officer and Co-Founder at Sunbots Innovations and Co-Founder at Xwits Developers. Get in touch.