A topic that comes up regularly on slack is how to best “design” for conversations. Our team has tackled lots of opportunities focused on conversation driven experiences — pitching and building a POC of a conversation driven car insurance buying application, a prototype integrating a tax ally into an existing tax product and spinning up a multitude of conversation-driven client demos. We’ve had success tackling some complex builds and learned some hard lessons from those opportunities that I often get asked to share.
I figured it was time to let everyone in on my secret — I hate chat-bots.
There. That’s it.
Obviously — there is more to it than that, but that is my personal key.
Cynicism helps to cut through the hype of the technology and gets our team focused on what matters — why should someone use this. Otherwise, we are building more digital disappointment and a guaranteed let down for users. That is the biggest challenge for conversational UI’s right now — making themselves useful and purpose driven. To be valuable, they need to be more than just an FAQ element plopped on a page or in an app that usually takes more of a user’s time to interact with than filling out forms or tweeting at a customer care rep.
Building these apps are not as simplistic as you may believe and the best practices are not a 1. 2. 3. type exercise — there are project-based best practices, and more specifically there are design best practices. Speaking to the prior, they are more ambiguous, but they have more impact on the whole. The project is less of a focus of implementing a chat UI and is a collaborative effort led by strategy, product management, technical experts and project leadership to help push towards making something that is useful that just happens to be a chatbot.
This is more than just semantic cutting of hairs — the process is closer to designing an agentive product than creating a dialogue flow.
That is where our team’s unique skillsets to weave together to do this, and that drives our success. We combine product management, creative strategy, design, front-end development, data science, linguistics, solution architects, and back-end developers to form teams that design these solutions collaboratively.
Conceptualizing usefulness
Chatbots need a value proposition — why should I used it. We suss this out using a few different techniques: using data, strategic research, persona creation or client supplied demographic information, and these are not mutually exclusive — the more you have, the better. Our individual engagements dictate the amount of information we have from the client and what we can discover ourselves. If a dialogue system already exists we can look at the conversation logs and analyze them for gaps, performance issues, and user frustrations. We can take those findings and combine them with strategy and our user’s needs to create an implementation with real value.
The first examples of this was a project for a car insurer. Our team was directed to “reimagine the car insurance buying scenario” with dialogue. We had access to chat logs from an existing product, and a client asks to reduce shopping cart abandonment. This guided our thinking, and we could break that into a clear mission for the project that served our AI hypothesis.
- Ask the minimum number of questions to get maximum info
Using micro-services calls to get additional content from a drivers license, vehicle information from VINS, and pre-populating info wherever possible, we can minimize our user’s effort to enter information and create a less arduous Q&A process for our users to get an insurance quote. - Make user inputs trigger UI & data states
Something that was discovered straight away from the chat data was the “focus” problem. The chatbot was boxed in a window and felt removed from the form the shoppers were filling out for their quote. When they got stuck or needed more help they asked the chatbot for clarification and more times than not, the user responded to the prompts with information that was meant to populate the form. By forcing a user to jump back and forth, the prior solution shifts their gaze and focus on the chat window. The existing system couldn’t do anything with the utterances because there was not an intent to match. - Give the user context
Handling something as complicated as car insurance requires us to support multiple drivers, multiple vehicles, various states — things can get messy. A user needs to know what vehicle or person the chatbot is asking about and needs to know when they digress or move onto the next topic.
A second example of this is a prototype for a tax company looking to create a tax ally to answer questions and guide users throughout the process. The approach is slightly different, but the end goal is very much the same — create a sticky and useful product for users. We did not have access to existing chat logs but did do a tremendous amount of work teaching Watson about their tax product, and our mission was to create a powerful ally for the user.
- Context is everything
Because completing your taxes is a very formulaic process we can use the specific steps the user is on to abstract information to narrow the responses to only relevant information specific to the current page the user is on. It also allows us to make a contextual suggestion about related topics. - Allow users to access knowledge on demand
We know the tax process can be extended — users need to refer back to the information they asked about later on during the tax process and have quick access to this information in real time. They can also see what Watson knows about them and the data it is using to make suggestions. The user can correct and edit the data at any time which will edit their information throughout the experience — removing duplication. - Suggesting — never doing
We enable form elements within the chat interface so Watson can gather data from the user and then take them to the relevant page within the tax form. Watson then pre-populate that data for the user. We minimize duplication of efforts and merely ask the user to confirm the info — do we have the right amount? Is the data correct? All they need to do is press confirm.
The last thing that applies to all these examples is to fail gracefully. Design a way to seamlessly pass to a human if the chat agent can’t solve the problem. Devise a system to leverage Natural Language Understanding to extrapolate the context of the failure and suggest answers the chat agent knows that are related. Schedule a call back with a human that fits on their schedule to solve their issues. We have to design pivots for these systems to perform when they don’t know something.
AI can’t know what it doesn’t know so this is an absolute when creating experiences — they will get stumped.
These are just a few examples of best practices for tackling a conversationally powered experience — not explicitly to design them but combining all these practices to create a more powerful integration. Best practices for the visual design of chatbots are much more straightforward.
Designing conversations
The chat interface UI is very defined thanks to our years of conversational familiarity with text messaging, messaging apps and the foundations of the social web — but there are some fundamental principles we can apply when working within the confines of the interface and some general design best practices to think about. Most of these are basic guidelines but can help reinforce some of the concepts above and also places clarity and focus on the UI.
Responsive content
A foundational practice whenever you design for mobile also applies to space restricted content like a chatbot within a browser window. Long content needs to be solved differently. We break lengthy responses over multiple chat bubbles to reduce the eye strain on the user and make the content more digestible as they scroll. The same idea can be applied to visualizations and solid material — views should be digestible and offer a glance — the user can investigate areas they find of interest. Similar to designing a snippet view of a blog post or an article — these ideas can be applied to long-form documents returned by an chat agent.
Clarity of voice
I always place emphasis on the responses coming from the chat agent and not the user — users know what they type and say — their input should absolutely be displayed — but it should never be the hero or the focus. The responses out of the system should carry with highest visual clarity and density on the screen — these are the insights we are delivering to our users and should be clear, easily scan-able and take the focus.
Hierarchy, structure, and grids
I often see chat agents in production, and there are very little structure and a lack of the absolute basics of visual design. Consistent use of grids will give your design a foundation in production and also provide more clarity to the information you are presenting to the user. Use typography to thread consistency through various rich UI elements and to give a sense of hierarchy — what is the most critical piece of info — what’s second? Guide your user where to look and focus first — then present aesthetically strong information they can digest quickly.
Motion and function
This is a biggie — we can use movement to convey directional focus and context — where do your chat bubbles originate from, how do they flow when a thought is broken over two responses — these details present tremendous amount information with very little work. Let your chats flow elegantly — have responses push older content and tertiary information up the chat scroll so the user can focus on the least amount of info in one glance. Use typing indicators to let the users know the AI is still writing or is processing information. These small nuances can increase legibility and improve interaction gracefully.
Stay motivated
These are just a handful of chat UI specific guides designers can use, and these are merely a glimpse at some of the care and considerations we need to apply when designing experiences in general. And none of these are gospel — just lessons I’ve personally adopted over the course of 2 years begrudgingly designing chatbots. Just because we are building something that is not the most rewarding or fantastic design project — doesn’t mean we throw all the work we are good at out the window.
Get over yourself — put in the effort and design the hell out of it.
That is a bitter pill I’ve learned to swallow — but that motivates us to build better products and still make things we are proud of from a design standpoint.
I can’t take credit for all the amazing work that has gone into the examples above — those are collaborative efforts with the data scientists, front and back-end developers, architects, and leadership on my team. They still tolerate me to this day.
Rob Harrigan is a Watson Prototypes Design Lead at IBM based in Astor Place. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
