AUF EINEN BLICK
Problem: Fahrstunden gibt es nur per Telefon zu Bürozeiten, sechs Standortkalender arbeiten nebeneinander her, und die Lern-App zeigt keinen Lernweg.
Mein Beitrag: Konzept für Buchungsportal, Lern-App und Kampagne und ein lauffähiger Prototyp des Buchungsportals, KI-gestützt umgesetzt und von mir geprüft.
Ergebnis: Regeln, die der Server verbindlich prüft, verständliche Fehlermeldungen, WCAG 2.2 AA als Grundlage und ein Pilotplan mit messbaren Zielen. Bewertung der drei Modulprüfungen: 100, 100 und 90 %.
Ein Fahrschulunternehmen mit sechs Standorten und rund 2.400 Fahrschüler:innen im Jahr vergibt Fahrstunden telefonisch, nur zu Bürozeiten und über sechs Kalender, die nichts voneinander wissen. Die hauseigene Lern-App DriveWords bereitet in zwölf Sprachen auf die Theorieprüfung vor, zeigt aber keinen Lernweg. Und für die Suche nach Fahrlehrkräften fehlt ein Auftritt, der zeigt, wie der Arbeitsalltag wirklich aussieht.
In meiner Weiterbildung zum UX Engineer für E-Learning und generative KI habe ich für dieses Szenario drei Bausteine entwickelt: ein regelbasiertes Buchungsportal, eine KI-gestützte Kommunikationskampagne und ein neues Lernkonzept für DriveWords. Das Buchungsportal habe ich zusätzlich als lauffähigen Prototyp umgesetzt.
Hinweis: Fallstudie aus meiner Weiterbildung mit fiktivem Unternehmensszenario. Alle Personen und Termine im Prototyp sind erfunden.
Ausgangslage
Fahrstunden lassen sich nur telefonisch und nur zu Bürozeiten buchen. Wer in der Schule oder in der Schicht ist, erreicht niemanden.
Sechs Standortkalender ohne gemeinsame Belegung führen zu Doppelbuchungen, freien Lücken und Leerfahrten zwischen weit entfernten Terminen.
Der Ausbildungsnachweis liegt auf Papier, Zusagen sind schwer prüfbar.
Website, Lern-App und Kursverwaltung haben keine gemeinsame Datenbasis.
Das Ziel: 20 % weniger unproduktive Fahrzeit und ein barrierefreier Auftritt nach WCAG 2.2 AA, auch mit Blick auf das Barrierefreiheitsstärkungsgesetz.
Meine Rolle
Ich habe die Fallstudie allein bearbeitet. Meine Aufgaben:
Regel- und Anforderungsanalyse: fünf Dispositionsregeln von der Getriebeart bis zur Tagesgrenze
Architektur und Schnittstellenentwurf: REST-API, Rollen und Rechte, tokenbasierte Anmeldung
UX/UI-Konzept mit barrierefreien Komponenten nach WCAG 2.2
Lauffähiger Prototyp, KI-gestützt mit Claude Code umgesetzt, von mir geprüft und getestet
Personas und Kampagne mit generativer KI, inklusive Quellenprüfung
Lernkonzept und Mock-ups für DriveWords in Figma
Echte Nutzer:innen standen in der Fallstudie nicht zur Verfügung. Grundlage waren der Unternehmenssteckbrief, die JIM-Studie 2025 zur Mediennutzung Jugendlicher und Fachliteratur zu Webentwicklung, Lernpsychologie und Learning Experience Design. Damit daraus keine Scheinsicherheit entsteht, habe ich jede Annahme als belegt, plausibel oder offen gekennzeichnet und für jeden Baustein festgelegt, wie sie im Betrieb überprüft wird.
Drei Personas
Lena, 17, Schülerin: will den Führerschein vor dem Schulabschluss, erreicht das Büro aber nur während des Unterrichts.
Tobias, 24, Berufseinsteiger im Schichtdienst: braucht Fahrstunden am Rand seiner Schichten.
Andrea, 46, Fahrlehrerin auf Stellensuche: will planbare Tage ohne Leerfahrten und einen Arbeitgeber, der das belegen kann.
Zentrale Erkenntnis: Frei ist nicht gleich buchbar
Ein Zeitfenster kann im Kalender frei und trotzdem nicht buchbar sein: weil der Standort nur Schaltwagen hat, weil die Folgestunde geografisch nicht passt oder weil die Person für diesen Tag schon genug Fahrzeit gebucht hat. Am Telefon löst die Disposition das im Kopf. Online muss das System diese Regeln kennen und erklären.
DriveWords: Inhalte, aber kein Lernweg
Die Ausgangslage der Lern-App zeigte fünf Lücken:
Kein sichtbarer Lernfortschritt
20 Fragen ohne Unterbrechung
Falsch beantwortete Fragen kehren nicht zurück
Audio ohne Wiederholung, Tempo oder Selbstaufnahme
Externe Videos ohne erfassten Fortschritt
Mein Gestaltungsziel: die extrinsische kognitive Belastung senken und den Wiedereinstieg nach Pausen erleichtern.
Sechs Entscheidungen prägen das Konzept. Die ersten vier betreffen das Buchungsportal, die letzten beiden Kampagne und Lern-App.
1. Die Regeln entscheidet der Server
Was sich geändert hat
Der Kalender zeigt nur noch Zeitfenster, die nach allen Regeln buchbar sind. Freie, aber nicht buchbare Fenster nennen den Grund, etwa „Diese Fahrlehrkraft hat zur selben Zeit bereits eine Fahrstunde“. Verbindlich entscheidet der Server: Er filtert das Angebot schon beim Abruf und prüft beim Buchen alle Regeln erneut.
Warum das wichtig ist
Die Oberfläche ist bequem, aber kein Sicherheitsnetz. Regeln lassen sich im Browser nicht umgehen, und alle Rollen sehen denselben gültigen Stand.
2. Konflikte erklären statt abweisen
Was sich geändert hat
Scheitert eine Buchung, nennt der Dialog alle Gründe auf einmal und markiert, welche sich nicht übersteuern lassen. Ändern zwei Personen gleichzeitig dieselbe Fahrstunde, bekommt die zweite eine klare Meldung statt eines stillen Überschreibens: „Diese Fahrstunde wurde inzwischen von jemand anderem geändert. Bitte neu laden und noch einmal ändern.“
Warum das wichtig ist
Wer versteht, warum etwas nicht geht, versucht nicht dreimal dasselbe und ruft nicht doch wieder im Büro an.
3. Jede Rolle sieht, was sie braucht
Was sich geändert hat
Fahrschüler:innen, Fahrlehrkräfte und Verwaltung arbeiten im selben Kalender mit unterschiedlichen Rechten. Die Zugriffskontrolle greift an der Schnittstelle, nicht nur in der Oberfläche. Einen zweiten Faktor verlangt das System nur für die Verwaltung, die den weitesten Zugriff hat. Fahrlehrkräfte dürfen Regeln im Einzelfall übersteuern, etwa in der Woche vor der Prüfung, und jede Übersteuerung wird protokolliert.
Warum das wichtig ist
Sicherheit dort, wo das Risiko liegt, und kein zusätzlicher Schritt für alle anderen.
4. Barrierefreiheit als Fundament
Was sich geändert hat
Die Kernkomponenten folgen den Erfolgskriterien der WCAG 2.2: Zeitfenster sind ohne Ziehbewegung wählbar und groß genug, Beschriftungen stehen über den Feldern, Hilfe findet sich immer an derselben Stelle, Buchungsbestätigungen werden für Screenreader angekündigt, und der Fokus ist jederzeit sichtbar. Ein automatisierter Test prüft die Kontraste aller Farbpaare, und die Oberfläche funktioniert auch in schmalen Fenstern.
Warum das wichtig ist
Barrierefreiheit ist hier Pflicht, nicht Kür. Und sie hilft allen, die unterwegs auf dem Smartphone buchen.
5. KI als Werkzeug mit Prüfpflicht
Was sich geändert hat
Personas und Kampagnenideen habe ich im Dialog mit KI entwickelt und jede Aussage als belegt, plausibel oder offen gekennzeichnet. Für die Bildmotive entstanden 16 Entwürfe mit vier Werkzeugen: ChatGPT, Gemini, Adobe Firefly und Canva. Wiederkehrende Fehler waren ein falsches Seitenverhältnis, zusätzliche Texte und erfundene Marken, erkennbare Gesichter trotz Ausschluss und veränderter Wortlaut.
Entscheidung
KI für Bildfindung und Varianten, finale Texte, Logos und Personen werden manuell geprüft. Die Kampagne „Abends buchen. Samstags fahren.“ zeigt reale Situationen statt Versprechen.
6. Ein Lernweg statt einer Inhaltssammlung
Was sich geändert hat
DriveWords setzt beim letzten Stand wieder ein und zeigt, was als Nächstes kommt. Begriffe werden zuerst gehört, dann gelesen und im Kontext der Fahrstunde angewendet, mit Wiederholung, Tempo 0,75× und Selbstaufnahme. Jede Antwort bekommt direktes Feedback mit Begründung, Fehlerthemen kehren früher zurück, und der Fortschritt ist je Kapitel sichtbar.
Bewusst weggelassen
Serien und Bestenlisten. Sie bestrafen Pausen und fördern Vergleich statt Lernen. Abzeichen gibt es nur, wenn sie an Lernziele gebunden sind.
Warum das wichtig ist
Wer neben Schule oder Schicht lernt, wird ständig unterbrochen. Der Lernweg muss Pausen aushalten, und jedes Element muss zum Verstehen beitragen, sonst erhöht es nur die Belastung.
Da es sich um eine Fallstudie handelt, gibt es noch keine Betriebsdaten. Das Ergebnis ist ein umsetzbares Konzept mit klaren Messgrößen und ein Prototyp, der zeigt, dass die Regeln tragen.
Lauffähiger Prototyp mit über 70 automatisierten Tests, die die Zusagen des Konzepts prüfen
Messgrößen für den Pilot: 20 % weniger unproduktive Fahrzeit. Die Quote der Übersteuerungen zeigt, wo eine Regel die Wirklichkeit falsch abbildet.
DriveWords: Erprobung über zwölf Wochen an einem Standort, mit Wiedereinstiegsquote, Lösungsquote im Wiederholungsversuch und einem klaren Abbruchkriterium
Empfohlene Reihenfolge: zuerst das Buchungssystem, weil es die Daten liefert, an denen sich alles Weitere messen lässt, dann DriveWords und zuletzt die Kampagne. Ein Arbeitgeberprofil sollte nur versprechen, was der Betrieb einlöst.
Bewertung in der Weiterbildung: 100 % (Webentwicklung), 100 % (generative KI) und 90 % (Educational UX)
Ein lauffähiger Prototyp macht Konzeptaussagen prüfbar. Erst im Prototyp wurde sichtbar, wie oft ein Zeitfenster frei, aber nicht buchbar ist, und dass die Oberfläche genau das erklären muss. Sonst wirkt das System willkürlich.
KI beschleunigt die Umsetzung enorm, gerade beim Prototyping. Die Verantwortung für Regeln, Sicherheit und Barrierefreiheit bleibt aber bei mir. Jede KI-Ausgabe braucht einen Prüfschritt, beim Code genauso wie bei Bildern und Texten.
Beim Lernen ist weniger mehr. Jedes Element muss zum Verstehen beitragen, sonst erhöht es nur die Belastung. Das gilt besonders für Gamification.
Ohne echte Nutzer:innen bleiben Personas Annahmen. Der nächste Schritt sind deshalb Gespräche an zwei Standorten und eine moderierte Beobachtung je Rolle, bevor das Konzept ausgebaut wird.
