NJ Transit mobile
app redesign
NJ Transit is the third-largest public transit provider in the U.S., serving over 270 million trips a year across New Jersey, New York, and Philadelphia. Despite its scale, the app riders depended on every day was falling short. Cluttered navigation, unreliable real-time data, and flows so complex that buying a ticket took 11 steps. I set out to understand why, and redesign it from the ground up.
This is a conceptual UX redesign based on public information and independent research. It is not affiliated with or reflective of NJ Transit's official design decisions.
A transit system under pressure
NJ Transit's scale makes its UX problems high-stakes: small points of friction in the app are multiplied across millions of riders who depend on it daily.
An experience that overlooked rider needs
In 2019, NJ Transit relaunched its app with a cleaner interface. But core UX issues from the previous version, including confusing navigation, unreliable real-time data, and poor accessibility, went unaddressed, and by 2021, pandemic-era revenue losses and a $1.25B bailout request made the need for a better rider experience hard to ignore.
A redesign rooted in research
I redesigned the NJ Transit mobile app through user research and iterative testing, focusing on making it more intuitive, inclusive, and trustworthy.
Experiencing the app firsthand
As a returning user, I re-downloaded the app and documented friction points. What stood out wasn't just what was broken: inconsistent terminology, flows that left you unsure if anything had happened, screens overloaded with text, and color contrast issues that made key actions hard to read.
Benchmarking the competition
I evaluated Transit, Trainline, and Tube Map to identify UX opportunities for NJ Transit. All three had real strengths, but vague, unverifiable information was the most consistent trust-breaker across each.
- Real-time vehicle tracking with a live map view
- Trip comparison across bus, rail, and rideshare in one search
- Clean, minimal interface with low visual clutter
- GPS accuracy issues in dense urban areas led to inconsistent ETAs
- Limited accessibility-specific filtering for routes or stations
- Few options for in-app customer support
- Strong fare comparison and ticket purchase flow
- Built-in accessibility settings, including text scaling and screen-reader support
- Clear seat and fare-class selection
- Service alerts were often vague, with no specific delay reason given
- Dense information screens created cognitive overload for new users
- Refund and cancellation flows required several extra steps
- Simple, iconic route visualization that's easy to scan
- Fast offline access to maps and schedules
- Minimal onboarding required for first-time users
- No real-time crowding or service-alert data
- Limited support for trip planning across multiple transit modes
- Sparse accessibility information for stations
The pattern that stood out most: Transit was faster but less trustworthy. Trainline was thorough but overwhelming. Tube Map was clear but static. NJ Transit riders needed something in between: an app that could surface real-time complexity without making the rider manage it.
Key takeaways that shaped my redesign strategy
Complexity kills confidence.
Riders abandoned flows that required too many steps or decisions.
Inaccurate data is worse than no data.
A wrong ETA erodes trust faster than a missing one.
Accessibility isn't an edge case.
Situational constraints like noise or one-handed use affect the majority of riders at some point.
Transparency builds loyalty.
Riders were more forgiving of delays when the app communicated clearly and offered alternatives.
Listening to what riders were already saying
To understand rider frustrations, I analyzed NJ Transit reviews and tweets, supplemented by commuter complaints from public forums.
One limitation worth naming: secondary research tells you what is broken, not why riders made the choices they made before giving up. Real user interviews would have changed this project. That is the first thing I would fix if I did this again.
The following themes surfaced consistently across user feedback:
Unreliable real-time updates
Riders frequently reported inaccurate arrival times and vague service alerts.
Poor customer support
Many users described unresolved complaints and difficulty obtaining refunds.
Accessibility gaps
Limited station-level accessibility info left some riders feeling excluded.
Confusing navigation
Users struggled with trip planning and ticketing due to cluttered interfaces and unclear flows.
Trust erosion
Repeated service issues and lack of transparency led to declining rider confidence.
Redesign priorities
The research kept pointing to the same problem: the app gave riders information without giving them confidence. That shaped four design priorities.
Improve application accessibility
Design for permanent, temporary, and situational disabilities using inclusive design principles.
Minimize cognitive load
Present schedule data in a way that reduces mental load and improves clarity.
Build user trust and confidence
Equip riders with real-time navigation, crowding data, and alternate transit options, like discounted rideshare credit for delays over 15 minutes.
Unify visual and interaction design
Build a reusable component library and unify the visual language across the app for a coherent, branded experience.
Designing for inclusivity
To support a diverse rider base, I applied Microsoft's Inclusive Design Toolkit and the Persona Spectrum, designing for situational and temporary impairments, not just permanent ones.
Accessibility isn't just about disability, it's about context.
Riders aren't just disabled. They're distracted, rushing to catch a train, juggling bags, chasing kids, or squinting at a screen in the sun. I designed for all of it.
Ideation and sketching
UI sketches
I translated research insights into early wireframes and paper prototypes, structuring key screens, including sign-in, trip search, and ticket purchase, around rider priorities.
Navigation icons
I explored iconography for home, account, trip-planning, and ticketing, choosing symbols that better communicate function and improve wayfinding.
Prototyping and refining
User flows & low-fi wireframes
Before designing anything, I mapped the core user journeys as task flows, including signing in, planning a trip, and buying a ticket, to identify where the existing app lost riders and where steps could be removed.
Mid to high-fi wireframes
I built progressively higher-fidelity wireframes and prototypes, treating the work as if it would eventually be handed off to engineering, using reusable components rather than one-off screens. In a real execution, features like real-time crowding indicators and rideshare fallbacks would need phased rollout as backend infrastructure caught up. I designed with that in mind.
A cleaner, more confident experience
The final designs reflect a cleaner, more accessible interface with improved navigation, real-time data integration, and a unified design system.
I identified three metrics I would have tracked: ticket purchase completion rate, time-on-task for trip planning, and support ticket volume for in-app navigation issues. Those were the places the existing app was most visibly failing riders.
Looking back
Designing for a transit system forced me to think about accessibility not as a checklist but as a design foundation. Riders aren't a homogeneous group. They're distracted, time-pressured, and navigating in environments that work against them. That reframing shaped every decision I made, and it's something I carry into every project now.
This project relied on secondary research, including app store reviews, tweets, and public forums, rather than talking directly to riders. If I were doing this again, I'd prioritize even a handful of user interviews early on. Quantitative feedback tells you what's broken. Conversations tell you why.
The logical next step would be usability testing with real NJ Transit riders to pressure-test the flows, followed by a proper design system handoff. I'd also want to explore how the app handles edge cases, including severe delays, service suspensions, and accessibility needs in the moment. Those are the situations that matter most to riders, and where trust is either built or lost for good.
The NJ Transit mobile app is a consumer product, but the design challenges it surfaces are anything but simple. Designing for users with fundamentally different relationships to the same system. Reducing cognitive load under time pressure. Making real-time data legible without requiring expertise to interpret it. Those are the same problems that show up in complex technical products, just with different domain knowledge underneath.
or simply want to say hi?