Rapidly prototyping mobile fare payment
Dear reader, please note that the following article was written while working at a former employee. It touches only a small part of a broad project. Just wanted to share this piece of process with you. Thanks for reading 🙂
Dear travellers, welcome on board
A lof us travel by train on a daily basis. This makes us truly aware of the challenges railway companies are facing. We’d like to build awesome mobile products to make traveling more pleasant. One way of doing this is through the conductors on the train. The boots on the ground. The people that provide first class service.
In the Netherlands alone, there are over 4.500 trips a day, transporting more than 1 million people. Conductors serve as facilitators on the train. They share a common goal of making travel time more comfortable for travellers.
This can be a busy job. Besides making sure the train leaves on time, they have a range of subtasks. Service rounds are one of them, during which they answer questions of travellers. This could be about timetables, ticket prices or information along the tracks.
For this sprint trajectory, we decided to focus on mobile payment on the train.
Can you pay with your mobile device?
One way of helping conductors might be through facilitating mobile payment. During one week, we worked together to explore opportunities for mobile payment.
Our challenge for this week was:
“How might we ease direct payment on the train?”
When you travel by train in the Netherlands, you need to have a valid card. That may come as no surprise. This card holds various subscriptions. This card replaces a paper ticket, but comes with complexities as well. First the conductor scans this card, when doing a check round. Under certain circumstances, a traveller needs to have a supplementary tickets. Say, you’re bringing your bike (1) and dog (2) along a trip on an international (3) track. That makes three ‘add ons’ you’ll need to load onto you card.
Some travellers (whether by accident or not) forget to buy such a ticket, before boarding a train. This could result in a fine, or ‘deferred payment’ (DP). Which is an actual written piece of paper.
Writing a DP is a lengthy proces, which can take up to 15 minutes. You can only image what this means if they needs to check 100 people’s ticket, on a trajectory of 30 minutes. In that way, we are challenging ourself, to come up with a more efficient way of handling this DP-process.
To do that, we have to make sure that direct payment on trains is easier for travellers. Together with our client we explored this topic during a one week sprint.
On the first day, we defined our common goals:
The project is successful when:
🔲 Travellers can use their mobile device to pay on the train,
🔲 Travellers have a valid ticket after paying,
🔲 Travellers are able to cross the gates at the station.
On the first day of our sprint week we started with initial prep-work done by both parties. First we focused on mapping the current deferred payment process.
During our first sessions we interviewed three conductors. We found out that this current flow can be rather lengthy. The current deferred payments process is as follows:
- Traveller enters the train (with or without extra tickets),
- Conductor performs a check round,
- Traveller gets his card checked,
- Conductor concludes there is no valid extra ticket. He then reads the travellers their laws,
- Traveller is either ashamed, frustrated or careless,
- Conductor asks for ID, asks extra questions, writes the DP,
- Conductor writes a paper DP,
- Traveller receives a copy of the deferred payment ticket on paper, and code to leave station,
- Both parties proceed their journey,
- Conductor hands in the copy of the DP at the end of the workday,
- Traveller receives letter at home, and pays DP.
Asking travellers to pay for a fine on the train can be a tedious and shameful process. Being able to instantly pay would unburden both parties.
The following points needed extra attention:
Attention points for conductors
- Decreasing the time it takes to write a deferred payment ticket,
- Increasing the level of service to travellers.
Attention points for travellers
- Keeping travellers in control of their data,
- Decreasing a feeling of incrimination / discomfort for the traveller,
- Providing travellers a valid ticket after payment.
Reframing an ideal fare payment flow
During the second day we each sketched our ideal flow. Together we talked through each others’ sketches, and sticker voted for the best. After voting we drew up a single vision of our ideal prototype flow. We focused on the benefits for both conductors and travellers.
With that mind, we made a new proposed flow, which you can see in the following image.
The current flow can take up to 10 minutes per traveller. First a conductor needs to check for an ID. He then writes down the details on paper and hands a copy to the traveller. Afterwards a conductor needs to copy the same data into an app that corresponds with the booklet.
The proposed flow introduces the use of QR codes for mobile payment. Meaning there is no need for an ID-check. We cut out some steps and the conductor doesn’t have to hand out paper copies of tickets anymore.
Visualising the proposed flow
Based on this input, we drew a serie of screens. You can see some of the essential screens down below.
- Calculating supplement price,
- Traveller-side PDF reader with ticket.
Roleplaying mobile payment
On the final day we welcomed six conductors to our office. We prepared a script for them, which consisted of:
- Welcoming the conductor,
- Getting to know the daily work of the conductor,
- Guiding them through the scripted prototype (roleplaying),
- Collecting extra feedback,
- Questioning by the rest of the team.
Our prototype setup consisted of two mobile Android devices, and two InVision prototypes. In that way we mimicked a two-sided payment experience.
The prototype script
- The conductor uses the first part of the prototype generate a QR-code and present it to the traveller,
- The traveller scans the QR-code from the conductors’ device. He is redirected to the second InVision prototype,
- The traveller finishes the payment flow with his preferred banking service,
- The conductor receives a notification of payment,
- The traveller receives a ticket on his mobile device.
The biggest smallest step
- Conductors found the application to be a great extra to their initial workflow,
- This application would make their check rounds way faster,
- It would reduce a sense of shame that is otherwise connected to writing a ticket,
- We presented travellers with an easy alternative for a ticket, and a valid code to open gates and leave the station,
- We gained trust from interviewing users together with all stakeholders,
- We gained a greater sense of responsibility towards the traveller,
- Our way of rapidly prototyping a suitable solution, is possible at very low cost,
- Using QR-codes in an InVision prototype mimicked an actual payment,
- As a value & discovery team, we strive to produce user centered designs. Our visualisations and prototypes should be as close to real-life examples as possible. Embedding QR-codes into prototypes to mimic payment, enabled a realistic testing script. Macgyvering with a couple of tools feels great 😬
Together we made a small step towards a new payment system. We validated our hypothesis and initial challenges:
✅ Travellers can use their mobile device to pay on the train,
✅ Travellers have a valid ticket after paying,
✅ Travellers are able to cross the gates at the station,
Next stop is looking for ways to implement this piece of service into conductors’ daily workflow. Outcomes of these tests wil result in another pilotstudy, building towards an MVP.
We explored the possibility of paying for an extra ticket while on the train. Confident in moving forward in helping conductors become better hosts to their travellers.