Some people are on time, others are out of time, and everybody thinks about time differently. For example, Americans write dates incorrectly, but that's OK. When it comes to interfaces, time is something we all fear misreading, often needing to double or triple check.
GoMore Date and time
It's a
date
Skills used
- Product design
- UX design
- UX research
- Frontend development
- Staring at Google calendar
GoMore is a global car sharing company based in Denmark. Without getting all Silicone Valley — It's Airbnb, but for cars. A core part of GoMore's product experience involves managing dates and times.GoMore also offers ridesharing and leasing
I worked closely with our App lead establishing standards across six languages for how we display dates and times on the website and app. Chipping away at the dozens of different ways we were showing them. I focussed on making things as human as possible — no robots allowed! I scrutinised each detail right down to the en dash.
For example:
“02/12/20 at 10:30:00 - 02/12/20 at 19:00:00”
became
“Tue, 2 Dec, 10:30 – 19:00”
Much better.
Our previous date picker on car profiles was hard work. The renter selected the dates that they wanted to rent a car and only then found out if it was available or not (through error messages). At the bottom of the page, there was also a complicated visualisation of the car's availability.
“This is Whac-A-Mole! There must be an easier way...”—I thought
to myself
Well — there was a better way, but it wasn't easy. We set ourselves the lofty goal of eventually incorporating the concept of availability, and we wanted to prevent people from being able to make impossible selections, removing our reliance on error messages. My brain began to sizzle gently with questions like, “What's the difference between 00:00 and 24:00?” "Technically 24:00 doesn't exist, but it's a useful way of communicating the end, rather than the beginning of a day
Time. Time to research best practices and competitors. Time to iterate. Time to build a prototype. Time to test that prototype with my girlfriend over the breakfast table. Time to test it with the general public. Time to withstand the scrutiny of the harshest critics of them all; backend developers.
Our first iteration prioritised reducing the number of clicks/taps. It was built to be fast and made assumptions, prioritising what data informed us were the most common booking patterns. The second iteration walks the user through each required step; it may feel slower but results in less confusion.
I feel proud of the work we put into this, and at the same time, I know that the solution doesn't work for everybody. There's plenty more that can be done, particularly around explaining why some days are unavailable and cannot be selected. But I'll save that for another time.