In Part I and Part II we looked at elements, both foundational and code-related, that affect speed. In Part III we started our exploration of velocity by looking at mitigating risk. In this entry, we'll look at expanding our app to other locales.
It may seem somewhat counter-intuitive, however, the job of mitigating risk becomes even more difficult when we talk about business on a global scale. One of the greatest problems we face when building a product for a global market, however, is not risk, but rather that we are used to thinking only in terms of our own country, and our app appears to be something like a tourist when it’s used outside of its home country.
It’s relatively simple to develop an easy-to-use app for your own country because we know all kinds of things about our country – like you cannot require someone to give their ZIP code for a cash purchase in the US, or that privacy laws for the EU require disclosure about how information – like a Flash cookie or browser fingerprint – is collected and used, or even more simple things like how to collect addresses and phone numbers or what funding methods (e.g. lastschrift or credit cards) are typically used.
Beyond the technical "how" of code development and reuse, issues such as legal restrictions regarding what information can be collected, when it may be collected, and how it may be used as well as cultural issues such as which item a user is likely to select from a list in a given situation affect payment interfaces used globally, but they affect other apps used globally as well.
In developing a global product, we have to consider not only the nuanced issues - like the selection rate of lastschrift versus credit cards in a payment interface - but other, simple things as well. We have to consider something as simple as what we know, or can know, about information like addresses and phone numbers for other countries.
You can easily target a single country and do the necessary research; however, we must either accept the impact of increased complexity that comes with a highly localized product or determine how to generalize the interfaces by answering a host of questions – for example, can we validate phone numbers or postal codes, what are the common elements in an address, what can we determine about different funding instruments, and how do we design for linguistic issues, such as text direction or significant variance in word length, and how does cross-border trade affect any or all of these issues?
Of course one of the greatest dangers in the globalization of our product, is like the danger associated with risk - it can easily impact velocity. Further, the more subtle part of the danger to velocity lies in the way data collection intended to mitigate risk or make a more global-friendly product contributes to cognitive overhead.
Notes:
- The EU
- Page load time is greater in LATAM than in the US (AR and BR have load times approximately 2x the US times); however, there is wide variance in APAC (load time in CN is about the same as US, but load time in JP is less than US times, with mobile nearly .5 the US times, and most other countries in APAC are significantly slower than US times). http://analytics.blogspot.com/2012/04/global-site-speed-overview-how-fast-are.html
- China Union Pay
No comments:
Post a Comment