Last week I argued that most AI features should not be chatbots. But once you have decided chat is genuinely the right shape for the problem, a second category of failure is waiting. Five chatbot UI design mistakes show up in almost every product I audit, and each one quietly erodes user trust before the team realizes anything is wrong. None get caught in usability testing. All of them show up in the second-week analytics.

What ties the five together is the same root cause: each one hides something the user needs in order to assess what the model is doing. Trust in a chatbot is built or broken in the small affordances that make model state legible.

Mistake 1: The model picks the wrong reference and the user has no way to tell

The user asks "and what about the second one?" The model picks the wrong "second one" from three turns ago. The user has no idea whether the model misread them or whether their question was ambiguous, and the two interpretations have completely different recovery paths. One says "rephrase your question." The other says "the model is unreliable on this kind of reference." Without a visual indicator of what the model is looking at, users default to the second interpretation every time, even when the first is correct.

The fix is a subtle anchor showing what the model is operating on. A connecting line back to the referenced turn, a quote-style highlight, or a small chip that says "responding about: [the earlier message]." Claude does a version of this with artifact references, where edits to a specific artifact get visually anchored to that artifact in the response. Most enterprise chatbots ship without anything equivalent, and the lack shows up as a confusing third-week bug report that engineering cannot reproduce because the model is technically responding correctly to its own interpretation of the user.

Mistake 2: One generic error toast for three completely different failures

Three things can fail when a chat sends a message: the API can time out, the model can refuse for content policy reasons, or the network can drop. The first and third are mostly platform-handled by 2026 with retry queues and offline drafts. Model refusals are the genuinely hard one because they aren't really errors. The user has to be coached toward a rephrasing the model will accept without being told they did something wrong, and without being given a roadmap to bypass the policy. Most chatbots collapse all three into one generic toast, which trains users that "errors mean the AI is broken" when often the right read is "I asked a question the model can't answer this way."

The fix is differentiated error states with recovery affordances that match the actual failure. The same modal shape is fine, but the messaging and the next action need to be specific to which kind of failure just happened. This is one of the cheapest improvements you can make to an AI chat interface, and it pays back in support tickets that never get filed and trust that doesn't get spent on the wrong failure mode.

Mistake 3: No way to fork the conversation from an earlier turn

Real thinking is non-linear. Every chatbot UI assumes it is.

A user is five turns into a useful conversation. They want to try a different angle on turn three's reply without losing what came after. Most chatbots embedded inside products force a binary choice: edit the earlier message and lose everything downstream, or start a new conversation and lose the prior context entirely. Neither matches how anyone actually thinks through a hard problem.

The pattern that works treats the conversation as a tree rather than a thread. The user can branch from any point, explore an alternative path in parallel, and come back to the original branch when they want to. ChatGPT shipped this in late 2025, Claude has had edit-and-branch on user turns for longer, and Gemini AI Studio supports it in its developer interface. The frontier labs have caught up. The chat embedded inside your bank app, your CRM, your CMS, and your support portal has not.

Most teams skip it because the data model is harder. A linear chat log is one table; a branchable conversation is a tree with parent pointers and a way to traverse it. Most product teams do not budget for the second one because no one in the room is asking for it on day one.

The reason users want it once they have it: they were already trying to think, and thinking branches. The first time someone forks a chat to explore three alternatives in parallel without losing the original, they stop tolerating single-thread chats in tools where the conversation actually matters. It is the affordance that quietly raises the floor for what counts as a competent chatbot ui design.

Mistake 4: Citations rendered in ways that hide or bury the sources

When a model claims something factual, the source matters, and the way the source is rendered determines whether anyone actually reads it. Inline footnotes hurt readability and break the conversational rhythm. Separate citation panels create a worse problem: the claim and its source are visually disconnected, so users mentally treat them as different things and stop cross-referencing. Tooltip-only citations are the worst pattern of the three, especially on mobile where they often don't trigger at all, and on desktop they make side-by-side comparison impossible because the source vanishes the moment the cursor moves. A 2025 study from the University of Tennessee and the University of Oklahoma ran 394 participants through four citation interface conditions and found that high-visibility designs dramatically increased source-hovering, but click-through to the underlying material stayed low across every condition. Visibility matters, but visibility alone does not make people verify.

The pattern that works in production is a persistent inline indicator, a small numbered marker placed at the relevant claim, that expands on hover or tap into a source preview, with one click through to the full document. Perplexity does the strongest version. Granola does an interesting variant that quotes the specific transcript segment behind each summary point, which makes verification almost free. Most enterprise chatbots either over-cite (every sentence has a footnote, and the response becomes unreadable) or under-cite (one block of links at the bottom that nobody reads). The middle ground requires deciding which claims actually carry citation weight, and that is a writing decision more than a chatbot UI design decision.

Mistake 5: No way to regenerate with different context

The user gets a response that is 90% right and missed one important constraint. The only options most chatbots offer are to retype the entire question with the constraint added, or live with the wrong answer. Both are bad. Retyping is friction; living with the wrong answer compounds, because the user remembers it the next time the chatbot asks them to verify anything.

The fix is a "regenerate with..." control that lets the user adjust the context of an answer without retyping the whole question. The most common case is adding a constraint the user forgot to mention. The pattern looks like this:

// Common pattern: only "regenerate" with no context change
[Regenerate]

// Better pattern: regenerate with structured context add
[Regenerate with...]
  └ Make it shorter
  └ Use only sources from 2025+
  └ Edit original prompt
  └ Custom instruction...

This is the single most consequential affordance most chatbots are still missing. Users who encounter it in one product carry the expectation to every other AI tool they touch, and chatbots without it start to feel under-built. Most teams skip it because "regenerate" is a thirty-minute feature and "regenerate with..." is a week of structured-input design with new state to manage. Users notice immediately because they were already going to retype the question; the control just saves them the effort.

What the five mistakes share

Every one of them hides something the user needs to assess what the model is doing: the context it is referencing, the failure mode it just hit, the branches available from any given turn, the sources behind a factual claim, the path back from a near-miss answer. Trust in a chatbot is built or broken in the small affordances of chat UX that make model state legible, not in the model itself.

What is the chat UI you have used that handles these well? Drop it in the comments. I am keeping a list.

I am a designer at Fuselab Creative, working on dashboards and AI interfaces for healthcare and enterprise clients. More writing at fuselabcreative.com.