Designing the Conversational UI

by
Published in Design, User Experience

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.

Article Continues Below
Article Continues Below

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#section2

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#section3

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#section4

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-large

As 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.

Acknowledge#section5

When the answer is valid, repeat it to make sure you understood it correctly, and move on.

Got it. Size large. And what color would you like?

Explain what went wrong#section6

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?

purple

I’m sorry, we don’t have purple. We have white, gray, brown, red, orange, pink, and black. What color would you like?

brbrbl

I’m sorry, “brbrbl”? Is that a color? We have white, gray, brown, red, pink and black. What color would you like?

gray

Cool! So a large gray t-shirt!

To forgive is divine#section7

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#section8

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 tomorrow

The 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#section9

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#section10

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 @jesse

Okay, Skipping the RSVP for now.

Matching your calendars for a meeting tomorrow (…)

Tracking back#section11

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-large

large

Got it. Size large. And what color would you like?

actually make it extra large

Okay, extra-large. And what color would you like?

Timing out#section12

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#section13

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 tomorrow

Seriously, 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#section14

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 tomorrow

You 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 pm

Cancel 3

Okay, 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?#section15

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.)

About the Author

Matty Mariansky

Matty Mariansky cofounded and is the product designer at Meekan in Tel Aviv. He has designed everything from slot machines to financial news sites. Matty invented the “traffic light” system for smart, effortless casual wear. He, for one, welcomes our robot overlords.

