People: on the enterprise

XII.3 May + June 2005
Page: 52
Digital Citation

Virtual bridges


Authors:
Dustin Beltram

With one hand on the steering wheel and another cradling her cup of coffee, Nellie grouses to herself about having to come in to work for an early meeting. Who schedules project kickoffs at 7am? Running late, she pulls into the nearly empty parking lot, gets a great spot near the side door, jumps out of her car, and sprints to the meeting room. When she arrives, only one other person is there: Paul, the project manager.

“Hey, Paul. Where’s everyone else?”

Paul points to the speakerphone, then says, “Hi Nellie, glad you could make it. Why don’t you introduce yourself to the rest of the team in Moscow?”

Three weeks into the project, Nellie has barely heard a peep out of anyone in Moscow. She’s supposed to be redesigning the enterprise security application her company recently acquired. But ever since the kickoff meeting, her email inquiries to the product manager have been met with perfunctory responses, and she’s still waiting to be granted access to their network fileserver. How is she supposed to do her job if she can’t get anyone to pay attention to her?

Many designers, especially at enterprise software companies, find themselves participating in development projects where the various team members are spread around the globe. It’s a curious situation; it’s hard enough to get product managers, engineers and user interface designers to cooperate when they’re collocated, much less when they’re spread across multiple time zones.

There are a number of reasons companies establish distributed teams. In an attempt to save money, many are outsourcing a portion of the development work by using less expensive programmer hours from “offshore” facilities. Another tactic is to develop a 24-hour work cycle by using resources literally halfway around the globe. Other companies’ distributed teams have grown over the years through mergers and acquisitions, and are now looking for ways to make the various product fiefdoms cooperate to build more integrated solutions. Alternatively, a large company may decide to open a regional office to take advantage of a localized talent pool.

Whatever the reason, companies seem determined to make distributed development work. As practitioners, we need to find creative ways to limit the impact on the UI design process. It’s not that the problems are significantly different from those typically faced by user experience teams—they’re just aggravated by distance.

For instance, sharing information becomes more difficult. It’s not possible to stop by someone’s office for a quick chat to clarify a requirement. Sharing documents and deliverables is more difficult too, especially if the company network doesn’t provide good connectivity to all sites.

It’s also true that any existing political problems seem to fester in a distributed environment. If UI design is not considered an integral part of the development process at a company, it’s all too easy to ignore remote UI designers on a project. Also, if a product team is used to making autonomous decisions, or if a culture of information hoarding exists, it can be difficult for a distant designer to join.

What’s a designer in Nellie’s position to do? Nobody has quite figured out the “best” way to run a distributed development project, but I offer the following tips:

  • Look for strategies that establish trust and keep the lines of communication open.
  • Use technology to build virtual bridges to your teammates, and fight against radio silence.

Text Communications

If the teams are in time zones with even a couple of overlapping hours, instant-messaging applications allow team members to see if others are “in” and permit them to “drop by” to ask quick questions. Email, of course, is essential, allowing you to ship working drafts of documents to the team for review and discuss issues as they arise, but it won’t work well to ship large visual documents back and forth. Discussion boards are better, if you can convince team members to use them reliably, because they maintain a searchable history of discussions over time. Document storage systems provide a central repository for all of the intellectual property generated by the team. Web-based systems are easy to use and often provide much speedier access for remote teams than a Windows file server or a Lotus Notes database. And, WIKI Web sites (collaborative editing Web pages) are becoming more and more popular as the open source software continues to develop and additional features are freely available.

Voice Communications

The venerable telephone is technology we take for granted, but it can solidify the virtual bridge you are building. Conference calls are a good way to conduct meetings; additionally a simple phone call from you to an engineer to clarify an ambiguous design point or discuss an implementation detail helps solidify your position as an integral part of the team and makes you seem not so far away. If the expense of international phone calls or a lack of desk phones at a remote site makes this impractical, experiment with voice chat or a virtual phone application like Skype.

Mixed-media Communications

Almost everyone is familiar with conferencing applications like WebEx and NetMeeting. But additional tools are available, including virtual whiteboarding tools with which you can conduct remote brainstorming sessions. If not virtual whiteboards, other rapid screen prototyping tools can come in handy, especially if they can be used by both designers and engineers to quickly exchange user interface ideas.

Look around and see what tools your company already has on hand that you might be able to leverage in service of virtual bridge-building. But if none are readily available, you may have to get creative, even a bit subversive. Is your intranet rigidly controlled by marketing or IT? Then look for ways to go around it by creating your own Web site to be shared by the project team. If the remote sites are connected by a high-bandwidth network pipe, try streaming usability tests live over the company intranet. The IT department might hate you for chewing up bandwidth, but team members will love the ability to watch tests in real time. If network connectivity is an issue, you can mail usability highlights to remote offices on DVDs. It’s much easier to pop a DVD in a laptop to watch test results than it is to find the office VCR, and DVDs are a lot faster to duplicate too.

Documents and other deliverables are communication tools. Many teams try to deal with the distance by producing extremely detailed specification documents in an attempt to alleviate any possible ambiguity from the intended design. But keep your audience in mind; developers tend to be visually-oriented, and are rarely keen on wading through a phonebook-sized specification. If you must pursue detailed specs, just make sure they’re not the only form of communication between you and the rest of the product team. Resist the urge to toss a specification over the wall, and concentrate on building the virtual bridge instead. The spec should be a secondary reference to confirm prior decisions arrived at collaboratively, rather than a developer’s primary introduction to the user interface.

The best foundation for a virtual bridge is to establish trust right up front by insisting key members of the project meet face to face at key points in the project. Travel is expensive and often restricted, but it’s essential to get everyone together in the same vicinity at least once for the kickoff meeting. We’re still human, after all, and no amount of technology can yet replace looking someone in the eye, sizing them up, and shaking their hand.

Back to our narrative, 14 days later: Nellie retrieves her luggage from the baggage carousel and begins looking for signage to guide her to ground transportation. On the cab ride to her hotel, she mulls over her plan of attack. The project manager may be a slippery devil, but she’s noticed a few of the lead engineers have begun posting comments on the project blog she recently set up. Cementing a relationship with them on this trip will ensure the developers keep her in the loop as the requirements evolve. If she can convince them she’s here to help, they’ll be more likely to work with her and accept her designs. And hey, if nothing else, she’s got a new stamp in her passport.

Author

Dustin Beltram
dbeltramo@acm.org

About the Author:

Dustin Beltram is a senior interaction designer at PeopleSoft. With stints at companies such as IBM and Rational Software, he has spent the bulk of his waking hours over the past ten years designing software for corporate users. When not in front of the computer (where he spends entirely too much time), Dustin likes to read science fiction, futz with his camera, and marvel at the human factors issues encountered by his new baby boy.

©2005 ACM  1072-5220/05/0500  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2005 ACM, Inc.

 

Post Comment


No Comments Found