Try Mural

Remote design sprints can’t work! Can they?

Right now you may be juggling multiple projects individually or within your team. I know the feeling - a bunch of meetings every day, all of them focused on different projects or spent with different team members, multitasking to the extreme. 

You’re working on a lot, but none of it feels like it’s making meaningful progress.

The design sprint is a great way to break this cycle. What’s a design sprint? It’s a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Teams typically get together in the same place and focus on the problem for 5 days. They often lead to breakthroughs that might otherwise take months or never happen at all.

Typically, a sprint will look something like this:

Intro-to-Design-Sprints.-Rafi-Finegold.-Dec-3-2017.-2

Day 1: Map out the problem and pick where you will focus

Day 2: Sketch competing ideas and solutions on paper

Day 3: Turn ideas and solutions into a hypothesis

Day 4: Build a high fidelity prototype

Day 5: Test your prototype with real users

 

 Our Situation 

Earlier this year, my team and I were feeling caught up in this cycle of extreme project multitasking and wanted to break it with a design sprint. The catch? We are a fully remote team and didn’t have budget to fly everyone to the same location for 5 days.

For the rest of this article, I’m going share how we planned and ran our remote design sprint. I’ll reference many parts of the sprint process outlined in the book, Sprint, but will mainly focus on what it was like to do this remotely - the advantages, disadvantages and the surprises. If you want to really learn the design sprint process end to end, I highly recommend reading the book.

 


 

Pre-Sprint Setup

 Forming The Team 

We followed the guidance from the book here and looked to set up a team of seven or fewer made up of a decider, tech/logistics expert, customer expert, design expert and facilitator. We left off the finance and marketing experts since we were just trying this out for the first time and didn’t think we’d be figuring out budgeting or promotion. We were motivated to figure out a particular problem, but equally motivated to learn if we could do this remotely.

Forming the team seemed to be made much easier by the fact that we’d all be remote. Travel didn’t matter. Location didn’t matter. Time zone mattered a little bit, but not much. Without those constraints, we quickly formed our sprint team. My colleague, Greg Smith, volunteered to play the critical role of the facilitator, one that would prove to be quite challenging in a remote setting. I would play the role of the Decider. Now that we knew who, we needed to figure out when.

NOTE: We’ve since moved on to planning our next three remote design sprints and have employed a process using MURAL to help identify the team members for each sprint. This part was pretty obvious for our first one but hasn’t been for the next few since we will be doing them with and for other teams. We now use the template below to source candidates for each of the roles. Then we dot vote to pick the winners. There’s some discussion afterwards, but this has definitely sped things up.

 

 Scheduling The Sprint 

I knew that the hardest part would be finding 5 days when we could all be “out of the office” and fully focused on only this. Out of the office in a remote context means setting the expectation in advance that we were unreachable. For the 5 days, it meant shutting off all notifications and eliminating distractions.

To help us find a block of 5 days, we used a simple calendar picking tool, DoodleIn the book, it’s recommended to do 5 consecutive days, Monday through Friday. We couldn’t find an available Monday-Friday block anytime soon, so we opted to wrap around a weekend, going with a Wed > Thurs > Fri > Mon > Tues. This was another area where being remote was a big advantage. Remote or not, we just couldn’t find a Mon-Fri block that worked. We are a distributed team and I imagine most sprints involve 1-2 team members traveling to be with the others. Asking people to travel somewhere and either stay for the weekend or leave and come back is a lot to ask. Since we’d all be remote, that wasn’t a factor.

I was a little concerned that we’d lose momentum after the weekend, but that didn’t end up happening at all. In fact, having the weekend in between “deciding” and “prototyping” days worked quite well. The two day break felt like it arrived at the right time and we came in on Monday (our day 4) fully energized.

 

 Pre-Sprint Preparation 

A couple of weeks before we were scheduled to start, we had a meeting with the team where Greg, our facilitator, briefly reviewed the overall sprint plan and the problem we’d explore. After that, we mostly focused on remote logistics. Definitely don’t skip this part! Because we worked remotely on a regular basis, we had good remote set ups. If you aren’t remote regular, here’s a quick checklist you can run through to get ready. Be sure you have:

  • A good camera
  • A good microphone
  • If possible, a dual monitor setup
  • A quiet place (a cubicle amongst many other cubicles is not a good location)
  • A good internet connection (one that can handle you being on video all day)
  • Some table or wall space to work with for the sketching portions
  • Some natural light (really helps when you are in front of a computer all day) 

Here are some pics of my set up. I ended up spending part of the sprint at the office and part at home. I was in my home office for the sketching day and covered the walls.

image12

image10

image9

We also used the preparation meeting to review the collaboration tools we would be using. For us, that was:

  • Google Hangout for anything that involved screen sharing or discussion
  • Google Drive for storing and sharing of documents
  • MURAL for collaboration
  • Slack for link sharing, chat and anything else (don’t forget to set up your Slack channel in advance so everyone can join)

 


 

