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.
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.
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.
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.