Seven Chatbot Design Considerations For The African Context
And Why It Will Be Applicable In Most Countries Where Users’ First Language Is Vernacular
Introduction
In most parts of the world, the first language or home language of people are not one of the major languages. The problem here is is that the big cloud Conversational AI providers only make provision for the major languages.
This impediment in available languages is understandable from a commercial perspective.
However, it leads to the scenario where chatbots or conversational agents are rolled out in a language which is widely spoken a particular target region. But, is not the first or home language of users.
Hence for the Southern African region, most-all chatbots are only available in the English language for obvious reasons.
The challenge lies in this…
Users interact with a conversational agent, not using their home or first language; but a second or even third language. Being English. This use of a non-first-and-familiar language leads to a few design elements to keep in mind. These considerations include what to expect from the user, and conversation design considerations from a dialog perspective.
In this article you will read about seven design principles to keep in mind when designing and developing conversational experiences for users, not interacting in their first language.
You need not be stuck with the languages presented in major cloud environments. Below are two links which are helpful in developing your own language model for a specific vernacular or localized language.
A good approach is to, at first, not focus on the dialog and conversational portion.
Start by creating a Natural Language Understanding API which you can use to detect intents and entities.
Create a few intents and Entities, add training examples to the intents. About 20 examples per intent will do.
Train your model and test it via the API interface. This will be a good indication of how accurate your NLU API is performing with the data you present. The upside is that RASA is open source and free to use; hence there is no licensing impediments in getting going.
1. Preferred Mediums
For a large corporate conversational agent in South Africa, about 70% of all conversations are conducted via the SMS/Text channel. This is followed by WhatsApp, mobile application and lastly via the web.
Not having access to a medium with rich conversational components and affordances have a significant impact on conversation design.
Older Phones
The reason for this phenomenon is the proliferation of older, simple handsets. Users are forced into the SMS medium with only 160 characters at their disposal.
In instances where multiple messages are sent by the chatbot, the messages can also loose sync. Hence the messages do not arrive in sequence and causes confusion with the user.
Lack of Conversational Components
Mediums like Facebook Messenger and web interfaces can offer benefits when in comes to conversational aids; or conversational components. Having access to decision buttons, marques, web views etc. can help facilitate the conversation. With SMS this is lacking and a natural conversational approach is required.
Affordances
No design affordances are available, and focus needs to be placed on wording, user input confirmation etc. The positive here is that the lack of affordances can make the migration to a voice interface easier. Seeing voice is ephemeral, has shorter dialogs and is confirmation dependent.
Delivery & Message Synchronization
As alluded to earlier, keeping multiple messages from the chatbot synchronized can be a challenge. In essence there is virtually no control over it. Delivery of messages is also network dependent.
2. Design & Desire
Once when I was involved in launching a chatbot for a pizza franchise, we discovered two intents which were not catered for. These were job seekers and requests for sponsorships. South Africa has an unemployment rate of 32%, and a youth unemployment rate of 58%.
These figures are the official numbers; but in reality it is much-much higher.
Hence this regional problem transpired in the conversations and it had to be catered for.
A case where the user’s desired path is not aligned with the design path.
The design is aligned with the organizations objectives and what is deemed important. The conversation the users want to have is often in stark contrast.
Looking at the Venn Diagram above, it is clear that these two circles need to aligned. The overlap needs to increase over time rather than decrease in size.
3. Conversation Driven Development
Migrating a whole conversational experience in terms what content is covered can be an arduous task and most frameworks do not make provision for this continuous migration.
Another design consideration is the development cycle of chatbots compared to mobile apps. There are perceived impediments to to mobile apps which seems to not be the case with chatbots.
As the graph above shows, this is perceived; with mobile apps the efforts is primarily upfront while with chatbots the real work starts after launch.
Rasa has coined the phrase Conversation-Driven Development(CDD) and in conjunction the Rasa-X console; visible below.
The idea and principles of CDD is universal to chatbots and any environment can implement the concept. However…
Rasa-X is really the enabler for the idea of CDD where the augmenting and migrating of conversations in terms of topics covered can be performed. Not as a specialized development exercise, but almost as an administrative task.
4. Compound Intents & Entities
When presented with a menu of very applicable options, less than 5% of users opt to selected one of the menus. From the total amount of users, 95% opt to rather express their desire in words using a sentence or two.
Virtually all users opt to not structure their input and merely type their request in natural language. Obviously this is what a conversational agent is designed for.
Also, I suspect users conversing in a second or third language are having trouble to categorize their request according to the menu items available.
This scenario is exacerbated when technology and specific products and services are involved. Hence users would rather defer the structuring of the input to the chatbot.
With the user describing their problem or query, compound intents and entities are introduced, which need to be handled by the chatbot.
5. Disambiguation
When users enter longer sentences, or describe their problem as a non native English speaker, ambiguity is introduced in many instances.
It needs to be noted that there is ambiguity which is easy for humans to disambiguate, but very hard for machines. The first example above being a case in point.
Then, there is legitimate ambiguity which is impossible to interpret (the subsequent binocular example). Here disambiguation needs to be employed.
The chat interface above left demonstrates how an ambiguous entry can be disambiguated with a short menu.
6. Domain & Irrelevance
Conversational Agents will virtually always be domain specific. All user entries will either fall within the domain or outside.
The domain of implementation needs to communicated to the user, rather than try and match the closest intent.
Some chatbot environments give the option to mark user input during training as irrelevant. This does not mean that the domain must not be adjusted as the users’ desire is detected and the domain needs to migrate to cover new intents.
7. Digression
Digression is the opposite of fallback proliferation. Digression allows users to interrupt themselves and momentarily or permanently (for the current conversation) digress to a different intent.
A typical example can be seen here, where the user makes a reservation.
However, prior to confirming the time of the reservation, the user needs to know the closure time and also the location. As these two factors plays a role on confirming the time.
Most chatbots will default to the question, what time? regardless of the question or entry is of the user.
The scenario should allow the user to satisfy a question or two, but then return to complete to form entry.
In cases where the user persist in digressing, the chatbot should ask the user if they want to abandon the completion of the form.
When an user wants to digress from a certain point, the user’s dialog can be utilized to determine what menus can be presented in the process.
Conclusion
Achieving these seven steps in a practical and efficient manner demands a chatbot framework which allows for the the following three elements.
Conversation-Driven Development (CDD) where continuous development and improvement is based on real-world user input on a daily basis.
Surface Complexity in a Simplified Fashion. Hence having a simplified user and development interface. Shielding developers and administrators from complexity and simplifying tasks.
Pipeline Independence. As new components and language tools are available, being able to implement these are important.
Too many cloud solutions lend no insight into what is under the hood. Configuration, re-configuration & training are important for continuous improvement.
Read More Here…
