Internationalisation and Localisation "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 5 January 2017 True Architecture, Culture, Product Design, Product Development, Mind the Product Mind the Product Ltd 547 SiQing Lin shares her experiences with Internationalisation and Localisation at ProductTank London Product Management 2.188
· 2 minute read

Internationalisation and Localisation

TUI’s small team in London, have designed and built mobile apps which are used by millions of people around the world. SiQing Lin shares how they’ve achieved success at such scale.

Build centrally, deliver locally 

Their business in Europe is broken into 4 market clusters, that allows them to do things on the ground how they are done locally. Despite this, from the outset, it was recognised that at their heart, each of the markets needed the same thing from their mobile apps. Thus the mobile hub was set up to take advantage of these synergies.

Have a clear reason for building your app

For TUI they wanted to be a service app that facilitated and enhanced the holiday experience for their customers who have already booked on a trip. They haven’t expanded into the inspiration space for people who are yet to book, despite attracting negative reviews from customers who misunderstand what the app is for.

Be clear on your code base choice and don’t be afraid to change

When they started, TUI used the web technology based Titanium platform, that allowed them to write once and publish across iOS and Android – this was all they needed for their MVP version. They were challenged by their different markets needing particular features rolled in and rolled out to their versions of the app. It also meant, that they were missing out on key features in each of iOS and Android in the quest for conformity. Finally, the more markets they added, the harder it became to manage development.

When you change, change to Lego

Finding out all of this, TUI decided to replatform their apps – using one native code base for iOS and another for Android. In addition to this, they employed a ‘nearly’ modular approach to their whole stack, breaking it into Product, Design, UX and Dev. This has reduced their whole development timescales by more than half, allowed them to test more often with users using hi fidelity versions and deliver customised features to all their markets as they need them. They compare this to building their products out of Lego blocks.

Be data driven

The TIU app no longer works on templates – it is based on the data they are receiving. For example, a menu is driven by the content that is there. If there is nothing, it will simply collapse. This change allows you to have far more flexibility in various markets / user groups.

One app, multiple configurations

The new structure allows TUI to build features / pages and then decide whether to roll it out to particular instances of the app, as decided by a configuration file. If they have the data set to support whatever feature it may be (for example a travel checklist) then it can be added by plugging that in, doing some testing and then rolling out.

Still more to do

Whilst the app’s front end is now modularised and features are able to be switched on and off fairly easily, the underlying data repositories that power them, still need some work. Wherever they can, TUI use common data sources, but their next step is to modularise the API layer to give them more flexibility in rolling out features dependent on them.

Comments 0

Join the community

Sign up for free to share your thoughts

About the author