I’ll take the sprinter

Rapidly prototyping mobile fare payment

Gaël van Heijst

Dear reader, the following article describes my take on this project as a UX designer. It touches only a small part of a broad project. Want to know more about Clockwork, please have a look at our work.

Thanks for reading 🙂

Fig. 01 | Conductor on a Dutch train. Image source

Introduction

Ladies and gentlemen, all aboard the project train

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 4500 trips a day, transporting more than 1 million people. Conductors serve as facilitators on the 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.


Challenge

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.


Current situation

Deferred payments

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.
Fig. 02 | Current ‘deferred payment’ process (plus sprint week focus)

Attention attention…

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.

Our proposal

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.

Fig. 03 | Proposed deferred payment proces.

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.


Design

Visualising the proposed flow

Based on this input, we drew a serie of screens. You can see some of the essential screens down below.

  1. Onboarding,
  2. Calculating supplement price,
  3. Traveller-side PDF reader with ticket.
Fig. 04 | Core screens of the mobile fare payment application.

Prototyping

Roleplaying mobile payment

On the final day we welcomed six conductors to our office. We prepared a script for them, which consisted of:

  1. Welcoming the conductor,
  2. Getting to know the daily work of the conductor,
  3. Guiding them through the scripted prototype (roleplaying),
  4. Collecting extra feedback,
  5. 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.
Fig. 05 | Testing script setup (conductor and traveller side).

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?

Our devices are already equipped with the ability to scan QR-codes. Specialists predict a glorious revival of the QR-code as a mobile payment method. We are optimistic towards these technologies.

Soon we will talk to conductor even more. Next stop is looking for ways to implement this piece of service into their daily workflow. We need to test this concept more in-depth. This wil result in another pilotstudy, building towards an MVP.

For now, we explored the possibility of paying for an extra ticket while on the train. We’er confident we took the biggest smallest step in helping conductors be better hosts.


Behind the Desk

In ‘Behind the Desk’ we share fresh perspectives and insights on our industry and way of working.

Visit our website or connect through Twitter, LinkedIn and Instagram.

If you want to join us, check out our open positions.

Unlisted

Gaël van Heijst

Written by

Design & write, photography on the side | UX Designer | www.gaelvanheijst.nl

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade