Principles of bot design
Despite plenty of excitement it’s still unclear how conversational UIs can be made to work in a practical sense.
But opinionated design principles can help us push past the hype, and design something real people will want to use every day.
We’re not lacking for self-assured sermons on how conversational UIs are the future. Much less is written about the practicalities of actually designing chatbot interactions.
Yet it seems like this is precisely what we now need. Early attempts at chatbots have fallen flat in their execution, mostly because they have relied too much on natural language processing or A.I. capabilities that simply don’t yet exist. Others have jumped on the bandwagon and tried to shoehorn unsuitable use cases into this new pattern.
In all the excitement of diving into this new technology most of us seem to have forgotten about the most important actor in this enterprise: the human being who is expected to talk to the bot.
So how do we go about designing bots? When are they useful? Should they be friendly and simple like Slackbot, or fake yet smart like Facebook M? Should they allow for free text input or create IVR-like options? These are not insurmountable questions, but the truth is we’re still exploring how to use this new medium to build great experiences.
Situations like these call for strong opinions, weakly held. When you’re tackling a domain like chatbots that are still very much in flux, it’s essential to be guided by clear design principles.
What are design principles?
All great, category-defining products are opinionated. Design principles lock these opinions in place upfront.
At their simplest, design principles are a list of strongly-held opinions that an entire team agrees on. They force clarity and reduce ambiguity, and represent a north star for everyone to aim for.
There’s an art to coming up with good design principles. They can’t be mere truisms. If they are, everyone will simply nod in agreement, but they won’t help you to make actual decisions.
For example, “We don’t make our designs too complex” is a terrible principle – nobody would realistically argue the opposite position. Truisms cannot guide your decision-making in any meaningful way.
“We favor simplicity over power”, on the other hand, is a great design principle. The opposite principle could also be argued – “We add complexity so our users can do cool things”. Opinionated principles like these will help you make consistent decisions throughout your design process.
With that in mind, let’s lay out some principles that will allow us to make progress on designing conversational interfaces.
Principles of chatbot design
1. Don’t pretend to be a human
Playing bait-and-switch with a user can make them feel that they have been duped, or that they don’t understand how a system works; both are bad user experiences. Don’t pull the rug out from under your users. This means not using “is-typing” indicators or artificial delays to make the user interface seem more human. On the contrary, conversation flows and bot messages should be styled differently and be clearly labeled in a way that communicates they are not human. This doesn’t preclude us from giving the bot personality.
2. Keep it incredibly simple
Chatbot conversations should be bounded to very particular subjects and follow linear conversation flows; we avoid complicated branching paths. We’re not trying to create a general, self-aware artificial intelligence here. It’s okay to expose and explain limitations. BASAAP. Individual bot designers shouldn’t have to account for tricky failure cases. Users will tire of complicated passages of dialogue.
3. Respect the chat medium
One advantage of smart messaging apps is that we can strip away a lot of apps and interface and reduce the interaction to a simple chatbot experience. It would therefore be pointless to turn around and drop an entire app directly into a conversation. Keep everything native to the conversational back-and-forth. Every bot interaction is about call and response, with the bot publishing comments into the chat thread and the end user responding in the reply area. Bots can’t modify conversations in ways that humans can. At the same time, make use of conventions: rather than printing out an ungainly URL in a bot response, show a nicely-formatted card previewing the linked page.
4. Optimise for the end user
Bots should be used to improve the end user experience, not just to make life easier for customer support teams. UX designers should ask themselves: would a human be better for the end user? If the answer is yes, you shouldn’t be using a bot. Bots should not attempt to replace what humans are good at; rather they should attempt to improve what humans are slow at. Machines should work; people should think.
5. Use sparingly
Bot interactions should be short and precise. It should be impossible to get into a protracted back and forth conversation with a bot; anything above two inputs feels laborious.
6. Provide an escape hatch
Always have a human fallback option, allowing the user to express “I’d rather wait and talk to a real human, make this robot thing go away”.
7. Use structured input when possible
The more alleyways a conversation can go down, the greater the potential for dead ends. Don’t place users in a situation where they need to guess the correct incantation required to proceed. Custom soft keyboards permit a limited range of input and can save a bunch of typing. For example, rather than asking the end user to type “yes” or “no,” show them two mutually exclusive buttons. Or validate structured text like email addresses before sending. In this way you can keep responses on track and sidestep the complications of parsing unpredictable plain text input.
8. Everyone sees the same thing
Bots don’t only appear to the end user. The humans behind the bots need a record of the conversation’s context too – how a bot replied and how end users responded accordingly. Common or lengthy bot messages may be displayed in a collapsed state in the admin view for the sake of neatness. Cases in which bot messages are private to an admin and are only internally visible are an exception.
Obey the principles without being bound by them
It’s important to note that these principles will almost certainly evolve, due to new technical possibilities or the simple fact that some of them were misguided. We should allow for both.
But having them in place makes things so much simpler from here. We’ve got a stake in the ground. Now we just need to apply these rules consistently and methodically. Without principles you’re just randomly firing ideas in any direction and hoping you’ll hit something that works.
