Conversational UI has begun to emerge and will eventually cannibalize many app experiences. As this transition progresses, conversational noise and spam, unfortunately, won’t lag far behind.
If we let that happen, the promise of conversational UI – more intimate, efficient and relevant engagement with users – could quickly get derailed by off-the-mark design choices. As designers and product managers, how can we avoid numbing users to conversational UI the way they’ve become numb to apps?
It all starts with texting. Texting is the ascii translation of spoken communication patterns…and not of prose writing (like email tends to be). Texting echoes voices back and forth, but with all the asynchronous, silent advantages we all know and love. Texting is at its best when you can almost “hear” your friend’s voice behind the words. So, what works best in conversational UI is a visual facilitation of this special type of flowing soundless voice communication. Here are 7 guidelines for designers to consider when weighing up what belongs in a thread and what doesn’t.
1. To converse is to be human
The basic structure of a face-to-face conversation is a natural back and forth: it has a cadence, etiquette, and lots of subtlety, not all of which can be captured digitally. There’s no emoji that replicates all of the nuance of facial expression or intonation we add to our spoken words. That’s why emojis and GIFs work well in messaging: they’re not words, but they’re part of the conversational flow and they’re part of tennis-like volley of meaning. Just as importantly, they don’t dominate the thread. The more we respect and reflect the natural conversational form, the more effective the conversational UI will be. So, regardless of what media, UI, or artificially generated words that go into a chat, the back and forth should ring true to life.
2. Use your words carefully
Elements like buttons for making choices or cards for displaying or collecting information may not seem like messages, but in conversational UI, they are and should be a continuation of the natural flow. How do you tell? I use a simple test by asking: “Can this bit of UI be posed succinctly in words?” lf the answer is yes, then I’ve got a good case for building a bit of threaded UI, but if not, then I should reconsider.
For example, if you want to collect an email from a friend, you could ask them, “Hey, can I get your email?” Equally, though, you could send over a small email collector that encapsulates the request. Questions like “Do you prefer red or blue?” or “What’s your phone number, can I send you a text?” work equally well in text and UI because they’re small chunks that are easily expressed.
For performing more complex tasks, though, like gathering data to complete a profile, neither a worded version or a UI version would work well in a chat thread: consider adding a profile screen.
3. Messages should fit on screen
Each discrete message in a thread, no matter whether it’s a simple text, card, photo or system message should be a complete unit and nestle in enough white space to keep the thread feeling like a thread. Facebook Messenger’s list results pattern for bots is cleverly presented horizontally in a set of swipe cards.
This isn’t the only pattern for presenting lists of things, but for photo browsing or shopping on mobile, it’s a good one. A tap takes you to an embedded web page. On the desktop, by contrast, the browsing experience is better served with a full blown window.
In either case, the results are contained, packaged, and presented with a compact message unit that sits nicely within the thread.
4. Conversations are transcripts
This may seem like an obvious one, but conversations are by definition a record of message after message after message, and strictly in that order. When you start to consider automated replies, bots, or other programmatic magic that could theoretically inject content anywhere, you can see why it’s important to stick to the transcript metaphor. For one thing, updating or changing part of the thread that’s in the past all but assures users will never see the change, so it’s a pointless exercise. But it’s not ethical either, unless you explicitly say you’ve done it e.g. Slack, for example, adds an “edited” notation when a message from the past is changed.
5. Messages are fossils
If conversations are transcripts, their atomic unit – messages – are ancient history and best left in the past. The rule of thumb for messages is that they should not be changed or edited if possible. You can’t go back and edit real conversations (even if we would sometimes like to!) and even in digital form most people don’t expect it so it’s unlikely they would notice or bother checking. Most consumer messengers simply don’t allow changes to sent messages. Business messengers which do, like Slack, add a note about the change so that it’s transparent.
6. No fakery: Keep the voices distinct
Nobody wants to be tricked into thinking a bot is a real person or confuse app updates with a friend’s genuine message. When the messenger presents anything in the thread, attribution should be crystal clear and even look different. This is how you create distinct but intertwining “voices” within a conversation without confusion. If everything looks the same, it makes it harder for users to pick apart who’s saying what.
7. Bots should be invited to the conversation
Bots should be triggered by a user action, or by a set of predetermined conditions. Once triggered, the very real problem for bots today is that they don’t work well enough for general purpose conversation. After they’re invoked, they need tight guardrails to function usefully and reliably, so structured replies for achieving a very focused purpose work best. For more about bots within conversational UI, have a look at my colleague Emmet’s post on principles of bot design.
Comments