With the near universal acceptance of the design sprint over the past decade, it’s hard to imagine work getting done any other way.
The five-step process (map, sketch, design, prototype and test) aims to be a faster, more agile and more efficient method of creating features. Typically held over five days, the model brings together cross-functional teams to quickly come up with a minimally viable product. Silos are broken down, and the best idea wins.
But as the model continues to be adopted by more and more teams, it’s evolving — and subtle changes are making all the difference.
For instance, instead of the typical five-day timeline, the design team at Spring Health runs a one- to three-day sprint. “Over time, we have found the shorter sprints to be easier to schedule and attend while still remaining inspiring,” Henry Bayuzick, design manager of member experience at Spring Health, said.
And over at Teachers Pay Teachers, the variety of avenues for feedback — through a weekly meeting with internal stakeholders and via research sessions with actual users — have helped narrow the scope of projects for Senior User Experience Designer Zakiya Pope and her team. “I iterate on the feedback and present a more curated solution to my pod for discussion,” Pope said.
Below, Bayuzick and Pope walk through the inner workings of their design sprints, what makes their sprints successful and the types of projects that have flourished because of the process.
First, what does a typical design sprint look like for your team, and who is involved?
Design sprints at Spring Health often stoke excitement across multiple teams. Combining folks from customer support and partnership success with subject-matter experts and members of the product team encourages unique perspectives that lead to fresh ideas and a deeper understanding of users. Separate from the ideas that arise, these sessions have a special quality that exposes the shared passion each individual has for improving mental healthcare.
More tangibly, our design sprints are made up of reviewing the problem space, activities leading to hypotheses and questions, and importantly, time spent together ideating. Most design sprints include a mixture of group work, breakout sessions and individual sketching. Research and validation happen pre- or post-sprint.
Logistically, we tend to run shorter design sprints — usually one-day to three-day events — instead of embracing the five-day design sprint. Over time, we have found the shorter sprints to be easier to schedule and attend while still remaining inspiring. Minimizing the friction of schedule increases the likelihood of facilitating a design sprint and overall contributes to a culture of exploration and collaboration.
What is the key to a successful sprint, and why?
We have found three elements that make sprints successful. First, a design sprint normally warrants a broader problem space that is either net-new or unusually tricky. We like to use sprints for new investments or areas we know our team is excited about.
Second, to run a productive design sprint in a shorter amount of time, plenty of prep and skilled facilitation are required. We often bring research, design Miro boards, and present slide decks to set context and expectations.
Finally, we like to make sure everyone attending has the headspace to focus and explore without worrying about what’s on their calendar. We discourage participants from dropping in and out if they cannot attend the entire session.
3 elements of a successful sprint at Spring Health
- A captivating problem space
- Sufficient planning and facilitating
- Clear schedules
What’s the most impactful idea that you've seen come out of a design sprint?
Recently one of our designers, Daniela Marmolejos, was leading a short design sprint to align on problems that members have when trying to find the right mental healthcare solution and generate novel ways to improve and personalize their experience. During that session, many cool ideas arose but one that resonated with the entire room was enabling Spring users to see third-party services in addition to Spring’s features that they may be able to use based on the members’ answers to their mental health questionnaire. This would ultimately help find the right option for the member even if it’s not something Spring offers yet. At that moment, everyone was able to empathize with the problem members felt and the solution reflected the group’s desire to find an impactful remedy.
First, what does a typical design sprint look like for your team, and who is involved?
Typically a sprint pod consists of an engineering lead, product manager, product designer and one to three engineers. As a team, we jump-start the sprint by mapping out the problem and determining the sprint’s overall goal. We document and capture this information in a product requirements document (PRD) that is owned by our PM. This process helps us to understand our users, define their problems and surface unseen obstacles. Once the PRD is complete, I explore design solutions through ideation — this is my favorite part because I get to create an improved experience for users.
I begin by exploring user journeys to fully map out different paths and, within those journeys, I design wireframes that illustrate how each screen should look. The wireframes can range from low fidelity to full-resolution, which illustrates the exact visuals, typography and hierarchy. After narrowing down several design explorations, I take the designs to a weekly design crit meeting where fellow designers provide design-led, centered feedback. This is a great space for designers to collaborate across projects and talk about all things design! After crit, I iterate on the feedback and present a more curated solution to my pod for discussion.
I explore design solutions through ideation — this is my favorite part because I get to create an improved experience for users.”
What is the key to a successful sprint, and why?
The key to a successful sprint is proper problem-framing, clear objectives and early user validation. Having these three things aligned allows for all core team members to approach their individual task explorations from a unified perspective and leads to a successful sprint.
It is essential to utilize a user-centered approach when problem framing. This approach allows us to better pinpoint users' wants, needs and existing pain points. It also helps focus my design explorations while still considering all perspectives. Having clear user and team objectives allows us to do three things: quantify the impact the new design experience has on users, determine the quality and measure user satisfaction based on agreed-upon measurable objectives and key results. Early validation allows for a more effective design sprint in many ways. It helps to manage stakeholders’ expectations, define the roadmap and focus design efforts.
What’s the most impactful idea that you've seen come out of a design sprint?
Recently, I had the opportunity to design an experience for sellers to see their stores’ Easel data. This was my first time designing for sellers and I was really excited to learn about their experience and pain points on our platform.
As a team, we had our own hypothesis on the ways sellers use their dashboard and product stats page and what data they wanted to see. Even with our insights, we needed to validate these assumptions through user testing, so I created three different design experiences that tested separate approaches to surfacing Easel resource data.
I partnered with our coordinator, PM and researcher to speak with five sellers. We asked a series of questions related to their selling experience and to hear their thoughts on the three design explorations.
The insights that came from this research gave our team tremendous learnings into what sellers do to manage their stores, how they connect with their users, and how sellers evaluate the quality of their resources. Although not all of our assumptions were validated, the learnings were impactful in how we approached the build, future seller tool enhancements and how other teams could approach seller-related features.
