<p>Published on <a href="https://blog.prototypr.io/top-5-tips-when-facilitating-a-design-sprint-690d75f5e18f?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Design by Howell </p>
<p>I recently wrote about my experience facilitating a design sprint, and thought I’d share my top 5 tips to help ensure you get a good result from your next design sprint.</p>
<h3>1. Build a solid design challenge</h3>
<p><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2FAWv3UAFkgz39u%2Ftwitter%2Fiframe&amp;url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FAWv3UAFkgz39u%2Fgiphy.gif&#038;image=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FAWv3UAFkgz39u%2Fgiphy.gif&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=giphy" width="435" height="317" frameborder="0"><a href="https://medium.com/media/e5846b30da9ecbd0b587bec264d228b6/href">https://medium.com/media/e5846b30da9ecbd0b587bec264d228b6/href</a></iframe></p>
<p>The design challenge is the cornerstone of the whole design sprint process, so we have to get it right. I came up with this quick little formula I use to write the challenge.</p>
<blockquote><p>How can we (~tangible sprint outcome) for (~customer) to achieve (~measurable outcome)?</p></blockquote>
<p><strong>tangible sprint outcome:</strong> this is what you will deliver at the end of your sprint, it could be a UI, a journey, an app… essentially this is what you will put in front of your testers on day 5.</p>
<p><strong>customer:</strong> defining your audience is key, be as detailed as you can/should be here to ensure everyone understands exactly who you are sprinting for.</p>
<p><strong>measurable outcome:</strong> this is essential in defining success and will form the basis of how you will test your outcome and what metrics you will need to keep in mind throughout.</p>
<h3>2. Bring in the customer voice early</h3>
<p><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2Fl0HlJ7aAQyvjxM6B2%2Ftwitter%2Fiframe&amp;url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2Fl0HlJ7aAQyvjxM6B2%2Fgiphy.gif&#038;image=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2Fl0HlJ7aAQyvjxM6B2%2Fgiphy.gif&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=giphy" width="435" height="243" frameborder="0"><a href="https://medium.com/media/9b236bcfd02bcc479cfc6d56bb1e662b/href">https://medium.com/media/9b236bcfd02bcc479cfc6d56bb1e662b/href</a></iframe></p>
<p>whether it be via pre-sprint user research or by having your end user give lightning talks, the voice of the customer fundamental.</p>
<p>What I’m referring to here is not simply data, but the anecdotal evidence that really gives you insight into how users feel about something which often propels some of the best ideas and outcomes during your first day which will flow on to the sketching and eventual solution design.</p>
<p>The best option is to have either customers or customer reps giving lightning talks, ensuring that your sprinters then have an opportunity for Q&amp;A.</p>
<h3>3. The schedule is more like ‘guidelines’</h3>
<p><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2FB4yvyXSBibwGI%2Ftwitter%2Fiframe&amp;url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FB4yvyXSBibwGI%2Fgiphy.gif&#038;image=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FB4yvyXSBibwGI%2Fgiphy-downsized-large.gif&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=giphy" width="435" height="225" frameborder="0"><a href="https://medium.com/media/4151198639dffd56785f0cb258d48ffd/href">https://medium.com/media/4151198639dffd56785f0cb258d48ffd/href</a></iframe></p>
<p>Google Ventures have a wonderful sprint handbook that goes into great detail around the 5 day sprint schedule. However, most of us will struggle to lock away 12 to 15 people in a room all day for 5 days straight. Often times you will need to flexible with your sprint schedule.</p>
<blockquote><p>The key is to prioritise what you can get done in the time available and adapt the standard schedule to best fit the deliverables.</p></blockquote>
<p>The same applies to lightning talks and sketching sessions, as a facilitator your job is to keep the good ideas and insight flowing, and to redirect or curb the process if it veers off track.</p>
<h3>4. Facilitating isn’t designing</h3>
<p><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2FFjDZHlUNzgUJG%2Ftwitter%2Fiframe&amp;url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FFjDZHlUNzgUJG%2Fgiphy.gif&#038;image=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FFjDZHlUNzgUJG%2Fgiphy.gif&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=giphy" width="435" height="239" frameborder="0"><a href="https://medium.com/media/1902d48f4132962fe7789b9ebc302651/href">https://medium.com/media/1902d48f4132962fe7789b9ebc302651/href</a></iframe></p>
<p>This is mostly directed to the UX &amp; CX community who often find themselves running design sprints. Once you take on the role of Sprint facilitator, you are effectively removing yourself from the design outcome.</p>
<blockquote><p>Your role now is to help everyone in the room be designers, meaning you won’t have design input into the outcome.</p></blockquote>
<p>The only caveat around this is if you are facilitator and also the producer of the final prototype. I’ve found this to be pretty ideal for myself as I can spend the first 3 days watching the design unfold and evolving my own mental model of how the prototype will function. This makes the day 4 prototype process much more efficient.</p>
<h3>5. Assign a User Tester</h3>
<p><iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2FcitBl9yPwnUOs%2Ftwitter%2Fiframe&amp;url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FcitBl9yPwnUOs%2Fgiphy.gif&#038;image=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2FcitBl9yPwnUOs%2Fgiphy.gif&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=giphy" width="435" height="326" frameborder="0"><a href="https://medium.com/media/a82b78e325862d115bddf8833da83a7a/href">https://medium.com/media/a82b78e325862d115bddf8833da83a7a/href</a></iframe></p>
<p>Taking a leaf out of the dev worlds rule book “never code review your own code”, in a design sprint should “never user test your own prototype”.</p>
<p>But there’s more reasons to have a dedicated tester than just best practice. If you can organise to have a dedicated tester be part of your core sprint team and attend every session, then they can have a better understanding of the challenge, and work on test scripts as the sprint progresses.</p>
<p>This gives you one less things to worry about, whilst also reaping better results from the testing sessions themselves.</p>
<p>I hope you find these tips useful if you are every facilitating or considering running a design sprint. If you have any tips or feedback please share them in the comments.</p>
<p><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=690d75f5e18f" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="https://blog.prototypr.io/top-5-tips-when-facilitating-a-design-sprint-690d75f5e18f">5 tips for facilitating a Design Sprint</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


5 tips for facilitating a Design Sprint

…

Top Stories