Three tried and tested hacks for your next Design Sprint

I have never been one to follow rules, much to the dismay of many of my high school teachers. Not that I was ever a rampant rebel, but I’ve always wanted to do things just a little bit differently. So, when I was asked to plan a Design Sprint I had the usual knee-jerk reaction to want to tweak it. Just a little.

Of course, I am familiar with the “know the rules before you break them” mantra. I had done a sprint or two earlier in my career, and during my years as a consultant, I had seen my colleagues run a fair few as well. Some were more successful than others. During this time I made a mental note of things I would like to try to do differently.

Fast forward several years, and we’re planning a Design Sprint between CoopX and one of the sub-brands Obs Bygg (Coops do it yourself and home improvement retailer). This seemed like the perfect window to hack the Sprint method, just a little tiny bit.

Our main goal with the hacks was trying to crack the code of how to get the whole room truly engaged with our users. Something I feel is an essential part of ensuring that the ideas generated in the sprint can continue to live on past the 5-day intense work period. On the team, we had a good mix of designers, sales experts, and higher-ups, all of whom were keen to create a kick-ass new product. None of the team members were estranged to the end-users, but we wanted to ensure that we all had the same depth of understanding and empathy for the end-users.

So, without further ado below is a list of the top three hacks we tried and how they worked out for us;

Pre-sprint user interviews

As a prep for the sprint, my colleague and I decided to do some in-depth user interviews before the sprint. We collected our findings into a short presentation that we used as an interlude during the expert interviews on the Monday session. We printed it and had it available as an insight museum throughout the week.

I would definitely recommend trying this out if time allows. This really helped set the scene and remind the group of who we were working for. Many of the insights and user archetypes were actively referenced and used throughout the week giving us a common language. The pre-sprint research also helped remind the group of the spectrum of needs our users had as we idea-generated, giving us both stronger and more diverse ideas.

Empowering everyone to take an active role in testing

Now, this may not be for everyone, but we decided to divvy up the test day (Friday) so that we conducted the testing in smaller groups (2–3 people per group, as we had 12 on our team). Some tested in in-depth interviews while some went out and guerilla tested on-site with staff and users. Everyone had an active role in the tests. As a prep for this, we created a small how-to guide on user research techniques, so everyone felt comfortable and ready for Friday’s test day.

This worked out brilliantly for our team. However, this approach is very much dependent on having a brave Sprint team. The benefit was that we got a lot of diverse insight (both user and staff) and managed to test with a lot more people, so the results of our test were more valid. The test setting was also closer to what I would consider best practice (not more than 2 interviewers per interview). This move also made sure that everyone on the sprint team was immersed in the design methodology, an important part of our work past the sprint week. The main gain however was that everyone on the team was left with a personal and close encounter with the end-user, and had a sense of ownership over the prototype and the insights.

Simplifying the insight-sharing

Sharing insights is a part of the standard sprint methodology, so in itself, this is not a hack, but the way we chose to share the insights is. We took a few measures to make the sharing session less heavy (who doesn’t need that on a Friday?). We decided to skip the video-watching to prioritise letting our team share insights from their professional perspectives.

After the testing, we re-grouped in the sprint room and everyone went through their notes and jotted down their Top 5–10 findings (thanks IDEO, this is one of my favorite techniques) on post-it notes. We then read them out loud and hung them up ceremonially on the wall under categories relevant to the test. Together we formulated these into key insights.

Before anyone gets upset about the risk of bias here, we did keep recordings for future use in the project. We also made sure each interview was well-documented with notes from each participant. Our goal with this tweak was to understand what each team member had heard, from their professional perspective. Once we had this we could formulate key insights that we had a collective understanding of. Collecting these individual findings into core insights helped us merge perspectives and create one common understanding of the results and next steps, taking into account user needs and business needs.

And what about what not to hack?

On a final note, just to keep things balanced, one of the things I would not recommend doing is meddling too much with the timing. General I know, but a very important point. If you want your Sprint week to check out you need to keep the momentum that has been carefully built into the timing of the Design Sprint methodology. So chop and change and hack but try to make sure you don’t stray too much from the original plan.

And there you have it! Three little hacks that we tried here at CoopX that improved our Design Sprint, and one little thing I would steer clear of. Now, hacks and tweaks aside I wish you all the best in your upcoming design sprint, whether it’s next week or just something you’re keen on trying sometime in the future.