This is part 2 of a series sharing our approach on how to design a conversational experience. Part 1 looked at the theory behind some of our best practices of Designing Conversational Interactions, and it was a deep dive into planning the structure of a conversational design flow chart.
Here we take an even closer look at a specific scenario in conversational design which can take designers by surprise: a sudden explosion of complexity when making a seemingly small addition to an otherwise simple flow.
The situation occurs when designing a use case which gathers multiple pieces of data (parameters) from the user. For a traditional user interface or a chatbot using just buttons, prompts and focused text replies, a flowchart shows a simple path from A to B to C. By locking users into a specific sequence of operations, the flow is straightforward.
But one of the great strengths of Conversational AI is giving users the freedom to interact in their own words, free of such constraints. It’s the difference between only letting them say “I’d like to book an appointment,” versus also supporting “I’d like to book an appointment this Friday at the Main Street location”. When adding this support for natural language understanding (NLU) by updating the design flow to show how it accepts parameters from the user in any sequence and combination, suddenly the diagram can explode into an overwhelming tangle of conditions and branches.
As a case study, let’s look at a bot being developed for a client in the banking sector. Suppose that after an initial welcome message and perhaps authenticating the user, the user selected an appointment-booking feature which requires (for now) 2 pieces of information, “Topic” and “Location”. As shown in the diagram, it’s easy to plan an orderly back-and-forth between the user and system to capture the parameters TOPIC and LOCATION, and the flow concludes with successfully booking the appointment.
But remember, the bank wants to let users interact at their own pace, in whatever way is most comfortable for them – and this is exactly why they want a conversational solution!
Again suppose back at the welcome message instead of saying “I’d like to book an appointment,” the user had said “I’d like to book an appointment at the Main Street location to talk about a loan”. A rudimentary, inflexible chatbot would respond by missing that information and saying something like “Ok, let’s book an appointment. What would you like to talk with us about?”
To avoid frustrating the user in this manner, the system needs to be ready to capture any parameter at any step of the journey. For example, it needs to handle all these variations provided by the user:
“Make me an appointment.”
“Make me an appointment at the Main Street branch.”
“Make me an appointment to talk about a loan.”
“Make me an appointment at the Main Street branch to talk about a loan.”
But how do we lay out a flow when we don’t know what information the user will have provided at each step, and avoid asking redundant questions? Here’s an addition to the flowchart above which seems straightforward:
But what happens if the system needs to capture a 3rd parameter, say letting the user choose the Date of the appointment? Watch what happens to the number of paths just leaving the first block:
And each one of those paths leads to an increasingly tangled web of states and branches – here is a portion of the resulting diagram:
If we dare add a 4th or 5th parameter – say the Time of the appointment or a preferred Advisor with whom to meet – then the complexity explodes out to 16 or 32 paths leaving just the first block alone. The quantity of paths and states throughout the diagram just grows too large for the reader to want to navigate and make sense of, let alone for anyone to design in the flowchart editor!
It may not seem like much was added, but the problem is that for each parameter added to a use case, when showing the flow in the manner above (which works fine for 1 or 2 parameters), the number of permutations in how the user can provide them free-form grows exponentially.
The root of this phenomenon is in the way that conversational systems offer a uniquely powerful and human-like experience by giving users the freedom to provide an arbitrary number of parameters at unpredictable times. Sometimes the user gives nothing and has to be prompted each step of the way, and sometimes they provide multiple parameters before the system even knows which use case they are interested in!
So what can we do?
The solution lies in a more methodical structure for handling many parameters, a design pattern we call a parameter chain, shown at right.
Notice the “chain” of repeated structures – each step in the chain asks, “do we already have parameter X? If yes then go to the next; if not, go ask the user for it and then continue to the next.”
Why does this work? It eliminates the approach of trying to show each possible combination of inputs we could receive from the user in each block, and instead distributes the handling of that throughout the chain.
This allows for a flow which only grows by 1 new step in the chain each time a parameter is added to the use case, instead of adding an exponential number of permutations.
If you’ve ever been working on a conversational design flow chart and suddenly felt overwhelmed by an increase in the number of paths and branches, a parameter chain might be the right technique to bring it back under control.
Have you found any conversation design patterns which solve recurring problems in conversational design? If yes, please share below!
