Many companies have begun to discover the benefits of human-centered design. But some feel it’s a big step to start working with UX and customer-driven development in all parts of the company. In order to make our award-winning practices accessible to more customers, we’re looking at ways to divide a project into smaller steps ‒ and Google Design Sprints is one of the methods that are inspiring us right now.
At Screen Interaction, we live and breathe human-centered design. It’s reflected in how we do everything, from initial project brief through research, analysis, ideation, prototyping, testing, to final delivery of product.
However, if you’re new to customer-driven development, such a project that involves developing and launching a qualitative value creating service can be perceived as a hefty investment with uncertain results. To meet the needs of clients who want to try but start on a smaller scale, we’re looking at ways to divide a project into smaller steps. We have some experience from doing shorter sprints, but we’re now looking at a more structured and compressed method, with pre-defined steps, to include in our offering.
While researching the field, we encountered Google Venture’s (GV) Design Sprint, a quick and controlled way of working that has proven results (GV is the venture capital investment arm of Alphabet, Google’s parent company). A “Sprint” can be described as a very structured process made up of two major contributions to the area of product development: Lean Startup, a well-known method within the startup world which favors experimentation, customer feedback and iterative design, and a classic IDEO design thinking process, where human-centered design is the backbone of everything.
Not all processes fit all contexts and organizations, but the method matched our initial criteria, so we did some more research to see what kind of benefits this process might offer. First out, we read the newly released and highly recommended book “Sprint - how to solve big problems and test new ideas in just five days”, but we also read lots of articles, blog posts and other people’s reviews, and even watched some of the most popular videos on the subject on Youtube. We really wanted to get to the core of what Google Design Sprints really is.
In future blog posts, when we’ve had the opportunity to test the method in action with our customers, we’ll put forth our own definition of Google Design Sprints. For now, the best description of the method that we’ve found so far is Google Venture’s own definition:
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at GV, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more — packaged into a battle-tested process that any team can use.
During the five-day sprint, a team of up to seven people from the company get together to work through an important challenge. The purpose is to be able to make informed decisions about what to focus on (or not to focus on) next, by validating the ideas with relevant customers ‒ and to do this within a structured, time-boxed approach.
If you want to dig further into the details of Google Design Sprints right away, this blog post explains most things you need to know.
Since Google Design Sprints are not essentially different from our regular way of working, many of the benefits of the method listed below are already part of our daily work at Screen Interaction. That said, these are the benefits experienced by those who tested Google Design Sprint:
Overall, from our previous experience with running shorter and faster projects, short design processes are great when developing and validating new ideas in a short period of time. To run several short Google Design Sprints, with different focuses and clients in a row, is by some people described as an addictive way of working, and we can imagine it is ‒ especially during a time when we’re more than ever distracted by technology.
The next step for us is to actually do some sprints ourselves. Based on what works and what doesn’t, we’ll further analyze what can be adapted, improved and implemented in our own processes. More about this in a future blog post; in the meantime, we hope that you try it out too!