Redesigning a Mobile
Ticketing App for Public Transit
Startup
Payments
B2G2C
iOS
Android
Overview
After four years of moovel's white-label application being live and serving 5 million users, I had gathered actionable feedback for improvements. Combined with an aging codebase, we had the green light from leadership to redesign our biggest revenue producer from the ground up.
Key Outcomes
-
Launched to 15 public transit agencies
with 5 million users -
Improved App Store ratings from 2.1 to 4.9
-
Reduced customer support calls by 75%
-
Enabled revenue growth by adding transit benefits support
-
Improved client satisfaction
My Roles
-
Management
-
Project Planning
-
Research
-
UX Design
-
UI Design
About the Company
moovel partners with transit agencies to provide iOS and Android mobile ticketing applications for riders and backend management tools for management and inspection staff.
Challenges & Opportunities
-
Long purchase process and time to ticket launch
-
Lack of support for payment methods
-
Accidental ticket activations
-
Bloated navigation
-
Crashes and odd behavior due to old codebase
-
Frustrated clients
-
Dated design
Pictured above: The 'before' version of the Mobile Ticketing Application, white-labeled for VRE.
Pictured above: Setting thematic goals for the redesign, itemizing important new feature requirements, and comparing design strategies
Simpler navigation
Our hamburger-style navigation caused problems. Not only had it been debunked as a good design pattern for hiding navigation, increasing cognitive load and becoming a "junk drawer", it doubled the amount of taps our users needed to navigate quickly from "Buy Tickets" to "My Tickets." And it out of thumb reach.
We updated the new design to follow best practice navigation with a tab group, located within comfortable thumb reach with prioritized user actions. Lastly, we consolidated the "Buy Tickets" and "My Tickets" functionality into a single "Tickets" tab to better align with mental models.
Protecting purchases
Many users called customer support after accidentally activating a stored mobile ticket.
We introduced two design changes to reduce this problem:
-
We made the 'In Use' ticket more obvious. We added color and an animation to draw the eye and empower users to find it quickly.
-
We added a confirmation alert when someone tries to use a stored ticket while one is already in use.
Better payment options
In addition to adding Apple Pay and Google Pay to the available payment options, We learned many riders receive employer benefits towards transit, particularly in the DC area. We also learned we were missing out on revenue opportunity because we didn’t have a way for users with transit benefits to use 100% of their balance.
We introduced a new split payment method that allowed people to use all of their balance.
Purchases made with transit benefits increased after introducing this payment method option
Outcomes
2.1 to 4.9 Stars
App store reviews increased post-update
75% Fewer Issues
Customer support reported 75% fewer ZenDesk support tickets post-update
Happier Clients
Account Managers reported all clients that received the new design were happier (as measured by their internal tracking system)
5 Million Reach
Launched to 5 million active users spread across 15 public transit agencies.
Time-Tested
Seven years after launch of the update, the app still has a 4.9 app store rating and running in select agencies.
Pictured above: The design team whiteboarded different design approaches.
Key Decisions
A faster purchase process
From user interviews and ethnographic observation, I uncovered two new insights about audience behavior:
-
Many riders purchased tickets while boarding the bus or train. Usually they had one stored, but if they forgot they ran out, they had to purchase a new ticket. The long process to purchase a ticket caused these riders to bottleneck the boarding process, frustrating operators and other riders, and be stressed.
-
Riders purchased the same type of ticket. Transit trips are usually routine—to and from school, to and from home—with the same origin and destination. It can take up to 6 selections, as it does with Chicago's Metra system, to buy a ticket: route, origin, destination, rider type (e.g. 'Adult'), ticket type (e.g. 'One Way'), payment method. Each step costs the user time.
We designed a simple pattern called "Buy Again," a button that pre-loaded a previously-purchased ticket into the shopping cart. This reduced the time to purchase from +25 seconds to under 5 seconds.
