How to Apply a Design Sprint to Voice-Based Products

BY MIKE EDMONDS ON FEBRUARY 1, 2018

At the outset of 2018, there are already over 50 million voice-based devices shipped, up from 1.7 million in 2015 (see footnote). Consumer adoption of voice-based products has grown to the point where businesses need to understand what voice-based experiences can mean to them. But, as I’m sure we’re all aware, exploring new business models such as voice-based products and experiences doesn’t always come naturally to big companies.

I believe the answer is to use a test-and-learn approach to create a minimum lovable product (MLP) product – or the version of a new product a business can launch to create customer love with the least amount of effort and expense.

The test-and-learn approach my colleagues at Moonshot and I use is an adaptation of the Design Sprint. The Design Sprint can help companies overcome the “How do I get started?” challenge by offering a test-and-learn approach that minimizes risk.

Context

Google Ventures has popularized the use of the Design Sprint to reduce the risk of developing new products. (In fact, Jake Knapp of Google Ventures wrote the book on the topic.) With Design Sprints, development teams create and test product prototypes within a five-day time frame, as outlined by Google Ventures:

  1. Monday: identify a problem to solve and pick an important place to focus.
  2. Tuesday: create competing solutions to the problem.
  3. Wednesday: decide on the best idea to turn into a testable hypothesis.
  4. Thursday: build a realistic prototype.
  5. Friday: test the prototype with target customers.

Teams typically use Design Sprints as part of a broader methodology known as Design Thinking, a process for solving complex, open-ended problems that don’t have a “right” answer. Through Design Thinking, businesses identify the right problem to solve by gaining empathy for the target user, create and consider many options, converge and refine on selected directions, and validate the concepts through prototype testing. The accelerated nature of a Design Sprint in the context of Design Thinking gives teams a disciplined way to make go/no go decisions on nascent product ideas without requiring costly and time-consuming testing.

Design Sprints for Voice

To help readers understand how to apply the design sprint to a voice-based product, I have come up with a hypothetical example of an omnichannel apparel retailer that is launching a new loyalty program. For the purposes of discussion, let’s say the retailer wants to examine what role, if any, voice products could play in supporting the journey of a loyalty customer. For example, how might we introduce voice to support the experience of enrolling in a loyalty program or redeeming loyalty rewards?

Now let’s say the retailer has tasked a product team to figure out an answer. As a product manager leading a Design Sprint, understand that the team might be apprehensive because they have pigeonholed themselves according to their roles – they might bring the “But I’m not a designer” mentality into the process. You might need to do some educating before the launch of the Design Sprint to set expectations and disabuse team members that Design Sprints are just for designers.

The team must also be well-versed in the company’s strategy, product development goals, and its customers’ wants and needs. If not, the team should be willing to do some homework under the leadership of the team leader.

Thus prepared, the team is ready to jump into the Design Sprint.

Day 1: Identify a Problem

The purpose of Day 1 is to identify a problem you want to solve, which you do through customer empathy-based research. At this point, someone on the team has a deep understanding of the customer journey and represents the customer to keep the team properly centered. In our case, we are exploring the role that voice could play in the loyalty program experience.

The input for Day 1 is a thorough understanding of your customer’s journey and pain points you are trying to solve with the loyalty program, based on customer research that identifies the opportunities for improving customer experience.

Day 1 workshop activities would range from creating a list of Sprint questions to visualizing the customer journey in a single map.

Day 1 Workshop Activities

  • Set long-term goals
  • Create a list of Sprint questions
  • Visualize the customer journey in a simple map
  • Generate “how we might” (HMW) notes
  • Organize HMWs into themes
  • Note and vote on HMWs
  • Attach HMWs to the map
  • Identify the target for the design sprint

Throughout the day, the team will have developed a simple journey map that identifies the actions of a customer participating in a loyalty program and the retailer’s actions at each touchpoint. The map is not created with voice in mind, though. Once the map is created, the team identifies various pain points which are reframed as “how might we” statements. For example, if the team surfaces a pain point that customers have with remembering their reward balance, an example might be, “HMW explore the role that voice could play in helping a customer find their reward balance?” The team sets the focus for the rest of the Sprint by identifying where the prioritized HMWs address specific moments on the map.

