In the last article (read: Decoding Chat bot use cases), we looked at various ways chat bots can be leveraged. Some of the pitfalls that me and my team came across and maneuvered (some of them the hard way) while building one can be used as best practices when taking the chat bot building journey.
1. Chat bots can be created in minutes
There are numerous frameworks that claim to create a chat bot in minutes, maybe you can create something quick and dirty in that period but the reality however is far from that – It takes time and effort to create a good chat bot.
Human interaction is a complex affair; and like it takes time for a child to understand the nuances of speech and conversation, it takes time to create bots that mimic that art (certainly not that much though).
A chat bot should be built while deliberating how the conversation would happen, the various routes it could take and how to bring a conversation back to the topic in question if it gets sidetracked. After going through this process of ‘design thinking’ we can expect a bot to provide a good user experience (UX).
2. Keeping the chat open ended
Humans, by nature, tend to experiment when interacting with technology and conversations can quickly digress to figuring out the meaning of life and the answer as number 42 after a period of 7.5 million years can be somewhat of a downer to most people.
It’ll be so nice to have chat bots that understand and take care of everything like the ones in SciFi movies that control the mother ship while the crew is in cryogenic sleep, but it’ll take Artificial Intelligence (AI) and Natural Language Processing (NLP) a while to get there. In the meantime, we need to keep the scope of the chat bot limited and not expect it to do everything under the Sun (or the Galaxy). Care should be taken to understand the requirements and the bot should be designed such that the user does not stray away from the stated purpose.
One important thing to consider here is that keeping the conversation closed ended does not always mean that all the questions or statements uttered by the bot need to be that way – it would not make a very good conversation. The conversation can be closed ended in several dialog turns. A dialog turn is a unit of a conversation when the user responds to a bot utterance. The bot should be able to steer the conversation from an open to a closed ended one in an optimal number of turns, usually around four.
Keeping a human in the loop when it’s not possible to keep the conversation closed ended is also a good practice and something that should always be a part of design considerations.
3. They require a lot of text input
When interacting with machines, humans tend to be terse. They also don’t read voluminous text if presented, especially in a chat like interface. Keeping that in mind is essential while designing a conversation.
If a chat bot expects or presents large volume of text, it’s more likely to be left unused or misunderstood. ‘Chatty’ bots are a strict no-no and if there is a NLP component to the chat bot, it should be able to handle short sentences as responses.
4. Chat bots are like messaging apps
If we go by the traditional definition of a chat bot, it’s a computer program which conducts a conversation via auditory (text converted into speech or vice versa) or textual methods.
It’s not.
Having an intuitive UI apart from the textual interaction can augment the UX. A simple tool like an emoji response can greatly enhance the quality of the interaction while providing valuable feedback into the behavior of the user and your NLP accuracy. Providing options as button can also help keep the conversation closed ended.
5. Traditional personalization is enough
Personalization should not be limited to detecting the user or mentioning the name in the conversation, chat bots need to capture user actions and provide shortcuts to their usual actions. It’s a good feeling to order the usual at the coffee shop every morning, the autofill in web forms makes life so much easier – isn’t it? They should keep a track where a user was last in cases where it makes sense and should show progress for tasks that can provide it.
6. Using the chat bot where it’s not needed
Like any other new technology hype, chat bots are being used anywhere and everywhere these days. A bad UX will always shy away customers and quick & dirty implementations are the primary cause of that.
If some time and effort is spent on the design of the chat bot, most implementation teams can quickly realize the futility of using a bot in certain scenarios. A good ol’ web interface or a mobile app is a better and less frustrating option in a lot of cases.
7. Does it really need a personality?
Chat bots need to have a personality to make the conversation interesting, the type of personality depends on the use case as much as the personality of the user. So, Mr. Funny bones might be a good assistant but might not be able to sell stuff. Mr. Smarty Pants can do a great job at selling but could put off a learner.
If we look at the NLP part of the bot, one that is less accurate at analyzing the intent of a user response but has an amiable personality would probably work better than a more accurate one which acts smart (unless you can be 100% right always – dream away).
Like Disney builds it characters, chat bots should ideally be represented by a character. Story telling comes in handy here, once a decision is taken on the character for a bot, time must be spent on thinking about the story or history behind the bot and how that character will react to certain situations. Including these nuances can make the conversation interesting and help in building a brand that users can associate with.
These seven thumb rules are good moot points when a team starts building a chat bot and can help it move towards building the better bot, or not – remember, using a chat bot where it’s not needed will leave a bad UX and can prove to be detrimental towards the entire brand.
In my next article I’ll discuss more about the personality part of a bot and how voice and tone can help. Do leave comments about any specific topics you need me to discuss.
[About the author: Rishi Arora works as an Analytics Architect at IBM India Pvt Ltd and is currently working on building a Virtual Tutor.
*This article represents my personal views; I do not represent the view of my employer (IBM) in any way. This article was originally published on Linkedin.]
