There’s a great series of YouTube videos by Jake and GV Design Partner John Zeratsky giving both an overview of the entire process, along with a day by day introduction on what will be happening and what the day’s goals are. This was a great way to introduce the team to the process as a whole, but also a nice way to start each day.
What’s the process of starting a new development project in your organisation? Commonly, someone has an idea and creates a business case. The business case contains lots of assumptions, some loosely related statistics, lots of statements about how this project is going to do amazing things for the company, and a price. The business case gets passed from desk to desk, until someone signs-off on it and things get underway. There’s rarely more than two options – accept (at full project cost) or decline.
What if some of the assumptions were wrong? What if customers didn’t react the way imagined? Are the team going down the wrong path with the way the product was designed?
Sprint
We’ve been using a process pioneered by Jake Knapp at Google Ventures which helps solve big problems and test new ideas in just five days. It may not sound like a team can get very much done in five days at all, but I was surprised that the process really works. That may be down to how the process is laid out – it gives day by day and hour by hour instructions on exactly where the team should be focusing their efforts. This means that activities are timeboxed and so the team don’t spend their time going into too much detail on how a concept may function.
The idea is that a team can explore a problem and come up with one or more wireframes, clickable prototypes or even the very beginnings of a website or application that can be tested with five target customers on the final day to get feedback on what works, what doesn’t work and what improvements can be made when the project goes into full development. It may be that the idea doesn’t work at all, and that’s good. There’s been only spent five days effort in finding that out and that’s valuable information. It might be that with multiple designs, customers pick the alternative that everyone believed wouldn’t work (as was the case with the Blue Bottle Coffee Sprint explained in the book. Domain experts sometimes take for granted how others think about buying their product.)
Day-By-Day
Monday we explored the problem, identified risks, created a product map and interviewed domain experts about the problem and the map we’d created. The team took notes during the interview and created “How might we?…” questions. We had homework that evening to list out some UI ideas used by other sites.
Tuesday we used “lightning demo” presentations to present some of those UI ideas to the rest of the team. We used “crazy-8s” (a piece of paper folded into eight sections) to individually sketch prototype ideas, then individually sketching out solutions to the problem. These were very basic sketches and so there was no need to be an artist! We did deviate from the process a little here, meaning that the team reviewed these sketches in a showcase at the end of Tuesday (placing sticky dots on the elements they thought were worth taking forward).
Wednesday the decider (the person with the role of making the final decision) made the decision on what was going to be taken forward to prototype. This process is structured so that the heatmaps created by the team (placing sticky dots) help the decider make the decision. We started prototyping on Wednesday afternoon.
Thursday we continued prototyping with team members given specific roles. Makers are responsible for creating parts of the prototype, Stitchers are responsible for stitching the various parts together, Gatherers are responsible for gathering any assets that the prototype needs, Writers are responsible for writing text to go into the prototype and Interviewers create the interview script. I was really surprised at how quickly something came together.
Friday we performed the interviews, with five potential customers taken through the interview written by the writer. It was fantastic to see the feedback from the interviewees and how they reacted to the different parts of the prototype. Both good and bad feedback was received for various elements, but absolutely all of it was useful to see what could be taken forward into a full build and what could be replaced. Using Skype for Business, we streamed the interview to another room where the developers were taking notes (on coloured sticky notes – red for bad, green for good and yellow for neutral). Once the interviews were complete, we could easily see where common themes existed and even the priorities that could be taken into a full build.
So what did we learn?
- It’s important for everyone to have a shared knowledge and understanding of the problem.
- Sometimes you don’t need to always make the perfect decision. You just need to make a decision, and keep moving forwards.
- Group brainstorming is discouraged in favour of a timeboxed discussion followed by a decision made by the decider. This process is not a democracy, and although the decider can take on board the comments and heatmaps created during the sprint, the final decision is down to them. The team all agreed that this was a really good thing.
- Exploring in depth a small part of the problem and solving most of the problems means that once you start building a prototype, it comes together REALLY quickly.
- A lot of the time the people building the product can get bogged down in detail. You need real customers to find out what does and doesn’t work.
- You need a lot of post-it notes and sticky dots to use this process!
Was it worth it?
Absolutely! We invested five days. Five days! How much time is wasted in your organisation building parts of software projects only to find out that the concept doesn’t work when real customers come on board? How many customers have you lost because the user journey has fundamental flaws that could have been easily weeded out using this process?
Watch the video below to get an overview from Jake on the Sprint:
About the author
IJYI Ltd
IJYI Ltd.