Paris is beautiful, but when it comes to riding the metro, the city of Love does not seem so charming anymore.
The actual experience of using the machine, or when waiting for people to finish their order so that you can do yours, is not satisfying — not to say frustrating.
I had this pain point and couldn’t believe I was the only one. By asking people around me, it quickly confirmed there was an issue with this experience. Especially from my foreign friends which qualify it, and I am quoting them here, as a “pain in the a**”.
Le coup de grâce
If you quickly go on YouTube here, you will see tons of tutorials on how to buy a metro ticket in Paris. When I discovered this, that was it, I had to do something about it. Thanks you also Eric for showing me this:
Although, the Parisian metro has some splendid moments and is part of your Paris experience. It’s a great opportunity and shouldn’t be a weak point.
My purpose here is to integrate this buying process into a more global experience of Paris.
I decided to run a 5-day sprint, from Monday to Friday. I would work on this as a side-project after work. I followed GV’s process for this sprint.
If you’re a little impatient and want to play straight away with the prototype here is a little help.
Monday – Understand, Define
On first day of this sprint, I needed to discover why the machine was frustrating people. In other words, I had to define the problem.
This is why the first thing to do was to go down in a metro station and ask people if I could observe how they interacted with the ticket machine.
I chose the station Chaussée d’Antin Lafayette, I knew there were various types of travelers there— tourists, french people, groups — which will enrich the study.
Indeed, the best way to understand people’s need is to go in their environment and find out their context of use:
- Who are they?
- What are their goals?
- What is their environment?
I also did a usability inspection afterwards, reviewing the current system against a set of heuristics.
To give you an understanding of the ticket machine, I’ll start by the usability inspection first, then move the actual user tests.
The main use case, which I filmed just below, is taking a regular metro ticket (called ticket t+ by the RATP as you can use it in the metro but also buses, tramways and trains in Paris).
To get a bird’s eye view of the system, I laid out the machine’s Information Architecture.
There’s a gap between the travelers’ mental model and RATP conceptual model. What the travelers know is where they want to go and where they are right now. Asking them to know what kind of ticket corresponds to their trip is already an effort, the machine should do this job for them.
The interface relies a lot on recall rather than recognition. It’s asking efforts from the user to remember the station name’s spelling and which type of ticket they must choose. (Note: Navigo is the metro pass which will not be studied here as the overall experience is already satisfying)
As for navigation itself and error prevention, there are some inconsistencies, like the back button being on the bottom right of the screen (and its arrow spinning the wrong way).
It’s also very tricky to tap accurately in the lower part of the screen. This is due to the screen angle and the glass thickness (approx. 1,5cm). As shown in this drawing, the projected area of the button isn’t matching its tappable area. This leads to some errors. The lower fifth of the screen shouldn’t then contains calls to action, but rather not tappable information like status.
Note: the glass refraction isn’t taken into account here, which would be useful to calculate precisely the part of the screen we need to avoid. The safe zone could be defined as a 95% overlap of the projected area and the tappable area.
The machine isn’t helping to recover from errors and slips too, like shown in this video : I wanted to tap on the last item, because it was in the lower part of the screen the previous one got selected, I then wanted to recover from this slip by tapping back and discovered my search results hadn’t been saved.
The main menu
The main menu gives you 7 choices which are not really differentiated graphically, nor spatially separated to create clusters. It can be overwhelming. Though there are some categories that emerge:
- The 2 most frequently used tickets (ticket t+ and Paris region),
- Special destinations tickets (Disneyland and Airports tickets)
- Zones tickets (Paris visite, Mobilis).
The menu isn’t memorable as well.
When I asked people what they remember from the interface, they couldn’t tell me much. Everything looked very similar.
Searching for a station name
When you take a ticket for Paris Region (outside Paris), you have to enter the station name you want to go to.
First of all, the keyboard is breaking the QWERTY convention. It should adapt to the language chosen by the traveler: AZERTY for French people, QWERTY for English, Spanish, Italian people and QWERTZ for German speaking people.
Secondly, there’s no typing cursor, resulting in the absence of feedback on next letter position. If you press (accidentally) space twice, your search will not be valid.
Moreover, French spelling isn’t quite easy for foreigners, here are some station’s names examples:
- Neuilly-Porte Maillot
- St Rémy Les Chevreuse
Unfortunately for them, the machine isn’t helping. The search engine is quite basic and won’t give you any flexibility or help you recover from spelling mistakes.
You need to enter the exact name, starting with the first letters. For instance, if you want to go to Le Bourget, typing in “Bourget” won’t work.
Moreover, quite a few Parisian stations have Saint names, which can be also shortened “St”. Some station uses Saint, others uses St (RATP knows why…). You have to use the right one for your station, even you thought typing in St would save you some time. Here are the results for both cases:
I asked several nice people if I could observe their journey on the machine. I paid attention to the language they were using, their process, time to success, their pain points and finally noted what I thought could help me building profiles. Here is a sum up of these tests:
From these tests, 4 users profiles were revealed after a card sort:
But this card sort made me realize using personas for this kind of mass audience project would lead to inaccurate results.
Indeed, I knew I hadn’t encounter every profile during my field study: using only these 3 axis, that is a total of 2 x 2 x 2 = 8 possible profiles.
People traveling with the metro come from various horizons, using personas presented the risk of being too reducting. I also didn’t want to fill the missing bits with hypothetical data, which would make them biased.
Rather, I chose to uncover their Jobs To Be Done: personas focus on who you are designing for, Jobs To Be Done focus on what your user’s goals are and put them in perspective.
This is particularly relevant here: every person using the metro is different but their Jobs To Be Done can be similar.
Here are the JTBD I identified using the Jobs Stories framework:
The translation of these needs into design decisions means providing shortcuts for experienced users while helping unfamiliar users finding the right ticket more easily.
Defining the problem
I set myself the constraints of keeping the existing machines and technology. Changing them would indeed offer new possibilities — I remember Hong Kong and Singapore’s machines offering a great experience by simply choosing your station on the metro map. Which is great but needs an improved technology.
We could also imagine totally new ways of buying your metro ticket, for instance choosing your ticket on your mobile phone and then getting it with a NFC payment or using directly your phone as the ticket.
However, for this first study, I chose to focus on what the RATP could improve quickly at a lower cost.
These public ticket machines are hypothetically used by any type of people, which adds many constraints to the interface design: it should be simple enough so that everybody understands it — people from various cultures and age, with very low or high technology skills.
Moreover, the machine isn’t for getting detailed information on ticket options. That would lead people to compare tickets options, resulting in longer waiting times.
Comparing ticket options would be the role of the RATP website. Instead, we could recall what the traveler had seen on the website during his research in his hotel room/flat by displaying a small caption which would help to confirm he’s making the right purchase.
For a widely used machine like a ticket machine, addressing various personas needs can be necessary
The final objective would be to reduce the time to purchase in order to reduce waiting queues while giving satisfaction to the user. Therefore, mixing business and UX goals.
The most challenging scenario is when you want to buy a ticket for Paris region, as it requires you to type the station name (especially challenging if you are a tourist).
The most common scenario on the other hand, is simply buying a ticket t+: there are in average 600 million sold each year (stats here). This is the case for turquoise, rose and blue groups. This experience is quite efficient (success rate), though it could be more effective (time to success), especially when you hear from users that the overall feeling of using the machine is not satisfying. Shortcuts for experienced users would be welcome here.
Pain points to solve:
- Pain point #1: Taking a metro ticket often gets repetitive and slow
- Pain point #2: Taking a ticket for Paris Region is complex and confusing
- Pain point #3: The overall offer is not clear and organized
For metro travelers, the ticket machine is most likely the first connection point with the metro.
Therefore, giving a good impression is crucial, as it will impact the entire Paris experience.
We have indeed several cognitive bias that lead us to confirm our first impression. If it was negative, our brain will be drawn to details that confirm our bad experience. For more information see confirmation bias, selective perception and subjective validation.