.svg)
Overview
Prototype
.svg)
The design team chases perfection in the prototype
What this looks like
🔎 Designers try to create a pixel-perfect product in just one day.
When the design team starts on Thursday, they have up to 10 screens to design and build from basic sketches. Their goal is to end the day with a working, interactive prototype. It doesn't have to be super polished, just real enough to test with potential users.
Many designers find it very difficult to do this. With just one day to work, they shoot for a beautiful design and end up falling short.
Why it happens
📚 The standard design process focuses on research and detail, while the Design Sprint process focuses on speed.
Most designers have two ways of working — wireframing mode and visual design mode. The first is for figuring out every aspect of the flow and structure, including every detail, variation, scenario and workflow. The second is for making pixel-perfect designs with perfect copy, images and micro-interactions. Both of these processes usually include extensive research, looking at diverse references, creating multiple options and so on.
A Design Sprint is a whole different animal. It requires a rapid prototyping mode, where the design team has to create an entire prototype — from sketches to wireframes to visual design to user interactions — in just one day. The normal, detail-oriented design process just doesn't work.
How to prevent it
✨ Set the right expectations for the prototype.
📋 Follow a well-structured process to keep design moving forward.
There are two keys to helping the design team complete a user-testable prototype in just one day.
First, set expectations about the prototype from the start. In a Design Sprint, a prototype shouldn't be a barebones wireframe with Lorem Ipsum text, grayscale colors and no images. That won't look real. However, it also shouldn't be super polished with amazing layouts, typography, colours and interactions. This will take too long, and it can even bias users. Make sure the design team knows what level of fidelity you're aiming for, and what the prototype should or shouldn't include.
Second, use a clear structure to keep the design team on track, rather than chasing some detail in their search for perfection. We use a three-pass process during prototyping:
- Expectations & review (30 mins): Bring the design team together and go through everything at the beginning of the day. Review the storyboard, identify any gaps, check for missing steps, and raise any questions or concerns.
- Pass #1 (2 hrs): Start with the easiest 3-5 screens, where the designer has total clarity and no roadblocks (like copy or assets). There's no need to focus on details or get everything right. Just execute as quickly as possible.
- Review (30 mins): Bring everyone together to review the first pass. Discuss what needs to be improved and what needs to be done in the next pass.
- Pass #2 (2 hrs): Complete all remaining screens. This may sound like a lot, but several screens are probably done already. This pass isn't about making things visually better or polishing the design. It's all about fixing what's missing, completing the workflow, and making sure everything is coming together.
- Review (30 mins): Do the last review with the team. Check if the screens, copy and images look good and are in the right place. Identify what needs to be fixed in the final pass.
- Pass #3 (2 hrs): It's finally time for fine-tuning. Neaten up the screens and add a bit of polish. Fix where the copy isn't right, images aren't looking good, or the layout is messed up. The prototype should be 100% ready for testing once these 2 hours are done.
At the end of the day, your prototype isn't ready
.gif)
What this looks like
🧐 You didn't finish the prototype by the end of the day.
After a full day of working on the prototype, you're just not done. And that's a problem, because you've already booked user tests for the next day!
Oh well, it's time for overtime. The team ends up working until super late or even all night to complete the prototype in time. The prototype is complete, but everyone is burned out and ends up hating the sprint.
Why it happens
😕 You started designing without complete clarity.
✏️ Most designers aren't used to rapid prototyping.
This happens for two main reasons.
First, if there are gaps in the solution from Wednesday's sessions, it can be hard to finish the prototype in time. It's hard enough to design a full prototype, but when you have to first clarify the process, fill in missing steps, rewrite unclear copy and so on... it's near impossible.
Second, like we explained above, most designers just aren't used to rapid prototyping. Their usual design process emphasizes outcome over speed, but a Design Sprint needs speed above all else.
How to prevent it
⁉️ Make sure to fix any gaps or ambiguities in the storyboard.
✨ Set the right expectations about what a prototype means.
📋 Follow the three-pass prototyping process.
The first big thing to do is to check the storyboard for gaps. If you start designing with an unclear solution, you're in for trouble.
- Move step by step through the entire journey, and make sure the workflow makes sense.
- Check that the storyboard includes a detailed wireframe of every screen, not just the name of each step or rough sketches for each screen.
- No Lorem ipsum or dummy images in the prototype. Make sure there's a clear image and copy for each screen. If the designer will need to find a photo, make sure the sketch shows what should be in the photo.
If there are gaps, resolve them in advance — ideally at the end of Wednesday or before work even starts on Thursday. If that's not possible, kick off the day by allocating these issues to another team member. The designer can spend their first 2 hours on the screens that are clear while other people clear problems, wireframe missing screens and write final copy.
Next, as discussed above, it's important to set the right expectations and follow the three-pass prototyping process. Make it clear that a prototype doesn't have to be perfect, and stick with a clear plan to help keep the designer focused and on track throughout the day.
You review the prototype with stakeholders
.gif)
What this looks like
🧐 The stakeholders want to see the prototype before user testing.
Sprint participants, especially senior ones, may ask, "Do we get to see the prototype before you test it?"
You may be tempted to say yes. But there's a problem — you'll never get their sign-off in time.
An entire Design Sprint just takes 5 days. The prototype happens in one day, and it goes straight to testing the next day. How can you run your user tests on time if stakeholders are still reviewing the prototype or if they give you feedback?
Why it happens
🔍 Stakeholder reviews are normal, unless you're doing a Design Sprint.
This expectation to see and approve the prototype comes from the standard design process. Normally, when an organisation is working with a design team, a design doesn't move forward until key stakeholders sign off on it.
How to prevent it
👩🎓 Explain the role of user testing, importance of finishing a sprint on time, and lack of changes to actually review.
No matter what, don't show the prototype to stakeholders. There's not enough time in the sprint, and it'll lead to feedback that isn't helpful at that point.
What if stakeholders insist on seeing the prototype? That's when you have to step up and explain why it's a bad idea. There are three ways to do this.
First, make sure the stakeholders understand the role of user testing in a Design Sprint. Normally, user testing is about testing a polished product where everything has been thoroughly considered. In a sprint, however, the user test is just meant to get answers to the sprint questions. That's why the prototype doesn't need to be the perfect, final version of the product. It just needs realistically to show the ideas and elements that the sprint wants to test.
Second, explain that getting feedback and revising the prototype will slow down the sprint. If you don't finish a Design Sprint in 5 days, the team will lose all the momentum, excitement and energy that you spent the last week building. Tell the stakeholders that this week is about wrapping up user testing, then the prototype can go through another iteration.
Third, remind stakeholders that they've already essentially signed off on the prototype. As part of the sprint, the team worked together for 3 days to create a detailed storyboard. The only thing that has changed is that the storyboard is now digital and a bit more polished. The key elements are all the same, so there's nothing new to review or sign off on.
🤩 Pro Tip:
Schedule your user tests in advance, before you finish the prototype. This is a good way to burn your bridges and keep you on track. With user tests scheduled, you won't have the ability to delay the sprint for things like stakeholder feedback or prototype iterations.
Learn to run successful Design Sprints from experts at Parallel
