top of page

Google Design Sprint - What is it?




Google Design Sprint: The sure-fire method for efficient innovation!

There are many challenges a developer has to face before bringing a new product or service into the market. Production costs, development time, testing and quality assurance phase, these are just a tip of the iceberg. In some cases, a product may be in a long development phase, utilizing hours of labor and lots of resources, only to be scrapped mid-way owing to unforeseen problems cropping up. The huge amount of money spent on development and labor burns a hole in the production budget in such cases. What if such issues could be handled efficiently without actually going into full-blown production? This is the fundamental ideology behind the concept of Design Sprint.

The design sprint is an agile user experience that is revolutionizing product design and development since its inception in 2010. Developed by Google Ventures, this framework cuts design time drastically, providing ways to achieve solutions without wasting valuable resources. It aims at bringing the developers together to answer critical business questions, followed by brainstorming to pick the best design approach, and then implementing the idea to design a quick prototype. The prototype is then tested rigorously and optimized with new features to provide the best user experience.


How does Google Design sprint work?



Google Ventures developed the sprint as a method to answer critical business questions in just five days. The framework works by repeating cycles of rapid prototyping and user testing. One of the advantages of Design sprint is that the design team will be able to grasp how the users will react to the actual product in the future before investing time and effort into building the real product. This is made possible by designing the prototype of the product and putting it through several rounds of testing.

Design sprint replaces conventional work with smart, inclusive work that is an aggregation of ideas contributed by every member of the Sprint team, aligning the team towards achieving a shared vision. The approach is user-centric and result oriented. It does not depend on the scale of the product, and both big companies and small companies alike can use it to optimize their design time and identify ways to address production bottlenecks. It also helps to incorporate new ideas into the project, thereby continually tailoring the best user experience.

The framework supports both divergent thinking and convergent thinking. Divergent thinking allows creative brainstorming, providing multiple possible solutions for the problem. Convergent thinking uses a set of defined logical steps to arrive at a solution.


When can the Design sprint be used?

  • To speed up the development process of a product.

  • While launching a new product or service.

  • While adding new features to a pre-existing product.

  • To solve any bugs or issues in a product.

  • To optimize and provide better UX design to the users.

  • To extend an existing experience to a new platform.

  • To facilitate knowledge sharing and collaboration among the team members.


The Design sprint cycle



There are five stages in the sprint, led by a Sprint master of the team. The team can cycle back and forth through the stages at any time, to make changes as and when required. The team starts by defining the problem and after the definition of the problem is revealed, the Sprint Master facilitates the sprint cycle.

The stages are,

Understand

Sketch and diverge

Decide

Prototype

Validate

Let us assume the sprint starts on Monday. The sprint stages are then spread over five days starting on Monday and ending on Friday.


Day 1 - Understand:

The team members are chosen from all levels of the organization, including UX designers, researchers, production managers, board members, and marketing managers. Before the start of the sprint, the team has a structured discussion and arrives at a long-term goal.

The first part of the sprint is to clearly understand what the problem is and discuss methods to solve it. The members use the 'How Might We' (or) HMW method to brainstorm and discuss creative ideas to achieve answers to the following questions: Who are the targeted users? What are the needs of the users? What are the problems expected to arise? What would be the context?

The team then reviews the strategies implemented by market competitors to combat risks. Combining all the inputs of the team, a simple map of the product or service is made. Finally, a target is identified: a difficult but manageable problem that can be solved in just one week.


Day 2 - Sketch

On the second day, team members are given time to analyze the target problem and write detailed solutions to address the problem on their own, following a four-step process.

1.Notes

Duration: Twenty minutes.

Members work individually and gather notes on feasible solutions.

2.Ideas

Duration: Twenty minutes.

This step involves jotting down some rough ideas and circling the most promising ones.

3.Crazy 8s

Duration: Eight minutes.

In this step, members fold a sheet of paper to create eight frames. Promising ideas are written in each of the eight frames.

4. Solution sketch

Duration: Thirty to ninety minutes.

The last step is to create a three-panel storyboard by sketching in three sticky notes on a sheet of paper. The sketch is expected to be crystal clear and self-explanatory.

The members stack their solution sketches face down in a pile and end Day 2.


Day 3 - Decide

The stack of solution sketches from Day 2 are critiqued and the best solutions are decided by polling. In the case of multiple tied votes, the Decision Matrix approach will be used to help narrow down more effective ideas.

The matrix is a simple diagram, which helps to judge all the ideas on a set of requirements that are necessary to attain the objectives of the whole sprint. The team will then weigh the risk against reward, and the solutions with the most promising rewards will be shortlisted. One final solution is then selected by the Sprint Master, and the winning ideas from the sketches are combined into a storyboard.


Day 4 - Prototype

The storyboard is a step by step plan to design the prototype. The storyboard is split into smaller chunks and assigned to members. Members are assigned roles such as Maker, Stitcher, Interviewer, Writer, and Asset collector. A quick prototype is created by the Maker, and in case of split work, the Stitcher ensures all of them fit seamlessly. A trial run is done to check for mistakes and the Interviewer is alerted of any errors. The Writer works with the Interviewer to create a script for Day 5's test phase.

The prototype is to be of good quality and should be made to appear as real as possible, to evoke honest user reactions.


Day 5 - Validate

By the end of Day 4, a realistic prototype is made and kept ready for users to interact with. At least 5 customers are picked to use the prototype, and the team observes how they use the prototype and records their answers in fact sheets. Each customer has a friendly 1:1 interview with the Interviewer, who asks them questions regarding their experience with the prototype. In the sprint room, the rest of the team watches the interviews over a live video feed and takes notes.

A grid is drawn on the whiteboard, and there is a column for each customer. As the interview goes on, interview snippets are written on sticky notes and stuck in the column of the respective customer.

At the end of Day 5, all the user comments on the whiteboard are analyzed and labeled into positive, negative and neutral reactions. A list of all the user feedback is made, and patterns are identified. Any major issues in the user experience of the prototype are understood and noted.

The members review the data together, absorb the learning, and discuss the next steps for the project. An action list of learning achieved by the sprint is then written down in such a way that it leads to the next session of product development.


Takeaways of the sprint



By the end of the sprint, each member understands if the solution is workable, and has a sheet of feedback that can be used to tweak the solution to perform better. The sprint session ends with a discussion of how the flaws in the solution could be improvised, or whether a new solution has to be tested. But the key takeaway is that a solution has been tried and tested in just five days, and the team has learned a great deal about the user's expectations and the steps to be taken to ensure customer satisfaction. The team is thus able to decide if the solution would be a success or failure, with minimal use of resources in just five days!


56 views0 comments
Post: Blog2_Post
bottom of page