Design Sprints: A Quicker Way to Create Requirements?

I came across the Design Sprint concept recently as I licked my wounds after a particularly difficult web/app development project.

I’d tried to modernize a core product offering for a friend’s business. 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 busy with day-to-day operations. So I wrote 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.

But, 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 employees 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 them. In hindsight, many of the circumstances on this project were set up for failure, but the biggest one was that while everyone had signed off on the requirements, no-one had really understood what they meant.

It was a hard lesson for me, and one I’ll remember well. When you do the thinking for others, you don’t really do it at all. What I needed was a way to get my clients to write their own requirements. A way for them to ask what their customers wanted, a way for them to explore new ideas and come together as a group, a way for them to self-validate what they thought were the right ways to do it.

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.

I stumbled upon the “Design Sprint,” an idea that has been popularized in the book by Jake Knapp of Google Ventures. It’s a process designed “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 leads teams from asking questions to building their own prototypes in five days, or less.

This seemed like an ideal system for building true alignment amongst stakeholders on a new project. While a typical requirements process might involve professionals interviewing customers, stakeholders, designers over weeks if not months to build a plan, a sprint brings everyone together, gets them on the same page, and forces them to build a prototype that can be taken to end users for testing.

I decided to put it to use with my next project.

Making the Case for a Sprint

One of the hardest parts of the sprint is to get buy-in from 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.

Since we already knew the general issue we were trying to tackle, I used the structure to compress the sprint into just four days. The first two days would be for ideation and sketching and discussion, before a day of prototyping and another day for testing.

I found it’s not necessary to have the whole team in the room for the full four days, but there are still a lot of details to be hashed out in prototyping and you want the majority of the team around to help, and they should also be there 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.

User Testing

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 were still needed, and the technical details still had to be ironed out. But I’ll certainly be using this methodology again to gather input and elicit context for future projects.