Before You Ship Another Mobility App: A UX Research Playbook for Transport Product Teams
Quick Summary
When EV charging apps score an average satisfaction of 32% for their core job helping someone charge their car away from home that’s not a design problem. It’s a research problem. The product shipped without enough of the right questions being asked before launch.
Transport product teams are building in one of the most behaviorally complex environments that exists. Passengers are stressed, time-pressured, and often dealing with physical infrastructure that doesn’t match the digital experience they’ve been promised. The margin for friction is close to zero. A confusing payment step at a charging station isn’t an annoyance it’s a reason to reconsider whether an EV was the right call.
And yet, most mobility apps go live with the same gaps. Different modes, different use cases, same pattern: a digital product that works in the lab and fails in the field.
The 32% Problem Nobody in Mobility Is Talking About
We Are Systematic analysed 7,967 app store reviews across 15 UK charge point operators in 2025 using a jobs-to-be-done satisfaction framework. The headline: overall satisfaction with the core job of charging away from home sits at 32%. Not one component job locating a charger, starting a session, managing payment reaches 50% satisfaction.
Payment UX is the sharpest failure. Satisfaction dropped 19 percentage points in two years, from 54% to 35%. Users report unexpected pre-authorisation holds one reviewer documented £360 held across nine separate charges and payment errors that arrive with no explanation and no recovery path.
J.D. Power’s 2025 EV Charging Satisfaction data tells the same story from a different angle: 14% of EV owners visited a public charger that year and left without successfully charging. ChargerHelp’s 2025 Annual Reliability Report shows 60% of those failed visits involved stations that were technically operational but unresponsive. The hardware was on. The software experience had broken.
The frustrating part is that none of this is hard to surface in user research. These failure patterns appear in the first five usability sessions. They show up in app store reviews the week after launch. The information exists. The research process isn’t structured to find it before the product ships.
That’s the 32% problem. And it isn’t unique to EV charging.
What Mobility App UX Research Actually Covers
There’s a version of UX research that transport product teams think they’re already doing. An accessibility audit here, some beta testing there, a round of stakeholder walkthroughs before go-live. That’s not wrong. It’s just not enough.
Mobility app UX research covers the full arc from intent to outcome including the physical, environmental, and situational variables that lab testing strips out entirely. The same principle applies across product categories: the gap between what research teams think they’re studying and what passengers are actually experiencing is where products break down.
Concretely, it includes contextual field research watching passengers use your app at actual stations, stops, or charging points, not in a usability lab. It includes situational usability testing that replicates real conditions: time pressure, poor signal, cold hands, distracted attention. A mobility app user is almost never relaxed and fully focused. Testing as if they are produces results that don’t transfer.
It also covers mental model mapping to understand what passengers expect to happen versus what the app actually does, payment and error state research most teams test the happy path and skip the failure states entirely and multimodal journey research that traces a full trip across modes to find where handoffs break.
The distinction that matters: mobility app UX research is not QA testing. QA confirms the app works as specified. UX research finds out whether what was specified is what passengers actually need.
The 4 Stages Where UX Research Changes Transport Launch Outcomes
- Before the product brief is written
The most common reason transport products ship with fundamental experience gaps is that the brief was written before anyone watched a real passenger attempt the journey the product is supposed to support. Discovery research at this stage doesn’t need to be large. Eight to ten contextual observations watching people navigate a transit journey, attempt to charge an EV for the first time, plan a multimodal trip will surface assumptions that would otherwise survive all the way to launch.
- During prototype and flow design
Paper prototypes and low-fidelity wireframes are faster to test than built products and faster to change. Running 5 to 8 usability sessions on a checkout flow or a charging session initiation sequence at this stage takes a week. Fixing the same problems after launch takes a quarter. Transport product teams consistently underinvest here because the design feels obvious internally. It never feels obvious to the person using it for the first time at 11pm in a car park.
- Pre-launch field testing
A research study in a lab cannot replicate what happens when a user opens a transit app with one bar of signal and a bus leaving in 90 seconds. It cannot replicate the moment a charging session fails and there’s nowhere to escalate. Pre-launch field testing structured sessions in real environments with real conditions is the most underused stage in transport product development. It’s also the stage most likely to catch the failures that become viral complaint threads three weeks after go-live.
- Post-launch behaviour research
Users who hit friction in a mobility app don’t complain. They find a workaround a different app, contactless tap, a phone call and the product team never sees the failure because the user left silently. Post-launch behaviour research catches this. Regular structured observation, session recording analysis, and follow-up interviews at the 30-day mark build the feedback loop that makes version 2 significantly better than version 1.
Why Transport Teams Keep Shipping Products Passengers Route Around
A peer-reviewed study in the European Journal of Transport and Infrastructure Research documented a structural gap between what passengers need from transit wayfinding systems and what existing infrastructure provides. The practical result: riders bypass physical signage entirely in favour of smartphones. The infrastructure hasn’t caught up with the behaviour.
This pattern scales beyond wayfinding. Passengers who find a transit payment app confusing switch to contactless bank card tap. EV drivers who can’t troubleshoot a failed charging session drive to a different network. Commuters who can’t parse a journey planning app call the helpline instead. The product team sees low engagement. They don’t see that the product was routed around, not rejected.
This happens when research is weighted toward internal stakeholders rather than end users. Transport product teams often carry deep domain expertise they understand the infrastructure, the regulations, the operational constraints. What they’re less likely to have is a systematic process for watching someone encounter their product with no prior context and no tolerance for confusion.
The challenger mobility brands gaining ground on incumbent operators tend to close this gap not by spending more on research, but by running it earlier and acting on it faster. They test error states. They research equity gaps the same gaps that surface in retail UX research when unbanked users hit payment walls. They fix payment UX before satisfaction drops 19 points.
The Real Cost of Skipping UX Research in Transport
The 14% non-charge rate is a useful proxy for what skipped research costs in mobility. For every 100 EV drivers who visit a public charger, 14 leave without charging. Not every failure is a UX failure hardware breaks too. But 60% of failed visits involve stations that are technically operational. The hardware is on. The experience has failed.
That’s a research failure upstream. Someone shipped a session initiation flow, an error state, a payment recovery path without ever watching what a driver does when it doesn’t work on a dark motorway forecourt at 8% battery.
The cost compounds in transport the same way it does in CPG product development: silently. A passenger who bounces off a confusing app doesn’t file a complaint. An EV driver who gives up on public charging and only charges at home doesn’t generate a support ticket. Clean error logs and rising churn can coexist for months before the pattern shows up anywhere a product team would look.
There’s a secondary cost specific to mobility: habit formation. Transport and mobility products live or die on routine adoption. A passenger who has one broken experience in the first week is far less likely to return than someone who got a minor frustration in a retail checkout. There’s no equivalent of “I’ll try again next time I need groceries.” A broken journey is just a broken journey.
Building UX Research Into Your Transport Product Process
The most common reason transport product teams don’t run enough UX research isn’t budget. It’s timing. Research gets proposed after the brief is signed, after the architecture is agreed, after the launch date is set. At that point, findings are interesting but not actionable. The roadmap won’t move, the error states won’t rebuild, the payment flow won’t rewrite itself four weeks before go-live.
Fixing this means tying research to decisions, not to timelines. Practically:
- Discovery research runs before the product brief is locked not after the first sprint review.
- Prototype testing is a design gate no flow moves to build without at least 5 usability sessions on the critical path.
- Field testing is a launch gate not a subset of UAT, not the same as QA, a separate stage with real conditions and real users.
- Post-launch research is built into the roadmap at 30 and 90 days not proposed as a future initiative after the retrospective.
Worth saying directly: transport UX research doesn’t require large samples to be actionable. Five field sessions will surface the payment failure modes. Eight discovery interviews will break the brief assumptions worth breaking. The Hamburg spatial satisfaction study used 239 participants across six months to produce infrastructure findings that will shape that network for years. The investment is smaller than most transport teams assume. The cost of not making it is documented in every app store, every support queue, every non-charge statistic that didn’t have to be that high.
The Question That Should Come Before Every Mobility App Ships
Before the next release goes live whether it’s a new charging network app, a transit journey planner, a multimodal booking flow, or a fare collection update there’s one question worth stopping for:
Have we watched a real user attempt this journey in real conditions?
Not in a sprint review. Not in a conference room with the product team and a demo account. In the actual environment, with the actual signal quality, the actual time pressure, the actual battery anxiety that comes with being a passenger who needs this to work the first time.
That’s the foundation of mobility app UX research. Not a checklist. Not a vendor tool. A commitment to seeing your product through the eyes of the person standing at a charger at 11pm, or running for the last train, or trying to buy a ticket with one hand and a pushchair in the other.
The transport teams shipping products worth boarding are asking this question before launch. The ones sitting on 32% satisfaction scores are learning why they should have.
