If you’re working on a system that supports various loyalty programs keep in mind that registered users for each provider have different registration methods.

You need to find a simple solution so that your users can see everything as it should be in the User Interface.

Let me give you some simple tips of how I made it work.

This very simple situation is really a usability issue. It may turn something as simple as registering into a confusing process. And confusion is the enemy of conversions.

So if you work with different providers, pay attention.

Handling Registrations

A case by case basis for every single provider is not a scalable option. The solution must work for for every partner you add.
For each loyalty program we need to define a schema with the fields needed for registration.

Solution 1: List the Fields

A naive solution would be to simply have a list of the field names that we want to display.

This has a great disadvantage, since each program has different ways of naming things. Some use a username and password, others might locate users by zip code or e-mail, others even use first and last name.
So what works for one program might not work for another.

If we are not consistent with the program’s language then we are set to give our users a headache.

Solution 2: Consider Semantics

Treat all fields by its semantics rather than their literal labels.
We need to keep both an internal fieldName as well as a fieldLabel, for display purposes.

Things look good enough, until you need to deal with a program with a more complex registration form. And it’s not only the labels, but also the software behind it.

Solution 3: Add Data

Add data to describe the business logic needed to validate each field.

Now our form is complete. For English speakers. But we may also need it to work in a different language. Specially since Loyalty Programs are fairly common in the Travel Industry and have a worldwide user base.

Solution 4: Internationalization

To add internationalization to the mix we can namespace the previous structure under a string identifier for each language,

We also need to take into account regional language use.

There are several international standards that describe language codes. It’s a good practice to use one of them.  For example, we use ISO 639-1 for the language’s code and ISO 3166-1 for the country’s code.

The Complete Solution

This is an example of how a flexible loyalty program schema could be defined,

And Finally …

You will be working with a lot of different travel providers as a developer for a specific system. So you’ll want to create code that’s flexible and works with different languages, fields, etc.

No matter what language your user speaks, the experience must feel be seamless. The key is that they don’t notice all the machinations in the background.

And make sure it all works!

If you have any question, feel free to e-mail me at [email protected].