One of the best workshops I attended at UX London 2014 was from the Google Venture Design Studio. It was run by two of the design partners, Jake Knapp and Daniel Burka, who talked about how they use 5 day prototyping sprints to design sites and apps for start ups. Some really interesting ideas emerged in the talk, and there were plenty of practical ideas that could be useful in my day-to-day work when thinking about new products and features.
The problem they’re trying to solve is that most software is usually created with several rounds of building, learning and iterating. This is typically how development work has gone everywhere I’ve worked, but it has some flaws in practice. The building phase always takes a lot of time, normally much longer than initially estimated, and once you’ve made something it normally generates it’s own overheads slowing you down further in the future. Even if your initial design wasn’t that great, if it does something useful you’ll probably have gained some users, who will become reliant on features that you’re now stuck supporting even whilst you’re trying to build the next shiny thing. Throw it away, you annoy your existing customers. Keep supporting it, you’re burning up time and are stuck with features you might want to replace entirely.
The aim of the 5 day prototyping sprint is to try and bypass some of that by squeezing the maximum amount of design education into a very short amount of time. It’s been inspired by similar processes at Ideo and Stanford’s Institute of Design, and has been used by Google Ventures against a variety of different domains with problems of varying complexities to provide companies with enough confidence to go out and build the products for real.
For a real life example of this process in action, have a look at this case working with Blue Bottle Coffee, to redesign their website.
The first thing I found interesting was how much of the process resolves around a series of self-enforced constraints, designed to add speed and urgency. A good example is the very first action of the sprint, which is to immediately book a series of customer interviews for the final day. This helps set a firm deadline for the upcoming work.
Here’s an overview of what that 5 day sprint consists of:
Day 1: Understand
Dig into the design problem through research, competitive review, and strategy exercises.
Day 2: Diverge
Rapidly develop as many solutions as possible.
Day 3: Decide
Choose the best ideas and hammer out a user story.
Day 4: Prototype
Build something quick and dirty that can be shown to users.
Day 5: Validate
Show the prototype to real humans (in other words, people outside your company) and learn what works and what doesn’t work.
Notice that very little time is spent actually building anything. It’s not until day 4, pretty late in the schedule, that construction of a prototype begins.
During the afternoon workshop we covered the first couple of days in detail. In this blog post I’ll give you some details about those days, and there are links at the end to Google Ventures own articles about the remaining days if you want to read more. I’ll put up an article about the remaining three days soon.
Day One: Understand
The first day is all about understanding the design problem. For this day you’ll want to include as many people as possible, everyone from the founders to design, development and marketing. All of them will be able to provide insights and will have different perspectives and information that will be useful. The goal is to gain common understanding of the problem, and to this end an outside facilitator may be useful as they’ll need to ask the kind of basic questions that might spark fresh ideas.
Typically this day will consist of a series of exercises. These could include a talk by the CEO about the market and opportunity. You might want to decide what metrics you want to use to measure the success of the project (the Heart Framework). Time can also be spent reviewing the current project – looking at what works well right now, and what isn’t so great – and also looking at some lightning demos of other products which are in a similar space. In our workshop we also ran a series of user interviews to get the customer’s perspective.
Throughout these exercises all of the participants should be jotting down “how might we” questions on post-it notes. During the workshop we were prototyping a flat rental site, so examples that came up included “how might we show users the average house price of an area” or “how might we search for flats near our friends”.
Next take all that information to figure out a single important user story that represents your product. This is the story that will building a prototype for. For our flat example, the group wanted to focus on the process of managing the move itself. Get this up on a whiteboard, so everyone is on the same page.
Day Two: Diverge
The goal of this day is rapidly generate as many solutions as possible. I was surprised that so much of this was done independently, without group brainstorming. I think this is because it’s felt that talking isn’t actually a very effective way to come to a decision, and can lead to “decision by committee”.
Each participant sketches out their designs for solutions to the user story chosen on Day 1, using inspiration from the “how might we” notes that are all over the walls. These are very rough sketches on paper and are done in several stages under a lot of time pressure. These are personal, so you can put whatever you like down – no-one else in the group gets to see them at this points.
First we all drew mind maps, with a deadline of about 5 minutes, to get all the basic ideas on paper at a very low fidelity. Next was a (stressful!) process called Crazy 8s, where we were given a total of just 5 minutes total to produces 8 designs – about 40 seconds each!
Finally is a storyboarding stage. This actually gets shared with the rest of the group, so you get a bit longer to work on it – but still only about 10 minutes. You get a blank piece of paper with 3 post it notes on it, and onto each note you’ll draw some of the UI. Together they represent a progression through the site. The paper can contain annotations. Each storyboard should be named (to make it easy to refer to it in discussions) and should be completely standalone – all the information should be present without needing any further explanation. They’re also anonymous.
Next the storyboards get pinned up on the wall and there is a chance for everyone to view/judge all the other entries. Everyone is also given a sheet on sticky coloured dots – these can be stuck on any parts of the storyboard you think is a good idea. This forms a sort of “heat map” of ideas you’ll want to discuss further.
Each design is discussed for a strict 3 minutes each, and then there is a round of “super voting” using larger sticky dots. This is weighted in favour of the decision makers – maybe the CEO gets all the votes here, or the decision-makers in the company may get additional votes where everyone else only gets a single vote. This process is deliberately not democratic, and again helps fight design by committee.
What did I learn?
- Use rapid prototyping to avoid the build, learn, iterate cycle. How many projects have I worked on that dives straight into building?
- Deliberately introduce pressure: you’ll get things done fast if you have to. Even individual discussions should be time-boxed.
- Talking is not an effective way to design. The goal is to avoid “Design by committee”.
- Design should not be democratic. Design needs an opinion, not consensus.