The 3-hour Design Sprint or how to conduct Design Sprints with virtual teams.If you’re familiar with Jake Knapp’s (of Google Venture fame) framework of the Design Sprint (as described in the book of The Sprint), you will know that it’s a highly effective tool to quickly produce solutions to vague problem-sets. The idea is to set aside one full week of uninterrupted time for all key stakeholders working on a product or feature, to come out with solutions that have undergone a phase of prototyping and customer validation.

At AIESEC, we are not able to follow this framework 100%:

• Key stakeholders do not work in the same office and travel often.
• With tenures of only 1 year, one whole week is usually too much commitment to ask from top leadership.
• Our development is outsourced to India (check them out here at Commutatus); time-difference does not give us this amount of common uninterrupted working time.

To overcome these challenges, we had to come up with adaptions to the framework. Based on the timezones (Rotterdam at GMT+2 and Chennai at GMT+5:30), we had to limit our meetings to a maximum of 3 hours at a time. Obviously, it’s impossible to cram 5 full days into just 3 hours. So, we divided the different agenda points into what can be delivered by an individual or small group at their own time, and what input and decisions need to be facilitated in the group. After multiple iterations and incorporating the learnings of one year of trial and error we came up with this agenda:

So how does it work?

• Check our copyable Google Spreadsheet with detailed outline here.
• Check our ready-to-go Google Slides Deck here.

Essentially, you take the parts of Monday, Tuesday, and Wednesday of the Design Sprint framework and facilitate those in 1-hour reach in one meeting.

The outcome of the Sprint will be the 3-panel sketches by each participant. If you have the time, you facilitate the voting process within the meeting, otherwise, you ask them to cast their votes virtually on the same day. Then the Product Owner (that is you I would assume, and depending on your preference with your designer or other stakeholders) sits down, identifies and prioritizes the big ideas, takes the voting into consideration (the Product Owner acts as Decider, so make sure not to get into Decision Paralysis based on conflicting opinions) and draws a full-fledged storyboard. This is presented in an onboarding meeting to the designer who takes the majority of the following week to create an interactive prototype. At the same time, the user interviews are being scheduled for the last day. The user interviews serve as a checkpoint for the idea. Based on the insights you gather, you decide if minor feedbacks need to be implemented, further testing is required or if you need to make changes to the storyboard and produce a different prototype (if the solution is not working at all, you might cancel the idea altogether or start all over with a new Sprint Meeting).If you plan to get more quantitative than qualitative data or you do not have the time or means to sit down with your customers for a full day, there are tons of tools to conduct this virtually and even autonomously (check my how-to here).Now with our current context of AIESEC’s global office having moved to Montreal (GMT-4), you might wonder how we manage to do it now. Well, we are definitely not able to run these 3-hour meetings anymore like we used to (after all, it’s hard to convince stakeholders to join us for meetings from 6:00 AM to 9:00 AM). We’re currently tacking it in two ways:

• Splitting up the three hours in 2 meetings (Pre-Sprint and Sprint), where the long-term goal, list of questions and target get identified first and the solution is brought out in the second meeting).
• We are currently piloting having developers with us in the office in Montreal to conduct the sprints with us (this comes with higher costs, of course).

After having practiced Design Sprints virtually for quite some time, I must say that it comes with certain advantages and disadvantages and after all, it is up to you to decide if you want to accept the downsides:

‍

‍What works well: ✅

• allowing us to run multiple sprints simultaneously.
• highly flexible.
• can be done virtually.
• suitable for both highly complex and simple problems.
• produces tangible outcomes.

What works not so well: ❌

• the outcome might require multiple iterations.
• still requires some amount of common working time.
• it’s easier for the Decider to wrongfully discard good ideas as there’s a lack of thorough explanation of each input.

Virtual Design Sprint was originally published in Laurins Page on Medium, where people are continuing the conversation by highlighting and responding to this story.