All Talk and No Buttons: The Conversational UI

We’re witnessing an explosion of applications that no longer have a graphical user interface (GUI). They’ve actually been around for a while, but they’ve only recently started spreading into the mainstream. They are called bots, virtual assistants, invisible apps. They can run on Slack, WeChat, Facebook Messenger, plain SMS, or Amazon Echo. They can be entirely driven by artificial intelligence, or there can be a human behind the curtain.

My own first encounter with a conversational interface was back in 1983. I was just a kid, and I went with some friends to see WarGames. Young hacker David Lightman (played by Matthew Broderick) dials every phone number in Sunnyvale, California, until he accidentally bumps into a military supercomputer designed to simulate World War III.

We immediately realize that this computer is operating at a different level: it engages in conversation with Lightman, asks him how he feels, and offers to play some games. No specific commands to type—you just talk to this computer, and it gets you, and responds to you.

Fast-forward 30 years. My teammates and I at Meekan set out to build a new tool for scheduling meetings. We thought, “It’s 2014! Why aren’t calendars working for us?” We wanted simply to be able to tell our calendar, “I need to meet Jan for coffee sometime next week,” and let the calendar worry about finding and booking the best possible time and place.

First we sketched out a web page; then we built an Android app, then an iOS app, and finally an Outlook add-in. Each one was different from the next; each attacked the problem from a different angle. And, well, none of them was really very good.

After building user interfaces for more than 15 years, for the first time I felt that the interface was seriously limiting what I was trying to do. Almost no one understood what we were attempting, and when they did, it seemed to be more difficult to do it our way than the old-school way. We could go on and crank out more and more versions, but it was time for a different approach. The range of possible actions, the innumerable ways users can describe what they need—it was just too big to depict with a set of buttons and controls. The interface was limiting us. We needed something with no interface. You could tell it about your meeting with Jan, and it would make it happen.

And then it dawned on us: we’re going to build a robot!

I’m going to tell you all about it, but before I do, know this. If you’re a designer or developer, you’ll need to adjust your thinking a bit. Some of the most common GUI patterns and flows will not work anymore; others will appear slightly different. According to Oxford University, robots will replace almost half of the jobs in the US over the next 20 years, so someone is going to have to build these machines (I’m looking at you) and make sure we can communicate properly with them. I hope that sharing some of the hurdles we already jumped over will help create a smoother transition for other designers. After all, a lot about design is telling a good story, and building a robot is an even purer version of that.

Photoshop? Where we’re going, we don’t need Photoshop#section2

Think about it. You now have almost no control over the appearance of your application. You can’t pick a layout or style, can’t change the typography. You’re usually hitching a ride on someone else’s platform, so you have to respect their rules.

And it gets worse! What if your platform is voice-controlled? It doesn’t even have a visual side; your entire interface has to be perceived with the ears, not the eyes. On top of that, you could be competing for the same space with other conversations happening around you on the same channel.

It’s not an easy situation, and you’re going to have to talk your way out of it: all of your features need to be reachable solely through words—so picking the right thing to say, and the tone of your dialogue with the user, is crucial. It’s now your only way to convey what your application does, and how it does it. Web standards mandate a separation of content and style. But here, the whole style side gets thrown out the window. Your content is your style now. Stripped of your Photoshop skills, you’ll need to reach down to the essence of the story you’re telling.

And developers? Rejoice! Your work is going to be pure logic. If you’re the type of developer who hates fiddling with CSS, this might be the happiest day of your life.

The first tool in your new toolbox is a text editor for writing the robot’s script and behavior. When things get more complicated, you can use tools like Twine to figure out the twists and turns. Tools and libraries for coding and scaling bots are cropping up by the dozens as we speak—things like Wit.ai for handling language understanding, Beep Boop for hosting, and Botkit for integrating with the popular Slack platform. (As I write this, there is still no all-encompassing tool to handle the entire process from beginning to end. Sounds like the voice of opportunity to me.)

But, let me say it again. The entire field of visual interface design—everything we know about placing controls, handling mouse and touch interaction, even picking colors—will be affected by the switch to conversational form, or will go away altogether. Store that in your brain’s temp folder for a little while, then take a deep breath. Let’s move on.

First impression: introduce yourself, and suggest a next step#section3

Imagine a new user just installed your iOS app and has launched it for the first time. The home screen appears. It’s probably rather empty, but it already has some familiar controls on it: an options menu, a settings button, a big button for starting something new. It’s like a fruit stand. Everything is laid out in front of you: we got melons, we got some nice apples, take your pick.

