As users, we require a good and practical interface when interacting with any system. It has to be simple enough for us not to get lost in it. At the same time, it has to meet all the needs we might have. The same applies to interactions with a chatbot. The conversation has to be simple enough so the user is not bothered with unnecessary information. On the other hand, it has to cover all possibilities that might occur when processing a user's request.

In previous articles, I described our chatbot solution that uses checklists as the main element of conversation design. In this article, I would like to share our process of creating a complex conversation from a simple feature request.

Since the design is specific to our chatbot solution, I will use the same tools for design as we use during real development, that is, pen and paper. Surprisingly, these are still the best tools to use. As a design template, I will use finite state machine diagrams. This is to simplify analysis and also it serves as a template to use in the final code implementation. So what will be shown? Circles and arrows. Every circle represents one piece of information that is successfully processed by the bot. Every arrow represents an input sentence or a condition that is imposed on data already provided during the conversation.

Feature request

Let's say that we have the following request for a chatbot feature from a customer:

In our company, we have meeting rooms that we use daily. We need to schedule our daily calls and business events like product demonstrations and virtual meetings. We need you to create and design a conversation feature that will enable us to book a room. Also, let's send an email to all colleagues that need to attend a given meeting. It would be nice if we could append an optional message. If any of the colleagues already have another meeting set up, then the organizer needs to see this information beforehand.

To simplify this example, we are going to assume that all other layers necessary for this feature are already prepared (sending emails, checking the schedule of users, etc.). That way we can focus solely on the conversation design.

Simple conversation line

Let’s start our first conversation design by looking at this:

In our company, we have meeting rooms that we use daily. We need to schedule our daily calls and business events such as product demonstrations and virtual meetings.

So how can we approach this? As designers and analysts, we have to think from the perspective of the chatbot. What information do we need to achieve the goal of this request? We will need to know at least the time of the meeting. There should be an action specification, and to avoid other interpretations we should ask the user for a clarification of the object, a room, in this case. From this we can put together our first checklist:

• Book
• Room
• Time or time range

Once we have all this information we should be able to move to the next step. In this case, the bot will make a reservation and send an email. Now let's transform this checklist into the conversation diagram:

We will have 4 steps in conversation. In each step there will be an interaction with the user if this conversation was not specified earlier:

1. What would you like to do? -> Book
2. What would you like to book? -> Room
3. When would you like to plan your meeting? -> Tomorrow from 9:00 to 11:00
4. I have created a reservation for you

Congratulations. We have designed our first conversation. What will happen if a user creates a single line with all specifications like this?

Book me a room for tomorrow from 9:00 to 11:00

In our chatbot solution, we only ask for information that we don't have. In this sentence all the information is present and so the only response from the bot will be number 4:

I have created a reservation for you

Optional parameter

Now let's have a look at the next part of the feature.

We need you to create and design a conversation feature that will enable us to book a room. Also, let's send an email to all colleagues that need to attend a given meeting. It would be nice if we could append an optional message.

For now, let's focus on the optional message specification and deal with adding users later in this article.

From the previous iteration our checklist looks like this:

• Book
• Room
• Time or time range

After time specification we should give the user an option to add a message to his email. A simple question should be enough. How about:

Do you want to add a custom message for your colleagues?

If the answer is yes, then we ask the user for the message itself. Otherwise, we move on to the reservation. We need to enhance our previous design a bit:

• Book
• Room
• Time or time range
• Do you want to add a custom message for your colleagues?

Yes - add a message
No - no message

At this point we have multiple possibilities on how to convert this checklist into a diagram. User interaction should be always the same but as we know, there are multiple ways to design a system. This is one of the possible approaches:

We’ve added a few steps to the previous diagram. The first 3 are the same. At the fourth one, we will ask for additional users, but for now, we can assume that this is taken care of, and we can focus on step 5. We can assume that the conversation from the chatbot point of view can be prepared like this:

5.Would you like to add a custom message for your colleagues?
a. Yes - Ok, what would you like to say?
b. No - Alright (and continue with I have created a reservation for you)
c. “users message” - Great, I will make sure your colleagues get this. (and go back to step 6)

6.I have created a reservation for you and your colleagues.

There is a reason for designing a conversation in this way. This conversation branch can be reused. We can use the same branch when adjusting this meeting. Or in another conversation where we need a custom message.

Now let’s see what the conversation for this iteration can look like:

Complex enhancement and iteration

In the last part of our design, we should introduce a way to add multiple other users to the meeting. Let's have a look at the relevant part of the request:

Also, let's send an email to all colleagues that need to attend a given meeting. It would be nice if we could append an optional message. If any of the colleagues already have another meeting set up, then the organizer needs to see this information beforehand.

Again we find ourselves at a point where there are multiple possible approaches to design a conversation that would satisfy this request.

I will present one of the possible approaches. The checklist for it will look like this:

1. What would you like to do?
2. What would you like to book?
3. When would you like to plan your meeting?
4. Would you like to add your colleagues to this meeting? Who is it going to be? (list of users / no)
5. Would you like to add a custom message for your colleagues? (already done)
6. I have created a reservation for you

So what does this checklist tell us? We start with a straight question - if there are going to be additional users. If not, then we direct the user to another part of the conversation - a custom message. For an affirmative answer (list of users should be also considered as an affirmative answer) we will move into additional questions. Here we can iterate and ask the user if the list of his colleagues is final. If so, there should be some validations and quality of life questions. Those can consist of checking given users if they are in our system. Or we can ask the user if he also wants to participate if his name is not already on the list. Also, this is the place for checking other users’ schedules for conflict meetings. Once everything is sorted out and the user is able to navigate all the possibilities, we should wrap this part of the conversation and move into a custom message part. And that part is already sorted out, so we should be done with the design.

Now let’s have a look at the diagram of this approach. For simplicity, it only shows the part for adding users.

From a simple and straight conversation, we’ve arrived at a really complex conversation full of questions from the bot and required answers from the user. But every possibility is covered and the user will have a list of all participants eventually. The first part (steps a, b, and c) deals with adding users. Then we process both conditions for conflicting meetings and current user participation. After that, we return a final list of users back to step 4 and we are done.

Even though this design is quite elaborate, the user conversation should be natural:

Conclusion

From a feature request to a solution - that should be a goal of every application developer. We took this vision and applied it to a chatbot solution. In essence, almost any issue that can be solved by a conversation with a person should be possible to convert into a conversation with a chatbot that will handle it as well, no matter the complexity, no matter the subject. There are still cases that we are not able to fit into an automated conversation, but that is another topic.

From a simple conversation to a complex one, there is always a way for a design that can give users the ability to finalize their task. For the best user experience, we should mind their requests and adjustments.

Written by Vojtech Kaisler