Designing AI people actually trust
AI makes software more capable and less predictable at the same time. Trust is the thing that decides whether people keep using it. Here's the product discipline I bring to AI experiences.
The strange thing about building with AI is that the model is often the easy part. You can stand up something impressive in an afternoon. The hard part — the part that decides whether anyone keeps using it a month later — is trust. AI makes software more powerful and less predictable in the same motion, and people don't adopt tools they can't predict.
So when I design an AI product, I spend most of my attention not on what the model can do, but on how to make its behavior legible, bounded, and correctable. That's a product problem, not a model problem.
Confidence is not correctness, and the UI must say so
The failure mode that erodes trust fastest is an AI that's wrong in the exact same confident tone it uses when it's right. The first time a user catches it — and they will — every future answer becomes suspect, including the good ones. So I design for the reality that the model is sometimes wrong: I show sources, expose the reasoning where it helps, and make it easy to see why the system said what it said. Trust doesn't come from the AI never being wrong. It comes from the user always being able to check.
Put a human where the stakes are
Not every action deserves the same autonomy. Drafting a message, suggesting a tag, summarizing a thread — low stakes, let it run. Sending that message, deleting data, moving money — high stakes, the human stays in the loop. The design job is drawing that line deliberately instead of letting the model act everywhere just because it can. A good AI product feels less like a black box making decisions for you and more like a fast, capable assistant that checks with you before anything it can't undo.
Boundaries are a feature, not a limitation
Founders sometimes want the assistant to do everything, and I usually push the other way. An AI that clearly does a few things well earns more trust than one that vaguely attempts anything. Boundaries tell the user what to expect, and predictability is the raw material of trust. "It always does X, reliably" beats "it might do anything" every time, even when "anything" sounds more impressive in a pitch.
Memory and context are trust infrastructure
An assistant that forgets what you told it two minutes ago feels broken no matter how smart each individual answer is. So I treat context and memory as core product infrastructure, not a nice-to-have: what should the system remember, for how long, and how does the user see and control it? Trust grows when the AI clearly holds the right context — and it collapses the moment a user realizes it's been guessing.
Design the recovery, not just the happy path
The AI will get something wrong. The question that decides your product's fate is what happens next. If the user can catch it, correct it, and move on in a couple of clicks, a mistake becomes a minor moment. If a wrong answer silently flows downstream into something that matters, one error poisons the whole relationship. I design the correction path as carefully as the happy path, because with AI the correction path is the product.
None of this is about making AI less powerful. It's about making power usable — turning an impressive demo into something a real person will trust with real work.
If you're building something where AI sits close to the user and trust is the whole game, I'd like to hear about it.
Written by
Entrepreneur, product strategist & experience designer
I build, advise, and invest in digital products — founder-first product strategy, AI-native experiences, and UX across industries. I run Zenith Studio, my AI-native product studio, from Kathmandu, working with founders globally.
Keep reading
Clarity is the real product work
Most products aren't confusing because the idea is bad — they're confusing because the thinking behind them was never made clear. Here's how I treat clarity as the actual work, not the polish at the end.
Read →Playbook · 7 minHow I pressure-test an idea before building it
Before I write a line of code or design a single screen, I try to kill the idea cheaply. Here's the sequence I use to find the assumption that would sink a product — while it's still free to be wrong.
Read →Turn the idea into a product.
If this maps to what you're building, let's talk it through.