The outcome of Day 1 is a goal that’s solvable and testable. For voice-based products, the goal is often referred to as the “intent” – the job you’re looking for the voice-based product to solve. With the goal of “checking the balance of loyalty points” defined, the team has now set the focus for the Design Sprint.

Before convening for the day, the team assigns itself homework for Day 2 to find some experiences and products that might inspire customer love.

Day 2: Create Competing Solutions to the Problem

On Day 2, the team sketches ideas for addressing the HMWs in the customer journey that they agreed on Day 1, such as helping a customer look up the balance of their reward points. Team members work on their own for this sketching exercise. In our loyalty program example, sketches might explore the role that voice assistants could play in driving awareness into the loyalty program (for example, “Alexa, ask <retailer skill> my rewards balance.”) Sketches might also address how to make enrolment in the loyalty program as frictionless as possible by exploring the role that voice could play at point-of-sale, or, to continue the example from Day 1, how voice helps the user inquire about their rewards balance.

Day 2 Workshop Activities

  • Lightning demos
  • Divide or swarm to decide how to assign the problem among the team
  • Sketch process (notes, ideas, crazy 8s, solution sketching)

The output of the sketching process will look more like a comic book narrative, highlighting when and where a voice experience could bring utility and delight to the customer journey. The idea of a comic book narrative shows how a voice-based Design Sprint differs from one that does not involve voice. Many Design Sprints at this point consist of rough wireframes based on, say, a screen-based or app interface. But with a voice-based experience, the team needs to depict a dialogue that a customer is having with the voice assistant, and the depiction needs to flesh out the environmental elements that inform the interaction, such as whether the customer is at home or in a car. Details like the specific conversational dialogue are not important at this step.

Day 3: Decide on the Best Idea to Turn into a Testable Hypothesis

On Day 3, the team converges to review individual sketches. The team then decides which solution has the best chance of succeeding and creates a storyboard for an actual product prototype. The storyboard is really a step-by-step plan to build the prototype.

Day 3 Workshop Activities

  • Art museum and heat map
  • Speed critique
  • Straw poll and super vote
  • Create the storyboard opening scene
  • Fill out the storyboard

The storyboard fleshes out the key elements of the conversational dialogue our retailer might have with a customer while the customer interacts with a voice assistant in context of a loyalty program. At this stage, the team gets down to the level of detail of depicting specific words that a conversation might entail (invocations and utterances). The team needs to account for all the ways a person might ask about their points balance and how the voice assistant might respond. Likewise, the team needs to take into account the tone of the responses (what role should humor play in the dialogue, if any?) The interface needs to be designed for the ear, not the eye. The ear is more comfortable processing simpler sentences, whereas the eye can accommodate compound-complex phrases more easily.

Day 4: Build a Realistic Prototype

On Day 4, the team mocks up a prototype – not the actual product, but a rough prototype that emulates the functionality of the voice-based product that the team storyboarded on Day 3.

Day 4 Workshop Activities

  • Select prototype tool/method
  • Divide and conquer roles
  • Create prototype
  • Stitch it together
  • Trial run
  • Fix mistakes. Run again

On Day 4, the team will get more granular, choosing, for instance, a specific voice-based platform such as Alexa, Assistant, or Siri. The prototype itself may be very rough or more polished depending on the problem being addressed and available tools to flesh out the storyboard. If the voice-based prototype is very simple and straightforward, there’s the chance the engineer on the team might code a simple skill on an Alexa device (for example). Alternatively, the team could record hypothetical customer voice commands using text-to-speech tools such as Amazon Polly. Alternatively, two people on a team could simply arm themselves with walkie-talkies and test responses to different customer’s commands, being careful to be in separate rooms to best emulate a true voice-based experience.

Day 4 will set up the team to test the prototype with customers on Day 5.

Day 5: Test the Prototype with Customers

