What We Learned from 6mo. of Design Sprints
Back in September, I joined an exciting new project: lead the user experience design team to re-imagine a major airline website. I was bright-eyed and bushy-tailed.
The team, on the other hand, was fatigued. They had been on the project 6 months prior to my arrival. The collective feeling of frustration and discouragement was palpable. I decided to breathe some life into the project with a shiny new process.
Design sprints to the rescue
The Google Ventures Design Sprint process was getting a lot of press at the time, and was curious about how it would apply outside of startup land. I knew it could be a way to speed up the cadence of our outputs. I also knew that regular validation gateways could help us break the indecisiveness that stalled much of our progress.
Our process wound up looking something like this:
What makes design sprints special is, not only high speed pace of one week iterations, but also the intention—every effort points to day five: user research. I like that. It gives a larger purpose to the work and creates accountability amongst the team. Intention is the heartbeat that brings design to life.
Customers, on the other hand, don’t give a shit about your intention. It either works, or it doesn’t. With the airport just around the corner, we had easy access to lots of customers in the domestic terminal. We brought our best intentions to them every week, and recorded what they had to say about it using a tool called lookback.
After a few weeks of this process, our weekly sprint schedule started to look something like this:
If you’re familiar with the GV Design Sprint process, you’ll see it’s not the same. We wanted to dedicate more time to refining interaction models and interface over storyboarding, so we used Wednesday for paper prototyping.
- We got ahead: At a one week sprint cadence, even if we didn’t get through all steps of the design process in that time, we made decisions faster. It time boxed all of our efforts and forced us to create a test-able output every Friday.
- Prototyping became synonymous with design: Before we started this process, prototypes were special things you made sometimes with developers. Now prototypes are the primary output of all work.
- We turned revisions into assumptions: Instead of making most of our decisions based on a combination of instinct and business requirements, we made them based regular interactions with customers. All design team and stake-holder revisions were recorded as assumptions and used to drive our Friday testing session. Only validated assumptions could confirm or kill an idea.
- We got an edge in defending our work: We built a serious library of footage, that could prove any direction we took. Most of us carried a library of anecdotes around in our heads, that could help us describe why we made the decisions we made.
- We got out of the building: Too many design decisions are made within the comfy walls of a studio. When we went to the airport, we lived the life of our users for a minute. It reminded us of all the nuanced frustrations you experience when you travel. It put us in our customers’ shoes, and gave us a level of empathy that lab testing could never provide.
- Frustration and discouragement receded: It didn’t end — let’s be real, designers will always have something to be frustrated about. However, the team felt like they were armed with reason whenever their design decisions were called into question.
What didn’t work
- One week wasn’t always enough time: The team was often stressed about having a prototype ready for the airport. Most of the time this was stage fright, but sometimes it was legitimate.
- Recording our findings became a problem: With so much research happening and no research team to filter through it, we found ourselves with a mountain of footage and notes, and no one capturing it into our assumptions spreadsheets.
- Motivation: I went on holiday for a few weeks, and when I got back, no one was using the process anymore. There are a number of factors here, one thing was apparent, at least with this team: without an enforcer process naturally degrades to paths of least resistance.
Google Design Sprints are a fantastic way to empower teams to get ahead of the curve in an agile/lean environment, no matter what the project size. They foster a culture of inclusiveness amongst customers and stakeholders. They also bring a buffer of reason to the design process, removing the over-emotion that designing from the gut can bring to review sessions.
Of course, design sprints aren’t a magic bullet. Make sure you’re vigilant in enforcing the process, and flexible in the time it takes team members to get their work done. If you’re like us, and working without a dedicated research team, make sure someone holds the responsibility of recording findings, and reporting them back to the team regularly.