Loading...Welcome back to the design sprint workshop! Today’s the last day of our intensive adventure.
Today, we’ll test the prototype you built yesterday.
How did we end up here?
First, we defined the challenge you were facing. Then, we created solutions sketches, and we voted on the most promising one. From there, we made a storyboard that formed the basis of our high-fidelity prototype.
And here we are. Over the past couple of days, we have recruited seven testers (two are backups, in case one of our testers disappeared overnight).
Today, we’ll test our prototype and conduct interviews with our testers to get feedback on our solution.
How we do the test
This testing stage has three main goals:
- To understand how the users approach the product (the prototype).
- To see how they experience the product.
- To learn what changes the testers would make to the product.
Is the test conducted in person?
If possible, yes. But most often, the tests are done remotely. We use services like Zoom, Skype, or Whereby to interact with our remote testers.
It’s essential to offer testers directions to complete the test. Why? Because even if the prototype is as close to the final product as possible, it’s not the final version of the product.
Blue and pink post-its
While they experience the product, we ask testers to write down their positive observations or comments on blue post-it notes. Negative remarks go on pink post-its.
At the end of the test, the post-its will be placed on a whiteboard divided into lines and columns — one line per tester and one column for each part (or stage) of the prototype.
By using colors, you’ll immediately know the areas that need improvements (the point of frictions), without even looking at what’s written of the post-its.
The interviews
After each test, you need to interview the tester. This interview is conducted by two team members from the client’s side. (Of course, the Pentalog folks will help.)
During the day, you’ll conduct five interviews. Each person will take a turn asking the questions while the other one takes notes.
The interviews last 30 to 45 minutes, with a 15 minutes break between each. You’ll need that time to prepare and deal with any technical issues that may arise.
The importance of remaining neutral
One should never lie to anyone, but we’ll make an exception here for the interviews. To make sure not to influence the interviewees in any way, tell them that this is not your prototype.
The goal of this white lie is to allow the testers to speak freely.
Pentalog’s Chief of Growth, Jeff Mignon, says, “A good way to start the conversation is to state that the prototype has been created by a team who is not present during the interview. Our goal is to figure out the pros and cons of the product.”
Of course, don’t insist too much on the fact that you had nothing to do with the prototype, because you might skew the results.
“You must stay as neutral as possible when asking the questions,” Jeff adds.
The Design Sprint Workshop outcomes
After the interviews, the workshop is done.
What comes out of it?
At the end of the exercise, we deliver our report to the client through Basecamp or a Keynote (or PowerPoint). In this report, we review the whole design sprint process and provide the client with:
- An executive summary.
- The final prototype.
- All of the comments, prioritized by importance.
- A list of the tension points identified.
- The How Might We questions (HMQ).
- The solution sketches.
- The recordings of the tests, if available.
- Photos from the workshop.
And we’ll give our client a list of recommendations to improve the product.
The Next Step
If this list is enough to move forward, the client will then move the product to the backlog of a classic sprint process.
If the test found problems that need further investigations or testing, we’ll organize a second workshop, which is called the design sprint iteration workshop.
The goal is to go through the same process, but starting with, we have figured out during the first workshop.
After this iteration workshop, this is it: you have to move one with what you have.
We have to remind ourselves that the goal of our approach is to solve a problem quickly, not to get stuck in a sea of iteration mud.
“The goal is not to get back to a waterfall approach through multiple iteration workshops, insists Jeff Mignon. One design sprint iteration workshop, and we move on.”
What if the prototype is a dud?
If the testers bluntly reject your prototype, stay calm, and start over.
“You should know right away that your solution doesn’t fly than after two years and lots of money wasted on the project,” notes Jeff.
Now, it’s your turn
With this series of articles, we have illustrated why and how we conduct design sprint workshops.
Now, it’s your turn to think about what you could solve through a design sprint.
What’s your pain? What’s keeping you up at night?
We can help you figure out what challenge to tackle and how to move forward with the help of a design sprint workshop.
Talk to us. We’re friendly. And we’ll help.
The Design Sprint Workshop series:
The Design Sprint Workshop: Defining the Challenge (Part 1)
The Design Sprint Workshop: Creating Solutions (Part 2)
The Design Sprint Workshop: Voting Day (Part 3)
The Design Sprint Workshop: The Storyboard (Part 4)
The Design Sprint Workshop: Prototyping (Part 5)
The Design Sprint Workshop: Testing (Part 6)
