I’ve been facilitating design studios with collocated teams for years. Many, including me, have covered the benefits of collaboratively sketching new ideas and concepts with a cross-functional team. Recently though, I was tasked with bringing this exercise to a distributed team. With the product and user experience team in New York and the development team in Vancouver, it proved to be an interesting challenge. What follows is a play-by-play of how we set up the exercise and executed as well as an analysis of the successes and failures of this first attempt. It’s worth noting that this was the team’s first design studio ever – which added another layer of complexity to the event.
We gave the teams a brief heads up of what was going to happen and asked everyone to come to their individual conference rooms with their own laptops. Each conference room had a Mac in it with a location-specific Skype account (i.e., it wasn’t a specific individual’s account – it was the “office” account). The two offices connected to each other via their office Skype accounts so that we could see each other as a group. This was critical as it was the closest we could get to physically being in the same room.
We prepared a very brief (~10 slides) setup presentation that explained the problem statement we were going to try and solve, customer testimonials and data illustrating that this problem was indeed real, the constraints of the solution space and a very brief recap of our customers’ needs. All of this went over very well and the teams understood the material clearly given their existing subject matter expertise.
Priming the pump with affinity mapping
Since this was their first collaborative sketching session, we didn’t want to jump right into drawing. To prime their creative pump, we kicked things off with an affinity mapping exercise. Typically these are done with sticky notes and a white board when the team is collocated.
In this case we used a shared Google Doc spreadsheet to conduct the exercise. We asked everyone in both offices to sign in to the shared spreadsheet. The spreadsheet itself had a column labeled for each person. We had 8 team members in the document at the same time.
The team was asked to come up with as many ideas as they could think of to solve the problem statement that was presented to them. Each team member would write one idea per cell in the column marked with his or her name. They had 5 minutes to generate as many ideas as they could. Some brief Q&A preceded the timer starting to clarify the constraints and guidelines for the exercise and the team was off! 5 minutes later we had a spreadsheet filled with about 60 ideas for various ways of solving the problem.
The next step involved each team member reading his or her idea out to the distributed team. Some ideas went by quickly while others were discussed with a bit more detail. The initial purpose of this was to simply have everyone in both locations aware of what was proposed by their teammates. While they could certainly read the spreadsheet on their own, it was much more powerful for each individual to read their ideas. The goal of affinity mapping is to then group these ideas into overarching themes around which the team can agree. In the physical world this is done by moving sticky notes around into the same physical area on a whiteboard or wall.
To simulate this in the shared spreadsheet, the facilitator (me, in this case) began a second sheet in the document using a personal laptop. The second sheet had column headers that reflected themes I was hearing as the group read out their ideas. Each column represented a theme into which a few of the ideas could potentially fit. This was done largely for efficiency of the process. We certainly could have started the second sheet as a group and figured out the initial set together but given this was their first time and we were starting to get a bit behind schedule I took the initiative to create an initial set of theme proposals.
The team was then instructed to take each idea they came up with and copy/paste it into the matching theme on the second sheet. If it didn’t fit they were instructed to create their own theme and were highly encouraged to change the wording of the themes if they felt it was not representative or misleading. Each member proceeded to do this for the next two minutes or so. We ran into some copy/pasting over each other issues. Google docs does indicate when another user has focus on a particular cell with a unique color for each user and their name. This helped a bit but this portion of the exercise got a bit messy. All in all, no theme names were changed and only one new theme was added. My guess is that the team was not completely comfortable with making changes to something that was already presented to them. I expect this to get better and easier with each run through this exercise.
The end result was a spreadsheet sorted into themes with each theme populated by at least 2 ideas and some with as many as 8. We reviewed the themes again as a team, discussed for a bit and agreed that this was a comprehensive set of solutions.
The plan was to break here and move straight into the sketching portion of the exercise but at 2 hours, we ran out of time for this meeting. We schedule part two of the exercise for two days later and allocated another 2 hours to it.
Note: following this exercise, the site cardmapping.com was brought to my attention. It looks very interesting and can potentially replace a physical whiteboard and stickynotes in this exercise. I’ll dig into it further but haven’t had a chance to run it through a proper exercise yet. Any opinions on it would be greatly welcomed.
Collaborative sketching with remote teams
When we reconvened we went through a modified version of the setup deck to recap the problem statement, constraints, user pain points and the themes we came up with during the first session. We then presented the team with the logistics of the collaborative sketching exercise.
The team was provided with a 6-up template:
and a 1-up template:
and a set of Sharpie markers. We explained to the team that we were going to ask them to sketch 6, high-level ideas based on the themes we brainstormed in 5 minutes. They were encouraged to draw, not write words and to use the sharpies to illustrate 6 separate screens or a set of workflows they felt made sense.
Five minutes later the team produced 8 sets of 6-ups that were filled out with visual ideas about how to solve this particular problem. We asked the Vancouver team to use an iPhone to photograph their sketches and email them to all the folks in NYC. We did the same for the Vancouver folks. We had initially considered simply holding the sketches up to the camera in each conference room but the resolution and the stability of the presenter’s hand made this sub-optimal. The process of photographing the sketches and emailing took about 5 minutes. It was a necessary task but it took a bit of wind out of the sails of the activity, as momentum was built up and people were anxious to share their ideas and see what others did.
With dual monitors we were able to view sketches on one screen and see the remote team on the other screen. This helped connect the dialog and the artifact to the conversation. Typically in Skype conversations participants don’t talk to each other but instead talk to the screen. I was happy to see the team members presenting their ideas both to their collocated team and the remote portion.
Each team member presented his or her ideas to both rooms. Given this was the team’s first time, there were the expected awkward moments of silence but a little proactive moderation through Skype helped move things along. The Skype connection held up well and allowed the remote teams to participate in relative real-time in the critique portion of the exercise. Having the sketches up close on local monitors was critical to the success of the critiques. It allowed up-close inspection of the artifact and direct, relevant questions and answers from the team. In doing some up front research for this activity, several recommendations came in to purchase an IPEVO document camera. It’s relatively cheap at $70 and has a great camera and stand for document photography and transmission. We didn’t use it for this initial round but are seriously considering it for the next go-around. It will be interesting to see how it compares to the simple iPhone-snap-and-share technique we used. At $140 total cost for the experiment (1 camera per office) it’s worth the gamble.
Another tactic we’re eager to try to speed up the sharing of the photos (if we end up sticking with that tactic) is getting them into a Dropbox folder automatically. We’re checking out ifttt.com to see if there’s something we can set up there that will automatically share pics from a phone to a shared folder. I’m aware that the site allows you to have Instagram photos dropped into Dropbox but am concerned that photos taken in that app don’t have the necessary resolution for this exercise.
The team that experienced this remote brainstorming session had never done any kind of exercise like the ones described earlier. This was perhaps a boon for us since we didn’t have to live up to previous expectations of processes and success. It allowed us to run the session as if this is the way it’s always done. The flipside, of course, is that, with no context, the team couldn’t tell us whether this was a better or worse way to elicit the same results. What they could tell us was that they enjoyed the inclusion in the ideation process and the ability to share their ideas with a cross-functional group.
I would deem this remote technique a success. We succeeded in having an 8 person team brainstorm together, share their ideas, draw together and come together around collaborative solutions for a specific problem statement. The distance was a challenge but was largely overcome with technology. Perhaps we were lucky to have a solid Skype connection as I’m sure a spotty one would’ve caused the exercise to fizzle. We learned a lot about what works well and the challenges of facilitating two teams in two different rooms. As with everything, this process is iterative and next time can only get better.
What do you think? Is this a viable technique for your organization? Have you done this before? What’s worked well for you when dealing with distributed teams?
P.S. — In Part II, I’ll follow up with any learnings from the next round of remote collaboration exercises.