While offshore usability has great promise, there are circumstances that are clear contraindications for an offshore approach. The following are flags that should keep you considering onshore operations only.
Immature Usability. Process-driven usability is systematic, with defined tasks and deliverables. It is relatively easy to do this offshore. But if the team works in an ill-defined manner, the usability specialist needs to be there. Sometimes decisions are made in free-floating meetings. The usability specialist struggles to be heard as ad hoc design proceeds. This is certainly poor practice, as it results in high cost and poor quality. It is also a poor place to try to take advantage of an offshore team.
Very Short Projects. There is some overhead in working with an offshore group. Briefings require travel or must be done remotely So if a project is just a few days long, the setup time for the offshore work is not amortized over enough of an effort to make it pay off. If the work is reasonably straightforward (for example, an expert review), the offshore involvement can pay off over a few days. If the work is complex (like tactical support for an eCommerce site), then assume a couple of weeks of investment for the staff to understand the situation. The offshore group will not break even for complex involvements of fewer than six to eight weeks.
"High Touch" Environments. There are some organizations where the usability work requires a tremendous amount of interpersonal interaction. This might be because non-usability staff are insecure about the role of usability professionals. It might be an unstable management structure. In these cases the amount of time that offshore usability people must spend onsite or communicating can become awkward. At least some of the usability work must then be done locally.
High Security. In advanced offshore environments security measures appear draconian. Companies who get BS 7799 certification don’t allow free access to the Internet, encrypt and mark files, and even frisk employees. But there is a reason for all this effort. The emerging markets are more corrupt and so there is more risk. With the extensive security efforts, an offshore operation probably has the same security as a normal first-world office. If a highly secure environment is needed (e.g., military intelligence), then offshore does not make sense.
Extreme Criticality. There is usually some risk associated with offshore environments. Top flight operations have backup power, phone, and Internet connections. But there is still likely to be a bit more risk. If a day or two’s delay is unacceptable, due to flood, strikes, or other unexpected events, then it is best to avoid offshore environments. Certainly there is ALWAYS a risk. But it is somewhat smaller onshore.
Travel and Blending Is the Best Practice for Offshore Usability Work. In India the term "mortgage" is not commonly used. Referring to a woman as "homely" is positive (it means she is a dedicated homemaker). Checking out from a store almost always involves three or more people helping. While Indian usability specialists will understand English well and even be acquainted with America and Europe, the cultures are seriously different.
How do you compensate for such cultural differences?
From India we can communicate with phone, email, and Web conference, as well as FTP. But it is not the same as being there. Remote testing is now practical. But remote in-depth interviews are as yet unproven. You can talk with colleagues. But it is hard to develop the personal relationships that help resolve the difficult points in the design.
How do we compensate for the distance in communication?
At Human Factors International, we have found that the best practice requires travel and blending of staff. Over 80 percent of our projects blend local staff with global resources. The local staff understand the nuances of culture and language. They are also easily present for design meetings. Generally we figure one-third of the hours worked on a project will be done by local staff. Does this make sense? Let’s take a typical example of an expert review. See Figure 1.
The blending cuts the cost almost in half, while maintaining equivalent quality and speed of delivery. A good deal.
There are also times when the offshore staff need to travel. When a team starts work with a new group, it is best to have them visit for a couple of weeks. This allows a personal connection to form and communication channels to open. Given this, the only key travel is required when developing standards or interface structures. A project involving just detailed design generally needs no travel at all.
Human Factors International
Sidebar: Salaries around the world
As Human Factors International tried to compare costs of doing usability work around the world, we realized there was no multi-country salary survey of usability professionals. It was not possible to do a rigorous and detailed salary survey, so we offer this anecdotal survey. We contacted usability practitioners and academics and provided the profile below. They were asked to give us an approximate salary range for anyone who matched that profile in their country.
Profile. "The ideal candidate will have three or more years of experience in usability engineering, including user analysis, interface design, and usability testing. Experience in usability work for commercial applications (Internet, Intranet, back office, products) is a must, as is consulting experience and/or training experience in corporate settings. A graduate degree in psychology (human factors, cognitive, engineering or experimental) or a field related to human-computer interaction is preferred.
"S/he must be able to carry out usability work under a director, produce excellent written deliverables, and communicate clearly with the client. S/he will be asked to perform the entire range of usability work. S/he will have extensive interactions with clients, so the candidate must have excellent interpersonal skills, be sensitive to the client’s needs, and be able to give small group presentations. Projects may include teams from remote offices, so the individual must have the ability to communicate and work remotely."
Data from those who responded is given below:
©2006 ACM 1072-5220/06/0300 $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 © 2006 ACM, Inc.