Running a Design Sprint
First, let me tell you a story of an app development project that went wrong – my first and only project that really went pear-shaped.
The client, a friend, needed to modernize functionality on their website which enabled readers to post items for sale. The existing functionality had been built over a decade previously, using an obscure development environment, and it had been built very poorly at that. The codebase was unusable, and their were glaring security issues to boot.
A complete rewrite was in order. The client had recently moved much of their system over to WordPress, so I figured a custom plugin that worked with their new system would be the way to go. It could deliver some dramatic improvements too.
As a former designer and product manager, I know how gathering requirements and getting the design right are critical first steps.
In this case, the requirements seemed fairly obvious, with some easy wins and lots of ways to make the process more efficient. I wrote up a 40 page requirements document, which generated some questions and a few comments. The client team were too busy to be contribute much more. So I figured all was good.
That should have been a warning.
To me, the challenges of transitioning the database, handling front-end content creation on a wordpress site, and integrating with a payment gateway seemed like the biggest risks. With the client team busy on day-to-day operations, and with only a minimal budget to fund the project, I needed to get a start on development as soon as I could. I figured everyone would be on board once they could see it working.
Well, long story short; they didn’t. When I uploaded an early release of the app for testing it generated heaps of confusion. I thought I’d be receiving bug feedback, but instead I received push-back on the base functionality of the system. Many on the team were attached to the old way of doing things. They wanted the functionality to be just as it was…. complete with the need to print out paper invoices to keep track of billing. I gave up in frustration. They did too. It was a bad result all round.
I’d taken for granted that stakeholders would ‘get it.’ But they didn’t. I assumed they were on board because they’d looked at the requirements. But they weren’t. In hindsight the circumstances on this project were set up for failure, but we didn’t find out until after three months of development – effort that was largely wasted.
It was a hard lesson, and one I’ll remember well. It is critical to get buy in from customers and users early on, demonstrate new ideas, and validate you’re building something of value. Do that before you write the first line of code.
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
The “Design Sprint” is an idea that has been popularized in the book by Jake Knapp of Google Ventures. It demonstrates 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.
After the previous failure, I decided I needed a new way to do discovery and get team buy-in from stakeholders on new system development.
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 separate project for five days.
I’ve found that the full five days are probably unnecessary. Indeed 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 more useful than the book.
It’s not necessary to have the full team in the room for the full four days. It’s important to have 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
Can you be a facilitator and a participant at the same time?
I tried and found it can actually work out quite well. On my first attempt, I was working with a team that didn’t have in-house design expertise. We had users, we had tech, we had management, but no-one to make it come together. We needed someone who could mock up the vision. That fell naturally to me.
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.
Into the second day as we started to remix ideas from other places, and sketch out designs and storyboard, I moved into a facilitator-enablement role, trying to provide alternate ways of thinking based on experience.
By the prototyping day, I became the hub for assembling content while the team hashed out the functionality.
The only downside is that once your own ideas are on the table with others’ it’s much 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.
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.