Conversational UX
Why Most AI Chat Experiences Fail (and How to Design Ones People Actually Trust)
By Sean Doherty ยท June 12, 2026
Last week I opened a support chat on a company's website, typed my order number, and asked why my delivery was stuck. The bot replied with a cheerful paragraph explaining its business hours. I asked again. It offered me a link to reset my password. I had not mentioned a password. Somewhere in that exchange I understood, with total clarity, that this thing had no idea who I was, what I wanted, or what it was even for. I closed the tab and called instead. That is the moment I want to talk about.
I have spent 25 years designing digital products, going back to my years as Toyota's first Kaizen engineer, and more recently building conversational systems for real people. Some of them worked. Some of them embarrassed me. When I led AI innovation at Coforge, I watched more than fifteen enterprise proofs of concept meet actual users, including voice-driven intake systems where the gap between a demo and a trustworthy product was enormous. And I built Fern, the concierge inside FloraLoop, which taught me most of what I know about the difference between a chatbot that talks and one that helps.
Here is the thing nobody wants to hear. When these experiences fail, the model is almost never the reason. The model is fine. The design is what fell over. Let me name the specific ways it falls over, because vague complaints do not fix anything.
The assistant that forgets who you are
You tell it your name, your account, the problem. Three messages later it asks for all of it again, like you just walked in. This is the failure that made me close the tab last week. It is insulting in a very particular way, because it proves the system was never really listening, only pattern-matching your latest sentence.
The fix is not a bigger model. It is memory, deliberately designed. Decide what the assistant should carry across the whole conversation, your identity, your goal, the last thing it promised to do, and hold onto it. In Fern, once you tell it you are shopping for a shade-tolerant plant for a north-facing flat, every later answer is filtered through that. It never asks you to repeat it. That single decision does more for perceived intelligence than any upgrade to the underlying model.
The wall of text
You ask a simple question and get back nine sentences, three bullet points, and a closing offer to help with anything else. Nobody reads it. On a phone it fills the whole screen. The assistant mistook volume for helpfulness.
Good conversation is asymmetric. A short question deserves a short answer. If the honest response is one line, give one line, then offer to go deeper. I would rather ship an assistant that says "Tuesday" than one that writes an essay about the nature of Tuesdays. Design the default toward brevity and let the user pull for more.
The confidently wrong answer
This is the dangerous one. The assistant invents a return policy, a price, a fact, and delivers it in the same smooth, certain tone it uses for everything else. The user believes it, because why wouldn't they, and acts on something that was never true.
The design failure here is not that the model guessed. Models guess. The failure is that the interface gave a guess and a fact identical clothing. So dress them differently. When the system is drawing from a known source, an order record, a policy document, let it say so and, where it helps, show the source. When it is reaching past what it knows, it should sound less certain, hedge honestly, and offer to check. I would rather my assistant say "I am not sure, let me find out" a hundred times than be confidently wrong once. Confidence you have not earned is the fastest way to lose a person for good.
No way out
The bot cannot solve your problem, and it will not let you go. You type "agent." You type "human." You type "speak to a person." It loops you back to the same three canned options like a maze with no exit. This is the failure that turns mild frustration into genuine anger.
Every conversational system needs an obvious escape hatch to a human, and it should never be hidden. Detect frustration. Detect repetition. When someone asks the same thing twice, or plainly asks for a person, hand them off cleanly, with the context they already gave carried across so they do not start from zero. An assistant that knows when to step aside earns more trust than one that pretends it can handle everything. Knowing your limits is not weakness. It is the whole job.
It hides that it is a machine
Some designers still think the goal is to fool you. Give the bot a human name, a fake typing delay, no disclosure, and hope you never notice. Then you do notice, usually at the worst moment, and every helpful thing it said before is now suspect. The deception poisons the trust retroactively.
Be honest about what it is. Fern is plainly an AI concierge, and it says so. People are remarkably forgiving of a machine that is upfront about being a machine, and remarkably unforgiving of one that lied. Honesty is not just ethical here. It is better product design, because trust that survives contact with reality is the only kind worth having.
It has no idea what it is allowed to do
You ask the assistant to cancel the order, issue the refund, change the address. It either refuses everything out of vague caution, or worse, cheerfully claims it did something it had no power to do. Both are the same underlying gap. The system does not actually know the boundary of its own authority.
This is the problem I care about most right now, and it is why I started Cura Mirai, which is patent-pending work on keeping AI safe and human-governed. An assistant needs a clear, enforced sense of what it may do on its own, what needs a human to approve, and what is simply off limits. Those boundaries should be real guardrails in the system, not polite suggestions in a prompt. When the assistant knows its own edges, it can act with confidence inside them and defer honestly outside them. That is what governed autonomy actually looks like.
The principles underneath
Look across those six failures and the fixes rhyme. They come down to a handful of things I now treat as non-negotiable.
- Honesty about uncertainty. Make a guess look like a guess and a fact look like a fact. Never let them wear the same tone.
- An obvious way to a human. The exit should always be visible, and the handoff should carry the context so nobody repeats themselves.
- Memory and context. Hold onto who the person is and what they are trying to do. Most perceived intelligence is just not forgetting.
- Knowing its own limits. The assistant should understand what it is allowed to do and admit what it cannot. Boundaries build trust rather than break it.
None of this requires a frontier model. It requires designers who have sat with real users, watched a conversation go wrong, and felt the specific sting of building the thing that failed. I have built those systems, shipped them, and rebuilt them after they let people down. The technology is ready. The question is whether we design it to deserve the trust we keep asking people to give it. Most teams are still reaching for a better model. Reach for a better design instead. That is where the trust actually lives.