Before actually building bots.
Over the past few weeks, I have been working at the Sutardja Center at UC Berkeley on a program for students interested in working on the latest trend in human computer interaction — conversational interfaces or chatbots. This is a condensed version of a presentation/talk I gave at the kick-off event.
If you have somehow managed to hear/read “chatbot” for the first time, read this excellent primer by Matt Schlicht. Simply put, a chatbot is software that people can interact with via chat.
After I talked to other students, I realized that a lot of students were not sure how to begin the process. How do you even think about building bots?
So, here’s an attempt at highlighting simple principles that I have used and you can use to think about building bots.
Define Your Bot’s Purpose
Why does this bot exist?
Define a use case for your bot and work out why anyone in this world would want to use it. Find a target user of your bot, someone who is not working on your bot, and find out how they carry out the use case currently. When you do this, you can work out the interactions your bot can offer.
Bonus: Act out the use case with another person. You, THE BOT, are just minding your own business. Enter USER who wants to get job done. Work out how the user can be successful in doing what they are trying to do and what could prevent them from being successful.
Context Makes Bots Less Annoying
Alright, you know what it is that your bot will be doing. What’s next?
How do you build bots that are not annoying? Well, from my experience, context is the most important thing. Most importantly, the bot needs to maintain state in some way. Maybe it records a person’s reply and replies to them based on it. Maybe it records everything a user says to provide intelligent recommendations? If your bot is interacting directly the context is one-on-one but in a group the bot needs to keep context with several individuals while supporting group level interactions. E.g. It would need to orient new members about how to use the bot. Maybe your bot interacts with external services or gets data from external services. How would user privacy work in this context?
There are several layers of context to get through and I can’t list them all but understanding and working it out is a great beginning. Just not this kind of context.
Set Expectations With The People Using Your Bot
A bot is not a person. Don’t pretend that this isn’t software.
I cannot stress enough the importance of starting off your interactions by communicating clearly and succinctly with the person using the bot. Managing user expectations becomes particularly challenging when the end-user just wants to know what the bot can do, and doesn’t care about how it does those things. Having your bot do it makes for a more natural experience. Erring on the side of setting expectations lower leads to less disappointment and a more positive experience.
The risk here is that of leading users to believe that the robot is worse than it actually is. I have some thoughts about a progressive enhancement strategy for building bots but that is not in the scope of this article.
Explore What Messaging Platforms Offer
Messaging is the medium.
For a lot of modern bots, messaging platforms are the medium of conversation. Text is the primary mode of information exchange on these platforms. However, People tend to focus on the information as well as the structure that delivers this information. Each platform affords distinct interactions and consequently, creates different mental models for people. Your user’s mental model of your bot is transformed by the platform where the bot exists. The way people would use your bot depends on how they use the underlying platform. Understanding this is crucial to making the best use of the platform’s capabilities and ultimately providing the best experience.
Imagine usability testing a Slack bot for someone who doesn’t know what Slack channels are. You need to think about how people use the platform where your bot exists.
This leads to my next point.
You Can Facilitate Conversation By Adding Structure To It
Conversations can go out of scope in limitless ways.
Your nifty pattern matching function provides different greetings to people but does it handle multiple languages? I am asking because mine didn’t.
Human language is not a great tool for conveying information. Ironic, I know. If you have ever struggled to provide directions to someone, you know what I mean. It is often easier to point vaguely in the general direction than reply verbally. People aren’t adequately equipped to understand what other people are saying.
It is quite unlikely that your bot can understand and reply satisfyingly to everything a person can say. So, you provide structured inputs. These can be formatted replies or text buttons. It makes it easier for you as well as the user. By providing a limited amount of conversational pathways or limiting interactions you can create something that gets work done. Ultimately, isn’t that what people want?
Finally, remember to —
Build, test, improve and then build, test and improve some more.
I remember the first time someone wanted to use a bot that I made and took 10 tries to get started. I remember when a user’s typing pattern was so odd that their phrases could not trigger behavior. I remember seeing a user who did not know how to add an emoji reaction in Slack, kept replying to the bot with the emoji and ultimately apologized for “not getting it”. People shouldn’t have to say sorry for using your product, right?
It can be hard to prototype a bot because bits and parts of the functionality don’t make sense out of context. You can carry out Wizard of Oz tests with target users. The “wizard” observes user inputs and simulates the system’s responses in real-time. You can carry out this test with a friend over any messaging app to save time and test ideas quickly.