In this Document

Planning Your Bot Welcome Messages Query Flexibility Providing a Response Error Handling Notifications Using Newlines Tone Consistency Asking for User Info

Designing the Bot UX

Just because bots don't have a graphical user interface does not mean that a bot cannot be well designed.

Building bots brings about new UX paradigms and challenges that Botler and bot developers on the platform work together to solve in order to make bots more user-friendly and accessible.

Here, we lay out some of the best practices for building your bot to help you convey the value of your bot as best as possible to users.

Planning Your Bot

Before you make your bot - whether it's a Data Bot or Service Bot - you should take a moment to think about exactly what information or functionality your bot will deliver.

The most useful bots serve one simple function. For example, a bot may update users about the score of a game, log pushups, get a link for directions, or bring headlines/breaking news.

These functions may seem small, maybe even trivial, but to a user this provides a cumulative value.

By using a wide array of bots from a single platform, users can get information or perform an action by a simple text message which would otherwise require them to open a browser, get a piece of paper, or open/install an app for.

You can read more about how Botler helps you make your bot useful by reading about the Botler Method.

Crafting Welcome Messages

When a user first messages your bot handle (for example, "@weather"), Botler returns to the user your specified welcome message. This is the most important message to your user because it is at this point the user decides whether they continue an interaction with the bot or not.

A good welcome message clearly conveys two critical elements:

Bot Function: What does your bot do? You should put your self in the shoes of a user who has no idea what the bot does. From the welcome message, a first-time user should be able to know exactly what they can accomplish with your bot.

Next Step: A good welcome message also tells the user what they must do to actually use your bot. For Data Bots this mean list out all triggers that you want your users to be able to access. Users will not know the handles you provide if you don't tell them in the welcome message. For Service Bots, this means prompting the user to ask a question or form a string of some pattern.

Here is the welcome message for Data Bot @BU_CS_350, with info for a class at Boston University. The message makes it clear what this bot's triggers are, and what info the bot can provide.

This is the welcome message for a service bot, @directions. It clearly explains the function of the bot, and tells the user how to use it.

When a user first messages your bot handle (for example, "@weather"), Botler returns to the user your specified welcome message. This is the most important message to your user because it is at this point the user decides whether they continue an interaction with the bot or not.

Allowing Query Flexibility

For Data Bots, a welcome message will list out all possible triggers which the user can ask to the bot. But Service Bots allow users to submit string queries of any form which get sent to your endpoint. (You can read more about how powerful Service Bots can be over here.)

This means two users who have the same intent - want to perform the same action - can form their emssage to your bot in many ways. It is the job of you, the bot maker, to implement some flexibility for user query processing so that you accept more than just one pattern of response because that makes your bot more robust.

For example, consider the @OSA_16 bot, a Service Bot for the 2016 OSA convention. Two users who have the same intent - getting the dinner menu - can form their queries many ways:

This could be achieved by looking for certain keywords. But ultimately, it is up to you to decide if you should/how to add robustness.

Important Note: if you are creating a Data Bot, our built in system allows for some flexibility in trigger handling. We are able to handle slight misspellings and rephrasings, and will also check if the trigger is contained in the query the user is sending. We then hit the trigger we think the user is most likely aiming for.

Providing Feedback & Responses

Your goal should be to satisfy user intent as efficiently as possible. The @directions bot parses one user string to extract a to and from location - it does not draw out an exchange over three or four messages.

Not all bots are equal, however. User intent can sometimes be satisfied right in the welcome message. For example, here is the welcome message for @CNN, a bot that provides headlines from CNN:

The bot creator put the top headlines right in the welcome message, anticipating that this would provide immediate utility to some users, instead of first a greeting where all the possible sections are listed, and then delivering headlines after a second interaction.

This welcome message also lets users know they can text "@CNN sections" to see all the sections which they can get headlines for.

Note: Botler also shortens URLs for Service Bots, so you don't have to. This is done automatically by detecting any links in your response.

This means that you can return URLs of any length (even if they are long) without exhausting text capacity, without frustrating users, and without sacrificing any link tracking you already have in place.

If a user is not requesting information and instead wants to perform an action to update or edit values (e.g. a user wants to log how many pushups they did) it is important that the bot responds with some message which reflects this action.

Consider Botler's own response when a user blocks incoming notifications from a bot:

Botler responds to the user by notifying them of the updated state of their settings. Without this, the user would not know if the action was successful or how to undo it.

Error Handling

What happens when the user sends a message which your bot does not understand or you could not parse?

For Data Bots, if a user queries a trigger which does not exist, Botler responds saying that no response was found for the query, you don't have to worry about it.

For Service Bots, it is up to you to decide what to tell the user if you could not understand the query.

@PressedCafe is a Data Bot, so when we query a trigger that the bot creator has not made, we get a standard error response.

If we query the OSA convention Service Bot with a string it could not understand, it provides an error message which the bot creator made.

This is a good error message for a Service Bot because it provides the user with alternate options to guide them.


Notifications to users should be relevant and sent only when necessary to fulfill your bot's function. In order to prevent users from blocking notifications from your bot, notifications you send should provide something of value to a user that relates to your bot's function.

Another strategy we urge you to consider is sending users a message asking if it is alright to send them notifications about a certain topic (e.g. breaking news) so a user can choose whether or not to receive them. That way you can ask them if they would like to receive updates from your bot about a different topic a few days later.

The mechanics of how notifications work can be found in the Service Bot documentation.

Using Newlines for Whitespace

We encourage you to visually break up different pieces of information using newlines. All Botler interactions are textual (i.e. no images), so line breaks carry over across both SMS and the Internet.

Using the newlines as whitespace, the @CNN bot makes the headlines much more glanceable than if they were all crammed against each other.

The @OSA_16 bot uses a new line in the error message to draw attention to a very important feature, which allowing a user to text for help. If the message did not have the whitespace, users may gloss over the critical feature.

Tone Consistency

You can project whatever voice or persona you would like over your bot. But in order to avoid confusing the user, use it consistently. Not being consistent in tone may lead a user to think they accidentally sent the message to a different bot.

For example, you might not want to send one message with, "Good morning, ma'am," and another message from the same bot with, "Ahoy, matey."

Unique use of tone also helps distinguish your bot from other bots.

Asking Users for Their Info

When users message your Service Bot, we provide a unique user ID, but Botler does not reveal any personal info about the user. While we discourage bot makers from asking for personal info, in some cases it is a legitimate value add.

To get personal info, you must ask your users directly for the required information. It is up to you if you want to validate this info, for example if your bot needs a user email, checking if the email is valid is your responsibility.

Note: Never ask a user for a password.