10 ways how designing a chat bot is different from designing an app

We, at Anaek, are betting heavily on messaging to be the future of interaction. The long web forms with its checkboxes, radio buttons and ugly file uploads will make way for a new type of interactions — bite-sized and in context. A single question which can be answered by pressing a button, a free form answer or reacting with an emoji. Boring will make way for interactive, cumbersome will make way for rapid and all-or-nothing will be subsumed by one-at-a-time.

There are some striking differences in designing a product in the chat bot world as compared to any other app or web product. In this post we try to capture some of the key differences.

Making a bot needs a different toolkit and new set of best practices

On-boarding a new user to a chat bot is very different from on-boarding a new user on to an app. Lack of visual cues, limited real estate and a propensity to test out the ‘AI’ in the bot usually sets up the on-boarding for failure. It is of paramount importance to get two things right, right from the get go. One, make sure you lead the user (think of it like the cross examination of a witness where leading her to prove your point, is allowed) to responding or interacting in ways your bot understands. This can be done in a variety of ways ranging from providing a set of sample answers like “Hi, Are you the office manager for this office? Reply with Yes or No”, to leveraging buttons or quick prompts, if they are available on the platform.

Leveraging buttons in Slack on OfficeAmp Bot

Two, set the right expectations. There’s nothing more fun than breaking a bot and posting screenshots of it on twitter. The more fun and conversational your bot is, the more likely is it to be stress tested. Keep things tight and get right to the point. It’s okay to use emoji’s to keep things upbeat and cute but asking “how’s the weather there” or “how’s it hangin!” is asking for trouble.

Designing workflows for a chat bot is where the difference from a conventional web/app is most striking. Unlike web/app, the most efficient interaction might not be the one that gets you to the exact place you want to get. It’s absolutely ok to get the user to the vicinity of where she wants to get to and then gently pave the way to the actual destination.

ExpenseTron in action in Slack: Using context and defaults to intelligently extract the information available, guess what you can’t extract and then let the user change the rest

For instance, take the example of a simple expense filing interaction. The bot needs to know several things to file the right expense, like the amount spent, the category of the expense, mode of payment, date of the expense, whether the expense is billable etc. Instead of interactively asking for all of these, it will extract what it can from what you say and guess the rest. Yes, it might fail to get it right in one go but in our experience it’s best to ask for forgiveness and provide a way to fix things, than to ask the user multiple things for doing something. Compare this with a conventional web form where you need to fill out all the things before you hit submit. This feels more natural and if you do your extraction intelligently, much faster as well.

Discovery of features is one of the toughest problems in the bot world today. In a sense, most of what your bot can do (assuming it can do a lot) is basically an easter egg. Some bots will rain on you a list of features and commands as soon as you initiate chatting with them. That is absolutely the perfect way to do it, if you’re going for intimidating the user into never coming back. Here again, lead the user to try out things but on a need to do basis. Guess what the users are looking for and keep introducing them to the specific actions. There’s no sidebar and no header to link features. This is the principle of progressive disclosure working the world of the bots.

You need to intelligently expose the user to more stuff based on what they are trying to achieve any time. In our previous expense example, you can expose the user to the expense reports functionality when they file their first expense with a simple “That’s great! You just filed your first expense. Now download your expense reports by typing ‘report’.”

MVPing in a chat bot world is far more powerful than in the traditional web/app. The ‘fake it before you make it’ and bots are a match made in heaven. Asynchronous time consuming use cases like research work, proof reading, data extraction and mining on documents, image recognition, seeking expert help etc can be achieved by a simple bot that collects all the info needed to achieve the task, manually doing it offline and then pinging the user when done. This is a great way to get off the ground, assess the demand and offer top quality service to your early customers while learning more about automating everything for scale.

Error recovery is a unique and interesting problem to deal with. A good chat bot won’t ever make you feel like you goofed up or that it didn’t understand what you said and in that sense, your best error recovery mechanism is the one that’s never needed. A healthy mix of “Did you mean” and “I didn’t get that, try out these.. instead” is usually a good solution but this is where things get AI-sy. The bot needs to be able to understand user specific lingo and learn from previous errors. Of course this is easier said than done. In an enterprise use case, where learnings from one user may or may not apply to the whole team, it gets even tougher.

The bot also needs to be able to keep a tab on the contexts along with the responses. Together they are a source of useful user information. Parameters like time of day, users’ previous inputs, interaction speed etc are all data points that the bot needs to store and operate on.

Receiving feedback and offering support is one of the most powerful advantages that a chat bot has over a traditional web/app. Ideally, you’d never want the user to leave the chat bot platform for anything. Be it learning about new features, asking questions, receiving support or even making payments, everything should ideally stay inside the platform. The platforms here have their work cut out as well. Just like buttons and drop down selectors by Slack, we anticipate many more such advanced interaction aids will come up that will inherently make the platforms more engaging and non restrictive. Until such time your key goal is to offload as little an interaction to the outside world as possible.

Slackbot offering documentation right inside Slack

This becomes slightly easy for support because when the bot fails to understand the user input, it can always search its knowledge base and surface articles that closely reflect what the user was talking about. Slackbot does this really well.

Measuring success goes beyond counting number of people who met the objective of the interaction. Number of interactions it took, failures encountered and if it involves guesses from the bot (like our expense example from before) then the number of wrong attempts it took the bot are all useful metrics that gauge the success of the bot. Getting the user there is not enough, how the bot gets her there is also super important. It’s only early days and there will be a lot more public information on tracking and measuring engagement and usage for bots but developing a strong application specific data gathering and analysis system, right from the start, is super important.

Localisation here simply means translating the text to another language and that’s it. Unlike traditional web/app products, where there is a UI and texts/strings need to fit inside certain boxes, there are no such restrictions in the chat bot world. In fact using multiple languages at the same time is possible. Think of it how a kid born and raised in America to immigrant parents would talk to them — while the parents speak in a mix of English and their native language, the kid almost always responds in English. When done right, this could be so powerful.

Leveraging the underlying platform to improve collaboration and extending the product is a unique possibility with chat bots. Since all interactions happen on an underlying collaboration platform, all interactions/workflow can easily be supplemented by users directly talking to one another. In the early days of AttendanceBot, we did not allow users to provide a reason while applying for a time-off request. We set the expectations that people should be able to directly tell their managers their reasons for the vacation by sending them a direct message on Slack. This is a great way to offset parts of your functionality to the platform via easy recipes that enhance the functionality of the bot.

SSO as a first class citizen — Bots along with their underlying platforms, offer an awesome add on to the overall experience in the form of single sign on. If in addition to the chat platform, you also need a separate web interface (say for some administrative functionality like setup or advanced functionality like dashboards), you can always use the underlying ‘Sign in with ...’ functionality of the platform.

External links to a settings dashboard for AttedanceBot using SSO of the Slack platform

There is no need for a new signup/registration or passwords and no need to provision/de-provision users. This is related to the previous point of leveraging the platform but deserves it’s own mention, especially because of its pertinence to enterprises.

It’s still early days, both for us and for serious bot applications. These are some of the early initial differences we’ve come across. Are you doing product management/design for chat bots? Do let us know what you think of our learnings and feel free to share yours in the comments.