Compared to that, your first encounter with a robot is more like a confession booth. You depend on the voice from the other side of the door to confirm that you’re not alone, and guide you toward what to do next.

Your first contact with the user should be to introduce yourself. Remember, you’re in a chat. You only get one or two lines, so keep it short and to the point. We’ll talk more about this in a second, but remember that having no visible interface means one of two things to users:

• This thing can do whatever I ask him, so I’m going to ask him to make me a sandwich.
• I have no idea what I’m supposed to do now, so I’m just going to freeze and stare at the screen.

When we did our first tests, our users did just that. They would either just stare, or type something like “Take me to the moon, Meekan.”

We were upset. “Why aren’t you asking him to schedule stuff for you, user?”

“Really? He can do that?”

It’s not obvious. So use introductions to define some expectations about the new robot’s role on the team. Don’t be afraid to glorify his mission, either. This robot handles your calendar! That way, users will be less disappointed when they find out he doesn’t make sandwiches.

Immediately follow this intro with a call to action. Avoid the deer-in-headlights part by suggesting something the user can try right now.

Try to find something with a short path to victory. Your users just type this one thing, and they immediately get a magical treasure in return. After this, they will never want to return to their old life, where they had to do things without a robot, and they’ll surely want to use the robot again and again! And tell all their friends about it! (And…there you go, you just covered retention and virality in one go. It’s probably not going to be that easy, but I hope you get my point about first impressions.)

Revealing more features#section4

When designing GUIs, we often talk about discoverability. If you want the user to know your app is capable of doing something, you just slap it on the screen somewhere. So if I’m new to Twitter, and I see a tweet for the first time, my options are set in front of me like so:

Easy. I’ll just hover my mouse over these little icons. Some of them (like stars or hearts) are pretty obvious, others might require some more investigation, but I know they’re there. I look around the screen, I see my Notifications link, and it has a little red number there. I guess I received some notifications while I was away!

But when talking to a robot, you’re just staring into a void. It’s the robot’s job to seize every opportunity to suggest the next step and highlight less-familiar features.

• Upon introduction: as we mentioned earlier, use your first contact with users to suggest a task they could ask the robot to perform.
• Upon receiving your first command: start with a verbose description of what’s happening and what the robot is doing to accomplish his mission. Suggest the next possible steps and/or explain how to get help (e.g., link to a FAQ page or a whole manual).
• Now gradually remove the training wheels. Once the first interactions are successful, the robot can be less verbose and more efficient.
• Unlock more achievements: as the relationship progresses, keep revealing more options and advanced tips. Try to base them on the user’s action history. There’s no point explaining something they just did a few moments ago.

• Proactively suggest things to do. For example, users know the robot reminds them about meetings, but don’t know the robot can also order food:

If the robot is initiating conversation, make sure he gives relevant, useful suggestions. Otherwise, you’re just spamming. And of course, always make it easy for users to opt out.

Cheat whenever you can#section5

It’s easy to assume our robot is operating inside a pure messaging or voice platform, but increasingly this is not the case: Amazon Echo is controlled by voice, but has a companion app. WeChat and Kik have built-in browsers. HipChat allows custom cards and a sidebar iframe. Facebook and Telegram have selection menus. Slackbot inserts deep links into messages (and I suspect this technology will soon be more widely available).

With all the advantages of a conversational interface, some tasks (like multiple selections, document browsing, and map search) are better performed with a pointing device and buttons to click. There’s no need to insist on a purely conversational interface if your platform gives you a more diverse toolbox. When the flow you present to your user gets narrowed down to a specific action, a simple button can work better than typing a whole line of text.

These capabilities are changing rapidly, so be prepared to adapt quickly.

And now, we ride#section6

As users become more familiar with chat robots, they will form expectations about how these things should work and behave. (By the way, you may have noticed that I’m referring to my robot as a “he”. We deliberately assigned a gender to our robot to make it seem more human, easier to relate to. But making our assistant robot male also allowed our team to subvert the common stereotype of giving female names to robots in support roles.)

The definitive book about conversational design has yet to be written. We’ll see best practices for designing conversations form and break and form again. This is our chance as designers to influence what our relationship to these machines will look like. We shape our tools and thereafter they shape us.

In the next part of this article, we’ll dive deeper into basic GUI patterns and discuss the best way to replicate them in conversational form.