If you work in tech, product management or design, it’s very likely that you heard the term “Design Sprint“ at least once. I wanted to address some of the most common misconceptions people have about Design Sprints.
If you work in tech, product management or design, it’s very likely that you heard the term “Design Sprint“ at least once. I wanted to address some of the most common misconceptions people have about Design Sprints.
We create high-fidelity prototypes every week. Here is how we do it and get home on time!
I am a Product Designer at AJ&Smart, a Design and Innovation Consultancy that has run Design Sprints (created by Jake Knapp, formerly of Google Ventures) for our clients from various industries for several years. Here’s a very condensed definition of Design Sprints, in case you never heard the term before: A Design Sprint is a very lean, fast and structured process to come up with ideas, rapidly prototype them and then test them with users — all within one week.
So every week, we run a Design Sprint with one of our clients. And every week, we rapidly prototype interactive digital product to put them in front of testers. For this, we have only one day. That’s it. Whenever we show examples of our prototypes, people are in disbelief that this is possible in such a short amount of time.
Some of our prototypes have as many as 40 screens. To get this done in 8 hours, we would need to finish 5 screens every hour (or 1 screen every 12 minutes!). This doesn’t account for breaks, letting your mind wander for a moment, or thinking about alternative approaches.
That’s a crazy amount of work for one day!
But as a company, our goal is to have consistent 8-hour workdays with zero overtime. Generally, we have been very successful with this. But squeezing the workload of prototyping day into a standard-length workday has been a tough nut. And we cracked it! Of course, you need a great team. But you also need a great workflow. We now have over a hundred sprints under our belt and found some ways to make this day much more manageable, which we would like to share with you:
The Storyboard is a really important part of the sprint process. It’s also the most difficult because it’s the first time in the process doesn’t follow the “Together Alone” approach, but is a group exercise with a lot of going back and forth, rambling discussions and second guessing.
It’s exhausting for everyone involved: The facilitator, the artist, the other Sprint participants. However, it’s an absolute must. Whenever we tried shortcuts or rushed it to get the it done as fast as possible, it came back to haunt us and lead to more stress during the prototyping.
We came up with a little hack to make the storyboarding much more structured (read: Storyboarding, 2.0!), but there’s just no way around doing a proper storyboard. If you skip this part of the process (“Nobody of us can draw”, “We already have so many good ideas”, “We’ll let the designers figure it out”), you can forget about getting your prototype done in one day, period.
Here’s what you need to do:
Use the last 10 minutes of the day to prepare a prototyping work file for the Stitcher. At this point, it’s just a Sketch file with very crude placeholder screens that the Stitcher will use to put together the prototype the next day.
That’s the end of the day!
The next day, the entire prototyping team (the Stitcher, the Artists, the Collectors) starts off with a short (10–15 mins. max) huddle in front of the storyboard. This is important to make sure that everybody is on the same page and nobody loses sight of what the prototype needs to achieve.
Creating a prototype doesn’t mean you have to code. Tools like Invision or Marvel are perfect for rapid prototyping, and they also allow for easy remote testing.
This way, the stitcher can already start putting together the interactive prototype even when there are still screens missing, and little by little, the prototype file gets filled. This also allows the stitcher to do an extra layer of quality control and proofreading, to check for inconsistencies and make sure the flow through the prototype makes sense.
Even with rapid prototyping, the prototype has to look great. Our testers have to approach them as if they were real products. But our time is limited, and we have to make a trade-off: If we want to get done in time for the test, we have to focus on what matters most, and that is creating a prototype that allows us to get clear answers to the sprint questions.
What we can’t focus on is pixel-perfect design, color schemes, typefaces or how the branding looks — at this point, none of these matter! At the end of the user test, it’s very possible that the prototype lands in the trash, and that all the effort that went into the branding has been wasted. Even if the prototype hits the mark completely in the first week (which is very unlikely), it’s still a long way to a full-fledged product. Fine-tuning has it’s time and place, but this time is not now.
That’s why we try to focus our efforts on where they count and streamline the rest of the design process as much as possible:
The workload on prototyping day is very high, so everybody has work very streamlined and efficient to get everything done in time. Here are some of the things you can do to help your prototypers get done in time.
Since everybody pretty much scrambles to get stuff done as fast as possible, it’s important to align along the way. Otherwise, you’ll end up with a disjointed mess of a prototype full of holes. For this, we have two check-ins.
After the second check-in, the main part of the prototype should be complete or close to completion and already allow you to get clear answers on the sprint questions. Now, you can use the rest of the workday to add missing non-essential screens and do a last run-through of the prototype. The last thing we do before we head home is to send our clients a link to the prototype, so they can take a look in the morning.
Then, everybody gets home on time and gets some well-deserved rest!
That’s right, we are not done yet! During the first user test, a lot of shortcomings of the prototype will become obvious: Problems with the flow, button labels that are confusing, missing elements, typos, glitches. All of this is normal and happens every time, and normally doesn’t impact the user test too much, since our interviewers are really good at glossing over these little problems. Still, we want to fix those things so our testers don’t get thrown off too much.
I hope this little peek behind the curtain demystifies rapid prototyping and makes it a bit clearer how creating a prototype in one day without overtime is easily doable for experienced designers with a proper workflow. If you try these tips for yourself, please let me know how it went, and if you have your own tips to share, I’d love to hear them!
Hacking GV’s Design Sprint storyboarding to get results faster, with less stress.
News and media find themselves in a race to the bottom as social media platforms and Google turn journalism into commodified pieces of content. Are newsreaders a way out?
As patterns and design systems mature, and white label UI kits and website builders become ubiquitous, what does that mean for designers?
© Tim Höfer 2024