Your Chatbot Conversations Must Allow For Digression
Don’t Trap Users In Constrained Dialog Paths
Introduction
Digression is a common and natural element of human conversations. The speaker, introduces a topic, subsequently the speaker can introduce a story that seems to be unrelated. And then return to the original topic.
Digression can also be explained in the following way… a user is in the middle of a dialog, also referred to as a customer journey, topic or user story…
…this journey is designed to achieve a certain goal, but the user decides to abruptly switch the topic or intent to initiate a dialog flow that is designed to address a different goal.
Hence the user wants to jump midstream from one journey or story to another. In general chatbots are not designed to accommodate this, and often, once a user has committed to a journey or topic, they have to see it through.
Normally the dialog does not support this ability for a user to change subjects or intents midstream.
Often an attempt to digress by the user ends in an “I am sorry” from the chatbot and breaks the current journey.
Hence the chatbot framework you are using, should allow for this; users popping out and back into a conversational topic.
For example, the user might be ordering a new phone, but switches topics to ask about tablets. Your dialog can answer the question about tablets, and then bring the user back to where they exited the customer journey for ordering a phone.
This approach gives your user a true unstructured conversation experience, being able to switch from one topic to another. This is analogous to a human conversation. Hence the user can change topics, following a dialog path or journey about the unrelated topic to its end, and then return to where they were before.
Again, this simulates a true, natural human to human conversation.
But First…
While building a chatbot dialog, also referred to as a topic or journey, you need to decide where in your conversational tree you will allow digression.
And where a return can be made back into the calling dialog.
Every root node in your dialog should be configured to allow digressions to target them by default. Child nodes are often not the target of a digression.
Nodes with slots are usually configured to prevent digressions away from it.
The ideal is for most nodes to be configured to allow digressions away, and targeted nodes to receive digression.
The final step is to specify what should happen after the node is processed.
When the dialog is configured to jump directly to another node in the journey, it is often to ensure that a specific sequence is followed.
And when the node is configured to skip user input, it is equivalent to forcing the dialog to process the first child node after the current node in succession.
To prevent breaking existing dialog flow logic, digressions should not be allowed in all cases. Before you can enable digressions away from this node, you must change what is specified in the final step section.
Design Considerations For Closing Nodes
The last thing you would want, is an instance where the user gets caught in a leg of the conversation. So most legs have a default message if a user does not exercise any input or if there is a “no match”. Users cannot digress away from dialog flows that use this approach. This is often referred to as fallback proliferation.
Evaluate branches that use this approach, and determine whether it would be better to allow digressions away from the branch. If the user’s input does not match anything you anticipated, it might find a match against an entirely different dialog flow in your tree. Rather than responding with a generic message, you can effectively put the rest of the dialog to work to try to address the user’s input.
Many dialogs are designed to ask a standard closing question, like; Did this resolve your issue? So, if you configure all of your final branch nodes to jump to a common closing node, digressions cannot occur. Consider tracking user satisfaction through metrics or some other means.
Digression Control
Ideally, you do not define the start and end of a digression, the user is in complete control of digression at run time. You only specify how each node should or should not participate in a user-led digression. For each node, you should be able to configure whether:
- digression is possible from and to that dialog node
- should digression be forced to return, like a sub-dialog, or can the conversation merely continue.
Why Do Chatbot Development Frameworks Not Scale Well?
One characteristic of some chatbot development frameworks, like Cognigy, is that there are multiple ways of implementing a conversational principle.
Initially this might seem like overhead, but the principle comes into its own when it comes to scaling.
Many Conversational AI development frameworks do not scale well due to primarily two reasons…
The first being, the absence of design & development affordances. This is the case with no-code and low-code environments. There are instances where a particular design principle cannot be implemented due to the absence of design/development canvas elements.
Obviously pro-code environments do not suffer from this ailment, but then there are other challenges involved with pro-code.
When the no-code/low-code environment does not have the affordance for a certain implementation, existing features need to be clobbered together and over-leveraged. And via improvisation the desired user experience is achieved. However, this is where the impediments surface with scaling and growing the conversational experience over time.
The second scenario is having a singe way of doing things for each design principle, and this is the most common approach. Having one design/development affordance per perceived conversation challenge and scenario is fair.
But having more that one possible affordance or option to approach a design challenges give developers/designers a chance to approach challenges with specific configurations of functionality.
For instances, if 10 design challenges are addressed with 3 options or approaches each, the number ways of solving grows exponentially. And this contributes to the scalability of the environment.
Conversational design requires or challenges can include:
- Disambiguation
- Digression
- Detecting Irrelevance
- Compound Intents & Entities
- Mixed Modality & Conversational Components
- Variation & small talk
- Named Entities
- etc.
Conclusion
The easy approach is to structure the conversation very firmly from the chatbot’s perspective. And funnel the user in and out of the conversational interface, this might even present very favorably in reporting. But the user experience is appalling.
Overly structuring the conversation breaks the beauty of a conversational interface. Unstructured conversational interfaces is hard to craft but makes for an exceptional user experience.
Users are so use to having to structure their input, that they want to enjoy and exercise the freedom of unstructured input; speech or text, which can lead to disappointment if the expectation of freedom is not met.
