Three Design Sprints Benefits

It’s been a few years since the publication of the book Sprint by former Googler, Jake Knapp, in 2016. If you been lucky enough to participate in design sprints, you know the value of a fail-fast mentality with real outcomes, like the chance to ideate with your team on possible viable solutions, including building and testing prototypes with your actual users.

There are many great takeaways, but from my experience working with product teams, these values stand out the most:

• Design sprints put the focus on the end-users
• Design sprints allow product teams to align not just on the “how”, but more importantly, “why”
• Design sprints build cross-functional team trust

First, a quick review for anyone not familiar with design sprints. We started using design sprints even before the release of the Sprint book in 2016. Back then, we called our version “sequesters”. The idea was to gather the product team into a room without any distractions — no email, no mobile phones, no calls, or other meeting interruptions so that we could completely focus on solving a redesign of a product. Unlike the Sprint model from Google, however, we gave our “sequester” two weeks to complete. Regardless of the length, our process was identical.

We begin with an understanding phase. This meant we visited actual users in the normal setting and observed them using the product, or a Contextual Inquiry. They walked us through their normal daily tasks. This included what they might do during some exceptions of non-normal tasks from time to time. We listened and took notes and then asked questions to take a deeper dive into understanding why they did some things and not others. From this first session of observations, we formed our problem space, identified pain points, and took our learnings back to the product team.

In phase two, we formulate our problem space into “how might we” statements for us to solve and brainstorm on possible solutions for each with the single goal — make our user’s life easier by providing solutions to address pain points without removing any of their high points.

After deciding on solutions in phase three, we go through an interactive process of sketching and rapid prototyping in phase four. We do this to find solutions that addressed user needs and business goals. Prototypes evolved from rough sketches on a whiteboard to eventual interactive designs that we could put in front of our users for validation.

In the final phase, we test our design with our end-users and measure our success. Did we make the improvements we set out to accomplish? If so great! If not, then it’s time to learn from our designs and begin the process again.

Overall, the “sequester” was a huge success for our team. Not only were we able to complete solid redesigns with strong solutions for our end-users, but it created strong bonds of trust within our teams.

At the top of my list is the attention and focus the product team devotes to the end-user and their issues, needs, and wants. Each member of the product team brings their own perspective, from design, technology, business objects, budgets, etc. Day 1 of the design sprint forces us all to put these aside, listen and understand the perspective of the end-user. How do they use the product? What are their workarounds? What is frustrating to them and what works well for them? This is the heart of user-centered design!

Secondly, and building off of my first value is the team alignment our product teams get from building empathy, or phase 1 of understanding the end-user. We all get the opportunity to align on what problems to solve, what elements to keep, and why we are working on this application. No more excuses about some process being a business, design, or development issue, because we all know the work and value that each team member brings to the product and more importantly, how each team member’s contribution affects the success of the end product.

Lastly, there is the trust in your product teams that comes from running design sprints. I have been on too many product teams where the contributions from some team members aren’t as appreciated as others. It’s important that all team members understand the contributions that each team member brings from planning and marketing to design and development. We are all part of the same team and we all want the same success for our product and end-users, which is to build the very best product we possibly can that solves problems and is enjoyed by our end-users.

If you’re running design sprints, what are the values you’re getting from them?