We’ve been big advocates of design sprints. We’ve dropped working with projects, and have been working almost exclusively with Boost, our design sprint format. Why? Because we can adapt and respond better to the job to be done, while following the same rhythm: understand, diverge, converge, prototype, test & learn. Delivering every week, no matter what.
We teach the same mentality to the students of Le Wagon - Brussels. A coding bootcamp of two months, specifically targeted towards young entrepreneurs that want to build the next big thing. During a one day workshop, we teach hands-on the ‘wagonistas’ how to embrace design in product development and deliver successful products to the market.
Figure 1: Our toolbox. A timer is essential for a good design sprint.
When we meet, the students have already worked full 5-weeks in Ruby on Rails and front-end development. Now is the time to put knowledge into practice. Make their ideas come true in the following 4 weeks. The right moment to go through a typical design sprint process and ask them:
- What’s the problem they’re solving for?
- Who are they designing for?
- What do these people try to accomplish?
- To tell a story about their users’ lives, goals and interactions with the product/service?
- To prototype with pen and paper.
- Test their ideas with users.
… and all these in only one day!
We start the day with exercises that help our incubating entrepreneurs understand and empathise with the users’ life.
We first ask them to present their ideas. Grandiose ideas around: healthcare, climbing, food delivery, golf, online learning, and apartment sharing.
We then go through a series of exercises that help us identify the user, their problem, and the job they are hiring the product to do.
Figure 2: Lightweight personas to trigger empathy and storytelling (photo by LeWagon)
##Diverge, Converge & Prototype Once we have defined our personas, users journeys and the jobs to be done, we’re ready to focus on the critical path of each concept. We exhaust our imaginations for potential solutions that meet the users’ needs. Sticky notes, drawings and flows start to cover the walls. Time passes quickly, we’ve to make decisions, it’s time to converge.
Figure 3: Teamwork makes champions
At this point we need to stop generating new solutions, converge on the best, and prepare our prototype for the user test that will follow. With pen and paper we draw each screen we need to test the flow of the critical path.
Figure 4: Quick sketches (photo by LeWagon)
##Test & Learn This is the moment of truth, the moment we test our prototypes. We’ve our test scenario ready, and we’ve assigned roles to each member of the team: a facilitator, a ‘robot’ that changes the paper prototype, a notetaker and a user (from another team).
Figure 5: Testing our prototypes.)
It’s unlikely that any team will nail it their first sprint. The purpose of the test is not to nail it but to learn. To test the hypothesis and assumptions we take during the first steps. To see what works and what doesn’t, and then to run a follow-on sprint starting at Diverge or Converge and test again with new users.
In the end of a hot sunny day (a rare thing in Belgium), our students earned their ice-creams. They worked hard to deliver a testable prototype in less than 7 hours.
They learned how to put people first in their process, how to tell stories, and how to focus on the critical path of their MVPs. They learned the value of throwaway prototypes that will later save them days of coding, and how to test their hypothesis and assumptions.
This article was first published on Medium for Central.