How Design Sprints have influenced product design at Grubhub
What’s a Design Sprint?
Google Ventures Design Sprint is a popular problem-solving methodology in the product design community. In a nutshell, it’s focused on getting the user-facing interactions right and testing early on.
While every team runs it differently, a Design Sprint lasts five days and has a basic structure:
- Day 1 — Setting goals and mapping user flows
- Day 2 — Sketching ideas (diverging)
- Day 3 — Deciding on a direction (converging) and storyboarding
- Day 4 — Prototyping
- Day 5 — User testing
The Sprint team consists of experts from different disciplines — design, product management, engineering, research, marketing, finance, and any other subject matter experts. A diverse team ensures that we get different perspectives, which increases the chance that we’ll come up with a prototype that’s both useful for real life users and technically feasible.
At Grubhub, we like to collaborate with Design Sprints because we can get experts’ undivided attention on the project and make decisions quickly. In an ideal world, we would run Design Sprints for all projects, large and small. For now, however, we run Design Sprints mostly when we work on larger scale features.
The reality is, at a tech company, most of us work on more than one project at a time. It’s an investment to lock a group of experts in a room for five days — device free. That means no meetings or checking emails during Sprint hours, from 10am to 5pm. As a result, Sprint team members have to stay late to take care unanswered inquiries from other projects. Additionally, preparing for a Sprint takes time. Someone needs to schedule expert interviews, recruit customers for user testing, book conference rooms and move meetings around. It’s pretty clear we can’t afford to have full-time Design Sprints every day.
But what if we want to utilize the tools and activities we learned in Design Sprints and use them everyday on projects of all sizes?
Develop a Design Sprint mindset
At Grubhub, we’re experimenting with reshaping Design Sprint from an in-the-war-room activity to a mindset everyone on the team shares when we work together. Since Design Sprint has a set structure, it’s possible for the team to become familiar with the process through practice and turn it into muscle memory. After participating in Design Sprints as both a design expert and a facilitator, I find I naturally apply the activities learned in Design Sprints when I tackle design challenges. For a team to share a Design Sprint mindset, the team members need to have a baseline understanding of Google Ventures Design Sprint. Our designers, product managers, researchers and and a large number of developers have been in Design Sprints and are comfortable with discussing low-fidelity design and having fast iterations.
Here’s how we keep Design Sprint processes in mind in our everyday design work:
Goal setting
Before you get started, you need to first understand what your final goal is. Goal setting is crucial even if the feature is small because it gives the team an opportunity to align on expectations and talk about what success looks like. When a design need comes up, a product owner (normally a product manager) raises the need by providing business objectives, data supporting the hypothesis, and success metrics. This information helps the team understand why we should work on a project and the big picture of how the new feature fits in the product ecosystem. The team then discusses and agrees on the project scope, design timeline, and deliverables.
Sketching
We believe a picture is worth a thousand words. For highly technical projects, we like to invite developers to sketch because that’s the best way to get the idea out of their head. In a sketching session, the leading designer presents a competitive audit and explains the scope of sketching. The product owner is there to answer any business objective-related questions. Participants then sketch out ideas on paper individually. The team goes around the room to present their sketches and talk about what they do and do not like. The designer uses this time to ask a lot of questions and pick the stakeholders’ brains. The information gathered in a sketching session helps the designer make decisions on design solutions and UX recommendations. As everyone has a chance to sketch and present their ideas, they are more likely to buy into the project and proposed solutions.
Prototyping
The definition of prototype on our team is anything that a user can interact with. It can be super simple and “ugly” as long as it contains the functionalities the team wants to test out. Depending on the project, designers might start with a wireframe or by using symbols in the Grubhub Pattern Library to design the layout. We normally review work-in-progress designs and give feedback a few times before putting it in front of testers. For projects that are heavy on interaction states and page transitions, we prefer to design and iterate in interactive prototypes because it helps us think through logic and use cases.
Testing with users
We encourage our team to test early and dirty and iterate fast. Watching real-life users interacting with our design teaches us what matters the most to our most important stakeholders: the customers. Once we have the prototype, our dedicated researchers conduct face-to-face usability studies with users recruited from targeted segments. Team members involved in the project observe the testing sessions and take notes. After the testing, we regroup to discuss what worked and what didn’t and decide on a direction for design iteration.
What happens next?
Researchers generate a findings report and share learnings with the team after each usability study. The team iterates and repeats the design-review-validate cycle until the design is in a good place to move into production for A/B testing. Once that happens, we continue to monitor the usage and the conversion rate and make incremental user experience enhancements.
Lessons we learned
Keep up the momentum
Iteration should happen as soon as testing results come back. If possible, clear out roadblocks so the team can push the project forward while everyone’s memory is still fresh and they are enthusiastic. Planning ahead and prioritizing the project allows designers and engineers to do their job well and see the results in a timely matter. In my experience, putting the project on the shelf risks taking more time and resources to restart it. Worse yet, the project might not see daylight again.
Define roles and responsibilities clearly
In a fast-paced environment where decisions are made quickly, it’s essential that team members are clear about their roles and responsibilities so they know how to contribute and when to speak up in a discussion. In everyday design, the roles are different than in a Design Sprint (for example, the facilitator role is not needed), but having clear role definition is equally important. I find the RACI responsibility assignment matrix helpful when defining roles and responsibilities in cross-functional projects. RACI is an acronym derived from the four key responsibilities most typically used — Responsible, Accountable, Consulted, and Informed. Who’s responsible for coming up with design? In our case, designers. Approver? The product owner. Consultant? Subject matter experts who work on related projects. They can be product managers, designers, engineers, and data analysts. Who should be informed? The answer is other designers, the pattern library team, and anyone who might be impacted by this project. We have had a few projects where the role of approver (or decider) was unclear, which resulted in a prolonged timeline.
It doesn’t have to be perfect
One thing we learned about being iterative and experimental is that it’s fine to make mistakes and not get it right the first time. Create an environment where people feel comfortable to fail fast and early. This is key to fostering a Design Sprint mindset.
Trust your team to make the most educated assumptions and validate those assumptions with customers in user testing. However, there is always a chance the results might not turn out to be as satisfying as we want it to be. When that happens, have a retrospective and ask “What did we learn from the failure, and how can we improve?” Then move forward with another round of iteration.
Do you want to learn more about opportunities with our team? Visit the Grubhub careers page.
