Build Design Systems With Penpot Components
Penpot's new component system for building scalable design systems, emphasizing designer-developer collaboration.

medium bookmark / Raindrop.io |
2016 was the year of the conversational interface.
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 UI along with one of the least fashionable interfaces – a form. In this post, I’ll go through the design considerations that led us to the towards this hybrid interface.
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?
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:
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:
From an implementation point of view:
After grappling with the pros and cons of a purely conversational interface, we decided it wasn’t the best design direction for the problem we were trying to solve.
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.
Although asking users to complete a form isn’t the trendiest interaction model, the 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.
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 out with a simple prototype, we felt this direction struck the right balance:
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 take 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 “form within a conversation” 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 interface 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 most obvious and unfashionable design is actually the easiest for people to use.
If this sounds like a project you’d like to work on, we’re hiring designers right now.
Further reading:
Principles of bot design
Bots vs humans
AI-driven updates, curated by humans and hand-edited for the Prototypr community