Contextual Design with Distributed Teams

Let’s assume you’re all fired up and ready to go. You’re going to do Contextual Design for real this time; you’re going to run your interpretation sessions, build your affinity diagram. Everyone’s enthusiastic and on board.

Then reality hits. Half your design team is on the east coast, the other half on the west coast. Because of the last merger, your product manager is in Dallas. Your documentation group has been centralized in Chicago and you have a corporate mandate to integrate with that new acquisition in Atlanta.

Contextual Design is based on building a shared understanding. How can you do that when the players aren’t even in the same time zone?

Fact is, this won’t be easy. But it is possible. Here are some tips to make it work:

Choose your face-to-face events

You can’t get by with no face-to-face meetings. But you can minimize them by choosing them strategically. The two most critical points for bringing the whole team together are the kick-off and the consolidation and visioning. You can run distributed interpretation sessions and you can run interviews anywhere, but these two sessions need to be face-to-face. They are both free-form meetings where ideas are worked out and clarified — you’ll find it much easier to sustain working from separate locations if you’ve started out face-to-face.

The project kick-off

At the kick-off, all the key players come together to agree on the focus of the project. Without a clear focus—an understanding of what issues you are addressing—you cannot run the project successfully. A kick-off meeting should end with a clear, explicit agreement on the answers to the following questions:

• What is the challenge we are trying to address? Is it a new technology, a new work practice, or an extension of existing products? What’s driving the work?
• What is the work practice you plan to support? What are the key tasks? Who performs those tasks? Who depends on the results, or provides key inputs to doing the tasks?
• What are the work situations you need to see? What will you learn from observing these situations?

Use these questions to focus your discussions. Also look at the different technology you have, so people share an understanding of what it can do, and set up a plan for doing the visits.

Appoint a project leader, and give him or her the right to handle logistics for the team. Planning the visits and interpretation sessions needs one person managing all the threads.

Share the customer visits

Everyone should go on customer visits. You’ll want to gather data from around the country, so having a distributed team is a benefit — different team members can do the visits that are close to them.

If you have a core team that’s more heavily involved, they can travel from location to location, assisting with the interviews and doing interpretation sessions with each subteam. Try and define at least two people in each location as part of the project — it’s too easy for one person to become isolated from the team.

Setting up distributed interpretation sessions

It’s not necessary that every team member be in every interpretation session. If you have core team members traveling to different locations, you may not need distributed interpretation sessions, as long as you have four people in each session.

If you do need to run distributed interpretation sessions, get a decent tool to share the interpretation notes. That’s all it needs to do — share a single application for all participants. You won’t need any of the fancier features of these tools. We have never successfully run a distributed interpretation session with NetMeeting ourselves; perhaps you’ll have better luck. But we recommend using WebEx, Groove, or one of the other distributed-meeting products.

Run a phone teleconference between the different locations to talk to each other. These are easy to set up these days even without special systems. If you have a videoconferencing system, use it but don’t use the videoconferencing audio. Turn it off and run a parallel phone conference. For whatever reason, the time delay on every videoconferencing system we’ve used is great enough that you cannot use it for an interpretation session—you spend the whole meeting talking over each other.

Running distributed interpretation sessions

The interviewer walks through their notes as usual. The notetaker captures notes, but shares the note-taking application so that all participants can see the notes as they are written. Sequence models can be captured in an editor, and this can also be shared.

Other work models are captured on flip charts, as usual. They are not shared with the rest of the team until after the session when they can be scanned or photographed.

If you do a flow model, the flow modeler should be located with the interviewer — it’s too hard to get it right otherwise. It’s better if the notetaker is located with the interviewer, but not critical.

Consolidation and visioning session

However much of the process you use, you need to end with a session that brings everyone together and results in agreement on what action will be taken. In a simple project, you’ll build the affinity, walk it for issues and design ideas, and summarize your ideas. You may also do some visioning and planning. You may come up with a prioritized list of issues, fixes, and features.

Whatever you do, end by writing down your decisions and your action plan for making them happen.

Working as a distributed team is more difficult than being co-located, but it is possible and you should not let it get in the way of gathering and using shared customer data. The key is to be explicit and careful about your logistics, findings, and decisions. When you’re distributed disconnects that wouldn’t matter in a co-located team are harder to deal with. Stay on top of the process, and you’ll be productive and effective.