18 Reader Comments

  1. Fantastic article. For me, the first conversational interface experience was Creative Labs’ Dr. Sbaitso, the software that came with the Sound Blaster card to test its voice capabilities. In my opinion the trickiest (and most interesting) part of this type of interface is the gradual learning mechanism that needs to take place in the background – Does the user jump around from task to task all the time? Are they taking a long time to decide? Do they need more help? Do they seem to have habits/preferences that can be addressed automagically?

  2. Probably the last part: automagical, proactive suggestions initiated by the bot is the most interesting.
    We see the proactive suggestions getting x8 more engagement than the actions that originate from the user’s side

  3. I imagine conversational UIs to be a more friendly way to convey user action however, I still see the need for UIs to be able to see your calendar summary, go back and edit things because often when you have a lot to accomplish, UI’s make it quicker. I don’t see large enterprises eradicating their systems for robots, however I do see it as complementary tool. Thoughts?

  4. It’s quite hard to replace existing tools and habits. We’re probably going to see robot augmenting existing tools, perhaps collecting joined insights from several sources into one. And eventually, where is makes sense, replacing them altogether.

  5. Web design is a very diverse and versatile subject, a lot similar to other aesthetic industries like fashion and architecture. Thus, web design trends change each year in accordance to the innovations in supply and demand in the aesthetics paradigm. It is the very essence of a good website design that it is visually appealing and tickles the visitors’ fancy.

  6. Very interesting, thank you! Could you tell more about “Picking from a list – Remember: no drop-down menus, combo boxes, radio buttons.”? I thought it’s a good idea to mix free text input with traditional UI, like choice via buttons. Telegram bots use this approach. What’s wrong with it?

  7. Hi Matty!
    I enjoyed your article and I retweeted:
    https://twitter.com/solyarisoftware/status/705653875999510529

    In facts your article point out finally some good suggestions for what I call #dialogFlow
    In general I feel we are in a early stage of design dialogs interaction guidelines (#noGUI).

    About the “time out”; the point is opinable; I maybe believe that bot must manage user session, going back to the conversation status, let say by example: filling a shopping cart. input data Not necessarly are to be canceled, if user come back to the bot one day after initial chat. minor point.

    A #dev curiosity: do you use/suggest any specific dialog script language ?
    I’m asking because I’m looking for a smart / modern script language to describe dialogs.
    My hope is to have a common open-standard script dialogs to share dialog templates for common knowledge bases; a possible interesting open-source project; isn’it ?

    BTW, I’m just discovered http://www.superscriptjs.com and I feel .ss text scripts esy to read (also for #nodev people); otherwise: what do you think about AIML or teh IBM Watson XML way ?

    thanks
    respect
    giorgio

  9. @Giorgio: Some cases indeed make sense to keep a persistent state, and not time out. In other cases, the robot can look stupid when he sticks with something that was said a month ago and obviously (to humans) doesn’t make sense any more.

    About the dialog, I was going to point to Superscript as well, it looks like a solid choice (note that its developer was hired by Slack some time ago, so we can possibly expect some news there).
    Also interesting to see tools that were designed for story telling (like http://twinery.org/) that can be used to construct dialog branching, and we might see them combined with other bot frameworks in the near future.

  10. Hi Matty, thanks for your reply!

    If I well read, superscriptjs (http://superscriptjs.com/) come after his creator, Rob Ellis, analysis on preexistent “similar” tools:
    – AIML
    – facade
    – ChatScript (https://twitter.com/solyarisoftware/status/706042612793384960)
    – Riverscript (https://www.rivescript.com/)

    BTW, Here an interesting article (2011) by ChatScript creator Bruce Wilcox:
    http://www.gamasutra.com/view/feature/134675/beyond_façade_pattern_matching_.php

    In facts there is not a consolidated script language to describe natural language dialogs.

    Superscriptjs seems to me a modern/simple synthesis of previous work.
    Generally speaking I’m very interested finding a “common” language for “dialog scripting”.

    The parallelism is that these “scripts” for chatbots dialogs could be something equivalent to HTML code for nowaday front-end #webdev.

    In a future, #textUI/#dialogFlow #UX experts + application experts (!) could manage the dialog scripting, whereas back-end developers (with usual skills) could be continue to develop the back-end service (coding the script server engine, the database, usual stuff…).

    Isn’t it ?

    But, chosing a common language for dialogs (detached from “running code”), conatins a possible big adavantage: in general, dialogs do not contain just the front-end interface communication; scripts generally contain also a kind of knowlegde/expertise on a certain domain… so sharing scripts is also about sharing knowledge (see old fashioned expert systems).

    That make sense, for you ?

    BTW, if I’m not too indiscreet, @meekanWorld app have been “hard-coded” on some standard dev language or do you used some dialog script language ?

    I’m asking because I feel your Mekaan (as x.ai) are almost complex and a potentially them could benefit od a “script-oriented” approach,
    On the other hand, more simple apps as ecommerce, booking (I call them #transactionalBots) could benefit for a very fast&simple; #UX, maybe “hard-coded” in usual programming languages…

    Glad to know your opinion about it 🙂

    Regarding http://twinery.org/, interactive fictions, text adventures/text-based gaming,
    Yes I just discovered great “establihed” languages (but now pheraps a bit forgot) in realm of games; see:
    http://inform7.com/ and http://tads.org/
    I’m not an expert on these, and thenm seems to me excellent but just focused on gaming goals,
    instead, I’m looking for a generale purpose script language “solution” 🙂

    respect
    giorgio

  11. I couldn’t agree more. There is great value in separating the content and logic of the dialogue from the back end.
    When we started out, things were quite simple, but now that the robot it getting very complex, following the branching and decision-making process has become increasingly complex.
    When all the dialogue is moved into its own sub-system, it makes it very easy to tweak the robot’s behavior and voice (I mean choice of words, not actual voice). It also makes a lot of sense team-wise, as there are very different people writing the front end (which is almost like developing a character for a screenplay) and the back (which, like you say, remained pretty much the same)

  13. Conversational interfaces know what you are asking and respond. On your smartphone, you may already have the Google app installed, but it’s amazing how you can perform a search and then engage in a conversation. You can ask about the Panthers this Sunday, and then ask “who is the quarterback” and you will hear about Cam Newton. This is amazing because the app understands context. (It’s been doing that for a few years, actually.) And, it’s only going to improve.
    Honestly I am considering it and discussing it with my team in my website design bangkok company. I bet that something interesting will come out soon.
    Thank you for the post

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career