Case Study: Buying Tickets and Reloading Cards in the LRT

13 min readJul 26, 2017

Disclaimer: This is my first time writing so I only focused on a small part of the whole process. Any comments and/or inputs are highly appreciated. Also, I’ll do my best to replace the photos with more decent ones in the future.

Commuting can be an arduous task especially during rush hours, not to mention the long lines whenever you’re buying or reloading a card for your train ride. As a person who commutes by train semi-daily, I experience these types of pet peeves during my commutes to work and it can be annoying sometimes. Annoyed at what or who, you might ask? At the commuters? Maybe we can take a look at the design of interface in the machines first.

I decided to make a short case study on purchasing tickets and reloading cards before riding the train. I’ll only be focusing on what we can do to further improve the interface within the machines and not the whole train commuting experience so that the scope won’t be to big for me to handle.

Before moving on, I’d like to mention that I’m not in any way affiliated with the Light Rail Transit Authority nor do I claim that the approaches shown here would work or not(unless tested) but the thought of getting test results gets me excited. Anyway, let’s begin shall we?

What’s the problem?

If you look at things right now, buying and reloading cards seem pretty straightforward so there isn’t really a problem with how we buy our tickets so I focused more on efficiency.

Things to consider

There are some questions that I asked myself while doing this case study; mainly:

Why do people get stuck when buying a ticket or reloading a card?
What can we revise/omit to further improve the flow and interaction between commuters and the kiosk?

I would like to broaden the scope of the case study to all of the transit lines here in Manila but I chose to stick with the LRT Line 2. Also, I’m limited to my experience with commuting to work because, as I’ve mentioned, I’m not affiliated with the LRTA so there’re no data for me to use coming from them.

The options

There a couple courses of action that you can make when you’re faced with a kiosk in the LRT. These are:

Purchasing a Single Journey Ticket
Purchasing a Stored Value Card*
Reloading Stored Value Cards

*Note: for now, I’ll exclude the part where I purchase a Stored Value Card since I have a Stored Value Card of my own. I’ll add in the info next time.

A claim and some approaches

Looking at the user interface in the kiosk, there are things that can be improved to let commuters spend less time “talking” to a machine and go straight to the train. Some of the things that I focused on are as follows: information architecture, layout, and copy.

If you’re a person who has a background in design and has experienced buying a ticket from the kiosks in the LRT, apart from the layout, you’ll immediately notice how “cold” the copy and how all-over-the-place the hierarchy is. I bet we can do better than that. So with that said, I have set some tasks for me to work on during this case study:

Restructure the information architecture
Redesign the layout in the user interface
Rewrite the existing copy to a more welcoming tone
Remove unnecessary steps (if applicable)

Pre-journey rituals

FIGURE 1.1 — Initial screen shown in the machines

Purchasing a ticket and/or reloading a card seem and should be very straightforward. As shown in the photo above, you can either purchase a Single Journey Ticket or reload an existing Stored Value Card and the UI is transparent with what the machine’s able to cater. But for good measure, let’s redesign the page just to make the flow consistent with the rest of the mockups I’ll be showing.

One of the tasks is to change the copy from a cold to a warmer tone so I’ve added a header to make the interaction more engaging. I’ve also changed the copy in the language options since “Select Tagalog” doesn’t sound right to me at all.

I’m in the midst of learning how to write better copy so “Welcome to the LRT” is the best line I can come up with for now. I hope you guys can get my point with this. If you have anything better in mind, let’s chat about it in the comments section.

Now that we know what transactions we can do, let’s get to reloading a card first.

Reloading an existing Stored Value Card

Since I own and routinely reload a Stored Value Card, allow me to start off with the flow in this transaction.

FIGURE 1.3 — Screen after placing a Stored Value Card on the reader

At first glance, the layout of the screen upon choosing to Reload option seems adequate but I believe that we can push things further and make the layout easier and more contextual for the daily commuter.

Going back to the screen, the information is placed waaay far from each other that you literally have to look at each corner of the screen to process all of it. Also, for the card details listed above, do we really need to see the Card ID? Sure. The card status and the expiry date is helpful information but maybe we can do something about it. To top it all off, it really feels weird for me to see the line “Add Value” as the call-to-action for reloading a card. Does it mean that the card loses its value if it doesn’t have a balance in it?

FIGURE 1.4a — Proposed Reload Screen Mockup — First Page/First Variation

Here are some approaches that I’ve tried and I’ll list them down below:

First and evident change is the layout. I tried grouping the elements together closer to the center so commuters won’t need to glance through the whole screen to process the information.
Next change: information architecture. I placed a greeting up top. I also placed the call-to-actions below the card balance so that you’ll see how much you have left and at the same time, you can easily see what actions you can do in the screen.

