Conversational context allows us to interpret what has been said to us based on how new dialogs link with previous dialogs and environmental factors. In practice, if you ask someone a question and they say "yes," we humans know they are saying yes in response to our question because we in our brains contextually linked their response to our prompt. With computers, however, this isn't true. Computers are programmed around a system of inputs and outputs – meaning every new input isn't automatically associated with previous inputs unless you program it to do so.
Without context, when responding "yes" to a computer-generated question, the computer may not understand what you mean. "Yes" may be the correct answer – however, without a set context, the computer may not understand which question you are answering and treat your response as a new conversation.
Humans are naturally attuned to context – we're born with the ability to manage and understand it. This innate understanding, however, doesn't translate well to designing conversations for computers. Although we're designing with the end-user and humans in mind, it's essential not to forget the computers that process those designs, and how they understand and process information.
At Voiceflow, we think a lot about giving designers better tools to create and manage context. We believe it's one of the most critical factors in creating engaging, natural conversations. Context is often bucketed as one term that can describe the theme, but it is hard to communicate concrete applications in practice.
When designing Voiceflow, we've found ourselves creating new terms to segment different approaches to context that makes it easier for our team to communicate our design choices. These 6 context terms are what we'll be explaining today, and how we enable their design in Voiceflow.
Dialog context is the most common example of context. Dialog context is the memory of a conversation flow as it progresses through its dialog turns.
For example: if you are ordering a coffee and the barista asks "do you want sugar," and you say "yes," the barista knows your version of "yes" in the context of their question.
This is the most common context used, and it allows for the creation of multi-turn dialogs — without it, every dialog turn would be a new conversation.
In Voiceflow, dialog context is handled by "lines," which can be used to connect two dialog turns. You can create the same conversation with or without dialog context either by using an open-intent step, or a choice-intent step.
Context switching is the act of switching the context of a conversation, and for most people, you can think of it like changing the topic.
For example: let's say you are ordering a coffee through a conversation with a barista, you are now in the "ordering coffee" context. Suddenly, you ask the barista what time the coffee shop closes — which they then answer. So, what happens now?
You switched the context of the conversation from ordering a coffee to asking about store hours. A human implicitly infers that even though you switched the context of the conversation to talking about store hours, you still want to order a coffee as your intention of asking about store hours has now been fulfilled. In this scenario, the barista would "switch" back to the original context of ordering a coffee.
In Voiceflow, you can context-switch using "Commands," which are found in the Home block. Commands allow you to create sub-conversations that perform a task then bring the user back to where they were in their original context once the command is complete. An example is our "store hours" command which is invoked if the user asks about our hours. In practice, this allows the user to break from ordering a coffee to ask about store hours, complete that instance and return to the original question.
Using the example above, let's say instead of asking about store hours, you say you're experiencing a heart attack — now the barista knows your intention is to get medical assistance, and you no longer care about ordering a coffee.
In this case, you do not switch back to your original context, and the primary or prioritized context of the conversation changes. The barista is now focused on getting you medical assistance, that becomes the conversation outcome, and thus becomes the prime context of the conversation.
In Voiceflow, prime contexts are designed through continuous multi-turn dialog paths the user is following. Using open-intents, the user can switch their prime context and be on a different conversation path.
Sticking with our coffee example, let's say you walk into the coffee shop and say, "I need help."
In this case, the barista would ask to clarify what you need 'help with' and establish context for the conversation. Because you haven't entered the conversation with a specific context, 'help' could refer to many things: from finding the washroom to ordering a coffee.
Later, you say, "I need help" as you are paying for your coffee. In this case, even though you said the exact same thing, "I need help," which would trigger a "help" intent, the barista knows you need help paying and will say an appropriate response.
These are contextualized intents, and they are incredibly crucial to designing a great conversation, yet they are tough to design for as they add another dimension to every response.
How Voiceflow handles contextual intents is through a "stack" model where each "flow" can create a layer of context within the stack.
Voiceflow's context "stack" model is such a robust system that VF's CTO did a whole video explaining how it works in detail:
To create contextualized intents in Voiceflow, you can create two separate flows: a "home" flow and one for "order coffee." Within each flow, you can create a command with the "Help" intent. This will allow for a contextualized response using the same "Help" intent depending on which flow, or "context layer," the user is on.
In the example above, we can see that we are on the Root flow, which has its own "Help" intent. Because this is the root flow, our Help intent is generalized and allows the user to get medical assistance when they say "Help" as we are imagining they just walked into our store and need help.
In the top right, you can see that if the user activates the "Order coffee" intent, they are brought into the "Order coffee" subflow, which you can find a picture of below.
In the picture above, the "Order coffee" flow shows that this flow has its own version of the "Help" intent that is contextualized to ordering a coffee. In this case, because the user is ordering a coffee, we offer them help by showing them our menu.
Contextual intents can get as personalized as you, the designer, would like, and you can infinitely stack flows to create additional layers of context. In the example above, you could add a checkout subflow within the order coffee flow with a contextualized help intent to help the user with their payment method.
If Voiceflow does not have a contextualized intent for the user's current flow, the system will "look" at the next layer up. Meaning, if there is no help intent on the current flow, Voiceflow will look at the next layer up. This creates a contextual "waterfall" system that allows you to create incredibly engaging and personalized conversations.
When ordering your coffee, the barista introduces themselves by name and asks for our order. Feeling the need to reciprocate, we introduce ourselves by name as well and say our order. At checkout, the barista asks our name for the order. To a human, the barista forgetting your name may come across as rude or awkward — after all, you stated your name at the beginning of the conversation.
To an assistant, however, this is an example of incorrectly managing an overfilled slot context. Slots are the selected pieces of information we store from a conversation, and often we design conversations to only collect what is immediately relevant to our current intent. In this example, the user gave their name, but we were only looking for their order slots, so later in the conversation, when we needed their name, the assistant didn't have it.
An overfilled slot context is hard to design because it requires real-world testing to see where there are frequent opportunities for overfilled slots. Once we find an opportunity, however, capturing information and using it later is a delightful experience sure to wow any user with our assistant's contextual intelligence.
To use an overfilled slot context in Voiceflow, you can use dialog management and label potential overfilled slots as "not required." When you do this, the assistant will capture the slot if it's said, however, it's not required to move the conversation forward. This allows the assistant to capture information and then use it later in the conversation without explicitly asking.
Continuing with our coffee example, let's consider conversation factors that aren't influenced by what we say, but by the world around us. An example here would be if you were to walk into our fictitious coffee shop at closing time.
Even though all other conversation contexts are the same, the dialog will be different simply because of environmental factors, in this case, the store is closed. Now, our dialog will likely be very abrupt "sorry we're closed," or potentially a rushed less fluid outcome-driven dialog if the barista is friendly enough to still try and serve you.
These environmental factors take into account a non-conversation driven context that could range from the weather to time of day, or even if it's the user's birthday or returning visitors. Even the best conversation design in the world would feel like a horrible experience if it had the same experience before.
Environmental factors need to be taken into account to create more natural conversations. Over time, designs may get larger and larger simply to deal with an increasing number of environmental factors that may change the conversation — and that's just good design.
In Voiceflow, you can create an environmental context using the condition step to branch the conversation based on conditional statements (IF statements, like excel). In the below example, we are branching the conversation at the start after checking to see if the store is open based on the store hours variable (which we could get from an API). If the store is open, we proceed as usual, and if it's closed, we give them an appropriate "we're closed" message. This same logic could be applied to bad weather, giving the user variant messages based on the number of sessions they've had, or even a birthday message.
Using environmental context, you can personalize your conversations for the user based on the world around them – as a human counterpart would.
Designing with various contexts is one of the most essential things Cx Designers can do to create great natural-feeling conversations. It's not an easy task and highlights just one layer of depth to conversation design.
We're building Voiceflow with context in mind to ensure Conversation Designers have the tools they need to create exceptional, natural conversations. Voiceflow is the only visual tool that allows for the use of context. We'll continue to build on our context model to further empower the creation of amazing, natural conversations.
I'd love your feedback or thoughts, reach out to me: firstname.lastname@example.org