Most of us know ticket vending machines that are used for public transport. While people who often buy a similar ticket usually have no trouble using them, it can become quite hard for functions that we rarely use or for people who only rarely use the ticket vending machines. Why is it so hard to program them well?
What we actually want to achieve is searching an item in a multidimensional space. There might be many parameters relevant to the actual ticket and we need to find it through the navigation mechanisms that are offered to us by the software. Sometimes it is straightforward. For local transport some people want to buy a ticket for zone 1B and then they even find this offered on the home screen. Other people have no idea what this zone 1B is and actually do not even care. They should know where they want to go and the system should then know if it is „Kurzstrecke“, „Zone 1A“, „Zone 3D“ or whatever. But the zones might be a useful shortcut for the experienced user, because it can be known that in this case many different travel destinations can be covered by the same ticket, which can be found in a second on the home screen. Making it fast for the experienced user is actually a very good idea, because it saves the time of the customer and of the machine. But the more natural approach of just entering the destination should be provided as well. Up to this point they have actually done it quite well in some vending machines that I have seen.
But then there are some issues that are hard to deal with. I just give some examples that I have experienced without claiming to be complete.
In some cases there is a different ticket universe for local destinations in some area around the location and destinations outside of this. For example the region of „Schleswig-Holstein“ in Germany has a „Schleswig-Holstein-Tarif“ which applies to certain more local trains. The first step when buying a ticket was selecting between „Schleswig-Holstein-Tarif“ and something else. Which is something the customer should not need to care. It is bad to require knowing to which destination and even worse to which trains „Schleswig-Holstein-Tarif“ has to be applied and to which not. In this case „Hamburg“, which is a different region and not part of „Schleswig-Holstein“ as a destination was still part of „Schleswig-Holstein-Tarif“, which can be found out by trial and error, by asking someone or by using google on the smart phone. Hopefully the train is not leaving in 5 minutes. But again, depending on the train, it is anyway not „Schleswig-Holstein-Tarif“. Yes, the ideas behind it are not too hard to understand and many people know them like many people know what „Zone 1B“ means. But some don’t and they are having a hard time. The right way would be to ask for the destination and then offer some train connections or some choices for useuful and accessible parameters for train connections to pick the right ticket.
The next issue is that it is usually possible to buy the ticket in advance for the next day, which is a good idea, because it eliminates the stress of having to buy the ticket or having to wait in a line while the train is due to leave. When I tried that, it was not possible with „Schleswig-Holstein-Tarif“, which was again something that took some time to find out. The information that this is not possible should at least be easily available or even better it actually should be possible to buy all tickets at least a few days in advance.
The pricing system should be logical. While it is annoying that flight ticket pricing can only be understand by discarding all logic, this does not work well at all for train tickets, because there are much more stations and thus much more different possible tickets to calculate. A funny example was once constructed with three towns. A, B and C are in a line. A and B are far apart and an important connection. C is very close to B. It was possible to buy a return ticket from B to A. But it was cheaper to buy a ticket from B to C via A, because this was considered as one path and a discount applied because of the longer distance, which did not apply for the path from B to A or from A to B and the return ticket was calculated like a combination of two one-way tickets. This was resolved by disallowing the ticket from B to C via A. A better solution would be to make the tariff system more logical. If it is hard to distinguish between a return ticket and a one-way via-something ticket, it would be better to unify the discount in such a way that the same kind of discount can be given depending on the total distance covered by the whole ticket.
When taking a bicycle on the train, a bicycle ticket needs to be bought. Since this is a more rare case, it is not found on the home screen and it has to be found through some navigation. I do not have an easy answer for this, but it should be done in such a way that it can actually be found by an inexperienced customer without too much difficulty. I had to use google on my smart phone for the last bicycle ticket that I bought, which is not how it should be.
Many railroad companies offer a ticket for frequent travelers which needs to be paid once a year and then provides a discount for most tickets. It is sometimes not clear, when this discount is available and when not. This information should be easily accessible during the ticket buying process.
I think that ticket vending machines are an interesting example of usability and a lot can be learned from them for other applications. And a lot of things have actually been done right, but that is not enough.
See also:
