How to approach conversation design: Getting started with Amazon Lex (Part 2)

AWS Feed
How to approach conversation design: Getting started with Amazon Lex (Part 2)

As you plan your new Amazon Lex application, the following conversation design best practices can help your team succeed in creating a great customer experience. In our previous post, we discussed how to create the foundation for good conversation design. We explored the business value of good conversational design and provided some tips on building a team. We also talked about the importance of identifying use cases to create an informed foundation for your conversational interfaces. Throughout our series, we emphasize the importance of keeping the customer at the focus of your design process—this will improve the customer experience.

In this post, with our foundation established, we review high-level design best practices and how to use them when designing your conversational interfaces. First, we discuss individual steps of the design process, and offer tips on gathering requirements and thinking about the differences between voice and text design. Then we cover individual steps in the design process, including creating sample dialogs, writing prompts, handling errors, and documenting the AI experience. These steps help focus the design of your project and streamline time to production. Throughout, we use examples from retail banking. You can also create your own bot using our self-paced Amazon Lex Workshop.

Gather all requirements before designing

A great design process starts with no design. Take the time to get all the key stakeholders in the same room to discuss your use cases. This includes the customer experience (CX) team and the business or product owner, in addition to developers, subject-matter experts, customer service representatives (CSRs), and contact center supervisors. You need people with varying viewpoints of the business and customer needs. Together, you can gather all the requirements to make your customers successful. A diverse group of stakeholders ensures that you have a variety of perspectives on the future design.

Prepare for the meeting by thinking through a number of questions for your team. Consider both the “happy path” (how the customer can go through the system relatively friction-free) and any places the customer might encounter problems. For example, if your application will process payments, discuss what happens if the customer wants to make that payment outside of the available date window. To verify customer identity, discuss the various ways they can do that (for example, date of birth, personal identification numbers, ZIP code or postal code), and when or if to transfer them to a human agent if they fail.

With that said, you want to create an ideal customer experience for the majority of your customers. The remaining customers may have unique requirements best served by human agents. If you try to design for every customer need, your system will become unmanageable.

With a clear understanding of the overall experience before you start designing, you can reduce time to production, with fewer revisions. It also saves development resource hours, which can save money on your project.

Design for voice and text

Before you design, you need to know how your customers will interact with the application. Will they be speaking, typing, or both? Designing for voice and text have different challenges.

Let’s think about presenting information in voice first. Voice design must occur in a sequential order, because customers can’t skip around between pieces of information or skim what they’re hearing. This sequencing means that the words customers hear must occur in an order that is logical to the customer. Additionally, providing the customer with too much information all at once could result in cognitive overload—giving the customer so much information that they can’t remember everything.

A text interface, alternatively, lets customers take their time to read or skim, and they can skip around as they take in the information. But cognitive overload can happen in text as well. You don’t want your system delivering extra-long prompts. The length of one message shouldn’t exceed the amount of space visible to customers without scrolling. Using multiple text bubbles or message groups can help with this, but don’t overuse them. If the application sends several messages all at once and the customer still has to scroll, it degrades the customer experience.

In terms of recognition, voice and text have different paths. For voice, the system first uses an automated speech recognition (ASR) system to transcribe the speech to text. Next, the text is provided to the natural language understanding (NLU). In a text-based system, the typed words go directly to the NLU. The extra step for voice can involve more difficulties, but you can account for these in the design (see the later section on handling errors).

You can consider using a single application for both voice and text. Keep in mind that customers may need to receive the information in different presentation styles. For example, a list format in a text window doesn’t read well in voice. A paragraph of payment summary details is understandable in voice, but may make finding the important details difficult in text. You can use session attributes to have Amazon Lex provide the correct prompt to the customer. This allows you to have the same macro structure of the interaction flow while targeting voice and text customers separately.

Create sample dialogs and review to ensure alignment

With all the requirements gathered and a decision on the interaction type, it’s time to write. From your use cases—the tasks your customers can accomplish in your application—you can create sample dialogs. These dialogs help you and your stakeholders better understand how customers will interact with the application. Use the requirements you gathered earlier to create multiple scenarios. Your dialogs should include at least one happy path per use case and other exchanges that are more error-prone. However, these aren’t meant to be exhaustive documentation of every possible flow or error scenario. These are high-level snapshots into various customer exchanges. After you’re written these samples, take them back to your stakeholders. Again, it’s ideal to meet with everyone who was involved in the requirements gathering. If you can’t get everyone, be sure to invite the primary CX stakeholders and have the full list of requirements for reference.

The following is sample dialog for a customer changing their direct debit account.

Reviewing the dialogs at this early phase has two benefits. First, you can confirm that you have understood and captured all of the requirements. It’s important to verify this before doing most of the design construction. Second, you have a variety of perspectives reviewing your work. Take this time to workshop difficult ideas and improve the design.

After you have sign-off from the business on the sample dialogs, you should ensure that your prompts will elicit the responses that you’re expecting. Clear, concise, and unambiguous prompts may be the most important step in creating a natural-sounding and intuitive conversational interface.

Write prompts conversationally

The first draft of your sample dialogs doesn’t need to have finalized wording. This is a starting point. All good writing goes through multiple drafts, so have a working session—or multiple sessions—on prompt wording. Keep the audience limited to your primary CX stakeholders. These sessions shouldn’t only focus on the words the customer will see or hear, but also on how the customer may respond.

