Onshore | Offshore: Don’t Break The Product

June 14, 2008 at 4:42 pm | In Process, Product development, Project management, Risk management, Usability | Leave a Comment
Tags: , , , ,

This article was originally published in Interactions magazine Nov + Dec 2007

Introduction

Offshore outsourcing (offshoring) for software development is a trend that is on the rise. The primary drivers of this trend are mostly economic. When the tech bubble burst in 2001, software companies saw their revenues drop while having to compete aggressively to win new business. In this economic climate, companies sought ways to cut costs while still delivering high quality products.

The technical workforce represents a significant portion of the operating expenses for a software company. On average, the fully loaded costs for a software engineer in Asia or Eastern Europe range between 30 – 50% less than their U.S. or European counterparts. And it’s not simply a matter of expenses. Engineers in these lower costs regions have proven their technical capabilities on numerous projects.

When user experience (UX) design is done in the U.S. or Europe, and the user interface (UI) development is done offshore in lower cost locations; there is a high potential for negative impact on product usability. All the user research, design and usability testing on earth will not make products usable if the design intent is not properly communicated to and utilized by development teams working in a remote location. The organization, processes, and communication paradigms used within development teams can make or break the usability of a system or product. There are two key issue areas that should be kept in mind if your UX design team is required to work with an offshore UI development group

  1. Immaturity of offshore UI development processes
  2. Interpretation of design intent

In this article I’ll examine these factors in depth; offer additional insights and perspective from several other professionals with offshore development experience; and suggest ways for overcoming the barriers of working across distance, time zones, and cultures.

Issue 1: Immaturity of offshore UI development teams

The lack of maturity in offshore UI development results from two key factors: 1) lack of experience with UI development in general; and 2) the low level of status in which UI development as an engineering discipline is held within many offshoring companies. Without mature practices in place, development proceeds by trial and error rather than by leveraging proven methodologies. Creating usable products can be challenging in your own country when working with seasoned UI developers. It becomes seriously challenging when offshore engineers do not have significant UI development expertise.

As a rule, UI development in offshoring companies is viewed as an entry-level engineering discipline where beginners can “cut their teeth” and then move on to more “interesting” technical challenges. This means that the onshore UX design team will often find itself working with offshore engineers who are relatively junior in their careers, and have little experience in either software engineering or UI development. Even if you can find engineers with some experience, this will most likely be in web site development, rather than building productivity tools or traditional applications. With inexperienced UI developers, basic knowledge of UI and application standards and behaviors will be noticeably lacking in their skill set.

Alvin Wen, the chief architect for a Manhattan-based software company, discovered this first hand while working with an India-based development company. “When doing UI development locally, we typically specify things loosely, and expect our developers to add the details based on their experience and knowledge of best practices. When we did this with our contractor, the results that came back were very disappointing. We needed to give the offshore team a specification that covered every single detail of the UI.”

Wayne Hom has significant professional experience developing UIs for products and solutions. He currently serves as CTO for Augmentum, a software services company with offices in China, India, and the Silicon Valley. Wayne mentions that, “In China, until very recently, UI was not thought to be the most interesting software problem to solve. While the recent Internet boom and handheld device proliferation have changed that perception, even now there are few GUI gurus that you can simply hire. As a result, we focus on developing potential talent in the people we hire. And China has enormous numbers in the potential talent category.”

Recommendation: Hire experience and build long-term relationships

1. Take great pains when selecting an offshore contractor: Find an engineering team that is experienced in UI development, standards, and technologies. Interview every UI developer that will be working on the project to ensure they communicate well in the native language in which you will conduct your business. The benefits of working with a team of experienced UI developers should not be underestimated. Less mentoring and coaching are required and, a better quality product can be built more quickly and with fewer errors.

Hom points out that, “Augmentum’s team in China focuses on hiring candidates who have demonstrated interest and aptitude for UI development based upon academic and prior work experience. Significant time is then spent mentoring and training these people, not only in technology, but also on style guides, UI consistency, project management, and client communication.”

2. Ensure the offshore contractor’s UI development team has a technical and management infrastructure: It is important that UI developers have a career path and value network for their skills. Engineers who are good at UI development should be able to progress organizationally as they broaden and deepen their skill sets and experience. If new engineers are constantly cycling through the UI development team, you will constantly lose organizational & domain knowledge. This will inhibit the offshore team’s ability to move quickly or advance into new products and technologies as business requirements dictate.

3. Manage the offshore team in the same you would an onshore team: Provide team members with responsibility, praise, and recognition when it’s due. A reward system should be developed to drive quality and usability into the product. Promotions, recognition, and bonus money (provided by the onshore team) should be paid out for exceptional quality work, adherence to specifications, and technical excellence. Reserve the right to fire developers from your project who are either not technically proficient, or that cause problems due to poor attitudes. If the offshore team is managed effectively, its members will be more motivated to contribute to the best of their abilities.

Jon Innes, a UX Director at Intuit, has previously worked with offshore UI development teams in India and China. He mentions that, “The culture of the offshore team must be one of implementing to spec, and the reward systems for the team must support this.”

