Editor's Note: What if you’re tasked with prototyping a potential skill idea and you only have five business days to get it done? I’ve asked Alex Baxevanis, Experience Director at Webcredible, to share how he and his team have designed a sprint structure that condenses the prototyping phase of a skill down to a five-day process. While there is no “correct” process to prototype, hopefully the below will help focus your efforts next time you want to validate a new voice idea.

Designing for a new technology can always bring a load of exciting ideas, alongside many questions and unknowns. Many people have asked us where to start with designing an Alexa skill, and we think we’ve found a great method that anyone can use to design a voice experience, from ideation to validation.

You’ve probably heard of the “design sprint” method popularized by venture capital firm GV. A design sprint is a time-boxed, five-day process aimed at refining an idea and increasing its chance of success when it hits the market. It felt like just the right fit for exploring voice interactions. Whether you’re a skill-building hobbyist, a professional developer, or part of a seasoned development team, this process should help you structure your prototyping phase and consider the various steps involved.

Here’s an overview of the voice design sprint and how we’ve used it to help clients design a new skill idea.

Day 1: Understand and Ideate

The first day of a voice design sprint starts by making sure that the team you’re working with, whether that’s a team within your own company or a group of people you’ve brought together for a brainstorm, understands how voice services like Alexa work in practice. Bring Alexa-enabled devices for participants to play with and get familiar with Alexa skills that would be relevant to the experience you're trying to build.

During our workshops with clients, we’ll also hear from subject matter experts on the customer journey, and the information and interactions that they could deliver through voice.

Where possible, we’ll always look for examples where people are already interacting with a brand through voice. This includes listening in to customer service calls, or shadowing staff as they talk to customers. For example, when we worked with Virgin Trains team on their Alexa skill, we went to train stations to hear first-hand (and note down) how exactly customers were wording their questions, and how Virgin Trains staff were responding.

We close the day by writing out as many ideas as possible, inspired both by the possibilities of voice and our learnings from customers. At this stage, we don’t set any restrictions. All we ask is that participants note down for each idea:

• Who their user might be (e.g. a train traveler)
• What voice could offer (e.g. purchasing tickets)
• In what context might people use voice (e.g. at home)
• What the final outcome or benefit for the customer is (e.g. catching a last-minute train)

Day 2: Narrow Down the Idea and Start Mapping

Armed with an initial set of ideas, the second day is focused on whittling down the list to those that might best work for voice. We’ve developed a checklist based on our experience and working with the Alexa team. We get all sprint participants to go through the checklist and see how their ideas fare. In some cases, it’s a clear “yes” or “no.” In others it’s a “maybe,” which means we should definitely test our assumptions when we prototype.

The team gets to vote and collectively agree on one or two ideas to pursue. Then we get to work, writing down scripts and mapping the flows of completing a task through voice. To get people used to the format, we usually present a couple of ready-made examples for interactions that everyone can imagine, such as buying cinema tickets, or a food recommendation service like The Foodie below.

Before long, we get an idea for how simple or complex each use case can be, and how the ideal scenario might differ from an edge case. For example, in the case of a food recommendation skill, how will the experience differ if users ask for something that the skill supports (e.g. filtering by dietary constraints), versus something not supported (e.g. getting the calorie count by person).

However, words on paper never give an accurate view of how the same words might sound while spoken aloud. With that in mind, as soon as people have completed their first scenario we get them to “role play” it. One person plays the role of the user and the other pretends to be “Alexa,” taking turns to read out aloud their part of the script.

When people hear themselves saying what they’ve written down, they quickly understand what sounds like a real-life conversation and what sounds unnatural. They then spend the rest of the day iterating on their script and role-playing it again, until it sounds engaging and conversational.

Day 3: Prototype the Voice Experience

With a few scenarios mapped out, it’s then time to scale up and build a working prototype of the ideas we’re exploring.

Whilst it’s certainly possible to continue testing and iterating by role-playing alone, we’ve always learnt even more by trying our ideas on a real Alexa-enabled device. For example, we get a feeling for how what to do when something isn’t recognized, and how our answers sound when read in the voice used by Alexa (is it too fast, too slow or is something harder to understand when read out by a synthetic voice?).

