How to approach conversation design: The basics (Part 1)

Conversational interfaces have the potential to allow customers to interact more naturally with automated systems. From virtual assistants to concierge chatbots, conversational interfaces can bring convenience and personalization to customers at scale. However, these benefits depend not only on the technology that the Amazon Lex platform and other AWS services can provide, but also on establishing good conversation design as a foundation.

Conversation design is the discipline of defining the purpose, experience, and interactions of a conversational interface before it’s built. Whether you’re a product owner, design leader, or a developer, it can be beneficial to understand the design process and challenges that are unique to conversational AI. This post discusses the value of incorporating design into your process, along with concrete steps and concepts through code.

The business value of conversation design

What does it mean to have design as the foundation? It may be tempting to start building a conversational application by diving into technical challenges, or going straight into Amazon Lex. However, this tech-first approach may fall short on experience when placed in front of customers. Similar design principles apply to the success of a conversational application, as they would apply to the success of any software application. When customer needs, features, and interactions are considered first, the desired customer experience is clearly defined. This foundation results in a better customer experience and reduces duplication of effort when it comes to building—in other words, measure twice and cut once.

Introducing conversational design practices into projects requires an upfront investment in resources and time. However, the benefits can include a positive impact on customer experience, clearly defined business needs, and boosting the bottom line.

When presenting an internal business case for making these early investments, consider the following:

Placing an emphasis on design allows for upfront planning and can mitigate the potential duplication of development efforts later.
Creating a shared understanding for the product or use case through design documentation allows all stakeholders to agree on the proposed outcomes.
Presenting design assets to users early on, from sample dialogs to flow diagrams and even prototypes, allows for testing and iteration before a line of code is ever written.
Envisioning an ideal future state, and the steps to get there, provides an opportunity to identify the desired outcome. You can create a backlog of features that are unconstrained by the realities of an initial Minimum Viable Product (MVP).

Identify use cases

Today, conversational interfaces are common in a variety of self-service scenarios, such as banking, healthcare, and commerce. However, the interface design may vary depending on your business.

Typically, the most successful interactions with a bot are short, simple, and intuitive. These actions tend to follow a predictable and repetitive pattern—for instance, collecting information to look up an account. Once you’re comfortable with simple interactions, there’s always room to get creative and push the boundaries. It’s important to consider the limitations of conversational AI as well. Complicated requests that require quite a bit of interpretation may not be as strong of a use case for an automated conversational interface.

With a basic understanding of successful types of applications, identifying your use case starts with understanding the pain points and needs of your customer. Your customer may be the person who buys your goods and services, or could be your employees who depend on internal services to get their job done.

Let’s imagine a banking institution that has noticed its customers remain on hold for long periods of time to speak to an agent. This is a pain point that could result in poor customer experience and loss of business.

As a customer, I may want to speak with someone who can help me request a new statement, report a lost card, or transfer money to another account. This may inspire a feature to automatically route the customer call to the right customer service representative. Or it may inspire features designed to fully automate the more repetitive and simple requests.

These objectives can be referred to as user stories. A user story is a short sentence that expresses a user objective and a need that the objective is satisfying. User stories define your customer’s goals, and why they’re important. It can follow the pattern “As a [User Type], I want to [Objective], so that I can [Need].” As a bank customer, I want to verify myself so that I can get my account balance. As a customer service representative, I want to know the context of the call before they’re transferred to me so that I can be prepared to address their concern. This may inspire a feature that presents a service representative with the information a customer has shared with a voice assistant, so that the customer doesn’t need to repeat themselves.

After you’ve created an exhaustive list of user stories, the use cases that you want to support can be prioritized in terms of importance. The most highly prioritized can then move into design for further exploration.

Build a team

Many capabilities are required to launch a conversational AI application. Depending on the scale of a project, these capabilities may be found among a very small team, or may require much more specialization. Although many individuals may possess a range of talents that straddle disciplines, we discuss team needs in terms of perspective and contribution to an application.

To simplify it greatly, we can think of roughly four perspectives of contributors to a conversational AI project:

