Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Maximizing The Design Sprint

Following a summer of Wonder Woman, Spiderman, and other superhero blockbusters, it’s natural to fantasize about having a superpower of your own. Luckily for designers, innovators, and customer-centric thinkers, a design sprint1 allows you to see into the future to learn in just five days what customers think about your finished product.

As a UX consultant and in-house design strategist, I have facilitated dozens upon dozens of design workshops (ranging from rapid prototyping sessions to, of course, sprints). The sprint is by far the most effective process I’ve seen to drive customer-first decision making in a design thinky way.

What Is A Sprint? Link

Because ‘sprint’ is used to refer to a variety of processes, I’ve given a brief description of a few different types of sprints to clarify:

  • Development sprint: a set period of time for software development work and review. (This is not what I’m writing about.)
  • (Regular) design sprint: set period of time for the design team to create functional designs ahead of the development sprint. (This is still not what I’m writing about, but check out a previous Smashing article, Getting Started with Design Sprints.2)
  • (Google) design sprints: a 5-day process to understand if an idea maps to a customer need or opportunity without having to launch a minimal product. (Finally, this is what I’m writing about.)
Learn from meaningful customer feedback without having to build and launch a product. (Image: Google Ventures4)

Now that we are all on the same page about different kinds of sprints, let’s take a look at an example:

Recently, I participated in a sprint that had the big goal to use our pre-built kit to build an app (coincidentally) in five days or less. Given that this process normally takes months, we assumed the faster, the better, right? We wanted to make sure this assumption was correct and sprinted this idea.

We more or less followed the process suggested on the Google Venture’s website5. If you are completely unfamiliar with the design sprint, here’s a handy 90 second intro.

(We are aware that there’s a call to action to buy the book at the end of this video, but if you are not at all familiar with the design sprint, it will provide you with a quick introduction. We are not in any way affiliated with Google Ventures nor are trying to promote the book.)

This is what our process looked like:

  1. Monday, we set our goals, targets, and learning about potential users from customer experts.
  2. Tuesday consisted of drawing from inspirations and sketching a solution.
  3. Wednesday involved choosing a winning sketch and turning it into a storyboard.
  4. Thursday, we prototyped.
  5. Friday, we tested the prototype with customers.
Example of a winning sprint sketch that was turned into a storyboard and prototype.
Example of a winning sprint sketch that was turned into a storyboard and prototype. (Large preview7)

By Friday, our prototype reflected the flow of a customer learning about our kit, viewing examples of the types of apps they could build, and launching their own app in a short span of time. We thought we did a great job, as the prototype illustrated our main value propositions:

  • The features that would be available through our kit.
  • The speed with which they could have a fully functional app of their own using our kit.

However, we tested our prototype with customers and learned that our value proposition didn’t really resonate. While it would be great to have speedy deployment, our kit did not allow for the level of customization developers required to meet the needs of their own customers.

Was it a waste of time? Of course, not. If we hadn’t explored and validated the idea with a design sprint, can you imagine the time and effort that would have gone into implementing the wrong thing? Avoiding wrong turns is the superpower of the sprint.

This superpower allows us to make major decisions and sidestep business paralysis. But with so much to pack into so little time, every minute — from prep to during to after — is critical. I’ll share what I’ve learned to maximize the sprint experience and help us flex our new superpower.

  • Before the sprint: setting yourself up for success.
  • During the sprint: maximizing your sprint week.
  • After the sprint: how to keep the momentum.

Before The Sprint: Setting Yourself Up For Success Link

Successful sprints start with good preparation. First, know that it’s a lot of logistical work. Even with the Sprint book’s explicit guidance, securing the right space, time, and people is a big undertaking, so give yourself 3 weeks. Consider a schedule that looks something like this:

  • Week 1: Confirm the sprint with stakeholders and send out an email getting people to book travel if necessary. Tell them now about the NO DEVICES rule — one of the design sprint’s key ideas8, which basically says that the electronic devices shouldn’t be used during the sprint activities. Start scheduling users and customer experts to interview. Book your meeting space. If you can’t get a room for the full week at an office space, consider meeting at a hotel or nearby rental facility. If you haven’t already, start customer research (more on that later).
  • Week 2: Continue to follow up on your interviews.
  • Week 3: Gather supplies (recommend buying sprint kit9), schedule interviews, and send a reminder email to participants (remind them about the NO DEVICES rule).
Give yourself three weeks only to prepare the design sprint properly. Note how every week have a strong focus on involving customers. Large preview11

Notice that all three weeks involve scheduling participants. This is worth emphasizing because securing quality customer interviews can take time.

Quality interviews are with people who match your target customer. Getting the right people ensures that your feedback at the end of the week will be meaningful and adequate to drive decisions and next steps.

In the sprint example above (the development kit), we were testing an idea aimed at developers. The prototype we created wouldn’t make sense to non-developers, so we would have had difficulty recruiting the right testers on Craigslist or at a local Starbucks (unless we got really lucky!). Instead, we took weeks tracking down the right participants and finding interview times that worked for them. In this particular sprint, we drew from a pool of existing customers.

