.png){kind=spacer}
.png){kind=spacer}
Recent advances in location tracking have made taking public
transportation more convenient than ever, where riders have better, consistent service accessibility, increased information around route schedules and planned disruptions, and more accurate arrival estimates than ever before.
Still, as anyone who has ever ridden (and missed) the bus can admit, taking public transit can be ... far from ideal. API calls may pull outdated, inaccurate bus scheduling data, that is misrepresented as trustworthy to users who must eventually realize these inaccuracies the hard way. Not only does this deteriorate credibility, the frustration of waiting for a bus that never arrived is almost always unacknowledged, further exacerbating an already unsatisfactory user experience.
Spongebob awaits anxiously for a bus in Rock Bottom.
Additionally, there are many missed business opportunities to encourage bus ridership using existing event planning data and rider payment habits. The more users we encourage to ride the bus, the more busses are available, the better the system works for everyone!
My goal was to design an app that realistically addresses infrastructural shortcomings in upkeeping public transit databases, while encouraging future bus usage by capitalizing on existing information around rider habits and events.
Studio.init() allotted me forty eight hours for this project, so I prioritized design decisions based on ease of implementation and perceived business value rather than pie-in-the-sky solutions. I wanted to flex my skills not only as a UI designer, but as a product strategist.
The work of this application is meant to supplement, not overhaul, the public transit system, so using existing data infrastructures rather than implementing new ways to collect data was critical as a business outcome.
Alongside a few impromptu user surveys, I consolidated multiple research papers to understand the current public transit environment, as well as drawing from my own experiences as an urban transit rider.
The largest pain point for riders included low-quality data/lack of data management by transit agencies. This decreased perceived reliability of transit services and increased feelings of anxiety and frustration almost all riders.
Additionally, users experienced friction in switching between multiple different transit apps when traveling to different cities, suggesting that from a product development perspective, both riders and transit agencies could benefit from a white-labeled aggregate transit app, rather than one developed in-house.
"Added value of a customized transit app for metropolitan bus trips;" Read study here.
"Mobile App for Public Transport: A Usability and User Experience Perspective" Read study here.
"Current practices and emerging trends of transit apps for fixed-route bus services in the US;" Read study here.
"Rider Happiness Benchmarking Report" Read study here.
A good indicator of data quality? Recency updated. By showing users when the last time data for this bus schedule was updated, users are enabled to make bus riding decisions based off their own risk preferences, which allows for better outcome experiences.
Bus schedule last updated a month ago? Probably reliable. If it was last updated in six years ago, however, you might be better off walking. Equipping users with this context upfront gives riders more accurate expectations around arrival and wait times, and reduces the risk of frustrating outcomes.
Recent searches/bookmarks match rider's habits
Downloading map covers offline navigation
Visual redundancy of bus icon
Recent searches/bookmarks match rider's habits
Downloading map covers offline navigation
Needs connection action to reach toast message
Another way to foster a sense of trust in the app is to open lines of communication from the user. This is especially important with regards to safety while riding public transit, but lighter grievances such as technical issues regarding the app can be communicated as well. Intentionally asking for feedback give riders confidence that their concerns are heard, and can also be an outlet for positive commendation to public transit workers.
Rider feedback is most useful when it is tied to a specific trip, as this can help with future sentiment analysis—are rider sentiments correlated with specific bus lines or drivers? Times of day?
In addition, saving specific stops and routes in the app aids in rider trip planning by accurately reflecting rider preferences (least walking, least transfers, fastest overall etc).
Favorite saved stops/routes for ease of trip planning
Recent trips saved specific bus number with tap payment purchase ->
Makes feedback strongly associated with specific lines/bus drivers more actionable
Rider feedback directly corresponds to trip taken.
Custom messaging too irregular for data scrapping, (keep for beta to form categories for next release)
Users may not want to track previous trips for privacy concerns, include opt-out
By capitalizing on the social benefits of taking public transit (reducing traffic congestion, lowering carbon emissions, relieving the stress of driving in rush hour, etc.) we can incentive future usage through through goal definition and performance praise.
Miles tracked can be calculated in two ways, through location tracking or by ticket purchased (which estimates average miles traveled per ticket bought). This gives users privacy controls, while still providing positive feedback for their patronage.
Greater usage could be acknowledged through coupon codes for future rides, rewarding and incentivizing others to become high-use users.
By tracking public transit usage on an individually and local level, performance praise can be achieved through coupon codes for future rides, rewarding and incentivizing others to become high-use users.
.png)
.png)
.png)
I'm grateful to Studio.init() for giving me the opportunity to really showcase my design process: Imagine fantastically, iterate practically, and implement fiscally.
I showcased this project by thinking of the users holistically, rather than focusing on any specific point in the user journey. Often times, it's much more meaningful to design for when things go wrong than it is for when things go right. Different levels of information account for different potential blinds pots in data management, and failure of the system is recognized and compensated for, hopefully making your next bus ride that much more smooth.
See Next Project
.png)
.png)
.png)
.png)
.png)