Picture walking into a busy café. The air smells like roasted beans and cinnamon rolls. You step up to the counter and the barista smiles: “What can I get started for you?” She doesn’t ask for your life story or rattle off every menu item. She opens a doorway just wide enough to guide you forward.
That’s the role of a good conversational interface. Like the barista, it frames the interaction with just enough clarity to keep things moving. A single, well-placed prompt helps the user feel seen, understood, and in control.
Intent: The Hidden Engine
Conversational interfaces hinge on intent, the purpose behind what a user is asking. When you tell Alexa to “play some jazz,” you’re not giving her a playlist; you’re expressing an intent: I want music, specifically jazz, right now.
But human intent is rarely neat. Sometimes we hedge: “Maybe something upbeat… but not too loud… like Sunday morning music?” The system must extract meaning from half-baked words and steer toward clarity without killing the mood.
What Do Users Actually Want?
Behind every utterance, the words or sounds a user speaks, sits a goal. It might be simple (“set a timer for fifteen minutes”) or messy (“help me plan a vacation for five people with hiking and sightseeing under two grand”).
The danger is misalignment: a bot that gives you the weather when you ask about traffic, or a kiosk that demands a return date when you’re just browsing hotels. Misaligned intent feels like talking to someone who isn’t listening.
[Design in Practice] Map user goals as intent trees. Utterances branch outward, but the trunk is the underlying intent. This helps teams design for variety while staying rooted in purpose.
Intent vs. Utterance
An intent is the purpose behind what a user says. An utterance is the way they phrase it.
Think of intent as the goal, and utterances as the different ways people point to it.
Intent: I want coffee.
Utterances: “Can I get a latte?” / “One black coffee to go.” / “I need caffeine.”
Designers train systems to recognize many utterances that map back to the same intent. The goal isn’t to teach machines every word in the language, but to make sure they understand the variety of ways humans naturally express themselves.
[UX Lens] If your system only recognizes a single utterance, users feel forced to “speak robot.” Expanding utterances is what makes interactions feel conversational, rather than mechanical.
The Who / What / How Framework
Think of intent design like a stage play. Every play has a cast, a script, and a director guiding the performance. Conversational design is no different except that the audience and the actor are the same person: the user.
- Who is speaking? Is it a hurried commuter who just wants to know when the next train arrives? A first-time traveler overwhelmed by choices? A seasoned coffee drinker rattling off their custom order? Each “who” brings baggage, emotions, urgency, and familiarity that shape how they’ll phrase their request.
- What are they trying to do? Are they checking in for a flight, ordering coffee, finding today’s forecast, or skipping the current song on Spotify? The “what” is the heart of the user’s goal. If you don’t know what they’re aiming for, every response risks being noise instead of signal.
- How is the system helping? This is the invisible choreography. Does the system provide a quick answer, perform an action directly, or guide the user through a step-by-step process? A well-designed “how” adapts to context. Sometimes the best help is immediate action (“Set a timer”). Other times it’s scaffolding (“Let’s book your trip. What city are you leaving from?”).
Put together, this creates a scaffold: My chatbot helps [who] accomplish [what] by [how].
It looks deceptively simple, but that’s the beauty of it. Like stage directions that keep actors from wandering off into the wings, this framework keeps conversations grounded. Without that backbone, dialogue risks rambling into dead ends or overwhelming users with irrelevant options. With it, you get something sturdier: conversations that feel natural yet purposeful, playful yet productive.
[UX Lens] Try writing three versions of this statement for your own project. If your “who, what, how” feels vague or redundant, it’s a sign you need to research users more deeply before building.
The Mess Between Goals and Intents
Humans compress decision trees into fragments: “I don’t want to spend too much, but I want something nice.” That’s budget, quality, and expectation, all wrapped into one line.
For machines, those gaps are minefields. Treating every utterance as a neat command makes a bot feel like a vending machine. Imagine asking for “something affordable but fun” and being forced into rigid menus. Useful, maybe, but not human.
Good conversation design cushions the fuzziness:
Clarifying questions that sound natural (“When you say ‘not too much,’ do you mean under $500?”).
Suggested options that reduce complexity without boxing people in.
A touch of warmth (“Got it, cheap but classy—the sweatpants of vacations”).
Handled well, ambiguity becomes an opportunity to show attentiveness and empathy.tween a transactional bot and one that feels like a partner in problem-solving.
[Design in Practice] During testing, listen for hedge words like “maybe,” “sort of,” and “not really.” These reveal ambiguity points where clarifying patterns should live.
Designing for Clarity Without Killing Personality
Clarity and personality sit on opposite ends of a seesaw. Too much clarity makes the bot feel sterile; too much personality risks creating another Clippy.
The sweet spot is consistency. A weather bot can still joke, “Yes, it’s sweater weather again. Shall I set a reminder for your umbrella?” as long as the core message stays clear.
Personality also matters in repair. If a user asks for “cheap hotels in Chicago” but the bot hears “Chico,” clarity alone isn’t enough. Compare:
Cold: “No results found for Chico hotels.”
Better: “I think you meant Chicago. Want me to show you the best deals there instead?”
The correction is accurate and forgiving. Repair handled with warmth turns friction into trust.
[UX Lens] Treat error handling as its own design sprint. Draft “cold,” “overly playful,” and “balanced” repairs. Test which tone builds trust without slowing the task.
