Designing for Offshore Development

Everyone's talking about outsourcing and offshore development these days. It's been on the cover of major newsweeklies, featured prominently on the West Wing television show, and a topic of conversation around boardrooms and discussion groups. Regardless of your personal position on trade policy, globalization looks like it's going to be a fact of life in the software industry.

As an Interaction Designer, I'm not responsible for actually building the products I design. However, I find it increasingly clear that outsourcing creates a significant impact on the entire software design and construction process. Offshore development is in its infancy, but will continue to evolve to become an increasingly effective way to go about certain kinds of software construction. Based on recent project work, this article describes a number of observations worth considering as you ponder how outsourcing and offshore development may fit into your plans.

Tell them exactly what to build

One of the most significant realities about offshore developers is that they will build exactly what you tell them to build. This is both good and bad news. The good news is that they are likely to take your specification very seriously—not merely as a suggestion or starting point from which to improvise (as sometimes can happen within a development organization).

The bad news, of course, is that if you don't clearly plan and articulate every aspect of your product from user interface and product behavior to business logic and algorithms, developers are forced to rely on their own experience and judgment to determine an appropriate solution to an unforeseen problem or vaguely documented feature. The reality with offshore resources, however, is that they are very unlikely to have that experience.

Developers within product organizations have context and domain experience

"Traditional" developers in a product organization typically work in a given sector for a considerable amount of time. In addition to their coding chops, they are also likely to have significant domain knowledge and context about the product. This helps them make decisions when specifications fall short or technological limitations force them to change course.

Of course, even developers in the traditional in-house model are best served by clear and detailed design documents, but we traditionally rely upon their ability to understand the patterns and principles behind our design solutions to extrapolate solutions to new problems.

Offshore developers typically lack intimate knowledge of your product and business

Contrast in-house developers' understanding of product context with the fact that offshore "resources" may only be assigned to your project for a very short amount of time, may be quite inexperienced (the average age of engineers in India is 26), and that staffing may not be consistent across your project. Such developers are unlikely to understand how the bit they are working on fits into to the big picture of your product vision, and are unlikely to be able to make informed decisions about functionality and interface on the fly.

As observed in a recent Wall Street Journal article:

"the Indian engineers, who knew little about [the] software or how it was used, omitted features Americans considered intuitive… Accustomed to working closely with veteran engineers familiar with [the] products, the U.S. managers offered only vague outlines for each assignment. The less-experienced Indian engineers didn't include elements in the programs that were considered standard among U.S. customers. U.S. programmers rewrote the software, delaying its release by months"[1]

Failing to adequately design and spec the product not only invites the possibility that the end result will not meet your expectations (or even worse, your customers'), but also limits your ability to hold the development organization accountable for the end product. Without clear and complete specifications, it is next to impossible to contractually define project completion and deliverable acceptance criteria. What you end up saving on a dollar-per-hour basis can become dwarfed by endless iteration and a failure to get a desirable product to market.

Collaboration

Further complicating the need for clear and complete product design and documentation is the fact that the use of offshore development changes the whole collaboration dynamic. Just about every design and development methodology I've ever heard of agrees on the fact that the most efficient and effective way to convey information and drive decisions is through face-to-face conversation.

As a designer, I never feel particularly confident about a solution until I've shared it with the person responsible for building it and he has poked it and kicked it around…which is next to impossible when the person responsible for building it is in Bangalore and I'm in California.

Taking a simple e-commerce example, if we design an area of the screen to offer products that a user may be interested in (a la Amazon's "customers who bought this book also bought…"), someone must assess the practicality of querying the data warehouse to score and sort items in the list. If it increases page-load time by 5 seconds we may decide that it should be offered as secondary functionality on another page. In an offshore development scenario, this feedback may not be generated until design is complete and construction has begun.

Technical Design

Beyond evaluating the technical feasibility of interaction designs, there is the additional need for the design and documentation of all technical aspects of the product. One of Alan Cooper's hot topics these days is the importance of differentiating the activities of engineering and programming, where Engineers (often referred to as "Architects") are responsible for solving technical problems and determining how the software is to be constructed, and Programmers are responsible for actually producing the shipping code that comprises the product. (An analogy: Much the same as in the construction of a bridge or airplane, the people who design and decide how it should be constructed are different people from those who actually build it.)

So it seems that a product organization relying on offshore development still needs engineering resources in-house, first to validate the feasibility of proposed interaction designs, and second to document the technical aspects of the design.

And this second responsibility is no small task. While Interaction Designers are capable of designing and documenting a complete definition for all user-facing aspects of a product, there is a lot that goes on behind the scenes that also must be documented for the product to work properly.

Returning to the e-commerce example, not only is it necessary to assess the feasibility of providing "customers who bought this also bought…" functionality, but it may also be necessary to design and document the algorithm used to score the list, especially if it is considered to be proprietary business logic. While I'm sure the foreign development team is capable of devising some method of providing this functionality, it's utility to your customers is entirely dependent on providing the optimal method.

Conclusions

We already know that spending the time to holistically define and design a software product dramatically increases the likelihood that you will deliver an effective and pleasurable experience to your customers, and that communication is one of the critical ingredients to this design process. All this appears to be even more true if you decide to have the product built in India or Eastern Europe.

To be absolutely clear: to successfully outsource product development, it is crucial that every aspect of the product be specifically defined, designed and documented. The kind of hand-waving you may be accustomed to when working with familiar and well-informed developers will no longer suffice.

[1] Thurm, Scott; "Lesson in India: Not Every Job Translates Overseas", The Wall Street Journal, 4 March 2004. http://www.wsjclassroomedition.com/outsourcing/out_regret.htm

Filed under: Design & engineering, Development, Features

---

Post a comment

---