Design Sprints can help organizations devise new products, services, programs, and processes. However, they’re not a blanket fix for everything. In this post, we explore how to apply this innovation framework and its problem-solving methodology to impact-driven projects.

• If your agency has pitched a Design Sprint, this post will help you better understand the process, time, and resources required.
• Through a case study of our Design Sprint work with the Alliance for the Great Lakes, we will also share how this multi-day, human-centered design process creates value for organizations.
• Coupled with our problem framing workshop post, you could also use it to facilitate your own Design Sprint. Deeply understanding the problems we hope to solve can help teams design more sustainable solutions.

Better Innovation = Better Products and Services

Companies, government agencies, and nonprofits could all stand to improve their innovation and problem-solving capabilities. Common impediments to progress impact many organizations:

• Siloed or hierarchical organizational structures
• Outdated business management practices
• Lack of diverse perspectives

This can be especially challenging when your work focuses on solving social and environmental problems, as with many nonprofits, B Corps, and social enterprises. 

Design Sprints offer ways for organizations to foster better communication, stronger collaboration, and more successful problem-solving capabilities. In turn, this leads to better results faster and, often, for less money. 

Design Sprints in Business

Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype. The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.

— Google Ventures

Design Sprints are used by organizations of all stripes to solve complex business problems. They help teams quickly make progress toward solving specific problems for specific groups of people. Design sprints come in several varieties. All are intensive, hands-on, multi-day workshops.

While Design Sprints have historically been the purview of for-profit businesses, social enterprises, B Corps, and nonprofits can take advantage of this framework as well. Let’s explore how. 

Design Sprints for Social Impact

Because they are heavy on exploration and validation, Design Sprints tend to work well for problems that aren’t very well-defined. Perhaps your organization wants to create a program to address a certain community problem, for example, but you have many unanswered questions. Within the span of a few days, a Design Sprint can help your team:

• Clearly understand a problem (and who has it)
• Brainstorm and identify potential solutions
• Create prototypes to test those solutions with real users
• Build consensus on clear next steps

Conversely, a Design Sprint may not produce enough new insights to make the intensive process worthwhile if:

• You already have a clearly-defined problem
• Your team has answers to primary questions
• The organization already has a solution in mind

However, if you work with an external party like a consultant, strategic partner, or agency, the process of collaboration in and of itself can yield extraordinary value for all involved. The collaboration process alone could justify the commitment a Design Sprint requires. 

Answers Over Assets

While co-creating prototypes is part of the process, a Design Sprint’s primary purpose is to validate (or refute) potential solutions to complex problems. In other words, you wouldn’t use the Design Sprint framework to actually build a website. However, you could use it to answer important questions critical to your website’s success. For example, you might ask users, “Do users understand the registration process?”

Traditional business value is often measured in monetary means—number of products sold, for instance. On the other hand, impact problems require more nuance and are often not as easy to measure. The number of online donations, for example, is a helpful metric. However, it doesn’t tell you whether you’re solving a specific problem, such as raising people out of poverty or ending hunger in a local community. You need these answers to know if your impact-driven programs are successful.

Understanding this, Design Sprints can help you figure out whether or not a given solution might work. However, it is important to stay focused on outcomes, which can be challenging to measure, versus output, which is easy. For example, “we added four features to our app today.”

Our Design Sprint Process

Design Sprints comes in several forms, but most typically require 4-5 business days to execute plus ample prep time before and reporting time after. Here’s what we have found produces results. 

1. Identify Stakeholders: Prior to a sprint, we collaborate with our client’s team to identify a diverse group of stakeholders with different perspectives who will attend. We also research the problem they hope to solve in preparation for the next step.
2. Problem-Framing: A half-day problem-framing workshop before the sprint helps the team get clarity on which specific problem we want to solve and how to clearly define that problem. We assign user persona homework at the end of this workshop and, if necessary, adjust who needs to attend the sprint.
3. Understanding: Our first full sprint day together is spent running exercises meant to help everyone better understand the specific problem we hope to solve and identify potential solutions. Persona creation and customer journey mapping figure prominently in this day. 
4. Sketching: On day two, we sketch out ideas to visually communicate potential solutions and create consensus on the best ones. 
5. Prototyping: Day three is spent collaboratively designing a prototype. The make-up and level of fidelity required for this prototype varies from sprint to sprint. 
6. Testing: On the last day, we use the prototype to conduct several interviews with target users, asking probing questions and observing how they interact with it. Between interviews, the team regroups to discuss what was learned and decide if we need to change our approach on the next interview to get more valuable answers. At the end of this day, we decide on next steps based on what we learned.
7. Reporting: Shortly after the sprint, we share everything that was captured during our time together along with recommendations to continue progress. 

