{"id":12644,"date":"2017-10-06T11:00:21","date_gmt":"2017-10-06T10:00:21","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=12644"},"modified":"2020-11-05T14:10:02","modified_gmt":"2020-11-05T14:10:02","slug":"google-design-sprint-gone-wrong-taught","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/google-design-sprint-gone-wrong-taught\/","title":{"rendered":"A Google Design Sprint Gone Wrong (And What It Taught\u00a0Me)"},"content":{"rendered":"

\"\"<\/a><\/p>\n

<\/p>\n

Sprints are all the rage, but beware the snake-oil! This is what I learnt by taking part in a modified design sprint, run by people with incomplete understanding of the Google Ventures Design Sprint process<\/a>.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

Jake Knapp describes Design Sprints as a greatest hits of productivity, decision making, innovation, creativity, and design \u2014 and I think that\u2019s true. But I recently took part in a sprint which modified this \u201cgreatest hits\u201d formula heavily. My gut feeling was that these modifications were not beneficial, 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 GV process outlined in the book \u2014 to learn, and to be more prepared for the next time around.<\/p>\n

I\u2019m not going to go into specifics about the GV Design Sprint process.. all that stuff is in the book<\/a>, which you should definitely read \u2014 but here is a boiled-down outline of the process:<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n

A Design Sprint<\/a> is a learning loop where you define and create something (an \u201cit\u201d) you need to learn about. You test with real users, and gain valuable feedback and insights.<\/p>\n

Here\u2019s the stuff I learnt by taking part in a \u2018bad\u2019\u00a0sprint<\/h2>\n

Don\u2019t change the vision \/ foundation during the\u00a0process<\/h2>\n

This should be a no-brainer, but do NOT, under any circumstances start revising the foundation of the sprint, which was defined at the beginning of the process. 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 \u2014 and the whole house comes crashing down.<\/p>\n

Don\u2019t rush the time when sketching ideas<\/h2>\n

We only had very limited time (a few 10-minute slots) for sketching out ideas, which led to little time for exploration. The ideas that resulted seemed to be \u201cshallow\u201d and uninteresting. This belittles 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 \u2014 but it takes time to explore, and go past the obvious ideas.<\/p>\n

Don\u2019t go backwards in the\u00a0process<\/h2>\n

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.<\/p>\n

Don\u2019t test multiple \u201cits\u201d in the same\u00a0sprint<\/h2>\n

We ran a sprint over three days, with each day dedicated to a different \u201cit\u201d. 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 \u201cfrankensteined\u201d 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.<\/p>\n

Don\u2019t hand off the actual building of the\u00a0\u201cit\u201d<\/h2>\n

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<\/em> whatever they\u2019re 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 \u201cjust-real-enough-to-test\u201d facade of an artefact.<\/p>\n

Do stay neutral if you are facilitating a\u00a0sprint<\/h2>\n

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 \u2014 they can also get attached to their ideas, suffer from biases. So don\u2019t get actively involved if you are facilitating a sprint \u2014 stay neutral.<\/p>\n

Be mindful of group\u00a0dynamics<\/h2>\n

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 \u2014 this led to unfortunate group dynamics and biased voting.<\/p>\n

State explicitly which mindset you should adopt in a\u00a0sprint<\/h2>\n

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 \u2014 that you should fall in love with the problem instead. You should fall in love with the \u201cit\u201d you are trying to figure out how to solve.<\/p>\n

Final thoughts<\/h2>\n

Some good did come out of the sprint \u2014 specifically, three prototypes, ready for testing. It will be interesting to see what kind of user feedback the prototypes can generate. My hypothesis is that it will be fairly broad and hard to decipher, but time will tell.<\/p>\n

Despite this somewhat critical article, the sprint was a good experience for the team, and it demonstrated (to some extent, at least) how collaborative ideation and sketching works wonders when designing new concepts.<\/p>\n

This article was originally published on Mogen's Medium page<\/a>. <\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Sprints are all the rage, but beware the snake-oil! This is what I learnt by taking part in a modified design sprint, run by people with incomplete understanding of the Google Ventures Design Sprint process. Jake Knapp describes Design Sprints as a greatest hits of productivity, decision making, innovation, creativity, and design \u2014 and I think that\u2019s true. But I… Read More ￫<\/a><\/p>\n","protected":false},"author":176,"featured_media":12832,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[500],"tags":[],"class_list":["post-12644","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-process"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n