Design Sprints: Notes and Observations
I came across the Design Sprint concept recently as I licked my wounds after a particularly difficult web/app development project.
The client, a friend, had needed to modernize a core product offering on their website. Their needs seemed fairly obvious. The existing system was clunky and out of date. A rebuild was going to offer many easy wins and lots of new opportunities to make their service more efficient.
With my experience in product management and design, I know how important it is to do user research and document requirements. But the budget was limited and the client’s team were very busy with day-to-day operations. So. I did my best to write up a 40 page spec which outlined what I understood was the obvious solution. This was accepted without too many questions, and off I went.
At the time, the challenges of transitioning the database, enabling user content creation, and integrating with their payment gateway seemed like the biggest risks on the project.
Well, long story short; a couple months later when I uploaded an early release of the app for testing it generated heaps of confusion from the client team who would be administering it. I thought I’d be receiving bug feedback, but instead I received push-back on much of the base functionality of the system. Many on the team were attached to doing things a certain way and were resistant to changes I had introduced.
I’d taken for granted that the team would ‘get it.’ But they didn’t. I assumed they were on board because they’d given their thumbs up on the requirements. But they hadn’t really read it or understood it. In hindsight, many of the circumstances on this project were set up for failure, but the biggest one was that everyone thought I was building something different.
It was a hard lesson, and one I’ll remember well. Even though I thought I’d built the right thing, I’d neglected to get genuine buy in from users early on.
I know, that should be obvious. But when you think you know what needs to be done, it’s often less so.
Enter the Design Sprint
After this setback, I knew I needed a better way to do discovery and get team buy-in from stakeholders on new system development.
The “Design Sprint” is an idea that has been popularized in the book by Jake Knapp of Google Ventures. It’s a process “to solve tough problems and test new ideas within just five days”. It’s a clever mix of business strategy, innovation, behavioral science and design packaged into a step-by-step process that anyone can use.
The book identifies five steps over five days
- Mon: Understand. Map out the problem and pick an important area to focus.
- Tue: Ideate. Sketch out competing solutions on paper.
- Wed:: Decide. Make decisions and turn your ideas into a testable hypothesis.
- Thu: Prototype. Hack together a realistic prototype.
- Fri: Test. Get feedback from real live users.
This seemed like an ideal system for building true alignment from the client-team. I decided to put it to use with my next project.
Challenges Selling a Design Sprint
One of the hardest parts of the sprint is to get buy-in from leadership and the participants to make this possible. It’s a big ask to clear the calendars of several people so they can work on a single project for five days.
Reviewing experiences from others I figured it was safe to cut it down to four days. The first three days of group exercises can be condensed into just two days, leaving two more days for prototyping and testing.
AJ&Smart, a consultancy based in Berlin have also found a compressed design sprint to work well. They have produced a series of highly useful videos that walk you through the various parts of the process. I found these to be as useful as the book.
And it’s not necessary to have the whole team in the room for the full four days. You’ll want people with differing expertise and views early on, but it’s ok to release some after the second day. However, don’t let everyone go. There’s still a lot of details to be hashed out in prototyping and you want the majority of the team around to help, and when observing the tests.
From Facilitator to Participant
One of the challenges I faced off the bat was that I was the one being hired to design and build the system. The other participants included users, engineers, and management, but no-one else on the team really had the skills to make the prototype come together.
This would require me to be both a facilitator and a participant at the same time. This was a big risk, and I wasn’t sure if I could pull it off.
For the first day, I operated in a purely facilitator role as we defined our goals, worked through the interviews, discussed our “How Might We’s” and shared ideas.
On the second day, I moved into a facilitator-enablement role, trying to provide alternate ways of thinking based on experience. I sketched while they sketched and went through the same exercises together.
The only downside to facilitator-participation is that once your own ideas are on the table with others’ it’s perhaps harder to be objective about the direction the team should move. Yours becomes a voice in the crowd, versus the voice of gently pushing the team in the right direction.
But it worked, and by the next day we followed the process to bring all these differing ideas into one solution. By this point, my role as a facilitator was barely needed, and we were just one team working towards a mission of assembling a prototype for user-testing on the last day.
Working Alone Together
Perhaps the biggest strength of the design sprint was how it provided a framework for different people of different backgrounds to get their ideas out and in front of each other.
Many typical brainstorming sessions end up with a small core hashing it out while others sit by and observe. I’ve been in many meetings where you’ll discuss for hours, but little gets decided, or worse… a decider comes in with no context and makes a decision without really understanding the issue.
Design sprints champion a technique known as ‘working alone together.’ It recognizes the best ideas often come when people have time to think. It provides a process where the team surfaces lots of ideas together, and then individuals are tasked with pulling from that pool of shared knowledge to create designs of their own.
This led to some surprising results. In a coffee break before the final sketches, I chatted with one of the other participants and we seemed to have exactly the same ideas. I was even worried that it would seem like I was copying. But half an hour later when we hung up our UI sketches, our ideas were actually very different. Indeed most of the sketches were quite different. And then the process for reviewing and discussing these designs led to agreements rather than differences.
Building the Prototype
After sketching and storyboarding the design, it can be tempting to feel like you’ve accomplished most of your goals. In this example, our team was on the same page, and it seemed like we knew what we needed to do. But building the prototype brought a depth that we would have otherwise missed.
A day, or more accurately, six hours, is not much time to build a prototype. It didn’t give us enough time to build a working search tool, or display real results. But it did give us time to build something that looked real. We used Google slides to mock up several screens of a new system. The exercise forced us to gather real data, articulate how it should look and answer the details of how it would work. Many valuable decisions were made this day.
Google Slides proved to be a powerful and flexible tool for prototyping. It allowed everyone to participate and easily review. Really, it’s kind of an amazing tool.
Another benefit to this exercise is that it forces you to design something that might usually take much longer. I’ve seen design projects consume extensive time, especially with long cycles for revision. Having a full team in the room while you build their vision is very efficient. The end result wasn’t pixel perfect, but we had a straw-man, and everyone was on-board.
Features vs Cost
One weakness of the sprint process might be that it focuses more on design and not enough on technical feasibility. In this particular sprint, we had one person who would be largely responsible for the backend development. As ideas and requests were thrown out, it was hard not to feel for him as he tried to explain why some things were impractical or hard to achieve.
But we allowed many of those ideas to make it into the prototype anyway. It enabled us to ask how much our testers valued them. Post-sprint, an understanding of the value of various features informed us when creating a cost-value chart that could visualize where we’d get the biggest bang for the buck.
[[ Cost-Value Chart ]]
User testing is one of those things that gets a lot more lip-service than action. It’s actually a little awkward to schedule people to review your idea. But the results are well worth it.
It’s amazing how different people have different perspectives and different approaches to a task. When testing our prototype we found six different ways people were using to do the same thing. It’s illuminating and informative. User testing is often done as a product approaches completion, but this rapid early testing was very effective.
And the shared energy of a team learning from user testing is fun too. We did our user tests using Zoom which allowed us all to call in remotely, and observe the expressions of the user who was also remote.
What Would I Change?
As a requirements generation exercise, I found the design sprint process to be very valuable. It’s not a panacea, but the output was a team on the same page with a shared understanding of goals and opportunities – rather than a document which they may or may not have understood.
Follow-on refinements will still be needed, and more technical details would still have to be sorted out. But I’ll certainly be using this methodology again to gather input and elicit context for new projects.