Addressing the Problem of Great Lakes Beach Litter

For the purpose of this post, we will reference a Design Sprint with our client the Alliance for the Great Lakes. Our sprint focused on their Adopt-a-Beach program, which in 2018 alone resulted in 35,606 pounds of trash removed from area beaches during 900 cleanup events on all five of the Great Lakes.

The Adopt-a-Beach software had several major problems:

• First, it was buggy and often didn’t work as expected.
• It also didn’t work well on mobile devices.
• Finally, it was challenging for admins and volunteer leaders alike to manage.

The Alliance team wanted to challenge their assumptions about how best to improve the Adopt-a-Beach program, so we recommended trying a Design Sprint. The results were transformational:

We started out wanting to improve the Adopt-a-Beach website. Ultimately though, the ideas generated throughout the Sprint led us to change our thinking about how some parts of the program work. I think the distinction is a key one for us that showed the power of this type of exercise. We started with a problem—crappy website—and ended up challenging some of our assumptions about how the program works (beyond just the website). Overall, we’re going to end up with a stronger program and a better digital experience for our volunteers.

— Jennifer Caddick, Alliance for the Great Lakes V.P. of Communications and Engagement

Here’s what we collectively learned in each of the steps mentioned above.

Identifying Stakeholders

During initial calls and correspondence, we identified four distinct user experiences in the Adopt-a-Beach program: 

1. Volunteer signups to participate in beach cleanups
2. Volunteer leaders registering to create a beach cleanup
3. Volunteer leaders running beach cleanups
4. Admin reporting experience for Alliance team members.

