More and more of our clients are getting excited about implementing the Sprint framework into service design projects. They are impressed with how energy-boosting this way of working is. Best of all, in just one week you can solve strategic service issues.
By now you probably know about the basics of a design sprint, but I’ll quickly summarize it for you. A Design Sprint is a five-phase framework developed by Google Ventures that helps answer critical business questions through rapid prototyping and user testing. At Google they mixed the most effective business, design and research strategies into a framework that supports both divergent thinking and convergent thinking in only one week. The methodology has evolved within Google Ventures over time and continues to be refined and tested. At Koos Service Design we adapt the framework to fit our service-oriented clients’ needs and limitations, while honoring the theory behind all phases in the original Sprint. Curious about initiating your own Design Sprint to solve strategic service issues? All learnings below can help you in organizing a successful Sprint.

1. Gather the right crew
The key to organizing a successful Sprint week is making sure the right people are in your Sprint team. The “right people” are not necessarily those people in your organisation that want it most. It is those who will be owners of and working on the service moving forward. This is important because the work that happens in a Sprint is setting the strategic direction for the entire project. Ideally your team would therefore also include any key leadership that have the ability to reject the outcomes of the Sprint. Make sure the team is not too big: according to the Sprint framework the ideal team size is maximum 7 members, ideally at least a UX designer, a user researcher, product owner and an engineer. When you want to involve more people, invite them for lightning talks (see below).

2. Align & Focus
Align your Sprint team during the planning phase by defining the desired challenge, goals and deliverables together. Be sure to validate this with your team’s leadership (CEO or other stakeholder) beforehand to ensure you have support along the way. When the challenge, goals and deliverables remain vague, you’ll end up constantly having to manage expectations during the week and burning a lot of energy in stakeholder management. A good challenge is a clear sentence such as “Redesign the onboarding process for your app”.
By placing clear limitations on the build, our teams were all able to solve their Sprint challenge, rather than getting excited about all the possible nice-to-haves that wouldn’t necessarily serve the project best. Having only one day to build a prototype means you want to clear away everything that doesn’t fit your focus. Keep this in mind in every aspect of the Sprint week and don’t hesitate to interfere when a discussion or route is going too far from the initial Sprint challenge.

3. Invite expert team members for fresh perspectives
Invite expert team members on the first day to give lightning talks. This gives these people a voice and a chance to share their expertise. It also gives the team a sense of ownership over the Sprint’s outcome. And they can introduce fresh perspectives.
If someone can’t join the Sprint, but has important insights or information to share, schedule them to present in the lightning round. These talks are meant for sharing aspects such as technical opportunities or discussing previous efforts, or for setting up the context and vision for the team. Because the more information your Sprint team has about the problem at hand, the more likely they are to develop viable solutions. These talks don’t need to be done in person; they can be presented remotely.
In short
A Sprint is an effective and hands-on way to tackle challenges and create tangible results within a week. At previous projects we’ve always felt some discomfort in the planning phase because of the one-week pressure-cooker working method that is imposed on the team. But the results and the process have convinced many skeptics. Any issues could mainly be traced back to deviating too much from the original Sprint framework. In the end the right crew, focus, alignment and insights will deliver results that are a solid foundation for the next steps in your service design project.