Other ways to find good participants is to leverage people in your network, or use sites like to screen potential participants. If your value proposition applies to a more general audience, you will not need as much lead time to secure the right people, but making sure you have the right testers is essential for a successful sprint.

If there’s opportunity to do so, I recommend conducting at least some kind of customer research. Get a sense of the day-to-day tasks and goals of your customers through actives such as interviews and ethnographic studies (you will most likely need to start these activities more than 3 weeks in advance). Waiting until the end of the week to hear from customers in your sprint makes you less likely to have a value proposition that meets actual needs or opportunities. Without customer research, you are still relying on your best guess to understand what customers want or what would add value. Even though the sprint process takes into consideration input from customer experts, this is never as effective as hearing from customers directly. Instead, infuse the voice of the customer into your sprint from the start.

Now that you’ve set yourself up for success, let’s look at how you can maximize your sprint week.

During The Sprint: Maximizing Your Sprint Week Link

Like any good design thinking process, start with your customer. Right after you introduce the sprint and set expectations for the week, present the findings of the customer research. Do this at the very beginning on Monday so that your knowledge of the customer will influence the goal, target, and types of questions you ask your customer experts.

Start with empathy. Who is your customer and what is important to them? (Image: Nielsen Norman Group13) (Large preview14)

The discussion does not have to be exhaustive, but make sure the team knows enough to begin the sprint by building empathy for your customer. This will be the foundation for the rest of the week’s activities, including sketching on Tuesday15 and prototyping on Thursday16.

When creating a prototype, consider the appropriate scope and fidelity. The Sprint book recommends a high-fidelity prototype for a more realistic testing experience but only allows for prototyping to occur from 10am–3pm on one day.

We’ve found it quite difficult to build a high-fidelity prototype within the suggested five hours. For example, I’ve participated in a sprint that had three makers (makers in a design sprint are participants who create the prototype). Even with three makers, the prototype was not completed until well into the night. This prevented the team from doing a test run through prior to customer interviews, and the output of the sprint suffered.

Is there any way we can avoid this kind of stress and optimize the process? Allow me to share a few tips for maximizing the possibility of producing a viable prototype, as well as how to get the most out of the customer interview on Friday17.

The Prototype Maker Should Be Comfortable With The Scope Link

The maker (again, the person who will build the prototype) has the most realistic view on how long it will take to create the prototype — since they only have one day (Thursday) to do so. The maker should firmly remind the decider (the term the Sprint book uses for the person who will make the major decisions during the design sprint) to focus on validating the value proposition.

People, myself included, get excited about the opportunity to get real feedback from potential customers and try to include non-essential things to test.

For example, we once prototyped a chat feature that was unrelated to our value proposition because our decider wanted to know if people would use it for support. That kind of insight would be interesting, but creating and testing these nice-to-haves can happen later.

When these situations happen, the (prototype) maker should be able to overrule the decider.

Be Realistic About The Level Of Fidelity Link

The correct level of fidelity is the one you can create in the given time that illustrates your value proposition.

  • Use realistic content and data.
  • Illustrate the essential components of your value proposition in a way that is functional (i.e. for a website, critical path for a task is clickable).
  • Do not build out features that do not illustrate the value proposition (unless you have the time!).

Consider Plant Stops, a fictitious company that sells trees and planting services. Plant Stops has always been a brick and mortar business but wants to expand. They want to sprint to see if customers would be interested in buying trees online. Let’s look at an example page from their prototype in varying levels of fidelity from too low to too much to just about right.

Large preview19

Too low. The fidelity of this page is too low. It is not clear what task the customer is trying to accomplish and does not illustrate the idea that Plant Stops is testing.

Large preview21

Too much. This example illustrates the idea at a high fidelity level. In order to be realistic, it contains features that are not necessary to validate the value proposition and should only be designed once all other critical components are created.

Large preview23

Just about right. While not realistic, this example also conveys the idea and is sufficient to test with customers. Omitting additional features will free up time for more effective flow design.

More Than A Usability Test Link

After you’ve created a prototype on Thursday, it is time to test your value proposition on Friday. In my experience it is easy to turn customer interviews into usability tests (you don’t want to do that). This is especially easy if your tester is a UX person with experience giving usability tests (do I sound guilty yet?)

It took me a few sprints to un-train myself from asking only usability questions. For example, instead of asking, “where would you expect so and so to be?” I should have been asking, “what did you like or dislike about so and so?” Even more so, the best approach is to avoid specific questions and encourage the customer to think out loud.

Similarly, you might also need to walk users through the concept more than would be needed for a usability test. For instance, rather than watching customers fumble around trying to navigate the menu you created in 3 minutes the day before, get them to the key features as soon as possible to start getting feedback on your value proposition.

