2017-08-31

[Design Thinking in Action] Proposal for a Revise of the Ticketing System of Munich Public Transport

Yesterday I wrote up a a story about a very disturbing experience with the Munich Public Transport company (MVG). I posted this story to MVG's facebook page. MVG did not answer me. But a person called Mi Ke provided some interesting points in that thread.

As a long-time fan of public transport, now I just want to do something useful for all the passengers of MVG. Usually my wage is some xxx euros per hour for such sort of work. But I am too passionate about a good solution on this matter, so that I'm doing this for free here, and donate my work in this article to MVG. I know this won't be a perfect solution, but will be very glad if this paper can provoke thoughts and initiate a change in the MVG ticketing system.

Actually this could also be an outline for a bachelor or master thesis. If any student care to work further on this subject, simply contact me and I'll be glad to coach you or work with you.

1. Problem Statement

The German public transport systems in general provide rich sets of tickets, and every local system in a city has her own rules about how to use the tickets. This leads to significant confusion to average passengers, and leads to unintentional rule violation, which causes frustration and unhappiness to the passengers, and also leads to bad relationship between passengers and the transport companies.

Each kind of ticket is tailored for specific situations, usually the tariff is designed by business departments of local transport operators. The purpose of this paper is _not_ to alter the tariffs, but to design some processes to mitigate confusion and hassle when a passenger is buying and using a ticket.

A "ticketing system" in this paper is an abstract concept, it can be a ticketing web page for PC, or ticketing app for mobile devices, or ticketing machines in stations and on vehicles. While the graphical user interfaces may be different on each kind of devices, but the principles and the core process should be consistent across all devices.

The biggest mistake in many ticketing systems is: They assume too much from users, especially users from other cities and unfamiliar with local offerings and regulations. It is good if a user does her homework before she uses the system, but an extensive pre-study should not be a requirement for using the system. It is the local transport company's responsibility to embed and emphasize all important information into their ticketing process, and protect the users from being psychologically hurt by any unfriendly staff.


2. Design Principals

2.1 Keep it Simple

Local rules and regulations can seem very daunting in text. In fact very few people really read all the text just for fun. But in fact, most important points in those daunting text could be presented in a simple and approachable way. This presentation does not have to be text on screens. It can be diagrams, info-graphs, animations, sounds, or even some steps or mandatory interactions in the ticketing process. 

2.2 Keep it Consistent

In case of the MVG regulation, even if you buy a 1 day or 3 days ticket, you don't have to always validate it. Such tickets bought on buses or trams are automatically valid. Only when you buy those tickets from a train station, they are not "valid", you must manually validate it. 

This inconsistency puts passengers in immediate danger once they buy a ticket from any station. Innocent people buy a ticket and get the illusion of duty completed. MVG should not assume a passenger will always ask if a ticket needs validation or not. They get onto the tram, get inspected and then get insulted as "Schwarzfahrer". Poor poor passengers. 

The reason for this inconsistency is: some people want to stock such tickets. If they buy several tickets in one batch, there has to be a way to tell when a ticket is used or not.

This is not a good reason to keep the inconsistency.

Who will be buying such multi-day tickets? Not the local commuters who already buy monthly tickets or annual tickets. Most likely business travelers or tourists will need them. When they stock such tickets, they are likely to forget the tickets at hotels or in the pocket of another coat. So, the stocking of multi-day tickets should not be encouraged.

MVG should really just close the stocking possibility, make those multi-day tickets immediately valid once they are sold, and remove the hassle of validation for multi-day tickets. This is then a consistent and better user experience. Yes, I propose to change the regulation here.

2.3 Encapsulate the Suboptimal Processes

Before the regulation changes for a better user experience, passengers will have to live with some suboptimal processes. For example the "first buy, then validate" process.

It is the ticketing system's responsibility to encapsulate all the steps in these processes, to protect passengers from unintentional violation of rules, but not passengers responsibility to find out the correct usage.

