Designing the Conversational UI
In the first part of this article, we discussed the basic principles of conversational interfaces, and why you should consider building one for your own product. Here, we’ll dive a little deeper into more specific patterns, and see how you can translate them into a conversational form.
I want to present a few cases as examples to illustrate the challenges of designing a conversational interface, and go through some of the solutions we came up with at Meekan.
Validating input
With a typical GUI, when asking a user to supply more information (usually by filling out a form), you have lots of ways to make sure you’re getting a clean and useful response before moving on to process it. Is this a valid email address? Is this a phone number? Is this username already taken? You can restrict the input to be just numerals, or something that you pick from a predetermined list.
In a conversation, this privilege doesn’t exist. The person you’re talking to is free to type (or say) anything, so it’s up to you to construct your questions properly and digest the answers in the smartest possible way.
MINE THE REQUEST FOR INFO
Let’s say your robot is giving away t-shirts. He needs to ask the user for the size and color. If the user opens with “I want a medium size red shirt,” you already have everything you need right there.
But if the robot opens the conversation, or the user just says “Can I have a shirt?,” you’ll need to put the missing pieces together.
GIVE HINTS
Whenever possible, avoid open-ended questions and try to demonstrate the type of answer you’re looking for. If the pool of possible answers is small, just list them.
What size t-shirt are you? We have medium, large, and extra-largeAs a general rule, you should handle every item separately. Ask about the size; when you have the answer, ask about the color. Mixing several details in one sentence will be much more difficult to parse correctly, so ask your questions in a way that encourages a specific answer.
EXPLAIN WHAT WENT WRONG
If the input isn’t valid, explain again what you were expecting (versus what you received). If possible, be smart about distinguishing between answers you don’t understand and answers that make sense, but that you can’t accept.
And what color would you like?purpleI’m sorry, we don’t have purple. We have white, gray, brown, red, orange, pink, and black. What color would you like?brbrblI’m sorry, “brbrbl”? Is that a color? We have white, gray, brown, red, pink and black. What color would you like?grayCool! So a large gray t-shirt!
TO FORGIVE IS DIVINE
Remember, users are talking with you, not pointing to things on a list. They have more than one way to say what they want. If you’re asking for a shirt size, “extra-large,” “XL,” or even “the largest size you have” can all mean the same thing. “Thursday”, “thu”, “thrusday” (yes, with a typo) and possibly “tomorrow” could all point to the same day.
Switching tasks
Let’s go back to our good old GUI for a moment. A traditional app can perform different functions, which would usually be separated into discrete windows (or pages, or screens). If I have a calendar, it will perhaps show all of my monthly meetings laid out on the screen; when I want to edit one of them, I’ll switch to a different screen, and return to the previous screen when I’m done.
But a conversation is just one long string of sentences. How do you switch between different functions? How do you know which task you’re working on right now? Let’s see how this plays out.
The user starts a new task:
Meekan, schedule a team meeting tomorrowThe robot goes into his “schedule a new meeting” state and starts gathering the info he needs. But now something happens: the user is no longer interested in scheduling a new meeting, and wants to check her Thursday agenda instead.
Meekan, how busy am I on Thursday?This is the equivalent of hitting the “close” button on the New Meeting window, or pressing Escape on the keyboard. We have a few ways to handle it:
RESIST THE CHANGE
When the robot detects that the user wants to switch to a different task, he asks the user to explicitly abort the current task first:
We have an active meeting in progress. Say “cancel” if you want to abort the current meeting.You would typically take this route if the current task required a lot of investment to create, and aborting it would cause all this effort to be lost.
GO WITH THE FLOW
Again, the user asks for a task switch. The current task at hand is not too important, so the robot swiftly moves into the new mission. When this happens, it’s important to tell the user what’s happening: you’re aborting the current task and moving to a new one.
Here, the robot is expecting the user to RSVP for an upcoming meeting, but the user is instead starting a new, unrelated meeting:
Chris invited you to the project launch meeting on Friday 10am. Would you like to Accept or Decline?Arrange a new meeting tomorrow with @jesseOkay, Skipping the RSVP for now.Matching your calendars for a meeting tomorrow (…)
Tracking back
So we aborted task A in favor of new task B. Now that B is done, should we go back to doing A again?
At Meekan, we found that going back to the previous task seemed like the correct and smart thing to do, but would often cause confusion (for example, the user didn’t realize that task A had resumed, and tried to start it anew). If you do decide to track back, the key is to communicate properly. That way, the user knows what just happened and expectations on both sides of the conversation are aligned.
Looking again at our t-shirt example, this would make perfect sense:
What size t-shirt are you? We have medium, large, and extra-largelargeGot it. Size large. And what color would you like?actually make it extra largeOkay, extra-large. And what color would you like?
Timing out
This happens frequently in a chat. You’re talking about something, and then you step out to lunch, or get called to a meeting. By the time you’re back, you forget what the conversation was about. Quite frequently, the channel is filled with other people talking about other things, and whatever you were saying has scrolled into oblivion.
The robot should be aware of this. If the user starts something, disappears for a whole day, comes back, and starts something new, the robot can safely assume that the task from yesterday should be aborted.
Awaiting critical input
Sometimes you need a piece of information that you absolutely cannot proceed without. Maybe the user’s email address is required for the robot’s basic operation. Maybe you need to delete something first, and you cannot go further unless the user confirms.
In a GUI environment, you can pop up a modal window. It will block access to everything until the user answers this question: “Are you sure you want to delete everything?” The window will stay there until the user clicks either “Yes” or “Cancel.”
Replicating this behavior in a conversation requires the robot to refuse to do anything until he gets that vital piece of info from the user. This starts a loop that can get very annoying very quickly. Make sure you explain exactly what you need and why you need it. Prepare a few versions of this explanation, so that if the user tries to avoid it again and again, the robot will not get repetitive (and make the situation even worse).
To do my job, I need access to your schedule. Follow this link to connect your calendar.Schedule a new meeting tomorrowSeriously, you need to connect your calendar here to enjoy my scheduling superpowers.Am I busy tomorrow?I can’t wait to start working on your schedule! Please connect your calendar so I can do my magic.
This is not an ideal situation. Think carefully about whether you really cannot proceed until you have this particular information. If at all possible, make an educated guess and proceed, or at least allow some limited functionality, and ask for the information again when you absolutely need it.
Picking from a list
Depending on your robot’s job, you might eventually reach a point where the user has to choose from a list. Remember: no drop-down menus, combo boxes, radio buttons. If you have a list of items, and you need the user to select one or more, you have to give each item a unique name or number so that users can tell you which option they like.
Meekan, cancel that meeting I have tomorrowYou have 3 meetings tomorrow, which one would you like me to cancel?(1) Project launch at 10 am
(2) Team stand-up at 11 am
(3) 1-on-1 with Jake at 2:30 pmCancel 3Okay, I’m canceling “1-on-1 with Jake” tomorrow. I’ll notify Jake about this.
Numbering the meetings on the list gives users an easy way to reference the item they want to focus on.
What’s next?
There are still no rules; we have to make up our own. Let’s tell everyone what works and what fails for us. Let’s share, talk, write about it. It’s an amazing time to be a pioneer.
I hope my examples have stirred up some thoughts. Consider this article a launchpad for your own adventures in robotland. Now go build a robot! (And then tell everyone about it.)
—
This article was originally published in A List Apart on Feb 23, 2016, and is now reposted here as part of Meekan’s journey to create the digital office manager. Read more stories here
