Chatbot Design Canvas

Design questions to consider before you start

A revised version of the canvas is now available at #ChatbotDesignCanvas v2!

What is a chatbot?

The answer to this question will depend on who you ask. My take on it is that, chatbots encompass a wide variety of conversational computer programs. And for the same reason it is difficult to figure out the parameters of a chatbot that we set out to build for a given problem. Are you nodding along? If yes, you might find the following tool very useful.

Chatbot Design Canvas is a tool that can used for high-level design of a chatbot. The canvas prods you to ask certain questions in a certain order with the aim of figuring out the necessary parameters even before you get into conversational design and development.

The canvas above is colour coded with green (for value proposition) where you start, red (all user related parameters), blue (for all chatbot design parameters) and yellow (for all chatbot development and deployment parameters).

Download PDF here.

Let’s get started!

Bot Value Proposition

This is where you start. And this is the most important question you need to ask! What value does the chatbot provide to its users. What customer pain point is it going to address? Is it going to talk to them about weather? Share prices? Forex prices? Help them in online shopping? Or help them troubleshoot a product?

If you are working for a business client, you may be developing a chatbot to help ease their customer contact issues. The bot may be used to market a product range, sell them online, help resolve customer issues alongside the human team. Whatever it is, clearly understand the value the bot is providing to its users. You may want to consider all users: end-users as well as power users (admin, live agents, etc who work with the chatbot to serve the end-user).

Users

Who are the users exactly? Who are you building it for? In case of business bots, it could be employees and in case of consumer facing bots, it could be, well, consumers. Here is where you could drill it down a bit to detail. What is the age group of your users? Gender? Geographic location? And so on. What about the language they speak? The language aspect is important, because chatbots are designed to have conversations and therefore need to reflect the kind of language that users use to get adopted. You may also want to look critically at the user group in terms of their values and interests.

Again, do not forget the power users. These are people who will interact with the chatbot at a meta level seeking reports on performance, or configuring it and so on.

Devices

Having figured out who your users are, try to figure out the kind of devices they own or have access to. There are variety of devices that can be used to access chatbots: smartphones, tablets, laptops and desktops. Which of these devices do your users have or use the most?

While largely ignored, traditional devices like landline phones and simple feature phones can also be used to access chatbots. These devices do not depend on Internet data and therefore could be considered an option for users located remotely where data connections are faulty or unavailable. However, traditional devices have their limitations. Landline phone can only be used for voice based chatbots and feature phones can additionally interact using SMS (text messaging service).

Other emerging devices for automated chat are Amazon Echo and Google Home. If your chatbot is addressing problems in the user’s living room or in the kitchen perhaps, then these devices could be on your list.

Deployment Platforms

Chatbots can be deployed on a variety of platforms and devices. So it is important to understand which of these would be beneficial to your users.

Popular platforms for chatbots include Facebook Messenger, Skype, Slack, etc. There are more messaging platforms that have been opened up to chatbots. There are ones that popular in few regions only (for instance, Telegram is hugely popular in Russia but you won’t find a lot people using it in the UK). You may want to figure out which ones are the best for your target user group. These are messaging platforms that you can access via mobile apps, or websites.

It is also possible to build chatbots using more traditional platforms like text messaging (SMS), voice calls, email and social platforms like Twitter, which is not considered by many as a messaging platform. Traditional platforms are good for user groups that are not very tech savvy or live in regions where ICT penetration is fairly low.

You need to also think about the idea of sharing data with these platforms. Everything your user types into a Facebook Messenger chatbot is shared with Facebook. Are you happy with that? Think about it! If not, you can always build chatbots that can be plugged into a website.

Lastly, think about how different these platforms are in terms of what they offer the chatbot developer. Some like Facebook Messenger have great GUI elements like Cards and Carousels when others don’t. This could be important depending on what you want the chatbot to do.

If your chatbots are designed for devices like Amazon Echo or Google Home, then these devices come with their own platforms: Amazon Alexa and Google Assistant. Chatbots can be deployed as skills or actions on these platforms to augment the capabilities of assistants residing within these devices.

Modalities

What are the modalities of communication for the chatbot? Most simple chatbots use button based communication. User’s options are presented as an array of buttons and the user can communicate by pressing them. Going one step further, the chatbot could support natural language inputs. Users can type in textual utterances to request for information or respond to questions. Further ahead, the chatbot could support speech based interaction by processing incoming user speech and synthesising its own utterances. These options relate back to the choice of deployment platforms as well. Finally, you may also want to figure out if the bot needs to understand images (GIFs, emoticons, etc).

Personality

Does a chatbot need a personality? This is a question with many answers. Due to the nature of interaction (i.e. conversational), users invariably assign personalities to chatbots. So it is better for designers to figure out the chatbots personality before users do. So ask these questions: Do you want to give your chatbot a name? And may be a face? Is it going to be an extrovert? How formal or casual will its utterances be? Is it going to do small talk? Perhaps even tell jokes and limericks?

Conversational tasks

Having identified the value proposition, users and platforms, lets move on to identifying the specifics. What tasks do you envisage your chatbot doing? At this point, we need to break down the value statement into conversational topics and break topics further down into tasks. For instance, in a retail environment, the chatbot could provide value to end-users (i.e. consumers) by answering customer questions round the clock. Now the topics of conversation as such would be about delivery issues, returns and refunds, troubleshooting, etc.

