Buying a Metro Ticket in Paris — a UX Case Study
Paris is beautiful, but when it comes to riding the metro, the city of Love does not seem so charming anymore.
The situation
The experience of using the machine, or 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.
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.
The plan
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
Field study
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.
Usability inspection
Navigation
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.
Analysis
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:
- Arcueil-Cachan
- Falguière
- 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:
Usability tests
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
Context
1.
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.
2.
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.
3.
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.
Objectives
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.
Tuesday – Diverge
Keeping in mind what I understood and defined Monday, I started generating some ideas that could solve the problems I noticed.
I wanted to gather inspirations from various horizons. To do so, I built a Pinterest tab and started sketching:
A new information architecture
Details
My first idea was to bring back the focus on the most common choices: Ticket t+ and Ticket for Paris region.
By doing so we add some progressive disclosure. Depending on the situation you might want to allow the user to be more efficient by giving them more control or by guiding them.
The 2 examples above illustrate the 2 strategies. For pilots, being able to react quickly and have maximum control on their aircraft is essential. This strategy works well for users who are using a system often, but there will be a long learning curve.
On the other hand, let’s say you want to drive from Paris to Savigny Lès Beaune — I mean, why not? Small cities like this one won’t be indicated right from Paris, you will have to follow directions to a bigger city first to then encounter the smaller city sign. Thanks to this progressive disclosure, Paris is not overwhelmed with every French city signs. This is also related to Hick’s Law that you can check here.
The other tickets will be reserved for a 2nd page, where they will be clustered. As you can see on the picture, 2 groups were revealed: Special destinations outside Paris and Zones Tickets (unlimited travel in the chosen zones during a few days). The Navigo Coupon will be moved to the Navigo part to remain coherent.
For experienced users, it would be nice to provide shortcuts to their usual choices (ticket t+ usually).
For tourists, the machine should guide them in order to help them make the most of their visit. After all, your overall Parisian experience also includes how you cruise along the city. This study is aimed at not making buying your metro ticket a weak point of the experience.
To do so, we could give them the opportunity to search directly for a station, give smart suggestions and have a smart search engine which needs to be tolerant to mistakes.
Visual design
I made a color palette with the aim of making the experience more reassuring: during the interviews, I noticed the metro was a hostile environment.
Indeed, people were very suspicious, much more than they would have been even in the street for instance. This was definitely a strong point that was weakening the experience.
To do so, I used color psychology to create a calm atmosphere:
- Two shades of blue will be the main colors,
- Dark grey and white for the text
- The final touch will be the turquoise RATP used as an accent color.
By having a palette inspired by the RATP colors, I managed to create the reassuring atmosphere I was looking for and add a touch of branding to the interface.
Moreover, the turquoise used in the logo and palette is symbolic of Paris. This color is the result of copper’s oxydation and can be found on many monuments in Paris. It’s called vert de gris in French. This color helps setting Paris identity into the experience, which is ultimately the goal: riding the metro can be a memorable part of your Paris experience.
The two photos underneath are nice colors combination you can find in Paris and that I considered for the palette — especially brick orange from the chimneys and gold. You can see the vert de gris on Bastille’s column on the left.
For the interface buttons, I was inspired by the station name’s signs. Having a consistency between the interface and the actual metro ride experience would be a good way to enhance the experience as a whole.
Wednesday – Decide
Like a good recipe, I let these ideas rest for a night. I could look at them with a fresh mind on Wednesday.
The idea I chose was based on:
- providing shortcuts to get your metro ticket (efficiency by control)
- guiding inexperienced users with progressive disclosure and add a search bar right from the menu screen,
- have a smart engine that is tolerant to spelling mistakes and to different kinds of search,
- provide basic french articles shortcuts to facilitate search: Le, La, Les, Saint, Sainte, De, Du, Des ; and QWERTY/AZERTY keyboards,
- create clear and visual clusters of tickets, bringing the focus on the 2 most used tickets (efficiency by progressive disclosure).
The next step was to wireframe it, which I did, using black and white colors to focus on contrast first:
Thursday – Prototype
Before starting to assemble the prototype, I made a first round of tests using the wireframes and paper prototyping that allowed me to make small iterations. Then, I applied the color palette to the screens and built the interactions between them.
If you made it this far, congratulations! You sure earned yourself the right to have a little fun now:
👇 Click there to play with my metro machine 👇
Friday – Validate
Testing with the prototype brings a lot more fidelity to the test and give the user a much better sense of what the actual feeling will be like.
The objective was to validate whether the 3 pain points were solved. I had some insightful results that lead me to do some iterations on the interface (the prototype is now updated with these changes). For instance, the quick buy button was not visible enough, some details were added in the search results, the wording of the ticket t+/Paris region evolved into ticket inside/outside Paris, and the tests gave me the idea to show the itinerary during the ticket printing.