The first and most important goal is to avoid ambiguity. Ambiguity can arise in many forms, like “Do you want to continue, cancel, or start over?” This question doesn’t seem like it’s ambiguous. In voice, the customer could hear, “Do you want to continue…” and reply, “Yes” before the bot finishes. If the application isn’t expecting “Yes” as a response, this can lead to issues. Ultimately, the goal is to focus on being clear and thinking through how a customer could respond.

Second, provide customers with information as concisely as possible. When identifying a customer, you may want to let them know they’ve been successful. You have choices. Your application can be verbose: “Thank you. We have matched that information to the information on record in your account.” Your application can be terse: “Thanks.” Or the response can be some length between the two examples. You need to choose what makes the most sense for your brand and your application’s personality. However, long, clunky responses to short answers are part of the reason why AI interfaces sound mechanical and not conversational. While we don’t want to mask the fact that the customer is interacting with AI, it can still be conversationally.

Third, provide customers with only the information they need to know. For example, a customer calls, and the application doesn’t recognize the customer’s phone number. We don’t need to tell the customer, “I don’t recognize the number you’re calling from.” The customer likely knows that the number doesn’t match. If customers are identified by their phone number, you can ask, “What’s the phone number on your account?” This interaction implicitly acknowledges that the system didn’t match the phone number while attempting to gather the necessary information.

Additionally, the wording should sound like a natural conversational exchange and not like a piece of formal writing. It’s okay to use phrasing that doesn’t follow strict grammar rules. For example, in natural, native US English, people regularly split infinitives (“to not go”), end sentences with prepositions (“Who’s that going to?”), and start sentences with conjunctions (“And where do you think you’re going?”). Use contractions (“can’t“), even contractions that aren’t technically correct grammar (for example, “what’re” for “what are” in voice), unless this contradicts your brand attributes and your system personality. Even if unacceptable in traditional writing, using common speech patterns makes the application sound more natural and conversational in any language or dialect.

Finally, be flexible. After you have your wording in draft form, say it out loud—even if your application is text-based. Does it sound natural? If your team is using an Amazon Polly voice, sign in to the Amazon Polly console and test the prompts. If it doesn’t sound natural, you can update the wording. You can also modify the speed, style, and other attributes using SSML markup. Going through this practice may lead to wording changes. If you need the legal department to review the wording, test your wording before you submit it for approval. That way, you won’t need to ask legal for approval twice.

For additional tips, see our posts on writing great prompts for built-in slots and custom slots.

Handle errors

What happens when your customer starts describing their dog’s latest toy to your banking bot? What happens when your customer wants to pay less than the minimum amount due?

You need to account for these scenarios when possible. The first example involves customer input that doesn’t correlate to a defined intent. These phrases can be treated as a “no match,” that is, a phrase that the application’s NLU isn’t trained on. With Amazon Lex, you can use the built-in fallback intent. The fallback intent gives your customer a second try to provide their intent. You want to write prompts for the fallback intent that guide your customers toward providing responses that your application can handle.

Error scenarios beyond no matches may take more consideration. You likely already know some situations where your customers will fail. To account for these scenarios, consider the following:

• Where the customer can fail
• What help the application can provide to help the customer be successful
• How to ensure that the customer doesn’t get caught in an endless help-loop

For a minimum payment amount, what wording will you use if the customer offers a lower amount? How many tries will you let the customer have before removing them from the flow? And then will you transfer those customers, disconnect them, or take them back to a main menu? These are all examples of questions you need to ask.

With all error messaging, you want to ensure that the application wording aligns with your brand and the application’s personality. If you don’t, customers will notice, and they can find these experiences jarring.

Well-crafted error handling improves customer experience. It helps increase caller containment and decrease call abandonment. And although the term “error handling” implies difficulties, it should be viewed as helping the customer. Ultimately, you want to improve your customer’s experience, and customers need flows that help them through difficult points.

Document and manage content

Now, you’ve created your sample dialogs, determined your error scenarios, and gotten approval. It’s time for the rest of the documentation.

First, create a flow diagram. This is a more detailed view of the interaction paths for your customer. The flow should include all happy paths in addition to specific error handling scenarios. You can optionally include some or all application wording for the interactions, or you can label the shapes in the flow to relate to corresponding documentation.

The following is a flow diagram of a payment confirmation.

You also want to have a list of all the prompts. Set this up as a key-value pair (here, the key is the prompt label and the value is the wording). You want multiple versions of the prompts for the dynamic reprompting discussed previously. Your label for these prompts should indicate which version of the prompt should be used for each attempt.

If you need outside approval—for example, from copywriting or legal—for some or all of the prompt wording in the application, now is the time to have that conversation. At this point, your application flows are documented, your development team is hard at work, and going back to change the wording won’t significantly impact development time.

Finally, make sure that your documents include a change log. This is a section or a page that documents the changes that were made and how they’re marked in the document. The log can include who made the changes, the date the new document was released, prose description of the changes, possibly internal hyperlinks to those changes, and any highlighting or coloring used to show the changes. If you have multiple people working on a document at the same time, make sure that you have a way to maintain version control, so there’s no chance to overwrite someone else’s changes.

Conclusion

As you design your conversational AI application, keep these aspects of conversational design in mind. With these best practices, you’ll be better equipped to design your application in an efficient way that delights your customers. You’ll be able to streamline your development cycle to achieve faster launch times. And you’ll have the entire experience well documented for reference and updates as your application changes over time.

In the final post in our series, we discuss how to take the foundational elements from our first two posts and translate it into Amazon Lex. We specifically discuss the interaction model, and prototyping, testing, and tuning your application.

We at AWS Professional Services and our extensive AWS Partner Network are available to help you and your team through the process. Whether you only need 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

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.

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.