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.
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.
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.
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.
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.
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.
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.
This article was originally published on Medium.
The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions. The POC above represents self-initiated, non-commercial work.