Case study: The UX of selecting timezones
Our customers live in different timezones, spread over the world and most of the time, they want to experience our platform in their current timezone.
However, there are also reasons to have a different timezone than the one you currently live in and they should be able to update their preference in a smooth and concise manner.
The current state
As probably with a lot of platforms, the support for multiple timezones was more an afterthought than embedded in the MVP — and this is fine and totally valid at that point in time. So, without any surprise, the UX to update your timezone was a simple list of all available timezones that was extracted directly from IANA.
This resulted in a simple HTML select element with a whopping 388 entries.
Needless to say, this is horrible for a user to choose the correct entry from, which results in the following rating:
❌ clear and understandable UX
❌ future-proof
✅ easy to implement
While this was developed pretty fast, this approach yields some downsides. The first is very obvious: It is hard for a user to choose the correct value if they are not familiar with the specifics of timezones. The second one might be more tricky: Timezones are fluid.
We will examine both points in the upcoming paragraphs, as this will also build the foundation in our search for a better solution.
Veeeeery long list with duplicate entries
Imagine you are a non-technical person, living in a country, in a city with a date and a time. You have definitely heard of the concept of timezones before. But do you know the name of the timezone you currently live in? Is it UTC+1? Is it CET?Is it CEST? Is it maybe Europe/Berlin?
If you are such a person, it is also quite hard to choose your timezone from the list above. First, there are simply too many items to choose from. Second, some of them actually have the same time and some of them look like they would fit, but then change to daylight savings at different occasions over the year.
For the record,
Europe/Berlinis withinCET(UTC+1) during winter and inCEST(UTC+2) during the summer.
Your next question at this point is probably:
Q: How the heck would I know?
And the answer here is pretty clear:
A: Well, you shouldn’t know such things!
Timezones are fluid
That means, they can become deprecated at some point in the future — mostly due to political reasons. Also, new ones can appear at some point or simply change their offset.
While the latter two are no biggie, the big challenge appears if a customer chose a timezone that is deprecated in the future and not available anymore. Not a problem for us humans — but a big one for machines, usually resulting in a crash. 🔥
So, when thinking of a new approach, we better separate the presentation from the data. In that case, if a timezone gets deprecated, we don’t necessarily have to change anything in the application, as the representation of the timezone is still existing as a fallback for the time being.
If your product is not simple to use, start iterating!
Step one in product management? Right! Discovery. We had a look at different competitors and best practices. We only had one constraint: It should not involve too much change in the implementation, as this is not one of our main features of the application.
On the way, we found the OSX-approach with a world map that you can simply click on where you live and this chooses the fitting timezone.
✅ clear and understandable UX
✅ future-proof
❌ easy to implement
As this competes with our “needs to be easy to implement” constraint, this is not a suitable solution.
While looking further, one promising approach, that we found, is to group timezones into buckets and name them by the larger cities in that timezone. The grouping results in a reduced list length, while keeping the representation and data-structure separated.
While this seems to be much more convenient and resulting in a smaller list, there are still some duplicates in the offsets, resulting in a larger list than expected.
✅ clear and understandable UX
✅ future-proof
🤔 easy to implement
Now, we were already pretty happy with this, because it allowed us to keep the select implementation that we had already, by reducing the amount of selectable items (hopefully) so much that the customer would have an easier selection process.
There were two questions that we then had:
- Do we want to use UTC as prefix?
- Where can we get the list of groups?
Selecting prefixes for the labels
At a first glance, (UTC+01:00) seems rather fitting. It has this techy flavour that would convince everyone to pass it through. Then again, we had a look at the persona from above, remember?
Imagine you are a non-technical person, living in a country, in a city with a date and a time. You have definitely heard of the concept of timezones before...
Given that persona, placing (UTC+01:00) does not add value (except this techy flavour).
What else could we do? Simply list the cities as label? Fine, but then it might be unclear for the customer what the sorting behind would be. Again alphanumerical? Does that help if you search for Stockholm which would actually be in the same row than Amsterdam? No.
The simplest solutions are usually the best. When talking about timezones, we have to think of… well… time. 💡
If we prefix every line with the current time (and date) in that specific timezone, it is fairly easy for a customer to find the timezone that they are looking for, as they know what time it is at the moment where they live.
Grouping of timezones
At first, we thought, this is simply one Google-search away. However, that turned out to be harder than expected. We have not found a suitable grouping of timezones as of today. As we wanted to update the grouping easily if timezones change in the future, a manual approach was also not feasible, given the 388 timezones that we started with. Hence, I did what everybody with a tech-background would do: I built a script for that 🤪
To explain in detail how the script works would be too much for this article, hence there will be a follow-up soon on this, where I explain the different steps that had to be taken.
The result
Below, you can see the final result of our list, where we show the time (and date) prefix, as well as the list of up to seven cities in the according group. The list is 104 entries long. Which could also be reduced if we add a more fuzzy grouping logic, but looking at the length, it felt rather “ok” for now.
✅ clear and understandable UX
✅ future-proof
✅ easy to implement (now that we have a script, yes)
You can see the current implementation in real life if you want. You need an active account at XING and then go to “Settings” -> “Account” -> “Timezone”.
Follow-up
If you want to find out, how we aggregate the groups of time zones, please read my next article here on Medium.
Long story short
I presented our process when redesigning the selection for timezones. We group equivalent timezones, name them by the largest cities and prefix them by the current time in that timezone. There will be a follow-up article on how we achieve the grouping soon.
Discussion
I am very interested to hear your thoughts and experiences regarding this or other approaches.
- Have you other approaches?
- If so, what were your experiences?
If you are interested in connecting with me, please do so and please drop me a short line where you are coming from.
