Design Sprint: Fast is better than Good
Jul 2, 2013 | Mobile & Web
A majority of the projects at 8ninths are not the typical production work where answers are clear, solutions are known, and execution exercises are relatively straightforward. Folks come to us with problems that are fuzzy. Whether they’re seeking answers for product strategy, have questions about specific design conundrums or need direction as to what back-end code system to use, we hear it all. The 8ninths team in turn thrives on the challenging ambiguity, and is quite good at providing guidance, recommendations, design or completed products back to our clients.
And while Adam and I are habitual perfectionists, we have learned that just focusing on perfection is often the wrong approach in these types of exercises. In the real world of products and businesses, the competitions are shifting rapidly and continuously and the user behaviors are always changing. Perfect, such as it is, doesn’t exist for very long. Perfect also takes a long time, and by extension, a high cost to achieve. Certain things are worth the strive for perfection, but many aren’t. And thus we have had to learn to suppress our instinctual predilection for perfection and develop another skill: Speed.
Recently we read a great article about the rapid design process by Jake Knapp, a design maven at Google that led many of its most successful products. He created a process called Design Sprint that he’s been using in Google Ventures, which is a mix of VC fund as well as an incubator lab for up and coming technology companies that Google invested in. Each sprint takes a design issue and methodically creates a team understanding of the design, brainstorming and ideation for a number of solutions. Next during the sprint the you build a team consensus and decide on an approach, rapidly prototype the UX, and validate results. All within five days.
What I found impressive about this method is that the focuses are very well thought out. For example, spending the entire first day of the five days on building a group understanding of the issues at first seems wasteful, but I’ve found in my experience that achieving that common understanding makes the rest of the way much easier. The design person will come out of the first day with a much better understanding of the CEO’s motivation for the change, and the CEO has a better understanding of the design constraints for the problem. Done correctly, this allows the team to focus on solutions for the rest of the sprint, rather than constantly re-engaging on the same arguments.
Another area I was very impressed with is focusing the team on objective facts and data, and placing limits on the usefulness of one single person’s subjective thoughts and intuition. For example on the first day during the Understanding phase, the process emphasizes on reviewing existing relevant research and data, focusing the team on the tangibles rather than opinions. While on the last day the Validation phase is used to test the prototype on real user subjects and collect important data and insights to gather feedback for the design. At the same time each sprint participant, whether a CEO or a User Expert, is given opportunities to critique, but are only allowed a limited amount of time as to focus their feedback to those that are most important, preventing any single individual from taking over the design.
I also like his criticism on the traditional brainstorm, which can sometimes turn into a “everybody is shouting” kind of meeting. (Here I do have to humbly brag that at 8ninths we never have this problem 🙂 ) His twist to make it an individual brainstorm is an interesting one, though I do wonder if it defeats the purpose of a group “jam” that successful brainstorms can brain.
All in all, we at 8ninths will be definitely giving this process an honest try, and will report back in a future post. Stay tuned.