Google Design Sprints: Sprinting in a Hackathon

Google Design Sprints

The design sprint is a multi-day exercise aimed at validating solutions to critical business questions through design, rapid prototyping, and user testing. At the core, it shortens the distance between an idea and its learnings to days, rather than weeks and months. The basic steps of a design sprint are bringing the problem into sharp relief and agreeing on a focus; sketching solutions; narrowing in on a testable hypothesis; building a high-fidelity prototype; and, finally, testing the prototype with real users. 

Rightpoint often uses a modified version of the Google Design Sprint when kicking off innovation projects. They are a great tool for getting all stakeholders on the same page, focusing the team’s efforts, and rapidly developing prototypes to ensure the right product is built to solve a customer’s problem.

The key to a successful Google Design Sprint is a good facilitator enabling all voices on the team to be heard. It takes practice and experience to give a junior developer and the VP of Marketing an equal voice in the process. One way to gain this experience is to try a Google Design Sprint in a Hackathon. With no KPIs to worry about, and no seniority on the project, it is a chance for teams to get comfortable with the process in a low-pressure environment.

The Process

The Google Design Sprint is typically a three to five day process, while Hackathons are much shorter. In May, five Rightpointers and two free agents set out to “design a solution that recreates the power of togetherness for fans, athletes, and teams competing in a sporting event even without the ability to be there in person,” as part of the Boston-based Sports Innovation Lab’s Hackathon. With a 48-hour clock, we had to pare down the design sprint to the bare essentials while still making sure we were reaping the benefits of the process.

Sprinting in a Hackathon

With our challenge in hand, the team set out on an abbreviated Google Design Sprint to come up with a great concept for bringing back sports. 

Goal Setting

All Google Design Sprints begin with setting a goal for the sprint. It is imperative that everyone on the team has the same understanding of the problem trying to be solved and becomes laser-focused on coming up with a solution. While the SiL Hackathon had provided an overarching target, we focused our efforts to “Create Sharable Game Day Experiences for Fans, Teams, and Leagues.” Seeking not to boil the ocean, this goal rallied the team around “shareable” experiences on game days.

Research

The core team of a Google Design Sprint won’t have all the answers needed to solve the problem. This is where expert interviews come in during the traditional process. Because it was a Hackathon, we altered this step to focus on research. The team set out to learn how other entertainment venues create atmosphere, how teams make half-full stadiums feel less empty, and to understand what athletes and coaches’ needs were in an empty stadium. 

How Might We (HMW)

Problems and challenges are easy to write, but opportunities are where the magic happens. Throughout a traditional Google Design Sprint, team members are instructed to write down opportunities in the “How Might We” format on sticky notes. Using Miro, a digital co-working tool, we ascribed “How Might We” opportunities based on our goal and research. Because of the time-constrained format of a Hackathon, we did these all at one time. After grouping the stickies around common themes, everyone on the team voted five times for the top opportunities.

Our Top Vote Getters

“How Might We” give players the illusion of fans in the stands, HMW allow fans to choose their own experience, HMW allow fans to interact with each other, HMW create a shared sports watching experience that is like being in person with your friends.

Journey Mapping

Users don’t just magically achieve the goal they set out to when using a product or service. They need to hear about it, learn what it does, understand how to do it, employ the service, and ideally achieve what they set out to do. User Journey Mapping helps lay out this path to success in a visual way. We employed Miro to map out a season ticket holder, casual fan, athlete/team, and league’s path to the goal action that would solve the overarching goal we set at the beginning. Once we had agreed on the user’s journeys, we put our top four “How Might We” notes on the steps those opportunities had the highest chance of impact.

Art Gallery

Now that the opportunity and step in the journey is defined, it’s time to start sketching solutions. We started out with an activity called “Crazy 8s.” In one-minute bursts, everyone on the team draws low-fidelity sketches of an idea or concept that addresses the “How Might We” opportunities. Once the eight minutes is over, everyone sets off to create a storyboard. Similar to a movie storyboard, these three-panel drawings and text tell how a user may interact with a more fleshed out version of an idea that came from “Crazy 8s.” 

With our storyboards complete and posted in Miro, everyone on the team privately voted for whole concepts or ideas contained within a concept. We then took the highest-vote getters and crafted our final product.

The Prototype

The prototype phase of a Google Design Sprint is where the hard work of the previous week gets packaged and tested with real users. During the Hackathon, we stopped short of testing the idea with users and, instead, packaged our prototype for the final presentation. 

Our prototype was an app that served as a hub for digital fans' in-game experience. Working in conjunction with the telecast, fans can be present at the game and in the fan community. The app leveraged in-stadium tarps that projected virtual versions of fans that also reduced echo in the empty stadium.

How It Can Be Valuable to Your Company

To truly be a successful tool, Google Design Sprints require all voices to be heard, and not just the loudest or most senior. Doing a dry run on a Google Design Sprint in a Hackathon, when everyone on the team is equal, can give your team a chance to experience one without the pressure of KPIs or the weight of titles to get in the way of learning how to execute it properly. Once your organization learns how to do Google Design Sprints, it can quickly validate ideas and features, and get them out of spreadsheets and into the hands of users.