Usability feedback is definitely a plus, but you really want to make sure you are getting customer input on your idea. At the end of your interview, ask meaningful wrap-up questions. The answers that you receive will inform your decision whether or not to move forward with the project. For example, ask questions like:

  • What were your overall impressions of X?
  • On a scale from 1-10 (1 being the least useful and 10 being the most useful), how useful is X?
  • Use five adjectives to describe X.

Next steps Link

At the end of the sprint week, your team needs to decide if you will move forward with your value proposition. If not, you’ll need to discuss if there’s anything that can be salvaged from the project or if it’s better just to cut your losses and move on. The latter rarely happens, though.

Assuming you are moving forward with the validated concept, it’s important to stay focused. After such a successful and insightful sprint week, you wouldn’t want to lose the momentum, would you?

After The Sprint: How To Keep The Momentum Link

You’ve just had a week jam-packed with making decisions and progressing an idea. At the end of the week, people part ways and return to their day jobs. How do you keep the momentum? Here are some practical next steps and tips:

  1. Someone needs to be in charge. This could be the decider or someone the decider assigns to the role, such as a product owner or project manager. Ideally, this person was also a participant in the sprint.
  2. Decide what’s the minimum marketable product (MMP). What are the essential features and functions needed to deliver your value proposition? The customer feedback gathered during the sprint should drive this decision. All non-critical features (the nice-to-haves) should be saved for later.
  3. Make sure the prototype reflects the critical features of the MMP with UX design best practices applied.
  4. Test your prototype for usability. Now is the time to ask, “where would you expect so and so to be?”
  5. Get to work! Development can start using the customer-validated prototype. Your design team can start incorporating those nice-to-haves into the prototype, starting with the features that the product owner has prioritized based on customer feedback.
  6. Run more sprints. The design team would ideally conduct a few sprints ahead of the development team’s sprints. For example, if the development team is working in two-week sprints, then designers should schedule their sprints accordingly every two weeks, regardless of what type of design sprint they use. At the very least, the design sprints should consist of iterating on the prototype, testing with users, and passing off to the developers, ensuring that only customer-validated features are developed.

Using this process, you have established a continuous customer feedback loop, starting with your sprint.

Test Your New Superpower! Link

Since embracing the sprint, I have seen ideas — that have had no traction for years — gain new momentum and interest. Months and months of meetings and discussions bypassed by one week of collaboration, design thinking, and customer-centric decision making.

The tips gained from practical experience that I have outlined in the article will only make this effort more successful. So as you plan your next design sprint, remember how you can maximize your experience:

1. Pre-sprint

  • Schedule early
  • Research your customers

2. During-sprint

  • Start with the customer
  • Prototype at the right level
  • Conduct value proposition interview

3. After-sprint

  • Put someone in charge
  • Iterate and validate
  • Get to work

Now it’s time to test out your new superpower!

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23

↑ Back to top Tweet itShare on Facebook

Claire is a customer experience designer and strategist at Travelport. She is passionate about human-centered design throughout the customer journey.

  1. 1

    Thanks really, this is a great post …

  2. 3

    Great explanation of the different kinds of sprints. Shared it with our user experience/optimization team!

  3. 5

    Hey – nice read. But why do you separate design team and developement team – together as one team it brings way better results in less time. Cheers

    • 6

      Hi Susann, thanks for the comment! From the perspective of the Google sprint, it is ideal to have folks from the development team participate as well. And then after the Sprint, it works well to have the design team work ahead so that they have time to validate with customers before handing off to the development team. But hopefully there is lots of collaboration and communication across the teams. What are your thoughts?

  4. 7

    Thanks Claire, for the high level, in-depth article. It was a great read!

    I currently run, a user testing platform, and have trouble with some of my clients when they’re user testing prototypes. I understand that too low fidelity prototypes, users may find them confusing (they’re not experts) or only one user path is defined/clickable. Likewise, if the prototype is too high fidelity, the client has potentially missed an opportunity to test with a low fidelity prototype to see what does and doesn’t work.

    My question is, how do you define when a prototype is too low or too high fidelity to run a user test?

    • 8

      Hi Preston, great question!

      At the end of your Google Sprint week, the purpose of your customer testing on Friday is to understand potential customer interest and feedback before going live, so your prototype needs to clearly articulate your value proposition. That means 1) having a clear understanding of what the value proposition is, and 2) building out the elements of your prototype that most clearly reflect it.

      For non-Sprint test, similar advice if the purpose of your test is to see if your idea is good. However, if the purpose of your testing is more around usability, then you get benefits from testing at low and high fidelity. My advice is to recommend testing early and often. That way, you are getting feedback at varying levels of fidelity.

  5. 9

    This is great! I just went through product owner scrum training so a lot of this is starting to make sense to me :)


Leave a Comment

You may use simple HTML to add links or lists to your comment. Also, use <pre><code class="language-*">...</code></pre> to mark up code snippets. We support -js, -markup and -css for comments.

↑ Back to top