Constructing the mobile transit ticket
Creating a standard for a standard-less industry.
I’m going to make a wild assumption. Most users reading this are probably pretty familiar with mobile technologies and as such, enjoy at least a few of the conveniences that our devices offer us. From paying for your coffee to boarding your flight; mobile apps and services are streamlining tasks that previously took loads of effort.
One might assume that this convenience easily translates over to the world of public transit, but not so fast…
It Starts At The Ticket
Now, not all public transit systems rely solely on physical or digital tickets for their fares. Many public transit agencies are slowly but surely incorporating additional, more user-friendly, fare systems. Admittedly, these agencies aren’t always able to move as fast as they would like. This pace, along with providing a service to a very large and diverse group of users, means that fares in the form of tickets still play a very large role in the lives of transit commuters.
The Audience
In setting out to create our mobile tickets, we first and foremost focused on our audience. For us, that audience came in the form of two user types — the rider and the inspector (in some cases this is a station agent or a machine validator).
Both of these users need a specific set of information. The Rider needs information directly pertaining to their journey. In most cases, they need to know where they are coming from, where they are going, and what type of services they’ve purchased. Once purchased they need to know if a ticket is currently active or stored for later activation. Most importantly they need to feel secure in the fact that the ticket they’ve purchased is valid, that they won’t run into any trouble with the inspector.
The Inspector typically needs similar information. They might also need more technical details, security information, for example, that doesn’t hold too much value to the Rider.
While it’s important to understand the context the Inspector brings to the ticket design, we’ll focus primarily on the Rider’s needs for the remainder of this article.
The Objective
Our objectives were clear from the start. We set out to create tickets with:
- Uncomplicated visual hierarchy
- Predictable interaction patterns
- Consistent construction blueprints
- Modular blueprints (to a degree)
Visual Hierarchy
The hierarchy was a top priority for our team. Transit riders very seldom have the luxury to leisurely stand around and read information at a relaxed pace. Riders are often running to catch their train or bus connection, standing outside in less-than-desirable weather environments, or frantically looking around for the correct head-signs. Through continued iteration and testing, our team settled on a hierarchy convention that displayed desired information to the user in the appropriate order with necessary emphasis.
Interaction Patterns
Alongside visual hierarchy, a complimentary priority was to keep the interaction with the tickets clear and simple. If a user is to tap on any area of the ticket, we want it to behave the way they expect it to behave.
The user might find tickets in two different flows, in their cart or stored in their ticket wallet. We use various visual elements to differentiate between these sections and to indicate that the interaction model changes.
Tickets also have an expanded state, where the information changes for the inspector. This state of the ticket comes in the form of a full-screen takeover and introduces visual details for branding, security, and validation purposes.
Modular Parts
Building a ticket for a single agency is one thing, but making sure that ticket works for hundreds of agencies is another thing altogether. Standards, beyond GTFS data, are few and far between in the public transit world and when it comes to fare structures it’s no different. Cities have unique transportation cultures, with different riders, vehicles, and landscapes. While a fixed price fare might work for one city, a variable range or zone based fare structure might be a requirement for another another.
Regardless of the fare structure, our ticket needed to ingest information from an agency’s fare catalog and display that information in a way that makes sense to the end user. To solve this problem we’ve designed with modularity in mind. Our tickets are composite UI items, made up of multiple pieces that fit together to contain the information fed to them by the catalog.
Tickets are components within our design system, and as such, they can (and should!) adapt and change over time as the product and system grow and evolve.
Blueprints
Having a modularly constructed, hierarchy optimized, interaction tested ticket is great, as long as you can accurately and consistently reproduce it. Documenting the decisions our team has made along the way allow us to work closely with our engineering teams and incorporate these tickets into live products.
Conclusion
In a perfect world utilizing public transit for your commute is as streamlined and effortless as simply boarding the vehicles. While the world of transportation is rapidly changing, we’ve got a journey ahead of us. It’s up to teams working in this industry to make sure that we don’t leave users, like those still using physical or digital tickets, behind as technology swiftly progresses forward.