Fortunately, there are now many prototyping tools that make it really easy to turn an idea into a working Alexa skill, without doing any coding, including services like Voice Apps and Voiceflow. Whenever you’re prototyping, make sure to keep the situational design guidelines in mind.

Again, we walk the sprint team through a working prototype so that they can get a glimpse of the tool’s capabilities before they get going. Be wary of just using flow charts when prototyping for voice as conversations don’t always flow as smoothly as you anticipate. This is where situational design comes in handy. Watch this recording from the Alexa team for a primer on situational design.

We’ve found that even for complete beginners, one day is enough to learn how Voice Apps or Voiceflow work and create a testable prototype of one or more flows. It helps if people work in parallel, with one person creating the skill in the tool and others supporting by collecting sample data to use in the prototype and thinking of all the possible synonyms and sample utterances that users might want to say.

Toward the end of the day, the team also creates a discussion guide, listing all the questions and scenarios to be used when testing the idea with real customers. 

Day 4: User Testing

We dedicate the fourth day of the sprint to getting our idea in front of real customers. This means people who haven’t been involved in the development of the prototype, but could use our idea in real life.

Before we even start with the sprint, we’ll have recruited and lined up around six people for that day. We may not know exactly what we’ll show them, but we can at least find people with some affinity to the domain we’re exploring. For example, if we’re prototyping voice interactions around buying cinema tickets, we’ll recruit a number of regular cinema-goers with a variety of film preferences.

We also make sure everyone we recruit has used voice technology, like an Echo device, before so we spend the time testing our idea, not bringing them up to speed with how the service works.

On the user testing day, we’ll bring people into a usability testing lab (or similar quiet room) and ask them to try out interacting with our prototype Alexa skill on a real device. We’re experts at running usability testing on a variety of platforms, but we’ve noticed that when testing with voice we had to slightly adapt our approach. For example:

• Whilst people can try a lot of things on a prototype of a website or app, voice interactions tend to be quite short. We schedule shorter sessions or we use the extra time to probe more into how participants use voice services in real life.
• Whilst we normally ask people to “think aloud” and explain what they’re doing while they use a website or app, they obviously can’t do the same while also talking to a voice service. We get them to tell us how the experience felt once they’ve finished a conversation.
• When testing a website, if a participant feels lost or clicks on the “wrong” button, we can easily intervene and put them back on track. It’s almost impossible for a moderator to intervene and take over a conversation with voice service. If we see people repeatedly fail at something, we’ll give them a hint on what to say.

We take lots of notes and record all the sessions (with participants’ permission), so we get a clear record of how easy or hard to use our prototypes were.

Day 5: Analyze and Plan Next Steps

We start the final day by going through all our notes, reflecting on what puzzled participants, and what they said that our prototype skill couldn’t handle. We’ll go through our notes and recordings and pick out the exact words and phrases that people used. Where possible, we use our findings to get the prototype to understand more real-life scenarios and give clearer responses.

We then make a roadmap for future work required to properly build the skill and bring the voice experience to life. We’ll discuss, for example, what APIs are needed to get live data integrated and how we might keep testing it with customers to ensure we stay on the right track.

Finally, we have a go at sketching a “landing page” for our skill, showing how we’d promote it to customers. As there’s no way to “screenshot” a voice interaction, we think carefully about how we can best sell the idea, both internally and to customers browsing the Alexa Skills Store.

There you have it! We’ve gone from zero to a validated Alexa skill idea in just five days. Contact me to learn more about the voice design sprint. To learn more about designing for voice, check out the Alexa Design Guide.

Related Content

• Blog Series: 10 Things Every Alexa Skill Should Do
• Guide: How to Shift from Screen-First to Voice-First Design
• Guide: How to Design a Voice User Interface
• Guide: Tried-and-Tested Skill-Building Tips from Top Alexa Developers
• Situational Design: Build Adaptable Voice-First Interactions
• Situational Design: Individualize Your Entire Interaction
• Situational Design: Make Your Voice-First Interactions Accessible
• Situational Design: Talk with Your Customers, Not at Them