This is part one of a series on design sprints. This post will cover planning and prep—the key to making a sprint successful.
So what is a design sprint anyway? It is a framework that helps answer questions, inspire innovation, produce solutions, and align your team—quickly and efficiently. The framework consists of five main stages: Understand, Sketch, Decide, Prototype, and Test. We’ll breakdown each stage in later posts.
Design sprints come in all shapes and sizes. Google has a thorough process that takes five days. A five day sprint isn’t possible for everyone, so I’m going to focus on the shorter sprints we’ve done at IU Communications. We’ve assembled our own design sprint process with help from Google, conference workshops, and good ol’ trial and error.
Setting yourself up for success
Your sprint will only be successful if you take the time to understand your users as well as the environment and context in which your “product” will live. These four steps are crucial to a successful sprint.
Step one: Identify the problem you’re trying to solve
Your sprint won’t be effective if you don’t have a clear understanding of the problem you’re trying to solve. The problem can be something specific, like a staff directory, or it can be broader, like the redesign of an entire website.
Once you’ve identified the problem it’s time to dig into it—to really understand all of its ins and outs. Start by asking these four questions.
- What do you do?
For a website redesign this could be understanding what your organization does for the target audiences. For a specific component, answer what the component does for the audience.
- What is painful?
What isn’t working for the target audience? Do they not understand who you are? Do they have trouble using a feature? It is important to understand their pain points and find a solution that eases the pain instead of making it worse.
- What do you love?
What is working well and resonating with your audience? What is it about your organization that your audience loves? Understanding this will help ensure you build on what is working.
- What do you wish?
What do you want to happen? What do you want users to think about your organization? How do you want users to interact with your tool? Answering these questions helps clarify where you want to be in the future.
Document your answers and share them with the sprint team and project stakeholders before the sprint starts. This information will also be important in the first phase of the sprint.
Step two: Understand your users
Hopefully you have up-to-date research about your audiences and how they interact with your website or tool. If not, you’ll need to spend some time learning about them before embarking on the design sprint. You’ll be designing blind without it.
User research doesn’t require a lot of time and money. Here are some methods to quickly gather audience insights.
- Usability testing
Watch people use your existing website or tool. What problems are they having? What questions are they asking? What is their experience like?
- User interviews
Talk to your audiences—get to know them and how your organization fits into their life. What are their challenges and successes? What do they know or think about you? What do they need from you?
Create surveys to get information from a bigger audience group. Ask them whatever it is you need to know about them. We can help with audience surveys.
- Analytics review
Take a look at your web analytics. Where are people going? Where are they dropping off? What are they searching for on your website?
- Review industry research
Look for third party research about your audiences. Eduventures and the Pew Research Center are good places to start.
Try to use at least two of these research methods before starting your sprint. One method of research won’t give you a complete picture. At the same time, you don’t want to do so much research you never get started. It’s all about finding the proper balance.
Step three: Understand the playing field
You understand your audience, but what do you know about your competitors? It’s time to do a bit of digging to understand the context in which your website or feature will live.
We recommend looking at competitor sites. What are the similarities and differences? What are the trends? Do you want to follow those trends or do your own thing? Understanding the landscape will help inform these decisions.
You should look around at non-industry websites for inspiration—you never know where inspiration will come from. Also look at the websites, apps, and tools that your audiences use. It will give you a good understanding of the interactions and interfaces that your audience is familiar with.
Step four: Plan the sprint
Once your research work is done it’s time to start planning the sprint itself. This is where you decide the length of the sprint. We’ve done four hour sprints and multiple day sprints. The length usually comes down to the schedule of participants and the schedule of the project. In our experience the minimum amount of time you’ll need is four hours, but multiple day sprints are more effective.
- Identify the team
Figure out who needs to be at the sprint. These should be people who will be doing the work as well as decision makers. If the decision makers can’t be there, create a process for getting their approval.
- Share the information
Once you’ve got the team set, share your research with them. It is important to set the expectation that participants need to come to the sprint having read and digested the research.
- Gather materials
Secure a space, mark off calendars, gather supplies. I’ll cover this in more detail in a later post, but you’ll need post its, pens/pencils, paper, tape, small dot stickers, and space. Design sprints are analog—at least at the beginning. Put away devices and computers.
- Schedule usability tests
Recruit participants to test your prototype you’ll be building in the sprint. Five is a good number to start with. Scheduling the tests ahead of time provides a tangible deadline to work toward.
Upcoming posts will focus on the sprint activities themselves. Until then I’d like to leave you with some things we’ve learned from our sprint experiences.
Words of wisdom
- The more complex the problem, the more time you’ll need. If you’re trying to rework a website you’ll need multiple days to be successful.
- If you’re focusing on a smaller component you can get away with less time—maybe four to eight hours.
- Be very clear about expectations prior to starting the sprint. Success requires everyone to come prepared—especially during shorter sprints.
- Make sure everyone has the resources and time they need to properly prepare and participate.
- Have a clear plan for what will happen if you don’t get through everything during the sprint. Plan for variety of scenarios before you begin.