2016 was the year of conversational design.
Everywhere we looked, conversational UIs were breaking out of messaging apps and into the products we use every day, from shoe shopping to cosmetics and everything in between.
Many of these were successful, but many others were not. Conversational UIs might mirror the way we naturally like to communicate, but they actually required more mental load than traditional GUIs. If you’re asking a user to engage in a conversation instead of tapping a button or two, are you really making things any easier? At times it felt like designers were blindly applying conversational UI to interaction design, problems that already have better, if less trendy, solutions.
At Intercom, we’re bullish on conversational interfaces, but as a hybrid model of interaction. When we built our live chat for sales solution recently, rather than relying on text alone, we incorporated conversational design along with one of the least fashionable interfaces – a form. In this post, I’ll go through the design considerations that led us to this hybrid interface.
Figure out the problem first and the interface second
Our live chat for sales tool is all about providing a personal, human selling experience to your website visitors. In order to do this, when someone lands on your website, your sales teams need to ask for some basic information through the messenger in order to understand who they’re talking to and how they can help.
Collecting this information manually is a mundane and repetitive task for a sales team, so we decided to build a new skill for our bot, Operator, which would automatically collect your user’s information through the messenger on your website. Herein lies the challenge: how can we automatically collect this information in the simplest possible way for the end user?
Exploration #1: Simple conversational UI ?
As Intercom is a messaging product, an obvious solution would be to rely solely on simple 1:1 conversational elements. Here’s how it worked:
Operator collects the visitor’s emails and asks a series of further questions in order to “qualify” them e.g “What is your name?”, “What is your job title?”
Visitor replies with their answers.
System parses the responses as data entry.
This approach has all the benefits that simple conversational interfaces have to offer. It is a familiar pattern for everyone who uses text messaging apps, it uses the fewest amount of UI components possible, and it keeps all the user input interaction in one place (the reply composer).
However, many test users brought a number of concerns to light. From the end users point of view:
They need to read each sentence from the bot and parse them individually.
There’s no obvious way to skip the questions if they aren’t willing to give their information.
It feels mandatory that they need to submit their information, instead of an optional path.
Overall, it feels like a spammy experience they can’t easily get out of.
From an implementation point of view:
To avoid some potential “dumb bot” experiences, it needs to correctly parse answers out of a conversational reply. For example, many people reply to “What is your name?” with “My name is X”. Is it really worth the effort to employ some degree of Natural Language Processing for a seemingly simple task?
Similarly, handling validation for some questions is unnecessarily complex. For example, if someone enters an invalid email, should the error messages be delivered by the bot as well? This would add a lot of transactional messages and thus pollute the conversation thread.
It introduced more work for our customers to set it up. They would need to manage how the questions are phrased and edit them for their own tone and voice.
Operator would need to acknowledge the user’s response through some form of language (e.g. “Thanks”, “Got it”). Again, this adds to the overall cognitive effort for people to parse.
After grappling with the pros and cons of a purely conversational design, we decided it wasn’t the best design direction for the problem we were trying to solve.
Exploration #2: Gathering information with forms ?
If simple chat-based conversational UI wasn’t right for the job, what about relying on a form for collecting visitors’ information?
An early exploration showing a form-based approach overlaid on the messenger
Now let’s be clear: nobody likes filling out clunky, complex forms. As arbitrators of checkout, registration, and data entry across the web, their design often falls short, leading to friction and abandonment. As a result, many have ditched forms entirely in favour of different UI models.
A better way to introduce the form.
Although asking users to complete a form isn’t the trendiest interaction model, the conversational forms we tested to collect information did feel more understandable, honest and efficient when compared to the previous direction. Most people are familiar with basic forms, and it requires minimal back and forth bot interaction as the success and error states can be handled within the form directly.
However, our initial explorations with the form didn’t quite work. The form was introduced by overlaying on top of the reply composer and felt quite intrusive. It temporarily blocked people from sending a reply, and it made the whole experience feel mandatory and impersonal, not what we were aiming for.
However, perhaps we could try to keep the form interaction for collecting information, but think about a better way to introduce the form.
Exploration #3: Delivering a form within conversation ?
Having explored two opposite directions, we experimented with a hybrid design between both of our previous approaches. We had Operator deliver a form within the conversation.
After trying out this approach with a simple prototype, we felt this direction struck the right balance:
It stays within the conversation thread and doesn’t majorly interrupt the user’s flow.
It clearly signals the interaction as being optional: people could ignore it and continue the conversation as they like.
It was much more efficient in terms of capturing information.
Consider a hybrid approach and use other interactive elements within the conversation
To validate our instincts, we undertook a round of user testing with a prototype that engineers put together in just a few days. Overall, it tested much better than the previous two approaches. All the participants understood the data collection pattern and had no issues interacting with it. They understood that the questions were asked in order to get a tailored response, and had no issues actually giving their basic information.
Better still, a few of them answered all the questions within just a few seconds. In contrast, this interaction would have taken significantly longer if it had been handled with simple, back-and-forward conversational UI.
Considering how well it performed during user testing, we shipped this conversational form as the baseline design to launch with. Some of the factors that led us to believe that this was the right solution for launch may change over time as the tech improves (e.g. Natural Language Processing is only still emerging). We’ll monitor and continue to evolve, and possibly iterate on it as we measure it post-launch.
It’s a mistake to believe a conversational design means every user input and output has to be handled in a purely chat format. Whenever it makes sense, it’s fine to consider a hybrid approach and use other interactive elements within the conversation (e.g. buttons, cards, forms) to help users complete their goals faster and with less friction.
As designers, we should avoid jumping on the bandwagon when the latest UI trend rolls round. Instead, we should focus on the problems in hand, fully explore possible solutions (old and new), and evaluate based on what’s best for the users, not based on our own design ego, or based on a post we read on Medium. Sometimes the best solution could be considered as “boring”, and that’s okay. Sometimes the most obvious and unfashionable design is actually the easiest for people to use.
Comments