Nutzerfeedback für eine Fahrer-App zu erheben bedeutet, die eigenen Fahrer systematisch als Hauptnutzer einzubinden. Dazu dienen monatliche Umfragen, strukturierte Interviews in drei Phasen sowie sogenannte Test Drives: Entwickler fahren selbst mit der App, um zu erleben, was am Schreibtisch unsichtbar bleibt. Ergebnisse fließen direkt in Priorisierung und Roadmap ein.
Das Wichtigste in Kürze
- MOIA betreibt einen vollständig integrierten Ridesharing-Service: eigene Fahrzeuge, eigene Apps, eigene Fahrer und selbst entwickelte Fahrzeuge in Kooperation mit VW.
- Die Fahrer-Navigationsapp ist ausschließlich intern verfügbar und im Play Store nur mit einer MOIA-E-Mail-Adresse sichtbar, was sie zu einer reinen Business Application macht.
- Feedback der Fahrer wird in einem dreistufigen Prozess erhoben: monatliche Surveys, vertiefende Interviews mit Mockups und abschließende Nutzungsprüfung nach dem Release.
- Test Drives alle zwei Wochen in einer eigenen Testumgebung stellen sicher, dass Entwickler die App selbst am Steuer erleben und nicht nur am Schreibtisch simulieren.
- Neue Releases werden per Slow Rollout ausgerollt: erst 20 Prozent der Fahrzeuge, dann 50 Prozent, dann 100, jeweils mit zwei Tagen Beobachtungszeit dazwischen.
Wenn die eigenen Kollegen die Nutzer sind
Bei MOIA ist die Tester-Zielgruppe für eine der Apps deckungsgleich mit den eigenen Angestellten: den Fahrern. Die Vehicle Guidance Application, das Navigationssystem für die Fahrer, läuft nur auf einem bestimmten Gerät und ist nicht einmal im Play Store sichtbar, wenn keine MOIA-E-Mail-Adresse vorliegt. Es ist eine reine Business-Anwendung, mit der niemand außerhalb des Unternehmens etwas anfangen könnte.
Daraus ergibt sich eine seltene Ausgangslage für die Qualitätsarbeit. Normale App-Kunden wandern ab, wenn ihnen etwas nicht passt, und geben kein Feedback. Die Fahrer können das nicht. Sie müssen mit der App arbeiten, jeden Tag, in jeder Schicht.
Genau deshalb wollen sie Feedback geben. Ada Pohl, Senior Quality Specialist bei MOIA, beschreibt diesen Wunsch als Glücksfall: Wer gezwungen ist, ein Werkzeug zu benutzen, hat ein echtes Interesse daran, dass es funktioniert. Dieses Interesse lässt sich systematisch anzapfen.
MOIA testet einen Full-Stack-Ridesharing-Service
MOIA ist ein Ridesharing-Service mit gepoolten Trips, eigenen Fahrzeugen und einer kompletten App-Landschaft. Der Kunde bucht in der App, sieht Preis und ungefähre Fahrtzeit, und ein Algorithmus sucht das passende Fahrzeug. Gepoolt wird mit anderen Kunden auf ähnlicher Route.
Das Unternehmen baut alles selbst und nennt sich darum Full-Stack-Ridesharing-Service. Die App des Kunden, das Navigationssystem für den Fahrer, ein weiterer Screen für die Kunden hinter dem Fahrer, dazu mehrere weitere Apps. Selbst die Fahrzeuge wurden mit VW entwickelt, vom Innenraum bis zu den Sitzen. Die Fahrer sind angestellt.
Für die Qualität gibt es ein eigenes Quality Chapter, verteilt auf mehrere Streamline-Teams. Jedes Team verantwortet einen Bereich. Die Fahrer-App testet, ob der Fahrer sauber mit dem Trip interagieren kann: Kunde aufgesammelt, Kunde abgesetzt, Kunde nicht erschienen.
Ein wichtiger Rahmen kommt von außen. MOIA ist kein Taxiunternehmen, die Konzession erlaubt keine Tür-zu-Tür-Fahrt. Abgeholt wird an digitalen Stops, die die Stadt vorgibt, im Fußwegradius von 250 Metern. Solche regulatorischen Grenzen sind kein Detail, sie bestimmen das Verhalten der Software mit.
Feedback einholen ist kein Jahresritual, sondern ein laufender Prozess
MOIA arbeitet mit mehreren Feedback-Kanälen parallel, statt einmal im Jahr eine Umfrage zu verschicken. Einmal im Monat geht ein Driver-Survey raus, per Newsletter mit Link. Die Fragen wechseln zwischen direkt und offen.
Mal wird konkret nach einem Feature gefragt: Funktioniert das noch für dich? Mal bewusst offener: Was stört dich gerade am meisten bei der Arbeit? Was fehlt dir? Brauchst du mehr oder weniger Information? Aus diesen Surveys ergeben sich Tendenzen, was benutzerfreundlich ist, was fehlt und welche Ideen die Fahrer selbst mitbringen.
Aus den Tendenzen wird in mehreren Stufen ein Feature. Erst alles an Wissen herausholen, dann Mock-ups bauen, damit zurück zu einzelnen Fahrern gehen und nachfragen. Danach ein erstes funktionierendes Feature bauen oder releasen, und erneut prüfen: Erfüllt es nach einiger Nutzung seinen Zweck, macht es das Leben leichter?
Die Stärke dieses Vorgehens liegt im Takt. Wer Nutzer früh und wiederholt einbindet, baut Features auf Belegen statt auf Vermutungen. Das verkürzt den Weg von der Idee zur brauchbaren Lösung.
Test Drives und Test Rides holen das Testen vom Schreibtisch ins Auto
Alle zwei Wochen vor einem Release setzen sich Tester selbst ans Steuer. Beim Test Drive nimmt das Team ein Fahrzeug und spielt selbst Fahrer, während Kollegen remote oder von der Rückbank Trips reinbuchen. Der Grund ist konkret: Ein Navigationssystem am Schreibtisch mit einem simulierten blauen Punkt zu bedienen, ist etwas völlig anderes, als hinter dem Lenkrad zu sitzen.
Auch das Mindset der Entwickler verschiebt sich dabei. Etwas am Schreibtisch zu implementieren oder selbst zu fühlen, wie sich die App im Fahren anfühlt, führt zu unterschiedlichen Entscheidungen.
Der zweite Modus ist der Test Ride. Hier wird ein echter MOIA gebucht, das Team setzt sich hinten rein und beobachtet den Fahrer. Sind keine Kunden dabei, kommen Fragen dazu. Ada vergleicht die Rolle mit der eines Barkeepers: einfach annehmen, was die Fahrer an Beschwerden und Pain Points mitbringen. Seit der Pandemie ist dieser Kanal durch viel Remote-Arbeit etwas verloren gegangen.
Wichtig: Beide Formate laufen in einer eigenen Testumgebung, nie im Produktivbetrieb. Personenbeförderung erfordert einen P-Schein, und das Team will die echte Kundenbeziehung bewusst draußen halten. Tester sind keine geübten Fahrer, die gleichzeitig auf Verkehr und Kunden achten. Der Mehrwert der Methode geht verloren, wenn die Tester über die Kundenkommunikation nachdenken statt über die Qualität der Software.
Widersprüchliches Feedback zwingt zur Entscheidung
Fahrer wünschen sich Gegensätzliches, und genau das ist normal. Ein Beispiel ist die Informationsdichte auf der Karte. Früher wurde jeder Trip einzeln angezeigt, mit viel Information. Heute zeigt die App nur noch jeden Stopp; am Stopp lässt sich ein weiterer Screen mit den einzelnen Kunden öffnen.
Die Reaktionen gehen auseinander. Manche Fahrer sind froh, sich endlich auf das Wesentliche konzentrieren zu können. Andere wollen unbedingt mehr Information, schon bevor sie am Stopp sind.
An dieser Stelle reicht Nutzer-Feedback allein nicht. Das Team muss entscheiden, welche Gruppe es glücklich macht, und zieht dafür Sicherheit und Konzession heran. MOIA darf nicht überall halten. Steht jemand am legalen Haltepunkt, braucht es eine Regel, wo das Fahrzeug stattdessen hinfährt. Solche Fälle müssen in die App, unabhängig davon, was sich einzelne Fahrer wünschen.
Feedback liefert die Argumente für die Roadmap
Die größte Herausforderung ist nicht das Sammeln, sondern das Einsortieren. Das Feedback der Fahrer muss zusammen mit dem Product Owner so in die Roadmap, dass es zu den Stakeholder-Wünschen passt, etwa von VW oder von weiter oben.
Hier wird das gesammelte Feedback zum Hebel. Wenn viele Fahrer ein Feature als notwendig benennen, liefert das ein belastbares Argument dafür, es zu priorisieren. Business-Stakeholder und Fahrer verfolgen am Ende dasselbe Ziel: mehr und bessere Trips und eine gute Experience für die Kunden, denn das führt zu Folgebuchungen.
Das hilft sehr, und es bringt genau die Argumente direkt mit, die man braucht, um die Herausforderungen zu bewältigen.
Ada Pohl
Warum klassisches A/B-Testing hier schwierig ist
A/B-Tests auf Fahrerebene funktionieren bei MOIA kaum, weil die App auf Fahrzeugebene ausgerollt wird, nicht auf Fahrerebene. Aus Datenschutzgründen weiß die Navigations-App nicht, welcher Fahrer gerade mit ihr unterwegs ist. Damit lässt sich keine stabile Beta-Gruppe einzelner Fahrer bilden.
Stattdessen setzt MOIA auf Slow Rollouts. Der Start liegt bei 20 Prozent, zufällig auf die Fahrzeuge verteilt. Kommt nach zwei Tagen nichts Negatives zurück, geht es auf 50 Prozent, nach weiteren zwei Tagen auf 100 Prozent. Das funktioniert, weil alle Fahrzeuge gleich ausgestattet sind und die Tablets fest im Fahrzeug bleiben.
Eine zufällige Verteilung hat ihre Tücken. Die 20 Prozent können auch ein Fahrzeug treffen, das gerade inaktiv in der Werkstatt steht und gar nicht auf der Straße ist.
Für ein echtes Beta-Setup bleibt nur der Aufwand. Bei wirklich kritischen Features nimmt das Team rund 20 Fahrzeuge heraus, updatet sie manuell und lässt nur bestimmte Fahrer damit fahren. Wegen des großen Aufwands lohnt sich das nur bei Features, die in irgendeiner Form kritisch sind.
Die Testumgebung hat ihre eigenen Spielregeln
Auch eine eigene Testumgebung produziert Reibung, die man im echten Betrieb so nicht kennt. Stehen zu viele simulierte Fahrzeuge am selben Ort in der Service-Area, bekommt der Test-Drive nicht das Fahrzeug, das er für seinen Trip braucht.
Die Lösung ist pragmatisch und sehr menschlich. Über Slack geht dann die Bitte raus, die eigenen Fahrzeuge aus dem Bereich wegzubewegen oder einfach das Pooling auszuschalten. Ohne Pooling kommen keine Trips an, und der Test wird wieder einfacher. Solche Tricks gehören zum Alltag dazu.
Wohin sich der Fokus verschiebt: AD-Readiness
Rund um das klassische System sieht MOIA aktuell wenig zusätzlichen Bedarf, weil der Prozess weit ausgearbeitet ist. Der Schwerpunkt verschiebt sich Richtung Autonomous Driving.
Geplant ist ein Test, bei dem ein Fahrzeug von VW und Mobileye selbstständig durch die Stadt fährt. MOIA entwickelt dann die Verbindung zwischen Passagier und Fahrzeug. Intern läuft das unter AD-Readiness. Ein Großteil der aktuellen Denkarbeit geht in die Frage, wie sich das umsetzen lässt.
