I recently taught a session covering the fundamentals of UI design and usability to a group of about 50 engineers in downtown Bangalore...uh, I guess that was in July. I found these students refreshingly more receptive to tools and best practices than many students I've taught in the US, apparently because they possess a basic element of humility.
I present UI design and usability from this perspective: a successful design is one that factors for the human machine and its social and performance constraints. Too often UI design devolves into a subjective game resembling hand-ball with a curtain, which is totally unnecessary because in the end, lacking good customer data, no one really knows what constitutes good design...except the target customer.
Presenting the just the basics, stuff that is more than available in the US, I've found a great number of these junior -to- senior developers have taken hold of the teachings and have gone through extraordinary lengths to learn more so they can be successful UI developers.
The ACM's SIG-CHI has enjoyed an impressive increase in contributions from emerging Indian and Chinese experts, and the world's leading UI researchers often share their wisdom in these communities, so there's a change in the works.
Its interesting - not once have I experienced anyone on these teams argue that they can deliver intuitive UI design because "they too are computer users and thus know what is intuitive", an extremely common engineer cop-out for instituting good UI design methodologies. These developers understand they are located 10K miles from the target market, and the UI design fundamentals so often scoffed at in the US are simply accepted as tools enabling them to become more successful.
From a management perspective I suppose in the end its all how you sell an idea, how you position it as adding to their own personal "equity" as a developer. We've seen improvements in Asia, and slowly, in the US as well. I suspect competition is good for business in this regard.
I'd like to emphasize that being Indian or Chinese or Russian doesn't preclude anyone from doing good UI design - not making it a priority does, which displays reckless corporate disregard for maximizing profits over the product lifecycle. Once they accept their own limitations and how to use well understood tools for UI design, I've learned these eager contributors are often more than willing to put these new tools to work.
Again, thanks for the opportunity to be involved in this discussion. Cheers!
Bottom line: if you do it right you get what amounts to near-round the clock development at a fraction of the price. If you screw up, even as little as twice a week, you lose a week of development, and sometimes more.
Background: I've invested five years involved in the management and growth an Indian engineering team, and spent one year working for an engineering company based in Bangalore. I'd like to share some real experience and raw numbers for educational purposes.
First off, two things compel management to explore Indian development as a viable option:
1.) Cost savings
2.) They speak English
First, cost. The burdened rate for your average full time US software developer currently runs around $30-$50 an hour. (Burdened rate= hourly expense to the organization, which includes hourly wage, PLUS hourly breakdown of benefits, PLUS hourly breakdown of an individual's share of the operating expenses, calculated roughly as "AnnualExpenses / NumberEmployees / 2080", 2080 being full time work including vacation and all that.)
The burdened rate for your average web developer in Bangalore India runs anywhere from $6.50/hr USD for entry level engineers to $20/hr USD for intermediate host software end embedded engineers. Note that Bangalore is perhaps one of the more expensive markets for developers, certainly more so than Chennai and in Hyderabad (see below for regional discussion).
Quick - do the math. From a cost accounting perspective this makes loads of sense. The devil, of course, is in the details.
Next issue: "they speak English." That is true, but in the south, where the "High Tech Triangle" is defined by the cities of Bangalore, Hyderabad, and Chennai, often they speak Kannada or Tamil first, THEN they learn Hindi and English in school. Sometimes English isn't even their second language.
At this point many laugh and point out that there is then no way one could hope to understand these people, but that's an oversimplification. I've yet to have an experience where I've been unable to understand what an Indian Engineer is telling me.
Where this becomes an issue is where communicated expectations and requirements are sloppily conveyed verbally or through informal channels, such as Email. This audience of any should know to manage requirements well, but I've seen this mismanaged repeatedly.
Number 2 on the aged list of "Sex Best Practices of SW Development" states one should "manage requirements." Working with teams in remote locations, regardless if they are across the country or around the world, will fare far better if you nail this essential rule.
What happens if you don't manage your requirements? I encourage anyone to try working for a US company while located in a remote office...or even managing your project while on the road and working out of a hotel room. Working in India is often like working at the end of a 10K mile whip. Most people forget that hallway conversations don't make it to your remote office.
One more point on requirements: make sure your specifications include a definition of UI, preferably developed in the market where the product will be used, and look into using a string table to manage your strings, which helps greatly in your localization efforts. I actually make these recommendations regardless of where the SW team is located. Since when have traditional SW developers created winning interfaces?
If an Indian engineer has been toiling to get into SW development since they were 13 years old, how would they gain the experience to know what UI is intuitive? And even though developers have a good command of the English language, don't expect them to fix typos in your strings...which is why a string table is often better.
This is actually a huge issue, but in summary, nail your requirements and you come close to nailing this whole "they speak the same language" deal.
Finally, don't be shy to call during their operating hours, which on the west coast is 11.5 hours off. The work day typically begins at 9-10 am, and continues till 7-8 pm. Lunches are at noon or 1, and there is a coffee time taken at 3 or so. A phone call will nail close to every issue, far more so than an Email.
Finally, know your regions and how to take advantage of them. The "High Tech Triangle" is getting pretty sophisticated and therefore expensive, relative to other developers in other areas in India. Step outside this triangle and find some fat development deals, such as Profluent (not the one in San Jose), who is located outside this region and therefore hit even harder for business than those within, but my getting access to Profluent came through a strong personal relationship I have there. It pays to network.
Bottom line: process exists to negate risk, so evaluate the risks, then staff and define processes as appropriate. If I were to do it all over again, and I am, I'd invest in a project manager whose not afraid of 36 hour flights and 2 am calls, and I'd work with a smaller development shop before I'd work with a large one, for reasons I'll not enumerate here.
I'd like to end by sharing why I continue to chose native Indian developers for personal start-up ventures involving my investments: the developers I know there exceed the technical sophistication of domestic US resources. Too many American engineers smugly avoid cramming on diverse topics, a skill learned in the high-stress schools that weed our slackers. If I want good engineering work I call my friends in India.
Slashdot Mirror
I present UI design and usability from this perspective: a successful design is one that factors for the human machine and its social and performance constraints. Too often UI design devolves into a subjective game resembling hand-ball with a curtain, which is totally unnecessary because in the end, lacking good customer data, no one really knows what constitutes good design...except the target customer.
Presenting the just the basics, stuff that is more than available in the US, I've found a great number of these junior -to- senior developers have taken hold of the teachings and have gone through extraordinary lengths to learn more so they can be successful UI developers.
The ACM's SIG-CHI has enjoyed an impressive increase in contributions from emerging Indian and Chinese experts, and the world's leading UI researchers often share their wisdom in these communities, so there's a change in the works.
Its interesting - not once have I experienced anyone on these teams argue that they can deliver intuitive UI design because "they too are computer users and thus know what is intuitive", an extremely common engineer cop-out for instituting good UI design methodologies. These developers understand they are located 10K miles from the target market, and the UI design fundamentals so often scoffed at in the US are simply accepted as tools enabling them to become more successful.
From a management perspective I suppose in the end its all how you sell an idea, how you position it as adding to their own personal "equity" as a developer. We've seen improvements in Asia, and slowly, in the US as well. I suspect competition is good for business in this regard.
I'd like to emphasize that being Indian or Chinese or Russian doesn't preclude anyone from doing good UI design - not making it a priority does, which displays reckless corporate disregard for maximizing profits over the product lifecycle. Once they accept their own limitations and how to use well understood tools for UI design, I've learned these eager contributors are often more than willing to put these new tools to work.
Again, thanks for the opportunity to be involved in this discussion. Cheers!
Background: I've invested five years involved in the management and growth an Indian engineering team, and spent one year working for an engineering company based in Bangalore. I'd like to share some real experience and raw numbers for educational purposes.
First off, two things compel management to explore Indian development as a viable option:
1.) Cost savings
2.) They speak English
First, cost. The burdened rate for your average full time US software developer currently runs around $30-$50 an hour. (Burdened rate= hourly expense to the organization, which includes hourly wage, PLUS hourly breakdown of benefits, PLUS hourly breakdown of an individual's share of the operating expenses, calculated roughly as "AnnualExpenses / NumberEmployees / 2080", 2080 being full time work including vacation and all that.)
The burdened rate for your average web developer in Bangalore India runs anywhere from $6.50/hr USD for entry level engineers to $20/hr USD for intermediate host software end embedded engineers. Note that Bangalore is perhaps one of the more expensive markets for developers, certainly more so than Chennai and in Hyderabad (see below for regional discussion).
Quick - do the math. From a cost accounting perspective this makes loads of sense. The devil, of course, is in the details.
Next issue: "they speak English." That is true, but in the south, where the "High Tech Triangle" is defined by the cities of Bangalore, Hyderabad, and Chennai, often they speak Kannada or Tamil first, THEN they learn Hindi and English in school. Sometimes English isn't even their second language.
At this point many laugh and point out that there is then no way one could hope to understand these people, but that's an oversimplification. I've yet to have an experience where I've been unable to understand what an Indian Engineer is telling me.
Where this becomes an issue is where communicated expectations and requirements are sloppily conveyed verbally or through informal channels, such as Email. This audience of any should know to manage requirements well, but I've seen this mismanaged repeatedly.
Number 2 on the aged list of "Sex Best Practices of SW Development" states one should "manage requirements." Working with teams in remote locations, regardless if they are across the country or around the world, will fare far better if you nail this essential rule.
What happens if you don't manage your requirements? I encourage anyone to try working for a US company while located in a remote office...or even managing your project while on the road and working out of a hotel room. Working in India is often like working at the end of a 10K mile whip. Most people forget that hallway conversations don't make it to your remote office.
One more point on requirements: make sure your specifications include a definition of UI, preferably developed in the market where the product will be used, and look into using a string table to manage your strings, which helps greatly in your localization efforts. I actually make these recommendations regardless of where the SW team is located. Since when have traditional SW developers created winning interfaces?
If an Indian engineer has been toiling to get into SW development since they were 13 years old, how would they gain the experience to know what UI is intuitive? And even though developers have a good command of the English language, don't expect them to fix typos in your strings...which is why a string table is often better.
This is actually a huge issue, but in summary, nail your requirements and you come close to nailing this whole "they speak the same language" deal.
Finally, don't be shy to call during their operating hours, which on the west coast is 11.5 hours off. The work day typically begins at 9-10 am, and continues till 7-8 pm. Lunches are at noon or 1, and there is a coffee time taken at 3 or so. A phone call will nail close to every issue, far more so than an Email.
Finally, know your regions and how to take advantage of them. The "High Tech Triangle" is getting pretty sophisticated and therefore expensive, relative to other developers in other areas in India. Step outside this triangle and find some fat development deals, such as Profluent (not the one in San Jose), who is located outside this region and therefore hit even harder for business than those within, but my getting access to Profluent came through a strong personal relationship I have there. It pays to network.
Bottom line: process exists to negate risk, so evaluate the risks, then staff and define processes as appropriate. If I were to do it all over again, and I am, I'd invest in a project manager whose not afraid of 36 hour flights and 2 am calls, and I'd work with a smaller development shop before I'd work with a large one, for reasons I'll not enumerate here.
I'd like to end by sharing why I continue to chose native Indian developers for personal start-up ventures involving my investments: the developers I know there exceed the technical sophistication of domestic US resources. Too many American engineers smugly avoid cramming on diverse topics, a skill learned in the high-stress schools that weed our slackers. If I want good engineering work I call my friends in India.
I hope this has helped.