Introducing Fare: E-Z Pass for the Metro

In January, I moved to Paris for a semester abroad. I adored the art, the café filtres, and even the metro. One thing I didn’t love, however, was trying to make the train for morning classes. I always seemed to get stuck rummaging through my bag for my NaviGo pass as the Gare d’Austerlitz-bound train wooshed past below my feet.

When I started my UX internship at Viget, I needed a topic for my 10-week long solo project. My advisor, Samara, urged me to find a problem and ‘UX’ it. The options were endless: I could solve boredom while jogging, pretension in coffee shops, and even waiting at the DMV. But I remembered the countless last-minute searches for my train pass (inevitably at the height of rush hour) — be it my NaviGo, my Charlie Card, or my St. Louis MetroLink pass. Why wasn’t there a multi-city payment app for public transportation?

Well now there is. Meet Fare*, an app that solves the problem of the tiny-yet-cumbersome subway card — like E-Z Pass for trains and buses. (View a clickable prototype on InVision).  

Fare is lightweight, and opts for simplicity above all else. It replaces subway cards, so users just add a credit card to their accounts and scan through the turnstile using Fare’s QR code. The app works city to city, so it’s the same experience, say, on the bus in Boston as it is on the train in Chicago.

Fare was not only a chance to work on my user research, sketching, and animation skills but it was also a valuable learning experience. Here are some lessons I learned along the way.

Creating an MVP

In the beginning, I was so excited to make Fare wonderful by introducing a ton of features. It could have rewards! It could have badges! I could pair it with bikeshares across the US...and Europe! Okay, I’m exaggerating, but early on I fell into a tempting UX trap: feature-based problem-solving.

For a variety of reasons — from Hick’s Law to “feature fatigue” — adding features to a product doesn’t necessarily improve it. With that in mind, I made my app simpler and more efficient to use than a metro card. Fare didn’t need to do everything; it just needed to do one thing incredibly well.

Looking back, I realized that I had originally wanted to add features because Fare felt boring without them. But a product can have personality in other ways that don’t overwhelm it. I just needed to harness the power of animations and illustrations to make my lightweight app feel more charismatic.

Seamlessly Onboarding Users

Onboarding is tricky, because products must ask a lot of their users before any sort of trust or relationship is established. Sometimes they also throw new information at users with little explanation. How could I avoid these pitfalls?

In user testing, Fare’s “auto-reload” feature came closest to the pain-points listed above. Users can choose to automatically reload their virtual cards when balances dip below $5. This is a great feature especially for commuters, because they don’t have to repeatedly add money; Fare does it for them. But while “auto-reload” exists on some payment apps, the term is not universally known or understood. In one screen, I needed to explain auto-reload — what it is, when it’ll happen — and prompt users to set their reload value.

Placing the empasis on the onboarding process rather than just in-app screens made the first time user experience feel fluid and trouble-free. 

Being deliberate about error handling within the “sign-up” and “add credit card” forms also helped create a smooth onboarding process. Although error handling isn’t glamorous, offering positive reinforcement when users succeed on forms and showing where they’ve gone wrong can be the difference between a painless task and a vexing one.

Designing for Growth

Characters representing each city not only gave Fare a fun and playful feel, but they also helped distinguish between cities.

One of Fare’s core features is its ability to work across cities. Whether you’re a daily commuter or traveling to a brand new city, the app provides a fluid connection from one place to another. Though I set out to create an MVP, I always kept this fact in mind: if Fare were to grow in the future, how might that shape its current design? What can I build now that could scale later on?

In light of that, throughout the summer I asked myself the tough questions. How will the Fare brand carry over from city to city? And how does the physical infrastructure of, say, MTA vs.WMATA change Fare’s UI? How will information be displayed if I were to include cities from Accra to Zurich?

I’m not sure there’s a ‘right’ answer to these questions. Nevertheless, quirks and differences between cities should be addressed, and I’m glad I broached these hypotheticals. With constraints as part of my thought process, I found it easier to make design decisions and imagine where Fare could go.

In Conclusion

All in all, creating this app challenged my UX thinking in new and stimulating ways. I learned a lot this summer, thanks to Viget and everyone who offered their support. If you want to check it out, find Fare here.

*A disclaimer: Learning about Fare has been shown to increase users’ frustration toward current, antiquated subway cards. Terms and conditions apply.