Toronto Transit Tap: Designing Smarter Transit Payment from Scratch
A project for the “Smart City” design theme competition of the half-year course INF2191 Interface Design.
Team Members
Pranjal Swami | Francesca Weigensberg | Polly Yang | Aaron Yin | Lin Zhang
My roles
User Research; UX Design; Usability Testing; Website Interface Prototyping
Methods
Architecture Diagram, Persona, Scenario, Use Case, Requirement Engineering, Prototyping, Usability Testing, Presentation
I Learned
Teamwork, Interface Design Guidelines, UX Design Process, Design Scope
Kickoff
Design Proposal:
Toronto Transit Tap (TTT) is a mobile payment transit application for smartphones and smartwatches that has some desktop functionalities.
Why We Proposed This Design Idea?
The implementation of new technologies to pay to use the TTC is currently ongoing. Implementation and functionality of Presto is not going as smoothly as many hope. Through our design project, we hope to turn Toronto into a “smart city” by adding more ways to pay for transit using smart technology, particularly on smartphones and smartwatches.
Assumptions & Claims
We are assuming that Toronto and the TTC will be able to implement this to some extent at some point in the future, including having the capacity of internet at all stations and on trains.
We will be targeting users who use the TTC on a daily or near-daily basis (as opposed to tourists or infrequent users). The interface on the computer screen would have simpler navigation and functionalities as what is currently being used for Presto, and the software for the app would enable users to tap their phone or watch to pay for transit. The features in iOS enable users to subscribe alerts on their devices when funds are low and/or when buying a new pass.
Justification
As we move towards a cashless and “smarter” society, this design would reduce boarding time and be more convenient for frequent transit users, particularly for those in the downtown core, and reduce the lines at collector booths. It will ease users’ frustration and ensure that they have sufficient funds to pay for transit. The project is banking on the TTC catching up to most of the developed world when it comes to mass transit, but the increased use of smart devices proves that our project would be a worthwhile contribution to transit users worldwide.
Conceptual Model:
Our system primarily relies on three types of information systems: the platforms we will be designing for (the web, a smartphone, and a smartwatch), servers and databases to store user’s account and financial information, and the machines which will read the bar codes on the smartphone and smartwatch. Please see the architecture diagram for a visual guide as to how these systems interact and convey information to each other.
Research
Interview:
The first way we acquired knowledge of our users was doing short, informal interviews with TTC users, including people who use Presto to pay for transit. Most of our users were students at the University of Toronto, while another was an adult who uses the TTC to commute to work a few times a week.
Interviews were conducted in person, and we wrote down notes and key quotes in a notebook for reference.
Users were asked the following questions:
- Which TTC vehicles they ride on (subway, bus, streetcar, a combination of two, or all three)
- How frequently they use the TTC
- The features they like about the current payment system
- The features they dislike about the current payment system (including pain points)
- What features they wish could be implemented in paying for transit
- How receptive they would be to a mobile payment option (smartphone and smartwatch) for transit
Brainstorm:
We also had a brainstorming session lasting approximately one hour. Based on our notes from the informal interviews we conducted, as well as the current user experience of some of the group members (including one who uses the TTC to commute to and from school by using a metropass since Presto does not have payment options for students), we were able to integrate our findings and narrow down user characteristics, develop one persona, figure out key tasks, design scenarios based on said tasks, and establish a list of key user requirements, which can be seen below.
User Characteristics:
Primary users are transit riders who use the TTC on a near daily basis, or at least during the standard work week (Monday to Friday). These users typically would not load a random amount of money onto the ‘card’; they typically buy monthly passes, and some even buy a year’s worth of monthly passes to save even more money, in addition to being eligible for the Public Transit Tax Credit. Users may or not may own a car, but take public transit out of convenience and to avoid traffic during peak times. Primary users would most likely use TTT out of convenience and efficiency. Some users who choose not to carry a wallet would appreciate being able to pay for transit on a smartphone and/or a smartwatch.
Secondary users are those who occasionally use public transit, but rely on other methods of transportation (vehicle, taxi, ride sharing) to get around most of the time. They may have a Presto card for convenience, but see no need in purchasing a monthly pass due to not taking public transit frequently.
Ideation
Persona:
This persona was developed based on our interviews. Our persona is a student because the majority of people we spoke with were students; however, any frequent transit user can be a primary user, regardless of their age and occupation.
3 Top Scenarios:
The following are three scenarios depicting how our persona, Jennifer, would interact with TTT to complete various relevant tasks. While all three platforms are not discussed in the scenarios, the features and functions of TTT that are mentioned below are available on at least one platform.
Task 1: Load TTT account with funds (available on Website UIs and Smartphone UIs)
Scenario: Ann recommends TTT, a new public transit payment experience to Jennifer. Jennifer is surprised to hear that TTT has enabled mobile payment for public transit with a smartphone and smartwatch. Jennifer immediately does a quick Google search on her laptop to find TTT’s website, creates an account, and links up her PayPal account with the service. As a heavy PayPal user, Jennifer chooses to connect her PayPal account. In no time, the TTT website confirms the PayPal account connection and also prompts Jennifer to put money on her TTT account. After getting a confirmation message, she then uses the money from her PayPal account to purchase a monthly pass
Task 2: Get notified when there are insufficient funds (available on Website UIs, Smartphone UIs, and Smartwatch UIs)
Scenario: Jennifer has the TTT app onto her phone and already turned on notifications. When she enters the classroom and connects her phone to the U of T’s Wifi, she immediately gets a notification from the app on her phone, which informs Jennifer that there are only 2 dollars left in her TTT account and it’s time to buy a pass or reload her TTT account. Jennifer feels satisfied and thinks the app is quite timely in notifying when the funds are insufficient. Now she knows when to load money onto her account before her next trip.
Task 3: Tap to Pay at the transit machine (available on Smartphone UIs and Smartwatch UIs)
Scenario: It’s a typical Monday morning for Jennifer and she is running late for her 9am class. She somehow manages to get ready in time for the subway she takes to school. As soon as she reaches the subway station and is about to pay, she starts looking for her Presto card which is usually kept in her wallet. She soon realises that she left her wallet in her other bag. However, she remembers she has the TTT app on her smartphone. She takes her phone from her bag,, ensures she is connected to the internet, and opens the TTT app. She pays her fare by “tapping” her phone on the TTT scanning machine. The mobile app confirms the payment and deducts money from her account.
Solution
Low-fidelity Prototypes:
Based on the requirements generated in the ideation phase, the sketches of low-fidelity prototypes were divided into three sections based on devices. The workflows on each device were annotated in the sketches with texts and further illustrated in the appended flowchart diagram for each device.
Website UIs
Smartphone UIs
Smartwatch UIs
Medium-fidelity Prototypes:
We used Balsamiq to design medium-fidelity prototypes with annotations. Major user interfaces on each platform are presented as follows.
Major UIs
Testing
Usability Testing:
Our participants were mainly iSchool students at the University of Toronto enrolled in INF2191H taught by Olivier St-Cyr. There will be four rotations throughout the process, and we hope to get at least five participants total (at least one per group) to help us meet the ‘Rule of 5’, whereby testing five users typically reflects the opinions of 80–85% of users.
4 Participants were tested on the interfaces according to the following three tasks. After each task, they were asked to finish a questionnaire, and in the end, we asked them for their suggestions on the user interface design:
Task #1 (Website): Sign in and add a new payment method
You are a user of TTT and you need to add a new payment method on your computer.
Task #2 (Smartwatch and Smartphone): Receive notification on watch when funds are low and load funds on phone
You get a notification on your smartwatch that you have insufficient funds on your card, and you need to go somewhere. You realize you need to add money to your account in order to have enough money to pay for transit.
Task #3 (Smartphone and Smartwatch): Scan to pay for transit phone and get confirmation on watch
You use your phone as a payment method to ride the subway. Once the payment goes through, you get a confirmation on your smartwatch.
Usability Testing Results:
Pre-test Questionnaire:
All the participants owned (at the time of the test) smartphones and computers or laptops, and 50% of them own tablets. However, no participants owned smartwatches. Thus, their suggestions on designing the interface of smartwatches could be biased and/or limited due to their preference and familiarity with other devices.
In the two weeks prior to the usability test, 50% of participants took the TTC 3 to 5 times, and 25% of participants took the TTC 10 or more times. However, 25% of participants did not ride the TTC in the last two weeks. This shows that TTT would likely be used by more frequent transit users, and that a significant number of people do not rely on the TTC often to get around Toronto.
As to the method for paying for transit, 50% of participants preferred using Presto, 25% of participants liked using tokens or tickets, and the other 25% preferred using a Metropass. This shows that transit users likely prefer paying for transit with card technology like Presto and Metropass for transit fare payment, showing the potential embrace for an app like TTT. Cash is not least preferred way.
Scenario 1:
Website — Sign in and add a new payment method
75% of participants agreed our first task was very easy to complete, and 25% of participants agreed our first task was easy to complete. The feedback indicates the first task was straightforward and easy to accomplish.
As for the difficulties while completing the tasks in this scenario, 50% of the participants reported that the error pages didn’t tell them what specifically they did wrong when adding a new payment method. In addition, 50% of participants wanted a clearer way for the error message to be presented to them. This feedback shows that our error messages need to be written in a way to communicate to the user exactly what went wrong while trying to complete a task.
Scenario 2:
Smartwatch & Smartphone — Notification when funds are low and load funds
50% of participants agreed our second task was very easy to complete, and the other half of participants agreed our second task was easy to complete. The feedback indicates the second task is straightforward and easy to accomplish.
As for the difficulties while completing the tasks in this scenario, all the participants commented that the error page didn’t tell them what the problem was. And 25% of the participants reported that the radio buttons on the screen to select the amount of money/a pass to load were tiny.
Scenario 3:
Smartphone & Smartwatch — Scan to pay on phone and get confirmation on watch
50% of participants agreed our third task was very easy to complete, 25% of participants said it was easy to complete, and the other 25% of participants said it was difficult to complete. The feedback indicates that for many users, such a task would be straightforward, as it was easy to scan to pay on the mobile phone and get a confirmation message on the watch. However, the conceptual model may not match with every user’s mental model and, as a result, some changes need to be made to account for significant outliers.
As for the difficulties while completing the tasks in this scenario, 75% of participants reported that the error page didn’t tell them what the problem was. 25% of participants commented that the “My Card” label on mobile was not very clear. 25% of participants wanted a fewer number of clicks to get to the “My Card” barcode. 25% of participants didn’t know where to go to complete the task. This feedback demonstrates we should change the “My Card” label on mobile, and potentially reduce the amount of clicks or taps needed to get the barcode to make the task easier and faster to complete.
Insights from the Usability Testing Notes
Insights from Post-test Interviews
High-fidelity Prototypes:
Based on the results we got from the usability testing, we used Axure to create our high-fidelity prototypes. Here are some major screens on each platform. And the respective links to each prototypes are below each section.
Website UIs Axure Share Preview
Smartphone UIs Axure Share Preview
Smartwatch UIs Axure Share Preview
Major Selected UIs
Reflections
Summary of Work Accomplished:
Toronto Transit Tap is a mobile transit payment system that makes paying for public transit much easier in a smart society. With TTT, users pay for transit without having to carry around cash, tokens, and/or a physical pass or smart card. The purpose of this project was to make paying for transit more convenient in Toronto, a city that seems to be years, if not decades behind, other cosmopolitan cities around the world when it comes to public transit and how people pay to ride it.
While the basic concept for our project, mobile payment for transit, did not change, the iterative nature of this project allowed us to focus our efforts on key aspects of TTT, including but not limited to: key features, clear and concise error and confirmation messages, labelling of important functions and features, and ensuring its ease of use for multiple user groups. We paid attention to all feedback given, even some that were outliers, to create a better product for each iteration of the prototypes. More screens were added at each phase to compensate for additional needs and modifications to the project. Many features were worked around security concerns and within specific parameters to make it easy and simple to use while ensuring as much privacy of data as possible in a market that depends on the gathering and analyzing of big data.
Limitations:
The following are a list of current and future limitations for this project:
- Cost of the machine (scanner) needed to read barcodes on smartphones and smartwatches.
- Users would not be able to pay if all available scanners are broken. Currently the TTC will let Presto users ride for free when this happens, but this is not always the case, especially when transit users have to take shuttle buses.
- A lack of formal user research since no app like this currently exists in any part of the world (to our knowledge). Much of what we designed was a combination of various apps and services.
- Usability testing was only done with graduate student transit users. We may have gotten different results had we been able to test a greater variety of transit users from different backgrounds.
- Some features were not implemented due to security concerns.
- Recommendations regarding the size of radio buttons could not be followed through due to Axure’s limitations.
- Internet access is currently not available in most subway stations, so users would currently not be able to use this app to pay for transit. No timeline has been set as to when, or if, Internet access will be expanded across TTC stations.
- The prototype is currently based on the adult fare class, similar to how Presto currently operates. Those who want to travel based on senior/student or post-secondary rates would have to pay the adult rate at this time.
- Interac is currently not accepted as a payment method for users who prefer paying with debit over credit and/or Paypal.
Future Work:
- TTT was currently designed for iOS, and has the potential to be designed for Android in the future.
- Perform a different usability test with actual TTC passengers of varying ages and transit usage frequency instead of classmates (for example, ask them whether they are accessing the public transit regularly before we test them).
- Do more security studies in order to improve the implementation of auto-load features.
- Expand more fare options for senior/student and post-secondary users. According to a TTC employee, Presto will expand its offerings to include passes for different types of users by the end of 2017, so this idea is feasible.
- Potential to allow Interac as a payment method for those who do not want to pay with a credit card and/or for users who do not have a Paypal account.
- Ask TTC and Metrolinx to take a look at our prototypes and have them pay us if they wish to implement it (after everything has been refined and finalized).
