Hacking Google Venture sprints to expedite design discovery
Before the book was a thing, I did some workshops with Google Ventures - specifically Jake Knapp and Daniel Burka - about their new in-house process Jake had developed at Google called 'Design Sprints'. It was an interesting process being involved in GV Design Sprints, and it made me consider a range of challenges I hadn't really solved in my own workflows - how to involve stakeholders more adeptly, how to encourage teams of designers to move out of safe defaults, how to enable more junior designers to 'own' their concepts and pitch them into groups with conviction - and how to encourage 'mistakes' in the design process. Mistakes are important as they clear the way for stronger ideas, can inspire great ideas, and sometimes can just be great ideas incorrectly defined. Mistakes are the reason I don't use Moleskin notebooks anymore for my note taking; Moleskins make me nervous to sketch in - they force me to sketch in 'high definition'. Effectively they make me afraid of making mistakes, so now I use layout paper and sketch mistakes as part of my process. My desk is awash in pads of layout paper.
Anyway, Sprints are about sketching. And making mistakes. Which is great.
The full GV Design Sprint process boils down an entire product cycle from discovery to concept and test in 5 days. It's simple and effective. It engages stakeholders and the whole business from day one, removes barriers to communication (by getting everyone to draw their ideas and contribute) and forces a fifth day mandate to launch something. I'm not going to go any further into it than that - I'm sure Jake would want you to buy his book instead - rather what I'm going to do is focus on how Sprints can be done (or elements of them) to improve existing design team practises.
One of my favourite processes in Sprints is the use of Crazy 8s - a focus on drawing 8 iterations of something in 8 minutes. Crazy 8s is the 3rd process in the sketching part of the GV Design Sprint, relying on the previous process of generating notes on ideas, then doodling rough solutions. In the existing design structure I had, we already had notes and ideas. The notes were sometimes briefing docs, the doodles often whiteboard ideation sessions. But Crazy 8s was something new. It bridged the gap between the bigger picture looseness of the whiteboard and the more focused higher definition sketches. The problem we also had though was we'd discuss briefing documents in one meeting then maybe whiteboard it a day later. Crazy 8s felt too intense a process to just introduce it at random. It needed to exist within a framework of some kind. This led us to create micro-Sprints.
micro-Sprints
micro-Sprints are just that - smaller and more agile than Sprints. Much like Kanban, micro-Sprints can be called at any time by anyone to solve a problem. We found them useful for designing a new feature or module in an existing product. The team involved in a micro-Sprint should be as diverse as possible - ideally it should involve stakeholders from engineering, design, product and business. Oh, and ideally it should be in a single room with a visible timer. You should time-box the hell outta this.
A typical micro-Sprint involves:
A tl;dr briefing session - this is where the person identifying the problem explains the problem to the group that has assembled. It should be short and to the point. The team should then ask any questions they may have. Imagine it more as a kind of agile standup. (20 mins)
An ideation session - the team then uses a whiteboard to identify the problem and architect some immediate solutions. (20 mins)
Crazy 8s - the team then all take a sheet of large paper, fold it to produce 8 squares, and then iterate their solution 8 times from the previous ideation session. We used Sharpies to draw with - mainly because it helps people who can't draw communicate easily without trying to be neat, and also because you're drawing to communicate, not to win an art prize. (8 mins)
Solution Sketch - the team each take their solutions from the Crazy8s and focus them down to a single large sheet of paper. We used sticky notes to show the refined sketches and the paper to annotate around the sticky notes. (20 mins)
Show & Tell - the team then each individually present their idea, pinning it to the wall or whiteboard, explaining it and - most importantly - fielding questions and comments and then answering them. We found that the questions and comments worked best when they were critical as well as informative. At the end of the presentations we'd use small, brightly coloured circular stickers to vote on the ideas we liked. Each team member gets 10 stickers, and they can vote as many times as they like for whatever idea they like. (20 mins)
At the end of this process you should have a wall of solutions along with a clear heat map of team-led choices as to which is the best solution. And all of this is achieved in under an hour and a half. From here the team can either prototype the solution, or begin higher-def wireframing - depending on the scenario, and the complexity of the solution.
Problem solved.
