Published on | Prototyping: From UX to Front End — Medium Skjoldbroder

TLDR; The key thing for running a succesful sprint is having a constant, shared focus among the team. This way it is more likely that our prototype will ask the right questions, and therefore more likely that we will learn about the right things.

Diego Rodriguez eloquently said, “A Prototype is a Question, embodied”. A prototype is a manifestation of a question, in other words. It’s also a manifestation of assumptions, knowledge, ideas and many other things — but for the design sprint, the main point is to ask some people a question, and learn. Obviously, it’s important to ask the right question!

With this in mind, a design sprint is basically two things:

A process in which you build a prototype to ask exactly the question you want answered.
A test where wonderfully complex and real human beings respond to your prototype, giving you answers.

What makes a design sprint work? Obviously the process and the methods are important. That stuff is in the book, and thanks to Jake Knapp for writing it. Somehow, not all design sprints turn out great, though. One reason might be that we forget the absolutely most important thing in a Design Sprint: a shared understanding about the question we want answered here.

I know it sounds like a no-brainer. The team will obviously focus on the same thing and go in the same direction, right? Well.. not in my experience. People are intelligent and have lots of ideas of their own, which go in a thousand different directions. If you let this happen, it will reduce focus and clutter your prototype. Clutter your question!

On the first day of the sprint, the challenge is mapped out, sprint questions are defined, and through how-might-we questions, obstacles and pains are turned into opportunities. Ideally, this stuff is then kept top of mind through a few simple tricks. (Note: I didn’t invent this stuff, it’s all in the book — I highlight their importance here because I’ve seen it fail on more than one occasion.)

How to keep the purpose of the sprint clear

Write the vision and sprint questions down on a whiteboard, and keep it visible throughout the sprint. Remember to tell people why it’s there — to keep the purpose of the design sprint obvious and clear!
Studies have shown that framing a task impacts how people solve it. So on Tuesday, before sketching ideas for a highlevel 3-step storyboard, refer back to the whiteboard. Talk people through the work that has been done so far, and remind people what the purpose of the sprint is. Frame the task!
Repeat this framing after dot voting. Before the team creates a detailed user journey, simply remind them what has been done so far, what the purpose of the sprint is, and what the sprint questions are.
Finally, the same thing goes for actually building the prototype. The prototype is the embodiment of the questions you want answered. So it should directly reflect this — obviously.

To sum up: for a design sprint to be succesful, the most important thing is shared focus and a shared direction. This can be done very simply, by being very explicit about it, and by restating the purpose throughout the process to constantly keep it top of mind (you might think of it as an adjustment of a camera lens, to make sure it’s constantly in focus). This restatement of purpose will help your team avoid ideas that spin off in other directions, which will ultimately clutter your prototype and lose focus.

Thanks for reading 🙂 If you found this worth your while, please share it so others might benefit as well.

Design Sprint pitfall #1: lack of focus was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Design Sprint pitfall #1: lack of focus

Cool stuff, every week

More Articles