Product development with distributed teams has become more popular in recent years. This is partially due to the mobility of today’s workforce. It is not always possible to recruit the best talent from a company’s local job market, and not everyone is open to the idea of relocation. At the same time, the globalization of the consumer market creates a strong need for diverse teams that live and breathe in different cultures. One of the core skills of a strong user experience (UX) team is therefore the ability to work well with a product team located remotely, effectively communicating their design vision to ensure a polished final product.
Working at Microsoft in UX, I have many opportunities to work with different regional development centers internationally, such as China and Israel, and domestically, such as Massachusetts and Utah. The regional development centers’ programs are locally managed, with development and testing resources organized by product. Our UX team at the headquarters in Redmond, Washington, and product teams in regional development centers collaborate to release multiple products. Our charter is to drive Microsoft design principles into the products, as well as to ensure a consistent user experience across our product portfolio.
Why doesn’t each product team form a UX team in its geographical location? Having a centralized UX team at the headquarters allows us to drive interaction consistency for the entire division. We can scale out while remaining a centralized design unit. Moreover, the studio setup facilitates designer peer learning as we work closely together.
Having strong, close working relationships with colleagues in your distributed teams, particularly developers, is essential for implementing your ideas when you are not physically present.
An asset of having international teams is their expert knowledge in localization topics, such as text input method, text display, and regional user behavior. As a company, we gain diversity and global perspective through their regional research studies and participant recruitment for remote lab studies. Last but not least, distributed teams usually turn out to be very keen UX partners. This may be due to the perception of scarcity for centralized design resources.
However, collaborating in distributed teams is not all rosy—it has its own set of challenges, mostly related to distance and time-zone differences. It is more difficult to establish a satisfying level of rapport than when working with a collocated team, because of the lack of face time and hallway conversation. Project discussion and negotiation can easily spiral into a long thread of emails with diluted focus. Furthermore, one of the teams may need to meet at an awkward time, such as early in the morning or late in the evening, which can affect attention level.
Given that distributed collaboration has become popular, if not essential, for delivering great global products, how can we amplify the advantages and alleviate the challenges of partnering with distributed teams? I would like to propose seven best practices that in my experience help create successful project outcomes in distributed collaboration projects.
- The kickoff visit. Every distributed project should start with a kickoff visit at the regional site. Think about some small joint tasks that can warm up and launch the relationship with your distributed team. Some examples:
- Brainstorming core scenarios with the product team
- Workshops about writing scenarios, the design process, running focus groups, or setting survey questions
- Setting the expectation of deliverable turnaround times with the information architecture team
As a stretch goal, try to connect with people and their passion outside work. A lunch or dinner gathering is always a good venue.
- Recurring visits. After the kickoff visit, the UX team should set aside a budget for recurring visits to sustain the partnership. The frequency of visits depends on the project phase, geographical distance, and team budget. It could vary from one week per month to two weeks per quarter. While the activities in the kickoff visit are mostly intended to establish the partnership, activities in recurring visits should focus on getting things done, especially those tasks that require face-to-face interaction, like agile UX fit-and-finish and usability lab studies.
- Quality is more important than quantity when setting up a partnership. Focus on a few remote champions—people in the distributed sites who will advocate your ideas in your absence—when connecting with distributed teams. Good candidates are team leads or individual contributors who are passionate about user experience. Make good use of the kickoff and recurring site visits to let them know what you can offer. Activities like the design process workshops mentioned earlier are good ways to communicate your role in the project. Use great deliverables to substantiate your message to the teams. Having strong, close working relationships with colleagues in your distributed teams, particularly developers, is essential for implementing your ideas when you are not physically present.
- “The medium is the message” –Marshall McLuhan. The way you communicate is part of the message itself. People have a set of expectations that depend on the communication channel. Therefore, use the appropriate channels tailored to different contexts and goals. Here are the channels I use often and their considerations:
- Email. For relatively non-urgent matters. Expect more than a day’s turnaround time, especially for international teams, due to time differences. Try to be brief, but more contextual information can be included compared with, say, instant messaging. Be smart about who to put in the To: line for the most impact.
- Instant messages and phone calls. Because of their instantaneous nature, they tend to be used for quick checkins on timely issues. However, keep in mind your correspondents’ local time to avoid sending it at an awkward time.
- Online meetings. They allow for more interactivity with video and audio and are thus suitable for real-time collaboration (e.g., UX fit-and-finish, lab-study result presentation). At Microsoft, we use Lync, a videoconferencing and instant-messaging application, for all online meetings and presentations. If some stakeholders cannot attend at the set time, the recording function in most online meeting applications nowadays is useful for archiving and sharing afterward.
- Microsoft SharePoint. It’s a team collaboration tool that we rely on at Microsoft. Among the many collaborative features, versioning control enables partners to get the most up-to-date design and research documents, all stored in one location.
- Microsoft OneNote. This application is useful for capturing non-linear discussion, like brainstorm ideas, decisions, and follow-up actions from online meetings.
- Site visits. Despite all the capabilities that technology provides, for activities that are highly collaborative in nature, physical visits are still more efficient. For example, in the case of equipment setup for usability studies. Moreover, the visits allow both sides to have more candid talks through the off-the-record nature of face-to-face conversation. It’s particularly helpful to catch up on the “hallway conversation” happening at regional sites.
- Share your work early and regularly. In order to foster a strong working relationship with your distributed teams, share your design ideas and prototypes early and often. Try to involve your distributed partners in brainstorming. It encourages them to have a stronger sense of ownership of your proposed ideas.
For distributed collaboration, it is useful to have transferrable and self-explanatory work deliverables (e.g., PowerPoint decks or click-through prototypes) to document your design thought process. Designers can use storyboards and wireframes to lead the design discussions. Researchers can use lab study task lists and study results to drive study logistics and UX change requests into the product teams.
- Be thoughtful when setting up meetings. Scheduling meetings in advance, avoiding last-minute changes, and including a clear agenda with the meeting invite are all well-known office meeting etiquette. I’d like to emphasize their significance when interacting with distribution teams in different time zones, as those teams may have to stay up late or come into the office early to attend the scheduled meeting.
Be considerate: If you are working at the headquarters, avoid making the distributed teams always compromise by choosing a meeting time that’s convenient to you. They will recognize and appreciate your effort to respect their need for work-life balance. Also, be aware that holidays, even work weeks, may not be the same between different regions.
- Be aware of cultural differences. When interacting with teams in different cultures, be collaborative and open-minded. Interpersonal awareness is an important skill to have, particularly for teams that are used to working at headquarters and making autonomous decisions.
Working with distributed teams introduces both technical and cultural diversity to the company, which is integral to excellence. As with any collaboration, mutual respect and open communication can go a long way toward a project’s successful completion. Fortunately, most of the challenges mentioned here can be alleviated by recent improvements in technology and data-connection speed. Initially, you may find there is more preparation work needed for distributed collaboration. But over time, the effort you spend will be well worth the creativity and insights you might not have gained otherwise.
Charles Yiu is a senior program manager at Microsoft’s Next Generation Devices group. He has been leading products across U.S. and international product teams, defining and delivering user experience for next generation consumers, information workers, and IT professionals. He has a master’s degree in human-computer interaction from Carnegie Mellon University. email@example.com
Copyright Held by Author. Publication Rights Licensed to ACM.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2014 ACM, Inc.