There is a moment, early in almost every AI project I work on, when the team demos a model that genuinely works. The retrieval is sharp, the generations are fluent, the eval numbers are up and to the right. Everyone in the room is delighted. And then the thing ships, and real users touch it, and the delight quietly evaporates. Not because the model got worse — because the product never told the user when to believe it.
This is the part of applied AI that the leaderboard culture trains us to ignore. We obsess over the weights and under-invest in the seams: the places where a probabilistic system meets a human being who has to decide whether to act on what it said. Those seams are not an engineering afterthought. They are the product.
The model is the easy part
I don't mean that literally — training and evaluating a good model is hard, specialized work. I mean that relative to the problem of trust, the model is the well-understood part. We have benchmarks, ablations, and a decade of tooling for making a model better. We have almost none of that for the question that actually decides adoption: does the person on the other side know how much to rely on this?
A model that is right 92% of the time and silent about the other 8% is, in practice, often worse than a model that is right 85% of the time and honest about its uncertainty. The first one teaches users to either over-trust it — until it burns them — or to ignore it entirely. The second one lets people calibrate. Calibration is the whole game.
Confidence is a design material. You shape it with the same care you'd give type, color, and motion — because it is doing the same job: telling the user what to feel and what to do next.
Show the seams
Good AI products make their own boundaries legible. They don't hide the fact that an answer was generated; they frame it so the user can do something intelligent with it. In practice that looks like a handful of recurring moves:
- Cite, don't assert. Where an answer rests on a source, link the source inline. A claim the user can verify in one click is a claim they'll forgive when it's wrong.
- Expose confidence honestly. Not a fake percentage — a real signal. "Found 3 strong matches" reads very differently from "Here's the answer," and it should.
- Make the undo cheap. If acting on a wrong answer is reversible and obvious, users will explore. If it's irreversible and hidden, they'll freeze.
- Design the empty and the failure states first. The happy path demos well. The product lives or dies in the other two.
Latency is a trust signal too
We treat speed as a performance metric, but users read it as a character trait. An answer that appears instantly feels glib; an answer that streams in with visible work feels considered. Neither is more correct — but the pacing changes how much scrutiny the user applies, and a thoughtful product uses that deliberately. A streaming response that surfaces its sources before its conclusion invites the user to read along and judge. That's not a loading state. That's an argument being made in the right order.
Designing for the wrong answer
The hardest discipline is designing as if the model will be confidently wrong — because sometimes it will be. The question is never "how do we stop it being wrong," which is unanswerable, but "what happens to the user when it is."
A system you can't audit is a system you can only either fully trust or fully distrust. Both are failures. The job is to build the dial in between.
That dial is made of small, unglamorous components: a "why did I see this?" affordance, a one-tap way to flag a bad result, a visible record of what the system used to decide. None of it shows up in a benchmark. All of it shows up in whether people come back.
Build the feedback loop, then close it
Trust isn't a launch state; it's a relationship that compounds. Every correction a user makes is a gift — but only if it actually reaches the system. The teams whose AI products keep getting better are the ones who treated the feedback channel as core infrastructure on day one, not a "v2" line item. They instrument the moments where a human overrode the machine, and they feed those moments back into evaluation. The interface is where that loop opens and closes.
So when a team shows me a model that works, I'm glad — genuinely. But the real work is just starting. The model decides whether the answer can be right. The product decides whether anyone will ever trust it enough to find out.
I help teams across Asia-Pacific turn ambitious AI ideas into shipped, well-crafted products — pairing deep cloud architecture with a product designer's eye for clarity and trust. I write and speak about applied AI, developer experience, and the craft of building things that last.