In this series Jeroen Thissen (Creative Director) and Erik Rave (Technology Director) from Creative Digital Agency CODE D’AZUR look back on three years of developing voice applications for the likes of KLM Royal Dutch Airlines and LeasePlan. Each episode will highlight a new learning.
We have arrived at our fourth out of six lessons about developing for voice. This is an important one, which also reflects on the previous learning about your architecture. Why is it important to put ‘intent’ over ‘context’?
‘Context’ is the structure of the conversation. At CODE D’AZUR we start the design process of each voice application with a Conversation Tree (much like a ‘choose your own adventure game’) in which we design the expected conversation a user will have with our service. A ‘happy flow’ of our dialogue. We quickly learned the obvious:
People don’t follow trees.
When people talk to a chatbot they will curate their answer. You ask: ‘When would you like to depart?’, people think for a bit and answer: ‘next week Tuesday’. Alternatively, when using a voice service, people speak before they think. You ask: ‘When would you like to depart?’, people answer: ‘Uuuuhm next week Wednesday 18. Oh no 17. Tuesday that is, please’. They will use different wording every time – even when saying the same thing. They will say random things at random moments, move back to things they mentioned before or jump ahead to parts of the information retrieval process you didn’t expect. People are people. And so your conversation can’t be linear. It’s not a webform.
That’s why it’s important to put intent over context. In ‘Intent Based Conversational Design’ we focus on what the user wants to get out of the service we provide, first. Then we make sure the conversation is flexible enough to cater to the intent of the user at any moment. The result? We can jump backwards and forwards and out of the conversation at any time and we still know what’s going on and how to proceed.
By default, DialogFlow is set up to keep all intents open in any part of the conversation, but it can be tempting to limit intents per interaction to make sure the user walks through the conversation in a linear fashion, and to save back end development time. This is where you start to make choices based on your expected behavior of the user. In practice, you’ll see that it is very hard to predict behavior and, UX wise, it is much smarter to keep all options open for the user and have your system figure out where we are in the conversation.
This is a lot more work though. DialogFlow does not allow for any exchange of data between these intents. It lacks the functionality to make sure that one part of the conversation still knows what has been said in other parts of the conversation we built ourselves. For now, at least. This is another good reason not to rely fully on DialogFlow for the design of your action.