By further dividing the topics into tasks in this regard, one may come with tasks such as getting delivery rates (e.g. a conversation where the chatbot can ask delivery address details and calculate delivery rates and options), returns checker (e.g. a conversation where the chatbot asks questions to check whether the product can be returned without any hassle or not), etc.

Backend tasks

A chatbot is not just for making conversations. It needs to carry out tasks in the background at the same time it is chatting with the user. For instance, a ticket booking chatbot, will need to access the tickets database to check for availability and book tickets as part of the conversation. For chatbots providing access to information such as weather, share prices, etc, the backend tasks may be simple. On the other hand, chatbots assisting online shopping may have to access the back-end Content Management Systems (CMS) like Magento, Shopify, etc to search, get product information, create carts, take payments and delivery information and to finally checkout. Likewise, chatbots providing marketing services should be able to talk to the CRM systems like SalesForce, HubSpot, etc. Such interactions can include a variety of tasks like creating a lead, recording an enquiry, etc. Other simple tasks would include sending information via email or SMS to the user.

The idea here is to create a list of back-end tasks and map them to conversation tasks to visualise how the conversation may need to be amended so that back-end systems are accommodated robustly.

Third party services

There are a lot of third party services that are available that already do what chatbots need to do in a modular fashion. These services can be harnessed in order to not reinvent the wheel every time we build a new chatbot.

One of the key features for a chatbot is its ability to understand natural language (Please note that not all chatbots are designed to process language). But this need not be built from the scratch. There are services like API.AI, LUIS, IBM Watson, WIT.AI, and LEX (Amazon) that can do this for you. All you need to do is to build a language model to the conversational tasks that your chatbot needs to handle. These services will translate a string of words into user intents and parameters with which your chatbot can handle the conversation. If you decide to build a voice bot, you will need to process users’ speech inputs. You could do this using Amazon LEX, Google Speech API, etc.

Development platform

Having figured out conversational tasks, backend tasks, third party libraries to use, it is time we move on to another important question: the development platform. There are several options here:

1. Web based visual platforms: Chatfuel, FlowXO, Motion.ai, etc are for non-coders who can build a chatbot quickly once the conversational flow has been figured. They are visual in the sense that implementing conversational flow is by playing around (create, drag, connect) with conversational blocks. These are best for simple bots that do not rely overly on processing natural language inputs from users. These platform are becoming more sophisticated allowing chatbot users to talk to liveagents, connect to third party information services through webhooks, etc. They also allow developer to seamlessly integrate the chatbot with one or many deployment platforms.
2. NLU based platforms: Tools like API.AI not only process natural language utterances, but also allow developers to create full fledged chatbots. Thes tools are suited very much for NL based chatbots (read voice bots on Google Home). They allow developers to hook in their web apps as webhooks to allow the bot to do back end processing of users’ requests.
3. Conversational toolkits: There are tools like Microsoft BotBuilder SDK which can be used to build chatbots quickly. The SDK provide a library of tools to create conversational flows with ready made conversational engine in Node.JS, .Net and REST. Other similar toolkits include BotKit, BotPress, etc.
4. SDKs from deployment platforms: Every deployment platform we have discussed above have their own set of SDKs to help developers integrate their chatbots into the platforms. These SDKs specify message formats that need to be adhered to by the chatbot. In this case, you will be building the conversation engine and flow yourself and integrate it with platform SDK.

In case of options 3 and 4, you will also need to host the chatbot yourself in a cloud platforms like Heroku, Amazon AWS, MS Azure, etc.

Analytics

Analytics is for post development. Analytics helps understand how the chatbot is used, where it fails and what the users think. Analytics is about collecting data to infer answers to these and many other questions about how the chatbot is actually doing post deployment. Some development and deployment platforms have their own analytics suite: Chatfuel, Facebook, etc. On the other hand, there are several toolkits you could use: Dashboard.io, BotAnalytics, DialogAnalytics, etc. Very recently, Google has released its own analytics platform called Chatbase.

Analytics platforms provide us with insightful information on how the chatbots are being used. These include the total number of users, daily new users, user retention stats, popular inputs, inputs from users that the chatbot did not understand, etc. It also gives intelligence for our marketing efforts such as the source of the user: Facebook, Twitter, etc.

Marketing

What marketing techniques do you plan to use? This might seem like a question irrelevant to the development team. But it is not. Marketing approaches set the expectations on what a chatbot can and cannot do. Users very first interaction with the chatbot may be fuelled by those expectations. So it is necessary to understand how the chatbot will be marketed.

Facebook Adverts with a direct link to the chatbot via Send Message button is one way of getting users to start with in case of Facebook chatbots. Chatbot URLs can be marketed on other social media channels like Twitter, Instagram, etc. And it is always a good idea to tell users how to get started with the chatbot during marketing campaigns: say ‘hi’ to our chatbot, and in case of trouble say ‘help’.

These in turn should guide conversational tasks design as discussed above. You should think about whether the first time conversation with the chatbot is going to be different from subsequent ones for a user in order to facilitate onboarding.

So there you go! 12 questions that provide you a holistic bird’s eye view of the chatbot you are thinking to build.

Happy Chatbotting!

I am eager to hear your stories about how you used this canvas and other tools to identify the parameters of your new chatbot. Please feel free to comment.

A revised version of the canvas is now available at #ChatbotDesignCanvas v2!