Transport

Trainline — Let's "roll" back the datepicker

Decorative Arrow Pattern

Trainline (formerly Captain Train), is built on the top of other sell services like SNCF (French National Rail Service) and focus on user experience.

It makes sense for a new service entering in a competitive field to focus on user experience. Indeed, it's oftentimes what's missing to this historical services to make a real difference.

But anyways, that's not my point here... almost not.

The Trainline main issue with date picker

When Captain Train became Trainline, as a user, my fear was to loose all this good user experience I had until then.

Two years ago (2019), Trainline built a new app after acquiring Captain Train to merge the UK services in it, if I did understand the story. While building this app, they revamped the entire date picker for a weird one. This happened:

The old date picker for Trainline showing up a full calendar and some slots of hours. Handy.
The old date picker for Trainline showing up a full calendar and a time picker.

This was the old "all in one view" calendar that all the users appreciated a lot, based on them raging on Twitter.

The new Trainline app date picker displaying 4 rotor picker to pick the month, day, hour, and minute
The new version of the datepicker.

They decided to rebuild the date picker but the goal behind this isn't really clear.

Instead of having a big overview of the month and an idea of the available slots of time, you need to turn infinite amount of times five selectors for the month and the day followed by hour and minute.

Between us, the date and time picking action is one of the worst in term UX, no matters the type of project you are working on. The way you build it depends on the user's way of thinking there future actions. You don't ask a date for a birth date like you ask for a future departure or like you would ask for someone looking for approximate available time slots.

The issue with the 4 rotors is that you can't explore days without having a calendar right under your nose. Also, in term of fatigue, the rotors ask you a lot of actions and thinking. You need to be sure that the month is in the right year. You need to tap, roll,select, roll back if you missed the right date, and do it 4 times.

The old one is way smarter. The date picker is an actual calendar so you don't need another one under your nose. And to pick an hour you just need an approximate time. In term of energy asked to accomplish this take is way less demanding.

A solution for the Trainline date picker

Well I think you got the idea: they should roll back to the previous solution. The clients I asked and discussed with (around 20) were totally unsatisfied with this new way to pick a date. Maybe I fall into the trap of a biased sample, but those were not my friends, and sometimes random people I didn't know before that.

Sometimes when you refresh or rework an interface, the best you can do is not break what works. Now they know they broke something, they really should think of fixing it. Rolling back is a quick win.

Don't trust me. Trust the users.

I conducted one "guerilla test" after speaking with several people on social networks. Everyone agreed on the fact that this feature is painful to use in its current state.

So I wanted to validate if this new version was good. I asked someone to test the 2 versions on my phone. I took someone who already knows android phone to avoid discovery behavior. This person already knew this app, she was a user before the pandemic.

I asked to the person: can you pick a date of departure at the beginning of may, and return at the end of may.

Here is what she has done with the old calendar version, followed by the new version of it:

As you can see, several issues are obviously found with this test. First, the test went well on the calendar version.

On the second test, the first roll on the month went wrong but the user didn't see it right away, then the picking on the day was pretty slow and finally when she wanted to validate the date she pushed the Today's date button thinking this was the validation button.

"F#&k, what did I do? I pushed a button that disappeared, was it a reset button?"

She did it again taking care to read labels on buttons. Then she did the rest as expected.

Takeaways

Might be obvious for you now that we went through it already, but let's summarize what we've learned here.

  • Never put a reset button in a more obvious place than the validate button. Nobody wants to reset a form by mistake after they have put effort into filling it. That's also one of the things Fitts's law teaches us 😜
  • The rotor component is just bad in most of use cases I had the chance to test it in. It requires a lot of precision and usually doesn't match the user need. Unless you have only a few options.
  • When you radically change a core feature of your existing product, beware that you play with fire if you don't test it with actual users, like power users, but also newcomers. I mean, I suppose they didn't, otherwise we wouldn't have this kind of reaction on Twitter. (English answer of Trainline, French reactions)

A good article named "Designing the perfect date/time picker" on Smashing Mag would be a good recommendation if you are about to do it in your project.

About this suggestion

The suggestions we make are not made thanks to a full and proper user research. At best we did a guerilla study about user behavior. Most of the time, these are suggestions based on our own experience and needs, which don't represent necessarily all end users needs.

Rocket Icon
Newsletter

UX Design case studies directly in you inbox.

Thanks! Magic stuff coming soon! ✨
Oops! Something went wrong while submitting the form.
Recent Case Studies
View All
Link Arrow
Related Case Studies
View All
Link Arrow
Not enough related case studies at the moment. Stay tuned!
Thanks! Magic stuff coming soon! ✨
Oops! Something went wrong while submitting the form.