The ‘Remote’ Design Sprint
Last November, I took part in a design sprint for a government service that our team had already started building a few weeks earlier.
The team had wanted to run one of these events for some time. During the course of planning our roadmap, during our Alpha phase, we identified an area of our service that we felt could benefit from the design sprint process, to prepare us for the time when we started to work on this complex part of our user journey.
We never expected that by the time we ran it, we’d still be working remotely, but Design Sprints, like everything else in the world, have had to adapt.
This presentation is about the process we went through, to help you understand the potential value that can be gained from holding this type of event, whether you’re just starting out on a product or service; if it’s something that’s already in development, or something already in a live environment.
So, what is a Design Sprint?
The Design Sprint was invented at Google by Jake Knapp. Design Sprints have since been run by teams at Slack, Uber, Airbnb, Medium, Dropbox, Facebook, McKinsey, IDEO, LEGO, the United Nations, the New York Times, and many, many more.
https://www.youtube.com/watch?v=K2vSQPh6MCE
The Design Sprint website explains the purpose of this event as follows:
The big idea with the Design Sprint is to build and test a prototype in just five days. You’ll take a small team, clear the schedule for a week, and rapidly progress from problem to tested solution using a proven step-by-step checklist. It’s like fast-forwarding into the future so you can see how customers react before you invest all the time and expense of building a real product.
On the service we were building, there was key area on the roadmap, some months away from development but critical for us to understand, in order to build other journeys that would lead a user to that point. Although we weren’t expecting to create a final solution by running a design sprint, we knew it would give us the time to explore and understand the problem in more detail with a chance to be more creative how we could tackle it. We also recognised that by not understanding the finer details of the technical aspects, at this point, we would feel less constrained in our suggestions.
Prep and agenda
It was clear that preparation is key to getting this event to run smoothly, particularly in getting a commitment from everyone participating, including stakeholders, to dedicate 5 days of time and budget to the sprint.
A dedicated facilitator who understands the process but is not participating in the work is also essential for timekeeping and sticking to the schedule. It’s worth noting here that this is not an event solely for Designers — this event is for all types of specialists to get involved in. It’s a creative thinking process. We had business stakeholders, a technical architect, a product owner, an analytics expert, a researcher, a UX designer, and myself, as a delivery specialist.
You’ll need to understand, at a high level, the problem area you’re looking at, although much of the detail will come out as part of the process
Then in terms of the practicalities, taking what is usually a face to face week long workshop into the realm of the virtual, and running it remotely, you need collaboration tools that everyone can use, which proved tricky for us in a multi-supplier environment. We managed to get everyone access to Google suite, but even then one participant had to use their personal laptop to get into the tools.
A carefully planned schedule should be devised to avoid ‘screen’ burnout. And finally you’ll need to arrange for research participants to be available for the final day of the sprint — you should have a specific persona in mind, before you begin, so you can line up appropriate test subjects.
How does the sprint run
On Monday, you make a map of the problem. This includes ask the experts — where you bring in a few key stakeholders and ask them about the vision, customer research, how things work, and previous efforts. We then considered how we might apply these ideas to our problem space — reframing problems as opportunities. We then spent time defining the goal of the sprint and mapping how users get to that goal — essentially thinking about the journey users are taking before they encounter the problem space, placing it in context of the wider user experience.
On Tuesday, each individual sketches solutions. The day starts with an opportunity to look beyond your usual domain, collating ideas from other companies, and bringing those together to discuss — it’s good to have a chance to do this outside the usual domain and standard interface patterns or libraries that many bigger organisations seem to use now. The rest of the day was dedicated to sketching., which can be fun for some, yet daunting for others, especially those participants who have never sketched anything before.
This rough sketching and sharing of ideas was done around a number of time-boxed sessions with imaginative names, such as: Divide or Swarm; Four-step sketch Intro; and Crazy 8’s — all of which were designed to keep you focused on concepts and ideas, not refined drawings.
Each sessions built our confidence to refine the sketches which we then photographed and shared on a virtual whiteboard, ready for collective review. Our facilitator really helped with words of encouragement, and the mantra that ‘no idea is a bad idea’.
On Wednesday, you decide which sketches are strongest, by reviewing and analysing the ideas — and again, looking at the concepts, not on the physical presentation of those ideas. Constructive criticism and collating the best ideas from everyone is a chance to take the strongest themes from the collective to create a hybrid solution. Again the time-boxed, well structured sessions, such as Heat map; Speed critique; Straw Poll; and Super Vote, helped us focus on making decisions and agreeing a way forward (called the Rumble!)
All the time we were building in a sense of collective ownership — it’s no one person’s’ idea, it’s a team effort, a hybrid of all the best bits.
Collaboratively planning the user journey, and thinking about where this fits into the overall user experience that we defined on Monday, helped us to put the ideas into context, and also ensured we were all on the same page — an important factor for the final two days of the week.
On Thursday, you build a realistic prototype, and plan the user research for the final day. This was quite a high pressure day, as the reality dawned on us that we needed to build something, from our sketches, that could be tested with users.
Identifying the right tools to prototype and keeping it lo-fi was sound advice from our facilitator. With a competent designer in our midst, who can build hi-fidelity prototypes in the team, it was tempting to default to them to create our masterpiece. But our facilitator reminded us, this has to be a team exercise. Additionally, if the prototype is too good, he explained that you run the risk that anyone who sees the output of your sprint (business stakeholders, for example) may think this is a final design, which we’ve already established, isn’t the purpose of the Design Sprint.
We ended up using presentation software to build our interface (as we could screen-share and it had some basic drawing tools in it) and then we stitched our screens together with a free tool online, that we could ‘hot-spot’ with clickable areas, so users could interact with our design at a very basic level.
In addition to creating the prototype you need to prepare your research scripts. We split the team early in the day, so that some of us worked on building the prototype and others wrote the test scenarios. This is where the previous days’ collective understanding of the user journey and the ideas paid off, as it meant we could cover a lot of work in a short timespan.
Finally, we did an initial walk through with our facilitator, who had left us to carry out the days tasks without him overseeing the process. He was able to role play, as our first test subject, giving us chance to refine any issues we hadn’t spotted.
And on Friday, you test that prototype with five target customers. This, for us was a relatively straightforward day — testing the prototype with users, and making notes from our observations, as this is something we do on a pretty regular basis, and doing so remotely, is something we were already accustomed to.
Even so, we still had to make some tweaks to the prototype and the script on the day, as there were unexpected behaviours from our first user, which we really hadn’t considered during the rapid prototyping, and high pressure to get everything completed the previous day.
A debrief at the end of the day allows you to download all that you have learned from the test subjects, as well as any insights you have gathered as a result of seeing people using the prototype. By this time, as a team, we were exhausted, yet elated at how well the sessions had gone, and amazed at how quickly we were able to research, build and test the prototype together.
We had a final wrap up, thanking everyone who took part, and agreed next steps, which included a more detailed debrief the following week, with the business, sharing our insights and findings.
We also did a retrospective, in true agile fashion, to ascertain the value of the exercise and decide if the Design Sprint is something that we would use again, or promote to our colleagues.
So to summarise, on why doing a design sprint is worthwhile
Its an opportunity to work differently together as a team — you stop the old defaults of office work and replace them with a smarter, more respectful, and more effective way of solving problems
You can maximise team potential by bringing out the best contributions of everyone on the team — including the decision-maker — helping you spend your time on work that really matters.
You get a shared ownership of the problem space — you get buy-in from everyone regardless of role
It helps to demystify the creative process — stakeholders get a chance to see how the creative process works — and understand that it’s not straightforward. Design thinking takes time and anyone outside the creative space doesn’t always appreciate the thinking time that goes into solving problems. Once people can see a solution, it’s very easy for them to have an opinion about whether they think it works or not, — everyone is a designer it seems — but they often fail to appreciate the work that goes in beforehand — so this process certainly helps to illustrate the effort that goes in to solving problems with design.
You and your team can learn quickly what works and what doesn’t — rather than spending weeks or months working in individual specialisms, handing work back and forth, chasing for answers and potentially missing out on vital information in the problem solving process.
And finally…would I do it again? Yes, absolutely, but with everyone in the same room together would be my preference. Although the remote format worked, it’s no substitute for the in-person experience of a workshop. Making eye contact, reading body language, and having some banter, coffee and donuts together, would raise morale and no doubt lead to even more creative outcomes.