FIGURE 1.4b — Warning and error messages for varying card statuses

Since we’ve omitted the Card Details section of the first screen, let’s substitute the section into a Message/Alert section on the right. To make things more contextual, seeing a warning about your card, in my opinion, is more helpful than just plain seeing the information then and there.
Another change: copy. I’ve scrapped the whole “Add Value” line and placed in “Reload” instead. Maybe “Top-up” can be another option but that remains to be tested. Instead of “Current Value”, let’s change it to “Current Balance.” Lastly, we change the “Cancel” button into “Go Back” to make it sound more actionable.
Personally, I would remove this part of the step since we can assume that people who place their Stored Value Card on the reader will almost always want to reload. This is of course subjective because we want to consider people who just want to check their balance or the card status.

Moving on to the next screen, we see another layout with information that’s all over the place; it’s silly.

FIGURE 1.5 — Reloading screen for Stored Value Cards

For a first-time user of this interface, I get the feeling that that person’s gonna have trouble going through the whole screen. I get that the information is there but the placement and the hierarchy is just plain nuts. Once again, we can make this better.

FIGURE 1.6 — Proposed Reload Screen during Top-up transaction

I know that I’ve only rearranged the information from the previous screen to my proposed one shown in Figure 1.6. Some changes are:

Information architecture: I placed the “Current Balance” above the “Amount Inserted” on the left while placing other important information like the “Accepted Bills and Coins” section on the right. I’ve also highlighted the “Amount Inserted” to let the commuter know how much they’ve already inserted.
Copy: I changed the copy as well to make the tone more consistent from the previous screens. One notable change is replacing “OK” and “Cancel” with “Reload” and “Go Back” respectively; again, this is to make the buttons sound actionable.
Layout: The layout is defintely arguable. I made some variations but I felt like this layout works best among the mockups I’ve made. Since I have no data to work with, I just did my best to make things more legible for reading. Any inputs on this part is much appreciated.

After sacrificing your hard earned money to the machine and successfully reloading your card, you’ll arrive at the last page which is the confirmation of a successful transaction.

FIGURE 1.7 — Screen after a successful reloading transaction

The screen shown in Figure 1.7 has a number of things we can revise to enhance the experience further. First off, the lines “Value Added” and “New Value” really grinds my gears; I’m not sure if it’s the same for other people but it really doesn’t sound contextual in any way. Also, I get the effort on the “Receipt” button; you’re supposed to be able to print a receipt but again, the action doesn’t look that obvious.

FIGURE 1.8 — Proposed Screen Mockup for a successful Reloading

Here are some small changes shown in Figure 1.8 I made to make the experience more engaging and less robotic and generic:

I’ve omitted the “Value Added” section with the assumption that the new and current balance is the information that’s more important to the commuter. This bit is arguable of course.
Changed the copy from plain “Receipt” to “Print Receipt”, from “New Value” to “Current Balance”, and from “OK” to “Finish” to signify an end to the transaction. I changed the copy of the header as well to specify what transaction was done so instead of seeing “Transaction successful”, we see the message “Reloading successful.”
I’ve also placed a message on the right if anything happens just in case. Other than that, it’s just a simple message to part ways with the commuter.

Purchasing a Single Journey Ticket

Now that we’ve went through the flow of reloading a Stored Value Card, let’s move on to buying a Single Journey Ticket for those people who don’t usually commute by train.

FIGURE 2.1 — Screen after choosing to purchase a Single Journey Ticket

The screen on the shown in Figure 2.1 comes after the very first screen shown in Figure 1.1 above after choosing the “Single Journey Ticket” option. Although I don’t find any problems with the screen in Figure 2.1, as it is very straightforward, I still believe that the information can be better laid out, along with the copy.

FIGURE 2.2 — Interaction during a purchase of a Single Journey Ticket

One noticable change in the layout is the placement and the alignment of the stations. In my opinion, it’s hard to read through text aligned to the right so I simply switched the places of the ovals to the left while changing the alignment of the text to the left so that there’s not much of a disruption in reading. I also placed the buttons nearer to the “Ticket Fare” so that it’s easier to see where the actions are.
I changed the “You are here” and “Selected stations” to “Coming from” and “Going to” respectively so it’ll sound more like a journey than a simple statement. The “Ticket Fare” stays the same but with a slightly larger text size.

After selecting your destination, you’ll see how much the price of your ticket is depending on your origin. In my case, it’s ₱20.00 for each ticket coming from Recto going to Cubao.

FIGURE 2.3 — Screen after choosing your destination

The screen in Figure 2.3 has the same layout as the one in Figure 1.5. The only difference is the amount of information that’s placed on the right column. Information like the number of tickets and the amount inserted is visible as well; I have no drilling comments whatsoever on this screen but for consistency’s sake, I’ll redo the layout, copy, and hierarchy here on this screen as well.

Figure 2.4 — Interaction during inserting of bills and coins

To make things consistent throughout the screens, I decided to refer to the layout on the Figure 1.6. Here are some notes for this screen:

When you are buying Single Journey Tickets, transactions should automatically proceed as long as the amount inserted is higher than the ticket fare hence the lack of a “Buy” button on the screen shown in Figure 2.3. I added in a “Buy” button in Figure 2.4 with the thought of someone maybe wanting to cancel the transaction and go back to the previous screen.
Other than what I mentioned above, this screen has almost the same layout on Figure 1.6 but the only change here is the component where you determine the number of tickets you’ll be buying.

Figure 2.5 — Screen after a successful purchase of a Single Journey Ticket

I’m not sure why the designers of the application decided to place the buttons far away but I’m sure that they have their reasons for it. Again, the information display on Figure 2.5 is enough to complete the transaction but let’s try a different approach as well.

Figure 2.5 — Proposed Screen Mockup for a successful Purchase of a Single Journey Ticket

The screen shown in Figure 2.5 is exactly the same as the one on Figure 1.8. I changed the header and the copy to fit in the context of the transaction:

The header says “Purchase successful” instead of “Transaction Successful” (Unfortunately not shown in my photo. Sorry!)
Next, the buttons stay the same with some copy and layout; we can still either finish the transaction or print a receipt for proof of purchase.
Lastly, I placed a message on the right to, again, make the tone of the transaction more warm and less robotic.

Purchasing a Stored Value Card

The process of purchasing a Stored Value Card has the least number of steps. Going back to Figure 1.1, after you’ve chosen to buy a Stored Value Card, all you need to do is to insert your money and confirm how much you want to have as your initial balance.

Figure 3.1 — Screen after choosing to purchase a Stored Value Card

In this screen, we’ll come across a hurdle of how much money should I put in to purchase a Stored Value Card. We can see on the upper right hand corner shown in Figure 3.1 the information we need to purchase one.

Though, what does “Issuance Fee” and “Purse Value” mean? “Issuance Fee” is the price of the card while “Purse Value” means the minimum amount needed for your balance. A simple change in copy can help explain it better.

Figure 3.2 — Figuring out how much I should really put in

If you notice the photos in Figure 3.2, you can only purchase a stored value card once you’ve inserted 32PHP which is the price of the card along with the minimum balance needed. For a person who’s gonna buy a Stored Value Card for the first time, given the numbers that the system is showing, I bet that person’s gonna be confused as to how much we should really insert to buy a card.

Figure 3.3 — Interaction during inserting of bills and coins

I did my best to change a few things on the layout and it’s shown on samples in Figure 3.3:

I changed the copy from “Purse Value” and “Issuance Fee” to “Minimum Balance” and “Card Price” respectively. I’m sure that there are better approaches to inform the user that there is a minimum amount need to purchase a Stored Value Card but this is the change that I can think of for now.
For the layout, I just followed the ones from Figure 1.6 and Figure 2.4 to make things consistent.

Figure 3.4 — Processing page after confirming the amount for initial balance

Personally, I’d change the screen in Figure 3.4 into a simple rotating loading screen to make things less confusing.

Figure 3.5 — Screen after a successful purchase of a Stored Value Card

After successfully purchasing a Stored Value Card, we arrive at the screen shown in Figure 3.5 which is similar to the one in Figure 2.5. I decided to change a few things to make things the same for the whole case study.

Figure 3.6 — Proposed Screen Mockup for a successful Purchase of a Stored Value Card

The only change that I did here was to change the information that’s shown after you purchase a Stored Value Card:

Instead of showing the number of cards you’ve purchased, I wanted to show the balance to let the commuter see how much they have in the card. I think commuters are smart enough to know that only one card was dispensed.

Conclusion

Even though I only tackled the purchasing and the reloading side of commuting in the LRT, this case study gave me a lot of insight on how we can improve the process of a bigger flow to make things more efficient. The comments and inputs I’ve received helped me in realizing things that I didn’t know as well.

My only gripe with this case study is that I didn’t any data to work on to provide factual bases for my approaches. I honestly would like to test these in the real thing. If you know anyone from who’s from BeeptoPay.com, it’d be pretty awesome if we could test these approaches out.