The Sprint

 General Takeaways: 

  • The facilitator’s role is going to be extra challenging, because that person will need to manage and get people into multiple remote collaboration places. For us, that mostly involved a series of MURAL boards and docs in Google drive. These very quickly start to add up and on top of the ABC (Always Be Capturing) mandate of the facilitator, this will take lots of effort and focus.
  • Do some sort of warm up activity each day. You’d probably want to do this if you were together physically, but it felt really necessary being remote. We did silly things like describing our morning beverage selection process or sharing a fun fact. Do whatever works for you, but every little bit of energizing helps.
  • Do a mic check at the start of every day and after each break. It takes a few seconds and it’s worth it to avoid audio issues someone might not think are worth calling out.
  • Play music whenever possible. We did this during all the individual sections, like sketching. Again, it’s all about keeping the energy up. (You may even want to set up a shared Sprint playlist the team can add to.)
  • Without the physical queues available in a group setting, people will likely talk over each other. Facilitators will need to manage this if it gets in the way.

 

 Takeaways By Day: 

Day 1:  Map out the problem and pick where you will focus

We spent much of day 1 in MURAL coming up with our long term goal and sprint questions. Here’s another area where I think being remote is an advantage. Most of us can type faster than we write and we were able to very quickly generate lots of goal statements and sprint questions. Dot voting is always better when remote. It tends to remove the social pressures that come with affixing a physical sticky dot to a post it note that someone on your team created… while they stand next to you. It always seems to go faster and allow the good ideas to shine earlier.

Then we moved onto mapping out the problem. This portion felt more difficult because we were remote. We remained in MURAL and picked one scribe to manage it, but it just couldn’t quite compete with the ease of quickly drawing and erasing boxes and arrows on a physical whiteboard. Close, but in person gets the win for this section.

We also spent the day “asking the experts”, all of which was done over video or phone, which worked just fine. If we needed to, we shared our screen to show them the map. Being remote had a slight advantage here since we used MURAL to capture and affinity map insights gained from each expert, shown below.

Finally, we picked the part of the problem we would focus on and wrapped for the day.

 

Day 2:  Sketch competing ideas and solutions on paper

This day went really well. For our lightning demos of existing ideas, we each took turns sharing our screen and talking through our areas of inspiration. We had picked one team member to capture and sketch directly in our MURAL board during this. She had a stylus pen and iPad with MURAL running, so she was able to hand sketch in real time on her tablet. This worked really well. 

When it was time for individual sketching, we just stuck with good old pencil and paper for all the rounds. We played lots of music, too! At the end of the day, we each took pictures of our sketches and emailed them to our facilitator, who had them prepped and ready in a MURAL board for review the next day.

 

Day 3:  Turn ideas and solutions into a hypothesis

We jumped right into critiques and reviews of all the ideas. Our facilitator had set up the board you see below in MURAL, which was shared via his screen in our Google Hangout. One person captured along the way. Advantage went to remote here. There just didn’t seem to be any opportunities to campaign for or try to jump in and explain ideas. It felt pure :). Dot voting was also very easy here.

When we moved into storyboarding, it started to feel much harder. It was one easy for our scribe with the stylus and iPad to sketch ideas as she listened to lightning demos. But when trying to collaboratively story board with everyone feeding input to her, we all wished we could just be in the same room together. On the positive side, sketching the storyboard in MURAL allows you to copy and paste! This meant our scribe didn’t have to keep drawing the same frames over and over for each frame in the storyboard.

We finished the day by deciding what we would actually be prototyping the next day and wrapped it up.

 

Day 4:  Build a high fidelity prototype

This day began with a lot of debate about how we were actually going to prototype. We discussed Keynote, InVision, Google Slides, Powerpoint. Ultimately we settled on Google slides to create all the screens. Since we could all work on all of it simultaneously, it allowed us to move quickly.

We also decided we’d use InVision to stitch all the screens together to be used for our user tests. This day felt like it wouldn’t have mattered much if we were in person or remote. Either way, we’d likely have chosen the same tools. If someone needed an image or had a question we either chimed in on our video call or dropped it into Slack. The day moved along very quickly. By the end of it, we had a functioning prototype.

 

Day 5:  Test your prototype with real users

This day felt very familiar to us. We almost never conduct usability tests in person because of the challenges of getting our users to be where we are. We generally do remote moderated or unmoderated user testing. For our sprint, we used usertesting.com’s Live Conversation feature to schedule 5 user testers who we would test with. If you don’t have access to a service like this, I’d recommend using the same screen sharing tool you used throughout your sprint. Ultimately you just need two things: 1. To be able to speak with your user, 2. To be able to see how they interact with your prototype. Whatever tool checks those boxes and is easy to use is probably fine. Be sure to test your set up in advance a few times! I happened to be the interviewer for all of the user tests. After some experimentation, we decided that I would remained in our google Hangout and also join a Zoom room with the user tester. I shared my Zoom screen into the Google Hangout. It worked much like a one-way mirror would have worked where I was “with” the tester and the rest of my team was able to observe unnoticed through the Google Hangout. It also allowed the team to capture insights in our MURAL board along the way, shown below.

The capturing of the insights went smoothly. When all tests were done, we affinity mapped the insights to see the patterns.

And just like that, it was all over. We were excited, sad and exhausted. In a quick debrief we planned our next steps with this project and also reflected on what it was like to do all of this remotely. It was an incredibly positive and productive experience and we’re all excited about the next one!

 



 UPDATE: 

We recently welcomed Joe and Greg to share their story in a webinar - find the video recap and presentation deck here.

Joe Lalley

Joe Lalley

Joe Lalley leads an agency-style product organization at PwC, delivering a mixture of digital products and design thinking workshops.

Weekly Notes that Stick
An inspiring dose of design ideas to help you and your teams collaborate like the best pros out there.
Enter your e-mail
Where shall we deliver it?