Collecting user feedback for a driver app means involving your own drivers, the app’s main users, in a systematic way. MOIA does this with monthly surveys, structured interviews in three stages and so-called test drives, in which developers drive with the app themselves to experience what stays invisible at a desk. The results go straight into prioritization and the roadmap. New releases reach 20 percent of the fleet first.
Key Takeaways
- MOIA runs a fully integrated ridesharing service: its own apps, its own employed drivers and its own vehicles, developed together with VW.
- The drivers’ navigation app is internal only. It shows up in the Play Store only for users with a MOIA email address, which makes it a pure business application.
- Driver feedback is gathered in three stages: monthly surveys, follow-up interviews with mockups and a final check after release of whether the feature serves its purpose in daily use.
- Every two weeks, test drives in a dedicated test environment put developers and testers behind the wheel, so they experience the app on the road instead of simulating it at a desk.
- New releases go out as a slow rollout: 20 percent of the vehicles first, then 50 percent, then 100 percent, with two days of observation between each step.
When Your Own Colleagues Are the Users
For one of MOIA’s apps, the target users are the company’s own employees: the drivers. The Vehicle Guidance Application, the navigation system for drivers, runs only on a specific device and doesn’t even appear in the Play Store without a MOIA email address. It is a pure business application that nobody outside the company would have any use for. That makes user feedback for this app a special case.
It creates an unusual starting point for quality work. Regular app customers simply leave when they don’t like something, and they don’t tell you why. The drivers can’t do that. They have to work with the app every day, on every shift.
That is exactly why they want to give feedback. Ada Pohl, Senior Quality Specialist at MOIA, sees that as a stroke of luck: anyone who has to use a tool has a real interest in making it work, and that interest can be tapped systematically.
MOIA Tests a Full-Stack Ridesharing Service
MOIA is a ridesharing service with pooled trips, its own vehicles and a complete set of apps. Customers book in the app, see the price and the approximate travel time, and an algorithm finds a suitable vehicle. Trips are pooled with other customers heading along a similar route.
The company builds everything itself, which is why it calls itself a full-stack ridesharing service: the customer app, the drivers’ navigation system, a separate screen for passengers sitting behind the driver and several more apps. Even the vehicles were developed with VW, from the interior down to the seats. The drivers are employees.
Quality has its own Quality Chapter, spread across several stream-aligned teams, each responsible for one area. For the driver app, testing covers whether the driver can handle a trip cleanly: customer picked up, customer dropped off, customer didn’t show.
Some constraints come from outside. MOIA isn’t a taxi company, and its license doesn’t allow door-to-door service. Pickups happen at digital stops defined by the city, within a 250-meter walking radius. Regulatory limits like these are not a detail. They shape how the software behaves.
Collecting User Feedback Is an Ongoing Process, Not an Annual Ritual
Instead of sending out one survey a year, MOIA runs several feedback channels in parallel. Once a month, a driver survey goes out as a link in a newsletter. The questions alternate between specific and open.
Sometimes the survey asks about one feature: Does this still work for you? Sometimes it deliberately stays open: What bothers you most at work right now? What’s missing? Do you need more information or less? The answers show trends: what is easy to use, what is missing and which ideas the drivers bring themselves.
Those trends become features in several stages. First the team pulls out everything it can learn, then it builds mockups and takes them back to individual drivers for their input. After that it builds or releases a first working version and checks again: after a while in use, does the feature do its job, does it make the driver’s life easier?
The strength of this approach is its rhythm. When you involve users early and repeatedly, you build features on evidence rather than assumptions, and the road from idea to a usable solution gets shorter.
Test Drives and Test Rides Move Testing from the Desk to the Car
Every two weeks before a release, testers get behind the wheel themselves. On a test drive, the team takes a vehicle and plays the driver while colleagues book trips remotely or from the back seat. The reason is simple: using a navigation system at your desk with a simulated blue dot is something completely different from sitting behind the wheel.
It changes how developers think, too. Implementing something at a desk and feeling for yourself how the app behaves while you drive lead to different decisions.
The second format is the test ride. The team books a real MOIA, sits in the back and watches the driver. If no customers are on board, they ask questions. Ada compares the role to that of a bartender: just take in whatever complaints and pain points the drivers bring along. Since the pandemic, with so much remote work, this channel has been used less.
One point matters here: both formats run in a dedicated test environment, never in live operation. Carrying passengers requires a special passenger transport license, and the team deliberately keeps real customer relationships out of it. Testers aren’t experienced drivers who can watch traffic and passengers at the same time. The method loses its value as soon as testers are thinking about talking to customers instead of about the quality of the software.
Contradictory User Feedback Forces a Decision
Drivers ask for opposite things, and that is normal. Take the amount of information on the map. The app used to show every trip individually, with a lot of detail. Today it shows only the stops, and at each stop the driver can open another screen listing the individual customers.
The reactions differ. Some drivers are glad they can finally focus on what matters. Others badly want more information before they even reach the stop.
At this point, user feedback alone isn’t enough. The team has to decide which group to satisfy, and it uses safety and licensing rules to do so. MOIA isn’t allowed to stop everywhere. When someone else is already standing at the legal stop, the app needs a rule for where the vehicle goes instead. Cases like that have to be built into the app, whatever individual drivers might prefer.
Feedback Supplies the Arguments for the Roadmap
The hardest part isn’t collecting feedback but fitting it in. Together with the product owner, the driver feedback has to find its place in the roadmap alongside the wishes of other stakeholders, such as VW or senior management.
This is where the collected feedback pays off. When many drivers call a feature necessary, that is a solid argument for prioritizing it. In the end, business stakeholders and drivers want the same thing: more and better trips and a good customer experience, because that leads to repeat bookings.
“It helps a lot, and it brings exactly the arguments you need to deal with the challenges.”
(Ada Pohl)
Why Classic A/B Testing Is Hard Here
A/B testing at the driver level barely works at MOIA, because the app is rolled out per vehicle, not per driver. For data protection reasons, the navigation app doesn’t know which driver is using it at any given moment. That rules out a stable beta group of individual drivers.
Instead, MOIA relies on slow rollouts. A release starts on 20 percent of the vehicles, picked at random. If nothing negative comes back within two days, it goes to 50 percent, and after two more days to 100 percent. This works because all vehicles have the same equipment and the tablets stay fixed in the vehicle.
Random selection has its quirks. The 20 percent can include a vehicle that is sitting idle in the workshop and isn’t on the road at all.
A real beta setup is possible, but it takes a lot of work. For truly critical features, the team takes around 20 vehicles aside, updates them manually and lets only selected drivers use them. Because of the effort involved, that only pays off for features that are critical in some way.
The Test Environment Has Its Own Rules
A dedicated test environment also creates friction you wouldn’t see in live operation. If too many simulated vehicles sit in the same spot in the service area, the test drive doesn’t get the vehicle it needs for its trip.
The fix is pragmatic and very human. Someone posts a request in Slack asking colleagues to move their vehicles out of the area or simply switch off pooling. Without pooling, no trips come in and the test gets simpler again. Tricks like that are part of everyday work.
Where the Focus Is Shifting: AD Readiness
For the existing system, MOIA sees little need for more at the moment, because the process is well established. The focus is moving toward autonomous driving.
A test is planned in which a vehicle from VW and Mobileye drives through the city on its own. MOIA will build the connection between passenger and vehicle. Internally, this runs under the name AD Readiness, and a large share of current thinking goes into how to make it happen.
Frequently Asked Questions
Why do users of an internal business app often provide more feedback than customers of a public app?
Because they can’t switch to another app. Customers of a public app switch providers if they’re dissatisfied and don’t say anything. Drivers who have to use a navigation app during every shift have a vested interest in the tool working properly and are therefore willing to provide feedback. In 2023, MOIA’s driver app was only visible in the Play Store if you logged in with a company email address.
To what extent do regulatory requirements determine the requirements for a ridesharing app?
They help determine how the software behaves. MOIA was not a taxi company: Its license did not allow door-to-door trips; pickups were limited to digital stops within a 250-meter walking radius, as specified by the city. Where a vehicle is allowed to stop is therefore not a design decision, but a rule that must be reflected in the app.
How often is it worth collecting user feedback on an app?
On an ongoing basis rather than once a year. At MOIA, a driver survey was sent out monthly via newsletter, alternating between specific questions about features and open-ended questions about the biggest annoyances in their daily work. Mock-ups were created based on the trends identified and presented to individual drivers. After the release, a third round followed: Does the feature serve its purpose after some use?
What are the benefits of having developers and testers use the software themselves in real-world usage situations?
It reveals what remains invisible when working at a desk. Operating a navigation system with a simulated blue dot is different from sitting behind the wheel, and those who experience it firsthand make different decisions during implementation. At MOIA, testers drove the system themselves every two weeks before a release, while colleagues booked trips, always within a dedicated test environment.
Should test rides with real customers take place during live operations?
No. Transporting passengers requires a passenger transport license, and testers aren’t experienced drivers who can pay attention to both traffic and passengers at the same time. The added value of the method is lost as soon as the team starts thinking about customer communication instead of the quality of the software. That’s why, at MOIA, every test ride took place in a separate environment; real-world customer interactions were deliberately kept out of the process.
How do you handle conflicting user feedback?
You decide which group to serve based on additional criteria. When MOIA simplified the map to show stops instead of individual trips, some drivers welcomed the focus on the essentials, while others wanted more information even before the stop. Safety and licensing requirements were the deciding factors: Rules governing where a vehicle can divert must be built into the app, regardless of individual preferences.
How can a new version be rolled out with minimal risk if a beta group isn’t possible?
Through a phased rollout. At MOIA, a new version launched on 20 percent of randomly selected vehicles; after two uneventful days, 50 percent followed, and after two more days, 100 percent. A stable beta group of individual drivers wasn’t possible because the app ran at the vehicle level and, for data protection reasons, didn’t know who was currently operating it.
How can user requests be prioritized over stakeholder interests?
Collected feedback becomes a compelling argument. If many drivers identify a feature as necessary, that’s a solid reason to prioritize it in the roadmap. The more difficult task is not collecting feedback, but sorting through driver requests and stakeholder interests. Both sides share the same goal: more and better trips, a positive customer experience, and subsequent bookings.
