Kyiv Metro

Fare Card & Token Vending Machine

The Kyiv Metro is a rapid transit system that is the mainstay of Kiev’s public transport. Daily ridership – 1.32 million (2016), annual ridership 484.56 million (2016)

PROJECT ROLES

UX/UI Designer

YEAR

2015

PROJECT GOAL

Reduce checkout lines, simplify and speed up the process of purchase tokens and rides with fare cards

CHALLENGES

The fare card has two memory slots: monetary balance & rides balance, a user has to refill monetary balance before purchasing rides. The ride price depends on the number of rides user purchases (the higher amount of rides user purchases - the lower is the fare). Both memory slots have a max amount of restrictions (200UAH and 50 rides). There are additional restrictions on the bills that the vending machine is able to validate. The devices themselves should be easily montaged in places with a vast variety of lighting conditions.

IMPACT

As a UX/UI designer teamed with a multidisciplinary team of designers, created an application concept. Lo & Hi-fidelity prototypes were tested during user testing sessions to proof a design concept. The developed version was tested on a production ready vending machine hardware.

PROCESS DIAGRAM

The initial process flow was defined and approved with hardware & software developers

DESIGN CONCEPT OF PURCHASING RIDES USING FARE CARD

Purchasing trips using fare card flow. The design addressed several challenges: limitations on bill types the vending machine can accept, max amount of cash memory slot, max amount of rides that can be purchased, different fare price based on the number of rides passenger purchases. The main idea was to make clear a fare price options based on the current card balance and a cash amount user needs to add in order to purchase rides with a lower price.

DESIGN CONCEPT OF PURCHASING TOKENS WITH CASH

Purchasing trips using fare card flow. The design addressed the following challenges: limitations on bill types the vending machine can accept, max amount of cash user can add (40 UAH), max amount of tokens that can be purchased (10 tokens). The main idea was to make these limitations clear for a passenger to reduce the number of corner cases.

USER TESTING

As we have learned from metro stats there are two main scenarios for passengers that use fare cards: around 40% of passengers insert a random bill to refill their fare card for the occasional amount of rides (the hypothesis is that they are in a hurry), while other 40% of passengers use to purchase their rides at the lowest price available. The concept was tested against 3 scenarios:
1. Purchase a ride as quickly as possible.
2. Purchase rides at the lowest price available.
3. Purchase max available amount of tokens (as the most complex scenario that faces limitations).

The test results showed concept strengths and weaknesses.
98% of users were able to accomplish scenario #1,
83% of users completed scenario #2,
100% of users completed scenario #3.

Additionally, we asked users to rate the new interface against the current one and got the following results:

Scenario 1

49.4% – it’s much easier to use
19.8% – it’s easier to use
19.8% – it’s the same
9.9% – can’t provide an answer
1.2% – it’s harder to use

Scenario 1

28.6% – it’s much easier to use
48.2% – it’s easier to use
14.3% – it’s the same
7.1% – can’t provide an answer
1.8% – it’s harder to use

UPDATED DESIGN OF PURCHASING RIDES USING FARE CARD

The updated design was created according to the updated device requirements (screen size and aspect ratio, bill slot placement has been changed). There were also design updates that made the interface more logical from LTR perspective: "Cash Balance" -> "Rides Balance". As we understood that most users who care about the ride price know it quite well, the order of the data in the table of rides-price was reversed to become "Amount to add" - "Rides you get" - "Fare per ride" so now users can see the amount they need to add in the first place. There were also worked out edge cases like "The user took his fare card, replenishing it with money, but without buying a ride", "The banknote can't be accepted", "The max amount of rides is already purchased", etc.

UPDATED DESIGN OF PURCHASING TOKENS WITH CASH

Taking into account that 100% of users were able to complete the scenario of purchasing the max amount of tokens (the most complex while dealing with tokens) there was no need for significant design changes from that perspective. The design was updated according to the updated device requirements (screen size and aspect ratio, bill slot placement has been changed). There were also added interfaces of edge cases like "The banknote can't be accepted", "The banknote value is too high", etc.

TESTING VENDING MACHINE PROTOTYPE

Testing on a production-ready device showed that some updates on colors and brightness are required.