Since the Sprint book came out in 2016, design sprints have become a staple of collaborative processes. Thousands of companies have used this framework to create products before they’re released into the market. If you haven’t been a part of one as a product or user experience designer yet, you will be very soon. At Crema, we’ve been iterating and tailoring this process to fit not only our team structure, but also our client’s needs.
But … what is a design sprint?
A design sprint is a focused, 4 or 5 consecutive-day process with a team of people from different backgrounds that meet to discuss big problems, find potential design solutions and ready a prototype for usability testing on the last day. By the end of the sprint, the team knows if their idea is successful or partially validated, if they need to pivot, and which direction is best for the product. All this means that the team saved months of design and engineer resources.
Because of the importance each role bring to the table this week, it’s very important to bring your A-game as the designer; I know that wearing the ”designer” hat during a design sprint can be overwhelming and confusing. After my first experience and the ones after, I learned there are a few things designers can do to prepare, especially if this is your first time.
Design Sprint Preparation Tips
Know what to expect
This framework started at Google, and its success inspired the creators to write a book and create resources for others to replicate the process effectively. If you aren’t already familiar with the Sprint framework, I recommend reading Sprint by By Jake Knapp. I read it in 2016 during a trip from KC to Utah, and it’s a really enjoyable read that will help you get familiar with the framework and why it works. If you are not into reading books, the book is available on blinkist; a 15-minute audio and done!
Other resources from Jake Knapp that I consider super valuable are:
- Sprint Checklist: If you are in a time crunch and reading a book is not an option, take a look at this sample agenda to understand the key activities and events that will happen during a Sprint.
- The product breakfast club Podcast (available in Spotify and Itunes) This podcast is a behind-the-scenes look at how companies are building successful products. This won’t necessarily help you during your design sprint week, but it’s a good way to stay up-to-date on what’s happening in the product design and innovation world.
What is your role as a designer?
First and foremost don’t feel overwhelmed by the word “design” in the title “design sprint”. Designers aren’t the only ones doing the work. This process is an inclusive method that gives everyone the opportunity to contribute to the final design by bringing their expertise and skills to the table. During a design sprint everyone’s participation will help YOU, the designer, accomplish the goal to have a “good-enough-for-testing” prototype by the design “Prototype” day.
Every design sprint is different by nature and the roles involved will vary by each product, its stage in the product development cycle, and the problem your team is trying to solve. If you are the only designer, you will be in charge of working on the prototype. But if two designers are participating on the design sprint, discuss the team dynamics and set the stage for each designer’s role prior starting the design sprint. Decide ahead of time if one of you is going to be solely responsible for designing the prototype or whether both minds are needed. Then, determine capacity. This might also determine the tool you use. If you both need to design at your highest speed and potential, Figma is a better option rather than Sketch. Be proactive and make these decisions ahead of time.
Learn the teams' roles, the product and the problem (if applicable)
During a design sprint, people with different skills will gather in a room. There are ideally up to 7 people who have diverse roles and backgrounds. It will be good for you to know each individual’s role, especially if you are working with stakeholders outside of your company.
There is no design sprint without an important problem that needs to be solved (hence the sprint week). Your team will spend some time problem framing, so don’t try to have a complete understanding of the problem. However, do not ignore existing data or past user research, and meet with your product or project manager to get an idea of:
- Is it a desktop, mobile or tablet application? Is it a native app?
- Are there any environment constraints or app integrations?
- Are there any other key design considerations such as government standards or regulations?
The word “constraint’ has a negative connotation attached to it. However, don’t let that stop you from innovating—use it as the reason to think differently!
Prepare a sketch file
A “good-enough-for-testing” prototype means different things for everyone on the team. As a designer, good-enough could lead to a pixel perfect design. If you are a “Type A”, ambitious designer that will naturally put in all the effort to make your design as high fidelity as possible, a sketch file will be very handy.
I used to start all my new projects on a brand new file and a blank canvas. I learned the hard way this leads to more work if a project needs to scale. Files got messy really quick, and I ended up spending several hours cleaning things up. Therefore, I created a small UI kit with icons, symbols, font and layered color styles that can be easily swapped and updated. There are a few designers that have contributed to the community by providing their UI Kits. You can find plenty of these resources on dribbble.com and sketchappresources.com. While I’m appreciative of their generosity, I’ve found I need to spend time understanding what they’ve done and how to make the most out of these resources. A good middle ground if you don’t have time to create your own UI kit is to use one from another designer, but you should take the time to learn it, play with it and understand how its been created in order to quickly adapt it to your design needs during the prototype day.
Practice Rapid Prototyping
The first 2 days are usually designated toward creativity and innovation, so typically the designer or the strategist in the room are the ones capturing the team’s ideas on the whiteboard. I used to love sketching. But with all the digital tools available and after a decade of using graphic design software, I’ve lost that skill. I actually feel intimidated by the power of a marker. If you are the type of designer that jumps into Sketch (I’m guilty of this myself), understand that you’re not going to be able to do that--at least not for a few days. Prepare instead to do some killer sketching and rapid prototyping.
If you’re not used to sketching with pen and paper, a good way to warm up those muscles is to sign up for the Dribbble daily challenge email list and receive a daily challenge. Take 5-10 minutes a day and get a flow ready, just on your sketchbook or whiteboard. These exercises will give you confidence with your marker or pen again.
What to not do
Do not build a solution beforehand; that is going to be a big waste of your time! Make sure to enjoy the weekend, so you can come to the office on Monday completely refreshed and ready to tackle your Sprint week!
During the Sprint Week
Set expectations prior the prototype day
Make sure your team is aligned and you communicate what you can realistically accomplish by the end of the “Planning” day. The last thing you want to do is to have a 14-hour day on the Prototype. Or even worse—lack the ability to deliver the anticipated prototype.
Today, design sprints are a great way to avoid teams’ tendencies to overthink and instead, create something users actually want. Preparation and doing as much work ahead of time is key. That way, when the time to design comes, you are able to focus on generating the best concepts without getting distracted by the setup. I hope these tips help you prepare, so you can bring your A game as the designer in your next design sprint.
Did I miss anything? How do you prepare for a design sprint? I’d love to hear your feedback.