Of these, the Alliance team identified the volunteer leader (#2 & #3 above) as the most important user for this exercise. We chose to focus on their needs for the Design Sprint.

We then set to the task of identifying an appropriate group of diverse stakeholders with different experience and expertise to attend the sprint. Invites and scheduling followed. Once the team was in place, we sent out a process overview so everyone knew what to expect ahead of time.

Problem-Framing Workshop

Problem-framing is a critical precursor to running a successful Design Sprint. Prior to the sprint, we run a half-day problem-framing workshop to explore the problem we hope to address. This includes:

• Writing problem statements.
• Mapping those statements to a grid based on impact and effort, which helps us prioritize the most important statements.
• Identifying key stakeholders.
• Exploring target user problems.
• Finally, we map user problems with organizational business goals to identify where overlap exists. This is useful to help everyone better understand problem-solution fit.

At the end of the workshop, we reframe our problem statements and vote on a final statement that everyone can get behind.

Proto-Persona Homework

The last thing we do in a problem framing workshop is to assign a bit of user research homework. Yes, there is homework in a Design Sprint! We ask attendees to fill out a proto-persona template between the problem framing workshop and start of the sprint. This gets them thinking about user needs ahead of day one. 

What We Learned

This short workshop not only set the tone for our work together in the Design Sprint, but also helped everyone clearly understand which problem we planned to address prior to starting the sprint itself. It also helped us align our work with the Alliance’s larger organizational goals.

Why This is Important

Problem framing helps everyone better understand which problem you hope to solve, why, and for whom. This clarifies important details and saves significant time, since everyone is aligned on what to expect and how your work together fits into the big picture. A problem framing workshop also helps you identify if you have assembled the right team for your sprint.

For a detailed breakdown on how we approach problem framing, please see our post Solve the Right Problems with this 7-Step Problem Framing Workshop Template, which includes a free deck download.

Day One: Understanding

The customer journey mapping process was useful to get everyone on the same page, especially for staff who don’t interact with the website on a regular basis. This made it much easier to identify pain points and brainstorm potential changes as a whole team, instead of individually.

— Alliance Sprint Team Member

Our goal for the Design Sprint’s first day is to deeply understand important components of our work together, including target user needs, pain points, long-term goals, and so on. This includes the following exercises:

• Lightning Talks: Individual team members share what they know and their points of view on the problem we hope to solve.
• Long Term Goals & Questions: Starting at the end, we define what success looks like, then work our way backwards, through clarifying questions, to figure out the steps needed to achieve it.
• Proto-Personas: After the problem-framing workshop, team members are asked to define who we’re designing for. During this exercise, we review homework from the Problem Framing Workshop and have deep conversations on our assumptions about users and how to validate or refute them. Read our post How to Get the Most out of User Personas for more details on how we approach personas.
• Customer Journey Maps: These help the team identify key experiential touch-points in a customer’s journey through a process. For more information on how to run a customer journey mapping exercise, check out our post What is a Customer Journey Map? They often take two forms:
  • Current State: A point-by-point breakdown of a customer’s existing experience, this exercise is very helpful for identifying key areas to improve a product or service.
  • Future State: An aspirational map that helps everyone envision an improved experience over the current state.
• Expert Interviews: The team interviews experts with deep insights into customers, other similar efforts, the program vision, and how things work. In a typical sprint, these could be team members or invited guests. With the Alliance, we had enough expertise within the team that external resources weren’t necessary.
  
• How Might We (HMW): Based on insights gleaned from the expert interviews, the team reframes problems as opportunities in the form of questions, beginning with the words “How might we…”.
  Affinity Mapping & Voting: We group HMW notes into similar themes, labeling each group separately and discussing important distinctions or similarities between each. Then the team votes on the most thought-provoking or useful HMWs. Winning notes are placed on the journey map near a corresponding step.
  
• Pick a Target: The time of reckoning for day one, the team chooses a target to work on for the remaining days.
  
• Research Homework: Team members are asked to research existing ideas, other products and solutions or services that might be useful to provide some context for the next day’s activities.

Yes, this is a lot to cover in a single day. Design Sprints are not for the faint-of-heart! The rapid-fire nature of these back-to-back exercises, however, keeps everyone energized throughout the day.

What We Learned

Through collaboration and consensus-building during the day’s exercises, our team walked away from day one with a much better and more unified understanding of volunteer leader needs, their problems, and ideas for several potential solutions to make their Adopt-a-Beach experience a better one. 

Why This is Important

Using more traditional user research methods, the process covered during day one of a Design Sprint could take weeks, or even months. By running these exercises in succession on a single day, sprint teams can make important project decisions and move forward quickly.

Day Two: Sketching Solutions

The sketching was great. It was challenging, as it is a very different way of thinking for some. But I think it really helped shake loose some new ideas.

— Alliance Sprint Team Member

Day two helps the team get closer to a potential solution through a variety of sketching activities. Not everyone is comfortable with their sketching abilities, so it can be helpful to let people know that if they can draw a box, a circle, or a line, they’ll do just fine in these exercises. Day two exercises include:

• Lightning Demos: Each person gives a 3-5 minute presentation on what they learned in their research and why it could be useful to the team’s work together.
• Divide or Swarm: Reviewing the previous day’s artifacts, the team decides whether or not the entire team will tackle the same part of a given problem or individually focus on various parts. This is useful in order to get the most out of the following sketching activities.
• Sketching Activity: The team sketches potential solutions to your problem. This activity takes place in four parts:
  • Notes: Individuals review everything created or presented thus far, capture ideas, and take detailed notes relevant to a potential solution. This forms the basis of a sketching plan.
  • Ideation: Attendees jot down rough ideas, doodles, diagrams, etc. relevant to the proposed solution.
  • Crazy 8’s: Team members sketch out their strongest idea first, then rapidly create seven variations, one per minute. 
  • Solution Sketch: On a three-panel sheet, each person sketches out their best idea with enough detail that it can be easily understood by others.
• Critique & Review: Each team member takes turns narrating another person’s Solution Sketch. Notes are captured and place alongside each. Sketch creator clarifies if anything was missed or misinterpreted.
• Sketch Voting: Team votes on the sketches they are most excited about. 
• Storyboarding: Winning sketches are incorporated into a whiteboard grid. Using the Future State journey map and other artifacts as reference, the team creates a detailed narrative storyboard from the time a user first discovers the product or service until their last experience with it.

During sketching, storyboarding, and throughout the entire Design Sprint process of an impact-driven project, it is important to regularly step back and take a look at the full ecosystem. It’s easy on a Design Sprint to get caught up in the minutia. Taking a Systems Thinking-based approach to a design solution, however, gives the team an opportunity to consider their work in a broader context. This can help them potentially identify unforeseen consequences of their solution while they’re working on it rather than after the fact. 

What We Learned

While not everyone felt comfortable with the act of sketching, those exercises helped the Alliance team better understand specific components of our target user’s experience. This helped us move things along quickly once we got to storyboarding. 

Why This is Important

Sketching helps people think and communicate visually, rather than with words. This helps everyone absorb and process new ideas more quickly and effectively. By naturally progressing from small components to a larger journey via the storyboard, a sprint team can easily sweat the details while also seeing the bigger picture.

Day Three: Prototyping

I enjoyed the prototype part the best. Our group already had a lot of consensus around what the problem was and what we needed to do/what we wanted. Seeing it in person was very helpful.

— Alliance Sprint Team Member

During day three, the team builds a prototype of their solution to test with real users on day four. What you create (and how) will depend on several important factors:

• Your team’s technical capabilities
• Whether you’re prototyping a digital product, a service, a physical object, or a physical space
• Available time

To prepare for a successful prototyping day, we consider several things very carefully:

• Tools: Whether you use Google Slides, InVision, PowerPoint, JavaScript libraries, or cardboard and glue, choose tools that the team feels comfortable with. There is no room for steep learning curves while prototyping.
• Roles: If possible, the team should include:
  • 2+ Makers to create screens, pages, assets, etc.
  • 1 Stitcher to combine components into storyboard steps
  • 1 Writer to create appropriate content elements
  • 1 Asset Collector to find images, icons, samples, photos, etc.
  • 1 Interviewer to write questions and conduct customer interviews
• Planning: Assign team members tasks based on their roles and preferred tools. Clearly communicate processes for integrating individual work into the team prototype and where team members can find additional tasks once completed.
• Prototyping: The team should move quickly. Don’t strive for perfection. Keep the prototype simple and focused on the main features to be tested. Keep in mind:
  • Consistency: Prototype pieces should match one another and fit together.
  • Quality: Too low and your prototype won’t be believable; too high and you could run out of time.
• Trial Run: To prepare for the following day’s interviews, one person presents the prototype to the entire team, who revisits storyboards, sprint questions, etc. while reviewing. Have expectations been met? If necessary, fix any mistakes, patch gaps, and so on. 

Oh yeah, and we also have plenty of healthy snacks on hand.

By the end of day three, the team should know which questions they want to ask users, understand the interview process (observational vs. prompted interactive interviews, etc.), and be comfortable with their roles during the testing process. 

What We Learned

Important insights arose during storyboarding that helped the Alliance team rethink their prototype. Initial expectations were to create an entirely digital experience managed via a website and/or mobile app. Through the storyboarding process we realized that some interactions could be more easily managed through email, paper forms, or even phone calls. This drastically changed prototype content. 

Why This is Important

Prototyping produces artifacts that users or customers can interact with. Even if you end up throwing the prototype away, you will get valuable feedback that greatly increase your chances for success.

Day Four: User Testing

I really appreciated the different ‘check-ins’ you did throughout the week. I could see that those smaller conversations gave participants a chance to individually express questions or concerns throughout, especially if they weren’t comfortable bringing them up in the full group. It’s great to be aware that people have different communication preferences.

— Alliance Sprint Team Member

Customer interviews with the completed prototype comprise the final day of our Design Sprints. We allow enough time to conduct a thorough interview with at least 30 minutes between interviews to regroup, discuss what was learned, and so on. During our sprint with the Alliance for the Great Lakes, we scheduled interviews 90 minutes apart, which worked well. 

Room Logistics

To ensure your final day’s interview go smoothly:

• You’ll need two rooms: a small interview room as well as the sprint room with all the week’s artifacts nearby for easy reference.
• A video conferencing setup is ideal. This way you can stream the live interviews into the room with sprint participants so they can take notes. We use Zoom, which works well. Just be sure the two rooms are far enough apart that you don’t hear any unwanted echo or feedback.
• In the sprint room, use a whiteboard separated into columns for each interview subject. Add rows as necessary for team to take group notes per screen, feature, and so on. 

Interview Subjects 

Here are some important things to keep in mind.

• Schedule interviews several weeks out and have backup subjects in case someone can’t make it. 
• Recruit as diverse a set of interviewees as possible. Diverse perspectives lead to better solutions.
• Incentivize interview subjects where possible, whether this means paying them with cash, offering a gift card, a free membership, or some other means.

Using the whiteboard and/or individual notepads, make sure your team captures screen-by-screen notes on user feedback. Using markers or stickers, mark positive feedback green, negative feedback red, neutral feedback black.

Day-End Debrief

This is very important to do and easy to gloss over since everyone is tired and anxious to finish the sprint. Run a debrief at day’s end with the entire team and be sure to capture the following:

• Review personal notes and what’s on the whiteboard, searching for repeat patterns in user feedback.
• Review all artifacts from the sprint, comparing them with customer feedback. What similarities exist? Were there unexpected surprises or vast differences between your expectations on days one and two and what you heard during the interviews? Where were your assumptions correct? Where were they off?
• Have a team discussion on what was learned, giving everyone ample time to share and be heard. Also—and this is very important—identify whether your initial assumptions on how to solve the problem were on point or does the team need to course-correct to explore another idea?
• Finally, agree on next steps as a team. Will you need another Design Sprint to explore a different idea? Can you move forward with production using your prototype as a baseline? Answer these and any other dangling questions and capture your answers in a document to reference later (very important!).

By the end of a Design Sprint your team should feel both exhilarated and exhausted. Intensive, hands-on group collaborations like this can foster a lot of excitement and desire to continue the shared journey of problem-solving. Given the intense and nonstop time commitment a Design Sprint requires, it can also be quite tiring. Try to stay focused. By day four, people can get overwhelmed and tired, so it is easy during the debrief to gloss over insights and next steps. This is why post-sprint reporting is critical. 

What We Learned

Our interviewees for the Adopt-a-Beach prototype, who varied in experience level and expertise, gave us incredibly insightful feedback. With everyone a little frazzled from the long week, we learned the importance of staying focused while facilitating debrief conversations and capturing any feedback or important decisions made during this process. 

Why This is Important

This day is the culmination of your Design Sprint efforts. The feedback you get from each interview will, ultimately, drive how you proceed with the project. It’s a make-or-break day. Be sure everyone understands what’s at stake and is as fresh and alert as possible to make the most of your efforts. 

Post-Mortem: Reporting

The intensive focus was exhausting but well worth it. We cranked through so much more in a week than we could have done over a longer series of conversations.

— Alliance Sprint Team Member

Immediately after completing a sprint, our team creates a report with recommendations to keep project momentum moving forward. Design Sprints are front-loaded to maximize participants’ time and ability to quickly reach potentially viable solutions. To be successful, however, the groundwork laid during a sprint must be used to inform how any given project proceeds. It doesn’t end at the prototype. 

Here are a few important things we include in our post-sprint report:

• Insights to Action: During a sprint, teams make collective decisions on how best to proceed with one task or another. These decisions can get lost in the rapid-fire of sprint activities, so we capture and share them with the team.
• Questions to Answer: Similarly, many new questions arise that don’t get answered. We share this list as well.
• Sprint Artifacts: We share all notes, documentation, video recordings of interviews, and, of course, the prototype created.
• User Feedback: Specific insights and important feedback captured from interviews are listed by category.
• Opportunities: We identify opportunities that arose from sprint learning and make recommendations on how best to proceed so as not to lose momentum.
• Parking Lot Ideas: Finally, many great ideas come up during a sprint that aren’t directly related to sprint content. We capture and transcribe these so the team can revisit them when it makes most sense.

What We Learned

Our Sprint Report provided numerous recommendations for ways to proceed after the sprint was over. The Alliance subsequently facilitated several similar internal workshops using exercises learned during the Design Sprint process. These things clarified their thinking about how best to proceed and set them on the path to revising their overall program and producing the final digital product.

Why This is Important

A Sprint Report is the lasting document of your week together. In a perfect world, it is revised often and becomes a living testament to continued progress over time. Even if you don’t change or revise it, the recommendations should be a reminder that your work on the new product, service, program, or process has only just begun

Is a Design Sprint Right for my Project?

Design Sprints are a big commitment in a relatively short period of time—kind of like this blog post. If you read this far, thank you.

Design Sprints also aren’t a silver bullet for every problem or project. Sure, you can apply the framework to a wide array of problem types, but depending on the answers your organization needs to know, a Design Sprint might not be the best way to find them. However, if you want answers to some specific questions and would like to learn how a potential solution might impact a target group of people, a Design Sprint could be a good fit.

We have found some very compelling reasons—the time and money they save over the long run being at the top of the list—why you might want to add Design Sprints to your arsenal of problem-solving tools. In our humble opinion, the payoff is definitely worth the investment.

If you have questions about Design Sprints or the content in this post, feel free to reach out to us.