Components
The components of a global framework that will make expansion to any new market possible depend on a company’s ability to support languages, regulations/privacy, and internationalization for each market. There is a lot to get done for an international launch and I’d break the work into two sets of work. In an earlier post, I referred to these as internal and external facing but it is more nuanced than that. So here I am changing the metaphor to make this simpler. In weaving, the warp is the base layer. And woof is the layer that intertwines across all the base threads as can be seen in the image above. So the secondary, or the woof level of work is to get market fit, adapt the product to a market’s regulations pricing, partnerships, creating entities in each region, transfer pricing, sales, etc. All of this is unnecessary if the markets can’t be supported. In technical terms, you might say the stack that supports the product’s Warp needs to be built for configurability, scalability, and extensibility. Otherwise, each new country and region will introduce a long list of development requirements that increase costs and delay launches.
The work (Warp)
Language- Localization team
Most people are familiar with translation or localization work for launching in another country. There is another set of work that is UI, UX, and engineering-based to support languages. The UI should be localizable and should be in the same language with consistent translations that match any other content on the page. UX teams need to build the right workflows to support different languages and cultural norms, and engineering you need to build in the ability to sort, order, search save, and display different languages to a user. A general tenet of language work is to display the single language the user has asked for or expects. Avoid multilingual experiences. For the stack to be usable globally it should have font and engineering support for double-byte (CJKV) and bi-directional languages (Hebrew, Arabic, Urdu).
Regulations industry specific /Privacy state or federal laws -Legal, Privacy
There are 2 sets of work in this category. Legal, Privacy, and regulatory teams weigh in on what is required prior to a build happening. Engineering/UX/Product builds a prototype to share with these teams to ensure it meets the requirements and then a final build and review is done to ensure it meets the expected process. This work is especially important in regulated industries and in countries like Europe where GDPR affects every business’ collection and retention of data. And in the US many states are creating privacy laws similar to EU-GDPR since the US government has not passed comprehensive legislation.
Location-awareness or collection – engineering teams
Since so much of privacy and regulation is based on residency or location, it is important organizations can collect location data. This can be done manually or via IP address but each method has its own pitfalls. Product and UX teams should be aware of location as an essential data point that has to be leveraged whenever there is a privacy component.
Date/time/currency- internationalization: engineering teams
Most of the date/time/currency/sort/order work is backend development by the eng teams. Or they will need to integrate with libraries that handle this for them. Subsets of ICU and CLDR are built into all mobile libraries, but the effort and pitfalls are more numerous for the web and mobile web. Care should be taken to create consistency across different platforms for the product.
