Editor’s Note: We recently launched a new training course called Cake Time: Build an Engaging Alexa Skill. The course is a self-paced, skill-building course that offers guidance on how to build a high-quality skill from start to finish. In this 4-part blog series, we’re going to dive deep into the coding modules within the course.
Editor’s Note: We have changed the name of the Alexa skill in our beginner tutorial from Cake Walk to Cake Time given the term’s racially insensitive history.
Great voice design is the foundation for an engaging Alexa skill, which is why it is the starting point for the Cake Time course. Before we dive into design, I want you to take a moment and ask yourself the following: “Who leads the interaction between customers and an Alexa skill? Alexa or the Customer?”
Design is an important part of building voice-first user interfaces. Unlike screen-based experiences, a major part of designing the experience is mimicking a human conversational partner. Even simple skills can benefit from a well-thought out design. Before you write one line of code, you should work really hard to think through how your customers will interact with your skill. At the very least, your skill should be:useful, simple and sticky. Useful skills provide value to customers. Simple skills surprise and delight customers. By simple, I mean simple to interact with; no one likes calling a customer service phone tree. Sticky skills retain customer interest and inspire them to keep coming back. As you can see, your customer is a major part of the design. Customers interact with your skill through conversation. So, you should always start from the conversation and work back to a solution.
When my colleagues and I came together to bake the Cake Time sample skill (pun intended) for our course, we started with a simple idea and moved immediately into thinking about how we’d converse with the skill. We let the conversation drive the design and the features we would need to implement. We made sure the interaction was simple and that the experience would inspire our customer to keep coming back for more. We started with our happy path, which represents the simplest interaction our customer would have with our skill. Once we finished the design, we wrote a definition that defined the skill. Here’s what we ended up with:
Cake Time is a skill that celebrates your birthday! Tell it your birthday to have it count down the days. Interact with the skill on your special day to hear a happy birthday message.
The skill is useful, simple to use, and sticky. It gives the user a reason keep checking in and using the skill day after day. We also thought about how we could monetize the skill. Once our customer shares their date of birth with the skill, we’ll know their astrological sign, so we can offer a daily horoscope for a monthly subscription. For the rest of this post, we’ll focus on how we designed the core voice experience for Cake Time.
To help guide our conversation-focused design process, we’ve thrown away flow charts. We’ve started with situational design, which is a framework for designing voice-first experiences.
Situational design is a voice-first method to design a voice user interface. You start with a simple dialog that helps keep the focus of your skill on the conversation. Each interaction between your customer and the skill represents a turn. Each turn has a situation that represents the context. If it’s the customer’s first time interacting with the skill, there is a set of data that is yet unknown. If the customer is in the middle of playing a game, the situation is “game in progress.” The situation affects how the skill will respond to the customer. For example, a shopping skill with an empty shopping cart shouldn’t offer to let the customer check out. Likewise if the customer asks to checkout with an empty cart, the skill’s response should indicate that their cart is empty and assist them with shopping.
Now it’s time to revisit the question I asked at the beginning of this post. Who leads the interaction between customers and an Alexa skill? Alexa or the Customer? If you said Alexa, you’re incorrect. From the start of the interaction, your customer leads the conversation. They call out to your skill and it responds based upon the context (or the situation).
Take a look at the script below. Our customer started the conversation and our skill responded. We’ve drawn a blue box around each call and response that represents a turn in the interaction. We’ve also drawn a red box around the situation.
Once you’ve converted your happy path into cards, you can start trying to break your happy path by testing out unexpected utterances. For each unexpected utterance you can create a new card to handle it. This approach is much better than a flow chart because you’re focused on the dialog and not on arrows.
Now that we have a basic understanding of how situational design works, let’s identify our scenarios for Cake Time and walk through the storyboards that represent them. My colleagues and I identified three main scenarios:
Let’s take a deep dive into the storyboards we created for each scenario.
The first time the customer opens the skill, their birthday is unknown. Our skill needs to ask our customer when they were born. Since we started with the happy path, we assumed our customer provided the month, day, and year they were born in their response. We identified that we would need to save this information somewhere otherwise we’d have to ask them every time they opened the skill. We also wanted to indicate that we understood the user, so we used an implicit confirmation by repeating back their birthday. The storyboard below represents our happy path.
We’ve accounted for our happy path, and now we need to think about how things could differ. Our customer could just say, “November seventh” leaving out the year. We identified that we need a new card. Our situation is month: known, day: known, year: unknown. Before we create our new card, we’re also going to make some updates to our second card. We have incomplete information and we need to follow up with a question. So instead of using an implicit confirmation, we’ll change our response to give some context to the question we’re about to ask. So we’ll say, “I was born in two thousand fifteen.” This will be our prompt. Our question will be, “What year were you born?” Our new card will represent the customer telling us the year. Now that we know the month, day and year, we can respond with our implicit confirmation.
To support an unexpected utterance, all we had to do was add a new card and shift our implicit confirmation over to the new one. We can also create storyboard to represent the case where our customer only told us just the month. The situation would month: known, day: unknown, year: unknown. In this case we can reuse our card that asks for the year, and add a new card that asks for the day and insert in between the month and day. By now you can see that is so much more flexible than a flow chart.
Our customer could also say, “Today!”, or “Next tuesday!”, but we decided to leave that up to you to figure out how to solve. Hint: You can use the Amazon.Date slot type.
Now that we have storyboards that can handle collecting our customer’s birthday, let’s take a look at how the skill responds when it’s not their birthday.
When we know our customer’s birthday and they open the skill on any day but their birthday, we need to count down the number of days until their next. In this case we only have one turn, one card.
When our customer opens the skill on their birthday, we need to wish them happy birthday. In this case we will only have one turn, one card.
Our skill already supports changing our customer’s birthday. Our customer can say, “Alexa, tell Cake Time I was born July 12, 1981.” and the skill will update their birthday. This is known as a one-shot since it will go straight to our CaptureBirthdayIntent. Some customers may not be aware of how to use a one-shot so, we should think about how to modify the skill so that customers can modify their birthday once the skill has been opened. That’s a challenge I’ll leave to you.
Thanks to situational design, we have created a useful, simple, and sticky skill. We can now start building our skill. We’re going to build it over a series of blog posts, which will allow us to zoom in on specific concepts throughout the skill-building process. We’ll start with creating a simple interaction that just greets the user and says, “Hello welcome to Cake Time. That was a piece of cake. Bye!”
If you want to start building right away, you can follow the steps below:
Situational design is a great way to keep yourself focused on the conversations that your customers have with your skill. The process is more adaptive than a flow chart. It helped us build a solid representation of our skill and we were able to identify some holes in the experience. To get started with situational design, think about a skill that you want to build or one that you built in the past. Start with your happy path and turn each turn into cards then take those cards and combine them into a storyboard. Then try to break your happy path with unexpected utterances. Create a new card for each unexpected utterance. This will help you identify holes, necessary features and technology that you may have missed during your initial planning.
Let’s keep in touch. If you have any skill ideas or questions about situational design please reach out to me on twitter @SleepyDeveloper.