I Co-Created an Asynchronous Design Sprint
I’ve been participating in design sprints occasionally over the past five years. I was introduced to virtual design sprints in the Global Virtual Design Sprint last year. I recently started to wonder where they could go in the future. I was curious about how they could work with another interest of mine — asynchronous remote work.
I reached out to Lee Duncan who is the Enterprise Design Sprint Leader at IBM, and someone I’ve worked with in the last GVDS. He had the same curiosity that I had. We decided to team up and co-create the Manhattan Sprint Project.
Our goal for the project was to support the evolving needs of design sprints within our dynamically changing world. The way people work has become more digital, more remote, and more asynchronous. This shift has been accelerated even more by COVID-19. This evolution required challenging the inefficiencies around coordinating globally distributed schedules for meetings, dealing with internet connectivity issues, among other things.
We started out with the following principles about how the project should go…
Edit the team. The make up of the team for something like this is very important. Not only did we want people who were experienced with design sprints, but we also wanted people who were experienced and comfortable with asynchronous work. Some personality types fit this better than others. We wanted to include people who we thought would benefit from this type of experiment.
We started out with 40 people interested in the project, which is much more than either of us anticipated. We decided to edit the team by requiring people to make a loom video within 48 hours of our project announcement explaining 1) why they were interesting in participating and 2) what was their experience with design sprints and asynchronous work. We ended up with 19 video submissions, which resulted in 3 teams of 7 people each (including Lee and I).
A condensed design sprint process that focused more on the process than the actual outcome. We decided 3 days would be enough time to give us the insights we needed and would be enough work for us to manage. We focused on 4 main activities over the 3 days.
- How Might We (HMW) questions
- Generating ideas and related outcomes to turn into prototype (if the team wanted to build something)
- Producing lightning demos to get inspiration for a prototype
- Producing solution sketches
We wanted to stick to deadlines. This was going to be our main way of measuring success for the first version of the manhattan sprint project. It was important to make people aware that they needed to be accountable to their team as well as the project overall. We had 2 deadlines each day. A deadline for completing the work (HMW, lightning demos, etc) as well as a deadline for voting on that work.
We needed a tech stack that would make things run smoothly. Lee and I threw many ideas back and forth about what tools could enable the best possible outcome for the project. We ended up using slack, mural, and loom primarily. These worked out really well, and a lot of people enjoyed using loom for the first time. We also tried to implement Yac and Maze.design, but those didn’t really get used since their introductions were a little rushed.
We tried to automate as much as we could. There’s the saying “You don’t want to see how the sausage gets made”. That’s pretty accurate for some of the automation attempts we had. We started off with a pretty extensive list of things we should try to do. We were thinking about automating slack reminders, automating voting when activities were completed, automating announcement of vote winners, automating user testing, and a few others.
Due to time constraints, we only were able to implement slack reminders and announcements on winning votes. Those were done by a mechanical turk approach. Although the notifications seemed automated to the teams, it was really me in the background typing those up a few minutes before they were sent out in slack.
I tried thinking about ways to do the other automations through no-code tools like Zapier, Airtable, and a few others. Since I didn’t own the slack account we were using, I realized those wouldn’t be possible. That was the biggest shortcoming of the project in my opinion, and something we need to improve on in the future.
We wondered how to best enable asynchronous communication. In most design sprints, the facilitator is the one responsible for team building and leading the communication. We wanted to take that element out and see what would happen. We provided a few team building exercises in slack during the 3 days and some participants did come up with their own, but we noticed the team chemistry was lacking. That is another big improvement we need to make going forward.
The challenge for the project was ‘How Might we redesign physical space for the world with COVID-19 and after?’. We chose this to push the boundaries and try to veer any potential solution away from a digital product. Sometimes design sprint solutions end up being a digital product no matter how ambitious the challenge starts off.
Throughout the 3 days, I followed along with each team as they went through all of the activities. I was really impressed with some of the work that came out of it. The ideas covered a lot of different concepts. The winning HMW questions were…
HMW design spaces so that people can minimize their need to touch things?
HMW create multi-use spaces that can adept quickly, flexibly and easily to current needs?
HMW rapidly find new uses for abandoned/unused spaces? (shopping malls, parking structures)
Below are a bunch of screen shots of lightning demos as well as solution sketches from the project.
We learned a lot from the first iteration of the project. We tried to collect a balance of qualitative and quantitative insights to move forward with.
We looked at a few metrics. I kept my eye on the deadlines to see how many people were getting their work done on time. Overall, I’d guess that the deadlines were hit 65–70% of the time. That was good enough for me for the first version iteration.
It’s hard to quantify, but I would love to know how many of those missed deadlines were due to real jobs/real life taking priority, how many were due to poor communication, and how many were due to working styles not matching that well with asynchronous work. Regardless of the reason, we want to improve this metric in the next iteration of the project.
Feedback. After the 3 days, we sent out a retrospective for teams to write down any feedback they had. Here’s a screen shot below of one team’s retrospective.
We also met with some team members in a zoom call, to give them a chance to give us their thoughts face to face. We got great feedback, and a few interesting ideas to incorporate going forward.
Lee and I are already starting the planning for the next version of this. We will have more team building activities, better communication, better transparency, and better technology.
If you’re interested in hearing more about the project and what we’re thinking about going forward, you can watch the discussion that Lee and I had with Robert Skrobe and Sandy Lam on their podcast, Remotely Interesting.
It was a great discussion, and one that will continue over the next few months. I’m really excited to keep this effort going and see where it ends up.