Design thinking for Startups

How to do a fast and powerful brainstorm for great ideas

Embrace the “Nano Sprint”, a brainstorming tool to mind map potential prototypes using the Google Design Sprint approach — without losing your core team for five days! Spoiler alert: It will take them only about an hour.

By Johann du Toit

Building testable prototypes using the Nano Sprint

One of the scariest things about launching a startup must be not knowing whether you’re really onto something. Startups in the ideation stage can run all sorts of processes to make sure they have a bullet-proof idea, of which one of the most useful has to be the Google Design Sprint. In five days or less, teams can be coaxed into creating viable, user-friendly product ideas, skipping straight from coming up with an idea to testing it, without wasting money and time on building and launching a product first to see if it works.

The trouble, though, is that as sweet as that five-day sprint sounds, sometimes you just can’t afford to sacrifice an entire team for a week to brainstorm in this way. It could be a matter of funding. Or an issue of capacity. Or you’ve run out of time. You need some great ideas from your team, and you need it fast. All you have is a few hours to spare.

You need what I call a “Nano Sprint”. This powerful little Mini Me of the original Google Design Sprint takes the best of the process and distills it to its essence to deliver a highly effective, time-pressured brainstorm. It might not allow you to properly prototype and do much user testing, but it will allow you to come up with dynamite ideas that you could consider exploring further. It basically unleashes the magic of constraints on your team, enabling them to conjure up some cool ideas within an hour or two.

I can vouch for it, having talked a group of people through the steps at our most recent I|O Powwow meetup. We combined people from diverse backgrounds, including web developers, designers, entrepreneurs and marketers, and got some pretty decent creative nuggets out of it. Lets go…

Step 1: MAP 10 minutes

• Make up small, mixed skills groups: Let each team sit around their own table.
• Give the teams a pressing real-world problem to solve: In San Francisco it might be to navigate the unaffordably high cost of living in the city, in Cape Town it might be to solve the water crisis, and in India it may be to improve access to chronic medication in rural areas.
• Build a quick user profile: Give each team three minutes to interview each other to tease out who the ideal user is and what they might be looking for.
• Provide stationary: Give everyone a few A4 sheets, a small pad of sticky notes, some nice colourful pens or sharpies, and two sticker sheets in two different colours and sizes.
• How Might We’s: Now ask everyone to tackle the problem individually with some optimistic “How Might We” questions. They get three minutes and one sticky note per question to unpack any interesting ideas or new approaches to The Problem. Let your imagination go. Don’t get stuck on trying to decide whether to do a mobile or web app just yet. Let the problem guide you before deciding what the best solution is. It could end up being a piece of tech, infrastructure, a process, a campaign or whatever.
• Affinity mapping: Take one minute to group all the stickies into categories. Write the name of the categories that seem to be emerging above each cluster of related stickies. Don’t worry if the categories aren’t immediately apparent. Look for overlaps or duplicates to get started. Revise or change the categories to create the most useful map.
• Voting: Each team member gets one minute and three dots to vote strategically on the smartest, most practical How Might We’s. The point here is not to try to get to one direction yet, but rather to force everyone to think critically.

Step 2: SKETCH 14 minutes

• Fold your Crazy 8’s: Once each team has checked which How Might We’s got the most votes, they get to put their drawing skills to the test. Each person needs to fold an A4 in half and then in half again twice more to get eight squares.
• Sketch: Each team member gets 10 minutes to sketch up to eight ideas that they think could solve The Problem.
• Vote: Each team then gets one minute to vote on the designs within their teams that they think could actually work. Each person gets three big stickers to vote on best overall concept, and unlimited small stickers to indicate which individual features they like best.
• Solutions sketches: Setting the timer on three minutes again, let each person select their favourite main idea or smaller features to emerge out of the group vote. They need to then merge those ideas into their own sketch of their ideal prototype on an A4 using as many frames as needed, with words, pictures and a memorable title.

We’ve passed the halfway mark, so now it’s going to go fast.

Step 3: PROTOTYPE 8 minutes

• Vote: Giving everyone three minutes, let the teams vote again, this time on the one best idea to emerge out of each group.
• Visualisation of product: Taking five minutes, the teams must work together to sketch or make a mockup to create a representation of what the chosen product might look like, using the best idea. They can however also pull in some features they liked from other ideas to improve the overall awesomeness of the final prototype. They will be using this prototype to test responses from ‘users’ in the next phase.

NOTE: There are loads of great prototyping apps and tools out there, such as Flinto for app design, that you can use if you have a little more time to spare for this phase. But if you’re in a hurry, paper is fine too; just know it won’t give you the same depth of user feedback on the UX of your product as a scrollable, clickable prototype.

Step 4: TEST 10 minutes

• User testing: Now your teams have the chance to unleash their ideas on real potential users. In the Nano Sprint, give the teams 10 minutes to split up, with one half of each group rotating to another team’s table. They are now the other team’s interviewees. Teams then pitch their ideas to their ‘users’ and record their feedback, whether through scribbled notes, sound or video recording. In a real Google Design Sprint the design team might sit in another room and watch a live stream of actual user interviews about their prototype.

A Real McCoy sprint will end with one of three results:

1. Efficient Failure: Learn from your mistakes and move on
2. Success: You produced ideas that were good enough to take further in another sprint
3. Epic Win: Move to production

In a Nano Sprint, however, you’ve had a successful brainstorm if you’ve been able to find an idea mind-blowing enough to justify freeing up some resources for a longer sprint with real users, or at least a killer pitch to a client who might pay for it. It’s a win-win situation because you’ve filtered out the best ideas in record time, and you’re virtually guaranteed that your best ideas will deliver an Epic Win if you do decide to do a longer sprint!

This brainstorming methodology could even be adapted to areas outside of the product prototyping realm. Imagine how useful this kind of pressure test could be if digital, ad or PR agencies used a similar process with their clients in the room, to generate campaign ideas, or if scientists used it to think up new inventions? The Nano Sprint is so compact and yet so powerful. Just try it and see what happens.

ABOUT THE AUTHOR

Johann du Toit is a lead developer at I|O Digital in Cape Town and Africa’s first Google Developer Expert (GDE). Google flies him around the world to learn and teach things such as Google Design Sprints and other interesting topics to do with startups.

He regularly hosts meetups such as the I|O Powwow and Google Developer Group in Africa and leads Google Design Sprints for clients at I|O. He is the co-founder and lead developer of I|O-backed startup Passmarked.com, the world’s first comprehensive, open-source platform which tests how well sites work, based on the most up to date web standards.