Let There Be Light: Bringing Order in Conversation Design

I must begin with a confession. I’ve been reading Paradise Lost this week, and it's entirely possible that parts of this post were written while thinking about angels arguing about free will and a rather dramatic fall from grace.

But in all fairness, isn’t building a chatbot sometimes exactly like that? A single rogue prompt, and the entire flow spirals into chaos. A hallucinated product return policy, and the customer is lost in the void. Misaligned expectations between your model and your systems, and suddenly it’s the Fall of Man (or at least your quarterly NPS).

So — in the spirit of divine restoration — let there be light. Today, we’re bringing order to conversational design. We’ll walk through five fundamentals of chatbot UX — not just to make your chatbot talk better, but to make it work better.

1. Use Case Elicitation & Clarity

Before you build flows or fine-tune prompts, start by asking: What’s the actual job of this chatbot?

Is it meant to route users to support? Automate order status queries? Help customers file returns? Too often, teams dive into building “an AI chatbot” without ever aligning on a clear use case. The result is a generic assistant that’s technically impressive but functionally unhelpful — a chatbot that does a bit of everything but none of it well.

The clearer and more tightly defined the use case, the more focused the UX — and the better the outcome for the user.

2. Systems Mapping

AI says yes, backend says no.

Systems mapping is about aligning the conversational architecture with the actual technological reality of your business. It means understanding how your APIs work, what data is accessible, how actions like refunds or cancellations are triggered, what endpoints are stable, and which ones require authentication. It also means mapping these systems to your business logic — not just can we do it, but should we?

This isn’t a technical afterthought — it’s design work. Because when a chatbot says “I can help you cancel your order,” and your system has no such API or permission, that’s not a tech failure — it’s a UX failure. One that confuses users, burns trust, and ultimately results in more escalations than if the bot had done nothing at all.

A conversation designer doesn’t need to write backend code. But they do need to understand the technology and how it all works — enough to make sure the dialog reflects what’s actually possible, and where human intervention might be required.

3. Intent Design

Intent is the user’s goal. It’s what they want to do — regardless of how they phrase it. And no, GPT won’t always guess it right. Especially when different intents sound semantically similar, or when users stack multiple requests into a single sentence.

Effective intent design means creating a structured, user-informed set of categories that the bot can reliably detect and act on. This includes:

  • Designing intent granularity carefully — too broad, and you confuse users with vague responses; too narrow, and you overcomplicate handling.
  • Establishing prioritization rules — what happens when multiple intents overlap?
  • Planning for fallbacks when nothing is confidently detected, or when intent is ambiguous.

Good intent design doesn’t try to boil the ocean. It models just enough structure for the bot to move conversations forward — confidently, accurately, and consistently.

4. Entity Handling

Let’s say a user says: “I want a refund on the green shoes I bought last week.”

The intent is clear: they want a refund. The entities are:

  • Product: green shoes
  • Time: last week

Entities are the concrete details inside the request — dates, names, locations, order numbers, product variants, and so on. Recognizing them accurately is critical to performing the actual task.

When entity handling is poorly designed, several things happen:

  • The bot may ignore previously shared info and ask for it again (“What product are you referring to?”).
  • It might fail to track references (“the shoes” → which pair?).
  • It might rigidly require inputs in predefined formats or fields, breaking the illusion of conversation.

In short, bad entity design makes the bot feel like a form — a slow, confusing, frustrating form — disguised as a chat.

Good entity handling keeps context alive across turns, knows when to clarify, and allows users to speak naturally without being penalized for it.

5. Fallbacks with Grace

Every bot will fail at some point. The important question is: how gracefully does it recover?

Fallbacks are not just for errors. They’re part of the experience — a designed response to the unexpected. A good fallback doesn’t just say “I don’t understand.”

Graceful fallbacks show empathy and offer options. They acknowledge the user’s intent, even if they can’t act on it. They offer routes forward rather than dead ends.

Designers should think of fallback not as failure, but as a strategic layer of conversational safety — one that protects the user’s time, preserves brand trust, and reinforces that even when the bot doesn’t know, someone does.

In Conclusion

Conversation design isn’t about making the AI sound polite. It’s about making the experience work — end to end.

These five fundamentals — clear use cases, system alignment, structured intents, robust entity handling, and graceful fallbacks — are what actually drive effective chatbot UX. They turn a language model into a reliable assistant.

The smartest model in the world can still disappoint your users. But a well-designed experience? That’s what actually makes them stay.