{"id":1023,"date":"2021-10-13T08:35:21","date_gmt":"2021-10-13T08:35:21","guid":{"rendered":"https:\/\/salarydistribution.com\/machine-learning\/2021\/10\/13\/how-to-approach-conversation-design-getting-started-with-amazon-lex-part-2\/"},"modified":"2021-10-13T08:35:21","modified_gmt":"2021-10-13T08:35:21","slug":"how-to-approach-conversation-design-getting-started-with-amazon-lex-part-2","status":"publish","type":"post","link":"https:\/\/salarydistribution.com\/machine-learning\/2021\/10\/13\/how-to-approach-conversation-design-getting-started-with-amazon-lex-part-2\/","title":{"rendered":"How to approach conversation design: Getting started with Amazon Lex (Part 2)"},"content":{"rendered":"
\n

\"\"<\/a><\/p>\n

As you plan your new Amazon Lex<\/a> application, the following conversation design best practices can help your team succeed in creating a great customer experience. In our previous post<\/a>, 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\u2014this will improve the customer experience.<\/p>\n

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<\/a>.<\/p>\n

Gather all requirements before designing<\/h2>\n

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.<\/p>\n

Prepare for the meeting by thinking through a number of questions for your team. Consider both the \u201chappy path\u201d (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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Design for voice and text<\/h2>\n

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.<\/p>\n

Let\u2019s think about presenting information in voice first. Voice design must occur in a sequential order, because customers can\u2019t skip around between pieces of information or skim what they\u2019re 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\u2014giving the customer so much information that they can\u2019t remember everything.<\/p>\n

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\u2019t want your system delivering extra-long prompts. The length of one message shouldn\u2019t exceed the amount of space visible to customers without scrolling. Using multiple text bubbles or message groups can help with this, but don\u2019t overuse them. If the application sends several messages all at once and the customer still has to scroll, it degrades the customer experience.<\/p>\n

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).<\/p>\n

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\u2019t 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<\/a> 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.<\/p>\n

Create sample dialogs and review to ensure alignment<\/h2>\n

With all the requirements gathered and a decision on the interaction type, it\u2019s time to write. From your use cases\u2014the tasks your customers can accomplish in your application\u2014you 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\u2019t meant to be exhaustive documentation of every possible flow or error scenario. These are high-level snapshots into various customer exchanges. After you\u2019re written these samples, take them back to your stakeholders. Again, it\u2019s ideal to meet with everyone who was involved in the requirements gathering. If you can\u2019t get everyone, be sure to invite the primary CX stakeholders and have the full list of requirements for reference.<\/p>\n

The following is sample dialog for a customer changing their direct debit account.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Turn<\/span><\/td>\nParticipant<\/span><\/td>\nDialog<\/span><\/td>\nNotes<\/span><\/td>\n<\/tr>\n
1<\/td>\nAmazon Lex<\/td>\nThanks for contacting Your Favorite Loan Company. What can I help you with today?<\/td>\n<\/tr>\n
1<\/td>\nCustomer<\/td>\nI wanna set up a recurring payment.<\/td>\n<\/tr>\n
2<\/td>\nAmazon Lex<\/td>\nYour current balance is [$200.00]. That includes an overdue balance of [$100.00]. A payment of [$200.00] is due on October 15th. To set up a recurring payment, you\u2019ll need the routing number and the account number. Do you have that information ready?<\/td>\n<\/tr>\n
2<\/td>\nCustomer<\/td>\nNo<\/td>\n<\/tr>\n
3<\/td>\nAmazon Lex<\/td>\nOkay. I can wait. Let me know when you have the information.<\/td>\n<\/tr>\n
3<\/td>\nCustomer<\/td>\n\u2026
I\u2019m ready.<\/td>\n<\/tr>\n
4<\/td>\nAmazon Lex<\/td>\nTo start, what\u2019s the 9-digit routing number?<\/td>\n<\/tr>\n
4<\/td>\nCustomer<\/td>\n999-999-999<\/td>\nVerify against checksum list<\/td>\n<\/tr>\n
5<\/td>\nAmazon Lex<\/td>\nAnd what\u2019s the account number?<\/td>\n<\/tr>\n
5<\/td>\nCustomer<\/td>\n1234 567 890<\/td>\n<\/tr>\n
\u2026<\/td>\n\u2026<\/td>\n\u2026<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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\u2019s 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.<\/p>\n

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

Write prompts conversationally<\/h2>\n

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

The first and most important goal is to avoid ambiguity. Ambiguity can arise in many forms, like \u201cDo you want to continue, cancel, or start over?\u201d This question doesn\u2019t seem like it\u2019s ambiguous. In voice, the customer could hear, \u201cDo you want to continue\u2026\u201d and reply, \u201cYes\u201d before the bot finishes. If the application isn\u2019t expecting \u201cYes\u201d 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.<\/p>\n

Second, provide customers with information as concisely as possible. When identifying a customer, you may want to let them know they\u2019ve been successful. You have choices. Your application can be verbose: \u201cThank you. We have matched that information to the information on record in your account.\u201d Your application can be terse: \u201cThanks.\u201d 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\u2019s personality. However, long, clunky responses to short answers are part of the reason why AI interfaces sound mechanical and not conversational. While we don\u2019t want to mask the fact that the customer is interacting with AI, it can still be conversationally.<\/p>\n

Third, provide customers with only the information they need to know. For example, a customer calls, and the application doesn\u2019t recognize the customer\u2019s phone number. We don\u2019t need to tell the customer, \u201cI don\u2019t recognize the number you\u2019re calling from.\u201d The customer likely knows that the number doesn\u2019t match. If customers are identified by their phone number, you can ask, \u201cWhat\u2019s the phone number on your account?\u201d This interaction implicitly acknowledges that the system didn\u2019t match the phone number while attempting to gather the necessary information.<\/p>\n

Additionally, the wording should sound like a natural conversational exchange and not like a piece of formal writing. It\u2019s okay to use phrasing that doesn\u2019t follow strict grammar rules. For example, in natural, native US English, people regularly split infinitives (\u201cto not go\u201d), end sentences with prepositions (\u201cWho\u2019s that going to?\u201d), and start sentences with conjunctions (\u201cAnd where do you think you\u2019re going?\u201d). Use contractions (\u201ccan\u2019t\u201c), even contractions that aren\u2019t technically correct grammar (for example, \u201cwhat\u2019re\u201d for \u201cwhat are\u201d in voice), unless this contradicts your brand attributes and your system personality<\/a>. Even if unacceptable in traditional writing, using common speech patterns makes the application sound more natural and conversational in any language or dialect.<\/p>\n

Finally, be flexible. After you have your wording in draft form, say it out loud\u2014even if your application is text-based. Does it sound natural? If your team is using an Amazon Polly<\/a> voice, sign in to the Amazon Polly console and test the prompts. If it doesn\u2019t sound natural, you can update the wording. You can also modify the speed, style, and other attributes using SSML markup<\/a>. 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\u2019t need to ask legal for approval twice.<\/p>\n

For additional tips, see our posts on writing great prompts for built-in slots<\/a> and custom slots<\/a>.<\/p>\n

Handle errors<\/h2>\n

What happens when your customer starts describing their dog\u2019s latest toy to your banking bot? What happens when your customer wants to pay less than the minimum amount due?<\/p>\n

You need to account for these scenarios when possible. The first example involves customer input that doesn\u2019t correlate to a defined intent. These phrases can be treated as a \u201cno match,\u201d that is, a phrase that the application\u2019s NLU isn\u2019t trained on. With Amazon Lex, you can use the built-in fallback intent<\/a>. 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.<\/p>\n

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:<\/p>\n