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

Sprints are all the rage, but beware the snake-oil! This is what I learnt by taking part in a design sprint, run by people with only superficial understanding of the Design Sprint process.

Jake Knapp describes Design Sprints as a greatest hits of productivity, decision making and design — and I think that’s true. But I recently took part in a sprint which had been modified almost beyond recognition. I could tell early on in the process that many things were going to go south, but since I was unfortunately not in a position to change the process, I chose to view it as an opportunity to gather data, and do a comparative analysis between this “sprint”, and the process outlined in the book.

I’m not going to go into specifics about the GV Design Sprint process.. all that stuff is in the book, which you should definitely read — but here is a boiled-down outline of what the process does:

A Design Sprint is a learning loop where you define and create something (an “it”) you need to learn about. You test with real users, and gain valuable feedback and insights.

Here’s the stuff I learnt by taking part in a bad sprint

Don’t change the “it” during the process

This should be a no-brainer, but do NOT, under any circumstances start revising the foundation of the sprint: the “it” which was defined at the beginning of the sprint. In our case, assumptions, questions, goals and problems were literally revised on the last day of the sprint, rendering much of the process pointless, since everything in the sprint is built on top of this foundation. Mess with the foundation — and the whole house comes crashing down.

Don’t rush the time when sketching ideas

We only had two 10-minute slots for sketching out ideas, which led to the ideas being very shallow and uninteresting. There was no understanding of the true power of sketching: it is a formational activity which supports emergence of new ideas, and elaboration of existing ones. Sketching is a language which shapes and adds to the ideas which are put down on paper.

Don’t go backwards in the process

In this case, the facilitators asked us to review the solution after we had already picked and elaborated it. This led to a random features being added, a general lack of focus, and a bad group dynamic where some group members dominated the discussion.

Don’t test multiple “its” in the same sprint

We ran a sprint over three days, with one day dedicated to one “it”. This led to two issues. First, ideas spilled over from one day to the next. Ideas that had been discarded on day one, would be “frankensteined” alive again, on days two and three. People get attached to their ideas, and it showed! Second, there was a lack of clarity about the purpose of the sprint, which led to a lack of focus and slow momentum.

Don’t hand off the actual building of the “it”

In our case we had a 3rd party standing by to translate our sketches into finished layouts. And while this was convenient and easy for us, it is super important for people to get their hands dirty, and build whatever they’re going to test, for themselves! It teaches the importance of being specific and detailed, it shows how new issues emerge during such a process, and it provides first-hand experience of how easy it actually is to create a “just-real-enough-to-test” facade of an artefact.

Do stay neutral if you are facilitating a sprint

Our facilitators took active part in the sprint. This might have seemed like a good idea, but since they were also facilitating, they were in a position of authority, and ended up influencing many decisions which should have been in the hands of the sprint team. Facilitators are people just like the rest of us — they can also get attached to their ideas, suffer from biases. So don’t get actively involved if you are facilitating a sprint — stay neutral.

Be mindful of group dynamics

In our case, dot voting / heatmaps was done after people had explained their ideas and concepts. So there was full disclosure about which sprinter had sketched which ideas — this led to unfortunate group dynamics and biased voting.

State explicitly which mindset you should adopt in a sprint

A lesson which is perhaps the most important one, especially if you are sprinting with people who are new to design thinking and design in general: be extremely mindful to explicitly state what sort of mindset one should adopt in a sprint. Specifically, outline what design is, and what wicked problems are. Provide a warm-up exercise such as the 30-circle challenge. Explain the importance of not falling in love with your ideas — that you should fall in love with the problem instead. You should fall in love with the “it” you are trying to figure out how to solve.

That’s it! Thanks for reading — I hope you have a great weekend, and hopefully some time off with your family over the Easter holidays.

Further reading

<a href="http://ift.tt/2lIYHWK">http://ift.tt/2lIYHWK</a>

A Google Design sprint gone wrong was originally published in Prototyping: From UX to Front End on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Google Design sprint gone wrong

Cool stuff, every week

More Articles