On Day 5 you test how lovable your prototype is by involving real customers. Brace yourself: your customers might reject your prototype.  But remember, the point of a design sprint is to test and learn in an efficient way that reduces risk. And failure is part of learning.

Day 5 Workshop Activities

  • Interview prep
  • Conduct interviews (1-5)
  • Debrief

The input for Day 5 consists of customers that the company has recruited. The design team will have explained that a prototype (not a finished) product is being tested and that the customer’s input is essential to help the team to make a go/no go decision with the prototype. The actual test with the customer will likely consist of a role-playing exercise in which the customer tests the functionality for which the team decided to create a product on Day 1.

Here, the team needs to be watchful for both visual and auditory clues. A customer might sound comfortable with the interface but their body language might reveal discomfort, especially if the voice interface is too complex or the tone of the voice is not right. The team also tests for issues such as whether the conversation flowed as expected and how the customer reacts to the voice you’ve chosen for your assistant. You can also watch for how a person multitasks when they’re talking with a voice assistant. Since the customer is having a dialogue with a voice assistant, they are freed up to use their screens while they are talking. How does multitasking affect their attention span and complexity of the phrasing they use?

After the Design Sprint

The output of the five-day Sprint is a design that informs the creation of an actual minimum lovable product, or the initial version of the product that creates the most customer love with the least amount of effort and expense. At this point, the team may go in one of three directions for your prototype:

  • Take the idea forward (persevere).
  • Revise the idea (pivot).
  • Kill the idea (perish).

Your team may very well uncover ideas that, while not useful for the problem you decided to solve, are potentially applicable elsewhere. In this instance the product team would share its learnings with other areas of the organization to assess applicability.

The beauty of the Design Sprint process is its structure. Whether you’re exploring the potential of emerging technologies on a customer’s journey with a loyalty program or how to redesign the homepage of a website to drive sign-ups, the activities on each day remain the same. What’s different in our voice-based products example are the outcomes of each day. As a product team it’s important to understand the nuances of how the Design Sprint process can be applied in a variety of scenarios to drive different outcomes.

The alternative to a process such as the Design Sprint is flying blind. And the stakes are just too high for a business to guess. Innovation comes from a purpose-built process.


We used the following sources to arrive at the 50 million plus number of voice-based products already shipped:

We assume that about 50% of the annual sales occur in the fourth quarter, using Forrester figures that would place cumulative Amazon Echo sales at approximately 24 million today and climb to 35 million by year end.

We took this 35 million estimate and combined it with a calculated eight million Google Home devices sold every second since Oct 19 2017.

Strategy Analytics estimates that 24 million smart speakers were shipped globally in 2017. That reflects 300% growth over estimated 2016 shipments of six million units. The report also estimates that slightly more than 12 million smarts speakers were sold in the first three quarters of 2017 and another 12 million will be sold in Q4 alone. So if we just take this estimate of 12 million smart speakers sold in 2017 through Q3, and use the % for Google at 23.8% = 2.8 million, that brings our running total to about 46 million. Then all other players just need to have about 3-4 million shipped to get to our 50 million, which runs pretty close to the estimate provided by eMarketing of around 5.6% of the market going to players beyond Amazon and Google.

About MIKE EDMONDS

Mike is the Co-Founder of Moonshot by Pactera Digital, a global services company that designs around the intersection of customer behaviors, emotions, and emerging technologies to bring customers and businesses closer together. Mike leads a team of digital product managers helping brands use design thinking and lean innovation to discover, design, and deliver experiences that are lovable, valuable, and feasible. Mike has over 13 years’ experience working with B2C and B2B organizations on a global scale, in the US, China, and Europe, across a range of industry verticals including retail, CPG, high tech, automotive, logistics, foodservice distribution, petroleum distribution, quick serve restaurants, gaming & betting, and government agencies. Mike is also an Adjunct Professor of Digital Product Management at DePaul's School of Computing and Digital Media.

Get the best product content from across the web

Sign up for our free weekly newsletter with a lovingly curated selection of the best product content from all over the web.

28 Shares
Share
Tweet
Share