Issue 2: Communication and interpretation of design intent

Software design is a communication intensive activity, requiring high degrees of immediate and direct collaboration among the players. The nature of working with offshore development teams does not lend itself well to this type of approach and results in fragmented discussions and time lags to resolve issues. Spontaneous meetings and whiteboard-design sessions become nearly impossible when working with offshore teams. All interactions between teams must be scheduled and coordinated. It is typical to experience 24 hour time lags in communication since one team has usually gone home by the time the other team is just starting their work day.

Large amounts of information are necessary to build a well-functioning UI. At a minimum, the UI development team must know what aspects of a product’s object model are exposed to users; how those objects are to be presented on screen; how users will navigate between objects and interact with them; and the success and error conditions that can result from these interactions. If this information is not sufficiently well-communicated, building the product becomes difficult if not impossible. Without sufficient details, UI engineers will exercise their own creative initiative to fill in the gaps. When this happens, usability problems are likely to be introduced. Implementing UI objects and behaviors without a well developed understanding of target user populations, their tasks and objectives, and without adherence to known UI standards usually leads to poorly engineered results. QA organizations also cannot work effectively without detailed product specifications. If input and behavioral constraints are not documented, the QA team will not know how to correctly validate product behaviors.

Jeff Johnson, Principal of UI Wizards, has worked with offshore UI development teams India, Asia, Eastern Europe, and Israel. He mentions that, “Offshore UI development can be done naively or done with care. I am often hired to fix a project that has been developed offshore without much supervision. Sometimes I am called back onto a project to fix a design that has not been properly implemented to my specifications. On the other hand, there are offshore companies that will implement a specification so exactly that even the sample data matches what was used in the screenshots.”

Recommendation: Structure design & development to support good communication practices

The onshore company must develop artifacts and processes that support communication of design intent. Furthermore, the offshore team must be a full-fledged participant in these processes.

1. Detailed use cases: Help the engineering and QA teams understand who will be using the product and for what purposes.

2. Design specifications: Use the UX specification as a planning tool. Specifications must provide thorough and detailed instructions for all of the behaviors, navigation, and visual appearance of the objects in the user interface. Allow the UI development teams to review and understand all the details of the solutions they will have to implement. It will help them to plan and prioritize their work efforts more efficiently. A good specification is also helpful to other groups in an offshore team (e.g., QA, middle-tier and backend engineering teams, etc.) who can also plan their work around the user experience their work products need to support.

3. Specification reviews: Encourage the UI development team to provide feedback on missing UI details or back-end support requirements. Spec reviews provide a huge amount of buy-in because they allow engineering teams to review and scope the designs with a fine-toothed comb. This helps the offshore team to what it is they are being asked to build before the hard work of coding begins.

4. User interface QA process: Involve the QA team in validating the UI. They will naturally become your allies since good specifications allow them to develop their test plans early in the development cycle. This involvement ultimately allows the QA teams to more effectively focus on testing product functionality. Another important QA consideration is to ensure that you have a dedicated resource for testing the UI by hand, as many small-scale usability issues can be discovered this way.

5. Treat all UI problems as bugs: The QA team should log all UI defects they find and assign these to UX team members for comment on how the issues should be resolved.

6. UI feature sign-offs: Allow the onshore UI team and QA group to declare UI features completed to a satisfactory level of quality. UI sign-offs can be used to drive final project payouts, or bonus monies where ongoing working relationships are involved.

Conclusion: Create a top-caliber, usability-aware development team

As UX design professionals we have a vested interest in working with high caliber UI developers. In order to ensure this is the case; help create a solid offshore UI development team by:

  • Requiring a technical and management infrastructure for the UI developers
  • Working to set hiring standards and criteria such as UI engineering interest and aptitude, and UI-specific technical skills.
  • Utilizing a reward system to motivate team members as well as drive quality standards into the product

Getting an offshore team into the usability mindset is essential to creating a well-functioning, usable product. This is best accomplished by:

  • Educating the offshore team deeply and constantly about your product’s target audience
  • Creating user profiles that describe the product’s audience and their goals
  • Including detailed usage scenarios as a part of all UX specifications so that the context of use is well-understood
  • Creating detailed product specifications that describe the behaviors, navigation, and visual appearance of all objects in the UI
  • Leveraging the power of communication tools such as bug databases, email, VOIP telephony, and instant messaging to keep in constant contact with the offshore team
  • Engaging the offshore QA team to perform walkthrough UI evaluations as part of their daily testing matrix

With these types of processes in place, the offshore team will gain a much better understanding of the target audience, and an appreciation for why design and usability are important factors in a product’s success. Addressing the concerns outlined above helps ensure that products don’t become less usable just because they are developed offshore.

Offshore development companies that are interested in differentiating their service offerings from those of their many competitors may want to take note of the recommendations cited above. Software companies with sophisticated UX processes will more likely be attracted to a vendor who understands and utilizes these practices. The practices also offer significant value to less sophisticated clients of the offshore company (such as startups) who often need to be coached on all of the necessary requirements for engineering a superior user experience.

No Comments Yet »

RSS feed for comments on this post.

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.