In case of the purchase of the multi-day tickets, a ticketing machine in stations should help passengers get the ticket validated right within that machine. One possibility is: before the payment screen appears, an information screen should appear and say "The x-days ticket sold from this machine is not valid even after your payment. Do you want me to validate it now for you? You can stock it and use the ticket in another day, but please never forget to insert this ticket into the ...." If the user tap on the "Yes, validate it now" button,  a validation timestamp should be printed on the ticket.

3. A Passenger-Centered Ticketing Process in General

Passengers have different levels of familiarity to the tickets and regulation of usages.

A buying process with too many details about the tickets appears unnecessarily winding to a user who knows her ticket very well.

At another hand, there are users who hardly know which tickets are available and which one they should buy. There are also users who simply want some outing and do not even know where to go. For these users, the ticketing system should provide adequate guidance for making a buying decision, it should play the role of a recommender system.

The ticketing process should be different for these two groups of people. For the first group, the system should provide direct access to all possible tickets so a user can choose her ticket as quickly as possible. A first draft of this process seems relatively straightforward, and we will revise it for different sizes of screens later (not in this paper).

Here is the wireframe for first screen of the system.

Note for readers who don't know about wireframe: simply put it is the very initial stage of software user interface design. It focus on specifying user experience: what should be on the screens and how users are supposed to interact with the elements on the screens. At this stage, detailed design of layouts, fonts, colors, etc. is not important and should be ignored.

The content I put in the wireframes is not specific to MVG, it's just conceptual and intended to illustrate the idea.

Process for local transport ticketing system: 1 


The first group described above are very likely to choose "Yes, show me the tickets". Once that button is tapped, the second screen could present all available tickets, it might look like this:
Process for local transport ticketing system: 2-1
Once a ticket is chosen, a typical payment subprocess will start and the existing screen on MVG ticketing machines looks okay to me:



If the chosen ticket needs validation, a warning screen as described in section 2.3 should appear before the payment subprocess.

The subprocess for the second group of people (those who are unfamiliar with the local transport system) is a bit more interesting.

4. Subprocess as a Recommender System

This recommender system has a very clear goal of decision support. In a local transport system, typically it will have about 20 to 50 kinds of tickets in its disposal and should pick out two or three most suitable tickets based on passenger's needs. Most important parameters such as places the users want to go and the numbers of persons in the travel group should be explicitly asked, other parameters could be assumed and presented together with the results of recommendation.

I have a lot of work to do this evening and tomorrow, so I'll leave the wireframes and just describe my design draft in text.

In the first screen of the recommender process, users should input places they'd like to go, and the number of persons in the travel group. There should be a big button saying "I don't know, please recommend places to visit."

If the desired places are specified, then on the next screen, the system can present most suitable options, something like this:

1. A one-way trip, choose this: (a single trip button)
2. A round trip, choose this: (a round trip button)
3. Unlimited trips, valid in X days, choose this (input field for the number of days, and a x-day ticket button)
4. Stripe cards, validate stripes as you go, choose this: ( a stripe cards button)

Except the fourth option, all the three options above will print tickets that are immediately valid after the payment. And the expiration date and time should also be printed on the ticket.

Personally speaking, I'm not a fan of stripe cards. It's too easy to forget validating the strips and get yourself into serious humiliation. Maybe it's several cents cheaper than a regular ticket, but your dignity and happiness are more important. My advice to all business travelers and tourists: Don't buy stripe cards that require manual validation. Only buy tickets that are automatically valid after the purchase.

If, at the beginning of the recommender process, the user tapped the "I don't know, please recommend places to go.", the subprocess could be like this:

A "Tourism Attractions" button,  a "Recreation Paradise" button and a "Public Services and Emergency Help"

