Designing a Conversational flow
What is a good fit for conversations?
- A good conversation saves the user more time and effort than a screen-based UI.
- The conversation is intuitive
- Interaction is brief with minimal back and forth dialog
Identify the users
- Who are your users?
- What are their needs?
- How do they go about doing these taks today?
- What words and phrases do they use to carry out these tasks?
- What circumstances trigger these tasks?
Identify technical capabilities
Identify what the system can do and what isnt possible in timeline and resources What are the capabilities and limitations of the various systems that your Actions will rely on? What’s the format and quality of any data you’ll be using? Often, some reformatting needs to happen before some types of content can be appropriately rendered
Identify your key use cases
Considering technical limitations, level of effort, and timeline, what use cases can you support? Assign priorities accordingly.
- Aim for impact.
Put your effort where it will have the most impact. This may be scenarios that affect the largest number of users. It could be highly visible use cases/market differentiators. Or it may be a feature that makes a big difference for a handful of loyal power users.
Identify journeys and critical user journeys
Describe each of the relevant moments in the journey.
Create a persona
A persona is a design tool that helps you write conversations. Before you can write a dialog, you have to have a clear picture of who is communicating. A good persona evokes a distinct tone and personality, and it’s simple enough to keep top-of-mind when writing dialog. It should be easy to answer the question: “What would this persona say or do in this situation?”.
Users will project a persona onto your Action whether you plan for one or not. So it’s in your best interest to purposefully design the experience you want users to perceive, instead of leaving it up to chance.
⚠️ The goal of creating a persona is not to trick the user into thinking they’re talking to a human being, but simply to leverage the communication system users learned first and know best: conversation. ⚠️
A user persona is a specific but brief description of an individual user. Think about the types of people you expect to use your Actions, and create a few user personas to represent them. These user personas will help you avoid designing only for yourself and your goals.
|Here is an example of a persona for a travel bot|
|Name||Shania Gordon - Student|
|Key adjectives|| Practical |
|Characters who embody these adjectives|| Regular Online Shopper |
|Short description||A travel enthusiast. Loves new stuff and is willing to try out new things. Trusts websites and web contents. Takes user reviews and ratings very seriously. Often provides good user ratings and long descriptive reviews.|
|Key adjectives|| Resilient |
|Characters who embody these adjectives|| Banker |
|Short description||Tom likes to bring high value in everything he does. He weighs each option carefully before making a decision. He travels less often and wants to make the most of every trip. He wants to be in control of all his plans, and is always scouting for options to optimise his plans further.|
Write sample dialogs
Sample dialogs will give you a quick, low-fidelity sense of the “sound-and-feel” of the interaction you’re designing. They convey the flow that the user will actually experience, without the technical distractions of code notation, complex flow diagrams, recognition-grammar issues, etc.
By writing sample dialogs, you can informally experiment with and evaluate different design strategies, such as how to promote the discoverability of new features or how to confirm a user’s request (for example: should you use an implicit confirmation, an explicit confirmation, or no confirmation at all?).
Chart out sample dialogs
Identify key conversations. Talk it out in a natural manner. Identify main key dialogs
Follow Design principles for a great conversation.
Follow these steps to write sample dialogs for your feature:
- Step 1 :
Focus on one user persona and one key use case.
- Step 2 :
Find a partner and role-play the conversation, with one person pretending they’re the user and the other pretending they’re the system persona. Record the conversation. If you don’t have a partner, you’ll have to switch between playing both roles.
- Step 3 :
Transcribe the conversation. This is the first draft of your sample dialog.
- Step 4 : Repeat steps 1-3 with different user personas and key use cases
|Speaker||User utterance / Spoken prompt||Notes|
|Bot||Hi Cherry, I am TravelBot, your personal travel assistant 👋 I’m great at finding you travel packages so you can be as well travelled as the best of us!|
Travel made fun!!
|Bot||Is there anything specific I can help you with ?|
|Bot||You can choose among these options. |
Trips Experiences FAQ
|Bot||Planning a trip is super exciting, let’s jump straight in!|
Did you have a specfic destination in mind, maybe Europe? 🌎
|Bot||Great choice! How did you want to experience Sydney?|
River Cruise Land Journey Ocean Cruise Rail Journey
Create a diagram of the conversation flow
Identify dialog groups and flow between the dialog groups. Each dialog flow serves a common purpose. It can have multiple entry points or exit points. Some dialog flows can be re-used within more than one dialog flows.
Here are some examples
Test and iterate
User research can be helpful at any time during the design process. There’s no substitute for getting feedback from actual users to find out what’s working and what isn’t. The earlier you do this, the better.
- Work on a mock prototype
- Talk it out
- Take notes and record any issues
- Ask for feedback
What to expect in this experiment
- Natural conversation
Pay attention to the way users naturally ask for things. Do they feel like they can only speak in short keyword-like phrases, or do they sound more conversational? Do they sound hesitant or confident when speaking to your persona? Does the flow make users feel like they can only provide one piece of information at a time, or does it encourage them to provide multiple details in one sentence?
- User confusion
Look for places where users look confused or are unsure of what to say or do. Examine the previous prompts to see where you could make some clarifications. Was the call to action clear?
- Unexpected utterances
Users might say something you didn’t expect. Take note of it and add handling for it in your design.
- Signs of frustration or impatience
This is typically a sign that the interaction is too long-winded. Review your prompts to see if you can be more concise. Are there details that can be omitted? Observe who’s speaking the most Do users seem to be in control of the conversation? If not, how can you change that?
Design for most cases
Dont overdesign - Use the 80/20 rule, or Pareto Principle, to avoid overdesigning.
- Capturing information from the user, Break it up into small pieces of information to be captured
- Say little at a time. Keep messages short and relevant
- Capture in Escalating detail
- Progressive disclosure
- Confirmation prompts
- Selective reprompts
- Timeouts and no response prompts
Even with robust intents, there is still room for error. Users may go off script by remaining silent (a No Input error) or saying something unexpected (a No Match error). Use error prompts to gently steer users back towards successful paths or reset their expectations about what is and isn’t possible.
Good error handling is context-specific, so prompts for No Input and No Match errors must be designed for every turn in the dialog.
- Dont explain a command, make it intuitive
- Keep dialog on track
- Summing up
- Personalization should be relevant and informative
Voice 1. Anticipate verbal co-operation 2. Reduce auditory clutter–!