Business – Owners or business leads typically define project requirements, with the help of the rest of the team. They are the stakeholders whose approval is most crucial when deliverables are presented in order to move the project forward.
Management – Product and project managers, whose primary interest is in tracking business requirements, also keep the project under budget and on pace with schedules. This may also include managing operators who are responsible for ensuring ongoing compliance with security and privacy.
Developer – The developer or technical team is responsible for implementing and deploying designs in a way that satisfies the various stakeholder requirements that have been agreed upon. The technical team may also be required to implement analytics for tracking performance. In addition, a QA team needs to ensure that the implementation meets the design standards.
Design – The designer’s responsibility is to understand the requirements provided by the business stakeholders, and interpret those requirements to envision the end user experience. Designers create a series of artifacts that clearly document what will be built for both stakeholder alignment and as a source of truth for developers to work against.

The capabilities needed in a designer may be found in a multi-talented person, or may require a team with members who have specific strengths in the areas most critical to a given project. Whether the scale of your project supports a single designer or a team, there’s no single background that prepares a designer to be great at conversation design. An interdisciplinary background that touches upon two or more of these areas can be very valuable.

The following are some of the specific tasks of conversation design, which may require more specialized roles on larger projects:

Design thinking at the beginning of a project when requirements aren’t clear and alignment on use cases is necessary.
User research, to obtain and analyze input from a small audience that is representative of the actual end users to help inform the direction of the application.
Script or copywriting, to write the perfect language. For example, for a bot, considering the nuances of prompt-writing while staying on brand.
User experience design must account for impact, both positive and negative, that all design choices have on the experience of the user.

Other resources that may be useful depending on the scope of a project include:

Visual design may be required in cases where a there is a visual component to a conversational AI application, for instance everything from response cards and buttons to an avatar and interface styling, can enhance the experience of a web chat.
Sound design may be required for ear cons, sonic logos, or other audio cues that make the conversational AI experience come to life. In our banking bot example, an ear con could be used as affirmation that account details were registered, or to signify to the customer that they’re being transferred to a representative.
Bot personality creation can require translation of brand identity into a series of guidelines, or potentially the development of a character.

Craft a system personality

The personality of a conversational application is the combination of characteristics that sets up a foundation for things like tone of voice or terminology used by the bot. The personality is intended to help set expectations for the user. For example, formal language might be chosen to establish a sense of trust in a financial or medical-focused application. Similarly, motivational language might be chosen for an application intended to help with coaching or education. On the other hand, casual language or slang may be chosen for an application where the exchange is low risk. It’s important to note that a system personality isn’t intended to confuse users into thinking they’re interacting with a human.

Going back to our banking example, one way of approaching the personality is to reference branding guidelines with application purpose. For instance, Example Bank’s branding guidelines include characteristics like empowering, trustworthy, established, and reliable. The purpose of the conversational application the bank would like to build is to assist with banking activities and provide financial advice, convenience, and personalization.

By combining these, we set the characteristics that help define the conversational style while subtly reiterating to users what the application can be used for.

Consider the difference between these two lines:

“Hi, thank you for calling account services. We appreciate your business. In a few words, what can I help you with today?”

“Hey friend, thanks for calling. What do you need?”

The second is friendly and includes a similar prompt but may not evoke the trust that a bank requires. However, more casual language is appropriate for a retail customer service bot. Empathy is well-suited for a bot in the healthcare domain.

Conclusion

In this post, we discussed how to identify use cases for conversational AI, and touched upon crafting system personalities. The next post in this series provides tactical guidance on designing a conversational AI application from scratch. We use our banking example to review each of the following steps in the conversation design process while creating the appropriate design documentation along the way:

Scripting happy paths
Diagramming flows
Dialog repair
Defining an interaction model
Prototyping
Testing

We at AWS Professional Services and our extensive AWS Partner Network are available to help you and your team through the process. Whether you’re only in need of consultation and advice, or need full access to a designer, our goal is to help you achieve the best conversational interface for you and your customers.

For more information on Amazon Lex and getting started with AWS for conversational interface experiences, check out our Amazon Lex resources.

About the Authors

Claire Mitchell is a Design Strategy Lead with the AWS Professional Services AWS Professional Services Emerging Technologies Intelligence Practice—Solutions team. Occasionally she spends time exploring speculative design practices, textiles, and playing the drums.

Rosie Connolly is a Conversation Designer with the AWS Professional Services Natural Language AI team. A linguist by training, she has worked with language in some form for over 15 years. When she’s not working with customers, she enjoys running, reading, and dreaming of her future on American Ninja Warrior.

Nancy Clarke is a Conversation Designer with the AWS Professional Services Natural Language AI team. When she’s not at her desk, you’ll find her gardening, hiking, or re-reading the Lord of the Rings for the billionth time.