When the "Tourism Attractions" is tapped, on the subsequent screen, there should be options for "one day", "two days", "three days", "one week" plans. The places on the plan are of course carefully chosen and the routine optimized. And, it should intelligently disperse the order or routine of visiting for different buyers, so that every attraction won't get too crowded in a short period of time. When a user purchase a "plan", immediately valid tickets will be printed and a bar code of the plan details will be on the screen. The user can scan the bar code and get the details on her mobile phone.

When "Recreation Paradise" is tapped, on the subsequent screen, different themes such as "hiking", "art", "music", etc. will be presented. Choose a theme and 2 or 3 places will be recommended. Then choose the places you like and buy the suitable ticket. The system at this point will assume a round-trip ticket and ask for confirmation. If not round-trip, then present other options.

When "Public Services and Emergency Help" is tapped, places such as the currently opening hospital, police station, the nearest bank, etc. will be presented. Just choose one,  a one-way trip ticket will be assumed and the payment process immediately starts without any further ado.  Where to get off and the detailed address of the destination will also be printed on the ticket, so that the passenger can easily find her way after she gets off the tram/bus.    

This is just an outline here. A real research paper should discuss more about the details and support the statements with hard data.


5. A Word on the Trustability Investigation

I said in my last write up that "when misfortune happens, there should be some mechanisms to differentiate intentional fare dodgers and unintentional rule violators". Mr. Mi Ke said it is not possible. I don't think so. Technically it's well possible and there are several methods that work very well.

To find out the trustability of a person who tells her story about why her ticket is not validated or explains that she forgets her annual ticket at home, you can investigate her personal data and compute a trustability score of her. If the score is higher than some threshold, let her go and if the score too low, fine her.

We can model a trustability function to compute the score. This model could include the following components:

* Her "Schufa" score
* Her criminal records
* Her fare-dodging records
* Transaction records or credibility records of her online purchases on websites such as Amazon, ebay, etc.
* Analysis of all her words on internet: on her blogs, on social media such as Twitter and Facebook, etc.
* ...
* ...

Technically these are all feasible. Some Apps that offer people low-cost online credits are already using similar models to compute whether an online borrower is trustable or not.

The only "problem" here might be privacy protection. You could ask the passenger whether she'd like to allow such investigation to cancel her fine. If she signs the agreement, you can try to get all relevant personal data and compute a trustability score for her.

If you think that goes too far, sometimes there are much easier ways.

Several weeks ago I visited my relatives with train. I bought a ticket for second class. But I've been traveling with first class tickets for the last 5 years in frequent business trips. I went to the first class cart without any thinking, just like a reflex.  Then came the conductor. When I showed my ticket, I suddenly realized the wrong place. I said sorry, told my story and stood up to go to the second class.

In that case, it was really very easy to verify whether I told the truth. The conductor just needed to log into the DB system and read all my purchase records.

But he didn't. He waved his hands, and said "No problem, please sit here", and smiled to me.

That conductor's kindness brightened my day.

And, he was not the only kind conductor I know on the DB long-distance trains.  From news and friends' stories,  various other DB conductors helped confused people get their way around and did not make any fuss about their "wrong" tickets. Thank you!

Generally I find the service quality on long-distance trains much, much higher than local S-Bahn or trams. I love DB long-distance.


--------------------------------------------------------------------------------------------------------

My final word to MVG: Please be kind to your passengers, and please stop calling them "Schwarzfahrer" once they are caught riding without a "valid" ticket. You may say "well, it is actually a neutral word." But people have different perceptions of wording. The title "Schwarzfahrer" is really very hurting and insulting in my ears, almost a language violence. I know the MVG staffs are experiencing all kinds of language violence from unreasonable passengers. I feel very sorry for the staffs who get scolded by passengers. But, the fault of those unreasonable or less civilized passengers is not the reason to lower the level of your kindness and service quality. I do see many friendly MVG staff trying their best to help people in the stations. Thank all of you.

Let's all do our best to be good citizens.

No comments:

Post a Comment