Being able to ask for something in your own words can be a relief.
You do not have to know the name of a feature, understand the organization's structure, or guess which menu holds the answer. You can begin with what you need.
Conversational UX designs those natural-language interactions between people and systems. It connects what someone says or types with what the system understands, asks, explains, and does next.
At Abstraction, the work includes the conversation's purpose, structure, language, behavior, visual or spoken expression, and relationship to the wider experience. A chatbot, support assistant, AI copilot, conversational form, or voice interface needs more than a friendly introduction. It needs to help someone make progress—and remain understandable when the conversation does not go as planned.
The ambition is not to make a machine seem more human than it is. It is to make the experience more considerate of the human using it.
Start with the reason to have a conversation
Not every task becomes easier when it is turned into dialogue.
Someone comparing dates may benefit from a calendar. Someone scanning options may need to see them beside one another. Someone trying to describe an unfamiliar problem may welcome a question that helps them explain it.
We look for the moments where language contributes something useful. Can it help someone express a complex need, refine an uncertain request, find relevant information, or move through a task without learning a new interface first?
We also ask where the conversation should give way to another form of interaction. A concise answer can lead into a comparison, a visual selection, a conventional form, or a conversation with a person. The experience can move between these without treating chat as the destination for everything.
That connects Conversational UX to Interaction Design, Search Experience Design, and Form Design. We choose the combination around the task, not the novelty of the interface.
What the conversation is made of
The visible words are one part of a larger design.
We consider the person's goal, the information needed to help, the context already available, and the actions the system is permitted to take. We shape questions, responses, options, confirmation, correction, recovery, and the transition out of the conversation.
We also define what the experience should feel like. A support assistant dealing with an unresolved problem should not sound like a campaign encouraging someone to buy. A useful personality has to make room for the person's situation.
Some conversations follow tightly defined paths. Others use AI to interpret or generate language. Both need clear scope and a relationship to real information and working systems. A plausible sentence is not evidence that a task has been completed.
Microsoft's HAX Design Library offers useful principles for communicating capability, supporting correction, handling uncertainty, and retaining user control. In our work, those concerns become specific questions: What can this assistant actually access? What can it change? How will a person know the difference?
Understanding is not permission
“Can you move my booking?” may begin an investigation. It should not automatically authorize every change the system could make.
We distinguish finding information, proposing an option, preparing an action, requesting approval, and confirming an outcome. The appropriate checkpoints depend on the consequences of getting it wrong.
A simple acknowledgment can keep a conversation moving. A consequential change may need an explicit confirmation of what will happen. Google's established conversation-design guidance on confirmations makes this distinction and emphasizes allowing corrections. We apply the interaction principle to the actual product rather than copying a fixed script.
The content and controls should help someone understand what they are agreeing to. A bright button is not enough if the meaning of the action is hidden in a long reply.
This is where Human-Centered AI becomes practical. The system's ability to respond or act does not replace the person's agency.
Shaping a conversation about changing a booking
For a studio booking assistant, we work through the language and the service rules together. A request to move an existing session to Friday afternoon is a useful place to examine ambiguity, authority and confirmation.
The experience would first need appropriate account access, reliable booking information, and a clear service policy. It should not expose someone's booking details merely because a visitor knows their name.
With that foundation, we can shape an exchange along these lines:
Customer: Can we move our session to Friday afternoon?
Assistant: I can check options for your booking. I won't change it until you confirm. Which Friday do you mean?
Once the date is clear, the assistant could present available times, the studio involved, the session length, and any relevant change in price or conditions. Those details would have to come from the actual booking system and business rules—not be invented to keep the dialogue flowing.
The customer might then correct an assumption: “We still need three hours.” That contribution should help refine the options rather than force an entirely new conversation.
| Moment | What we need to design |
|---|---|
| A request is ambiguous | A focused question that resolves the uncertainty without asking for everything again |
| Alternatives are available | A useful comparison, potentially combining dialogue with visual choices |
| The customer selects an option | A clear account of the proposed change, including material consequences |
| The customer authorizes it | An action boundary tied to the specific change they approved |
| The system responds | An accurate distinction between processing, confirmed success, failure, and an unknown outcome |
| The request needs a person | An honest route to support with appropriate context carried forward |
If a change fails, the conversation should explain what is known about the original booking. If the outcome cannot be confirmed, it should not guess that everything is fine—or repeat the action blindly.
The complete design therefore includes more than the successful exchange. It includes changes of mind, missing information, unavailable options, interruptions, and the limits of the service.
We review the exchange with the studio team, then carry the agreed behavior into prototyping and implementation. The conversation needs to reflect the booking system's actual state, not merely sound reassuring.
Let tone respond to the person
Language carries the brand into moments when people may be curious, hurried, uncertain, or frustrated.
We want the experience to feel attentive without using warmth to conceal its limitations. It can acknowledge an inconvenience, explain the next useful step, and communicate clearly without claiming feelings or a personal relationship it does not have.
Being conversational does not mean being chatty. A person trying to resolve a problem should not have to read a performance of helpfulness before receiving help.
Content Design helps us decide what someone needs to understand, feel, and act on at each moment. Brand voice gives the experience recognizable character; context tells us when to soften, simplify, or get straight to the point.
We also make clear when someone is interacting with automation and when a person has joined. The transition should not depend on noticing a subtle change in writing style.
Voice changes the conditions
Voice Interface Design is one application of Conversational UX.
Speaking introduces questions about listening, turn-taking, interruption, pronunciation, pacing, and how much information someone can comfortably hold at once. The setting matters: what is useful in a private room may be awkward or inappropriate in a shared space.
We can design concise spoken prompts, correction paths, meaningful confirmation, and transitions between sound and screen. We should also consider people who cannot or do not want to speak or listen in that moment. Voice is a possibility, not a universal requirement for access.
The same principle applies across modalities: do not make people adapt to the technology when a more appropriate way to participate can be designed.
A handoff is part of the experience
“Talk to a person” should lead somewhere real.
We work with the business to understand when human support is available, what it can resolve, and what information should accompany the request. A queue, callback, or asynchronous response needs an honest explanation. We should not promise an immediate human conversation if the service cannot provide one.
Relevant context can help prevent someone from repeating their entire problem, but that does not mean transferring every part of a conversation without considering privacy and necessity. People should understand what is being shared and why.
Service Blueprinting helps connect the visible exchange to the employees, policies, information, and systems behind it. A conversational interface cannot repair an unsupported business promise simply by phrasing it more elegantly.
Make the behavior discussable before building it
Our design work can include task and conversation maps, sample exchanges, interface concepts, tone guidance, response patterns, action boundaries, recovery paths, and a prototype suited to the questions being explored.
Those artifacts help clients and technical collaborators examine the same experience. A design-tool prototype can make a proposed conversation tangible without pretending that AI, integrations, or business actions already work behind it.
Abstraction can lead or co-create the design with internal teams and specialist developers or AI partners. We make implementation responsibilities explicit and carry intent through Design Handoff.
Testing should examine how people express needs, understand responses, make corrections, and complete or leave tasks. Where end-user research requires specialist delivery, we can help plan and interpret that work with appropriate partners. Technical evaluation also has its own role; a pleasant demonstration is not proof of reliable behavior across real conditions.
Keep learning from the exchange
Conversational UX belongs within Design Thinking:
Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover.
After release, appropriate feedback and review can reveal misunderstood requests, unhelpful answers, difficult transitions, and opportunities to change the underlying service. We define what information is useful to collect and how it can be handled responsibly; we do not assume every conversation should be retained indefinitely.
The question is not simply whether the assistant responded. It is whether the person understood what was happening and made useful progress with an appropriate degree of control.
Abstraction can design a conversational experience as a focused engagement or as part of a wider product, service, or brand relationship.
Bring us what people are trying to ask for. We can help shape a better way to respond.