When you don’t have time for a 5-day design sprint

Two well-designed days can kickstart your next growth idea

I’m a big fan of the design sprint, and based on the success of the Sprint book, I think a lot of others are too. The five-day process Jake and team outline in the book is easily the best way to build momentum and validate ideas in a short amount of time.

But what if you can’t take your team away from their work for a week to run a design sprint?

It’s not just startups that face this issue. Small businesses and non-profits face similar constraints. Lately I’ve been experimenting with a compressed version of the design sprint that can be done over just two days, or even a weekend.

The basic stages are the same: Identify the right problem to solve, document the experience, brainstorm around focused opportunities, prototype, and test with users. The process, however, is drastically compressed.

There are two main differences that help compress the sprint:

1. Make the assumption that the team already has enough knowledge and expertise around the problem context. This helps move toward brainstorming and prototyping faster.
2. Separate the testing phase and make it asynchronous of the sprint. It is ideal to do user testing immediately after building the prototype, but it isn’t critical. Conducting small tests over the course of a week can be a more palatable commitment for small organizations.

This approach is not without risks, but if time is the primary barrier to doing a design sprint, the two-day approach can help kick start the idea.

If you’re interested in experimenting with the compressed process, I started a public folder with some of the tools and resources I’ve used in the past. There you can find a sample agenda, kickoff presentation template, prototyping resources, and several other tools.