Published on <a href="http://ift.tt/2uBsx3u">| Prototyping: From UX to Front End &mdash; Medium</a> Oliver Pitsch <img alt="" src="http://ift.tt/2uV3Gac">
After running several Design Sprints at <a href="http://studitemps.tech/">Studitemps.TECH</a> in the past years on all kinds of topics we’ve changed 7 things in the way we run and organize our Sprints and it changed the methodology for the better!
With the Design Sprint Google gave us a powerful technique to have a look into the future of our products. 5 structured days and you will fast forward to have your hands on a real product with the first users to give your real feedback. It’s by far the single most powerful product/UX/development technique that I’ve encountered in my career. (Thanks, Jake Knapp!)
But every technique can be customized to better fit your team and way of working. Here are the seven things we have changed in running our Design Sprints that made the Sprints even better for us.
<h4>1. Dig deeper into the problem</h4>
During the Sprintweek the Monday is dedicated to throwing light on the problem that you’re addressing. According to the book, this happens with a technique called “Start at the end”. Basically, it lets you picture a future where the Sprint has already happened and you have to state which questions have been answered and what has changed. It’s a good technique to get a clear idea of the Sprint Goal, but in our experience, it’s not sufficient enough to get a shared understanding of the problem we are trying to solve during the sprint.
We’ve implemented two exercises that help us achieve this shared understanding.
<h4>Best Practice or Bust</h4>
We are basically using the “Start at the End” technique, but we are also looking at the downside. Take a bunch of post-it-notes and write down all the stuff that changed and/or went wrong within the next 6 month to one year after the sprint. One side of a board is filled with all notes that picture a future where everything from now on works out perfectly. Where do you stand then? The other side of the whiteboard is dedicated to the dark side. Assume that everything you do from now on fails. What will or will not change in the next year. What will happen and how will it affect your business?
Taking a look in a dystopian future is honestly not the most uplifting start for the sprint, but believe me, it galvanizes everybody in the room. And having the best case scenario right next to it will immediately calm the waves.
<h4>Yell at us</h4>
For the success of the sprint, it’s crucial to end the Monday with a shared understanding of the problem. It turns out that in most sprint teams there will be experts that know more about the problem and experts that know less. With an exercise that we call ”Yell at us“ we give every participant the chance to shout it all out, explain the problem that we are trying to solve from their point of view and get as much of their experience on that topic onto the table.
On a side note, it’s good to know that this exercise does not necessarily have to be loud and full of tears, but it really helps to let some emotions flow for the other people to really understand the pain points.
<h4>Tip: Don’t discuss — understand</h4>
It’s important to try not to discuss the problem too much. Discussions take way to much time and don’t lead to good results. Try to get a shared understanding in that step and keep your big questions and opinions for later in the sprint.
<h4>2. Designate your experts</h4>
This is just a little trick that we’ve applied to make the sprint team feel better and more appreciated. Don’t talk about team members or participants all the time. Make sure to call the people that you decide to take part in that adventure experts. Because they are. Those are the experts that will play a determining role in solving your big issue.
<blockquote>“The choice of your experts plays a crucial role in the success of your Google Design Sprint!”</blockquote>
<h4>3. Get out of the building</h4>
In the Sprint Book Google describes their war room. It’s a room solely dedicated to events like the Design Sprint. With no surprise, not every office has enough space to install such a room. Same counts for us. We have plenty of small meeting rooms and even a pretty huge one that could easily fit a 30 people meeting. But none of the rooms match the criteria for a war room. And furthermore: our experience is that it’s a bad idea to run the Sprint in-house. It just opens up the chances to be distracted by the daily business.
<blockquote>“Get out of the building when doing a Design Sprint!”</blockquote>
That’s why we always book a large meeting room in a surrounding coworking space. It’s just perfect. It has the right size and comes with coffee and snacks!
So think twice before running the Sprint in your own office and try to find the space and budget to get out of the building.
<h4>4. Improve the Sketching Process</h4>
I love Tuesdays in sprintweeks! With my background as graphic and interface designer, I just love to watch colleagues from the sales department letting their creative juices flow!
And it still impresses me every time how creative and “out of the box”-thinking my colleagues from the other departments get if you just nudge them a little in the right direction.
Though, the Sketching process as described in the Sprint Book does not perfectly work for us.
Let’s recap the way the book outlines the process:
<ol>
<li>Take notes Gather key information, 20 minutes</li>
<li>Write down ideas Doodle rough solutions, 20 minutes</li>
<li>Crazy 8s Try rapid variations, 8 minutes</li>
<li>Solution Sketches Figure out the details, 30+ minutes</li>
</ol>
There’s nothing really wrong with this. But it showed that the team in the past Sprints did not really understand the difference between notes and ideas and also that they found it really hard to convert their crazy 8s into solution Sketches.
<h4>Therefore we changed the procedure a little:</h4>
<img alt="3 steps of the design process" src="http://ift.tt/2tWK7AU">Our 3-Step Sketch Process: Ideas, Crazy 8s, Feature Storyboards
<ol>
<li>Ideas, Ideas, Ideas, 20+ minutes That should be straight forward. You set your timer to 20 minutes and let your team write down their ideas. Tell the team to note everything that comes into their mind that would help solve the problem. This exercise is more or less a mixture of taking notes and doodling ideas, as described in the Sprint Book. It just gives the team the freedom to write or sketch, just the way they want to.If the team wants to extend the 20 minutes, just add another 10 and another 10 if need be.</li>
<li>Crazy 8s, 8 minutes No changes to the book here. You fold the paper and sketch out variations of ideas under time pressure. Pretty fun exercise! Pro Tipp: I recommend to use the app <a href="http://ift.tt/2uV3lEC">Bit Timer</a> as your timer.</li>
<li>Feature Storyboards, 30+ minutes This step is adapted from the original “Solution Sketches”. In fact, it basically is a renamed copy with a slight modification. The problem with the Solution Sketches is that the team did not understand what the expected outcome would be, even when I showed some good ones from the past sprints. In their minds, a sketch would consist of one sheet of paper, with one drawing and maybe some explanation text. Why 3 post-its? After renaming the final papers to “Feature Storyboards” and explaining that the desired outcome would be a sketched-down explanation of a single prototype-feature including an introduction to the feature, the action itself and an outro. Just like a short little storyboard. “You get to that page through an email, then you click the call-to-action and the download starts.” Intro, Action, Outro. Simple as that.Critics will now say that that’s what Jake Knapp meant with the solution sketches and I will not try to argue against it. It just turned out that it’s more obvious for the team with another name and another story.</li>
</ol>
<h4>5. Use a new approach to Storyboarding: The Proto Flow</h4>
The final exercise on Wednesday during your Design Sprint is the storyboard. The goal is to achieve a more or less detailed storyboard that shows the sequence of the desired prototype.
There’s only one drawback that we’ve experienced in some of the sprints: The team is quite exhausted on Wednesday afternoon when it’s storyboarding time. And putting down a detailed storyboard is a hard challenge in that condition of mood.
But it turned out that we would always start with plotting a flow chart of the steps the testers would run through while seeing the prototype, before filling the storyboard. And in most cases, this flow chart was absolutely sufficient to understand how the prototype would work.
During our last Design Sprints, I’ve turned this situation into an advantage and took the team a bit deeper into the flow plotting and skipped the storyboard afterward. We call this exercise the Proto Flow.
<blockquote>“End your Design Sprint Wednesdays with the Proto Flow and skip the storyboard!”</blockquote>
When ending the Wednesday with the Proto Flow you’ll have a flow chart of the prototype as a result that delivers a shared understanding of what will be created on Thursday without going to deep into the details and noting down every simple bit. This will build the foundation of the prototype and reduces the need of a complete storyboard.
<h4>6. Don’t use Keynote!</h4>
The following tip is more a best practice from our sprints than a general tip that will help all other sprint teams.
As recommended in the Design Sprint Book we used Keynote and <a href="http://keynotopia.com">Keynotopia</a> for building our first prototypes. But we also believe that people should always do the job they can provide the most value in. And since every of our sprints is facilitated by one of our UX designers we decided early on that the prototype in the Sprint would mainly be crafted by that UX designer.
Furthermore, it turned out that using Keynote would not speed up the prototyping process for us, but slow it even down. The reason is that we craft all kinds of designs and prototypes in tools like Sketch or <a href="http://ift.tt/2tWK8EY">Adobe xD</a> all the time. So it comes naturally to us to also work this way during the Design Sprints. We usually divide the sprint team into three groups that would craft the prototype according to the Proto Flow, create the content for the prototype and plan the upcoming interview for Friday. So we never face the risk of a sprint expert being bored on Thursday.
<h4>7. Host a public wrap-up</h4>
We are striving for full transparency of our work at <a href="http://studitemps.tech">Studitemps.TECH</a>. And if your company is somewhat like ours, it is important to you to inform your team about the outcome of your Design Sprints. Furthermore, the great folks at our company even call for this information.
So after every Design Sprint, we host a wrap-up of the sprint outcome for the complete company. We usually use one of the next Scrum Sprint Review Meetings and end the event with our wrap-up. This starts with a short explanation of the Design Sprint methodology for all attendees that hear about this for the first time. We then show the prototype and give insights on the user feedback from Friday. We also use this opportunity to talk about the next steps after the sprint and collect internal feedback.
As a result, the different departments approve the methodology more and more and now even volunteer to send experts in the upcoming Design Sprints.
Originally published at <a href="http://ift.tt/2uUKdXh">UX and the City</a>.
<img src="http://ift.tt/2tWEqDd" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2uUFwwk">7 hacks for your Google Design Sprint</a> was originally published in <a href="http://ift.tt/2cAqCpx">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

7 hacks for your Google Design Sprint

Top Stories