Ich habe den kompletten Buchungsflow für eine fiktive Marke, passo., neu gestaltet: Suche, Auto, Schutz, Extras, Checkout und Bestätigung. Angefangen hat es als Kursaufgabe meines UX-Zertifikats am UX Design Institute. Ich habe es bis zu einem getesteten Prototyp und einem finalen UI weitergeführt.

Umfang: Desktop-Buchungsflow, von der Suche bis zur Bestätigung.

Nicht im Umfang: mobiles Layout, Kundenkonto, Verwaltung bestehender Buchungen.

Umfang: Desktop-Buchungsflow, von der Suche bis zur Bestätigung.

Nicht im Umfang: mobiles Layout, Kundenkonto, Verwaltung bestehender Buchungen.

Das Problem

Die Leute haben kein Problem damit, für einen Mietwagen zu zahlen. Sie haben ein Problem damit, nicht zu wissen, was er wirklich kostet.

In fünf Usability-Tests auf sechs Mietwagen-Seiten tauchten immer wieder dieselben Reibungen auf: Details über mehrere Seiten verteilt, überraschende Weiterleitungen, vorausgewählte Optionen und Geldfragen, die bis zum Schluss offen blieben. Die Kaution war der deutlichste Fall.

«Würde die Filiale anrufen, wenn keine Angaben zur Kaution erscheinen.»

«Möchte alle Buchungsinfos an einem Ort.»

«Genervt, dass jede Änderung einen neuen Tab öffnet.»

(Sinngemäss wiedergegebene Beobachtungsnotizen aus den Sessions, keine wörtlichen Zitate.)

Problem Statement: Die wichtigsten Infos, allen voran Gesamtpreis und Kaution, sind verstreut oder ändern sich unterwegs. Die Leute verlieren das Vertrauen in die Buchung und greifen zur günstigsten Option.

Research & Discovery

Was ich gemacht habe

Fünf Usability-Tests auf sechs echten Mietwagen-Seiten, mit drei Teilnehmenden:

Was ich gemacht habe

Fünf Usability-Tests auf sechs echten Mietwagen-Seiten, mit drei Teilnehmenden:

Quelle

Seiten

Notizen

Kursaufnahme, beobachtet

Budget, Kayak, Hertz (eine Person)

Von mir moderiert

Europcar

Von mir moderiert

Sixt, Rentalcars.com (eine Person, eine Session)

143 Beobachtungen, 11 Themen. Jede Notiz landete in einem Affinity Diagram in Miro, mit KI-Hilfe geclustert und von Hand geprüft.

Affinity Diagram der Notizen aus den Usability-Sessions, in Clustern gruppiert

Cluster «Additional options»: Infos zur Kaution fehlten oder waren schwer zu finden.

Top 5 der Problemthemen, von 11 insgesamt

Buchungsflow und Informationsstruktur

Extras, Schutz und Zusatzleistungen

Navigation und Tab-Verhalten

Suche, Filter und Autowahl

Klarheit, Vertrauen und Begriffe

Preis (17) und Fahrzeugwünsche (15) fehlen hier: Sie beschreiben, was die Leute tun, nicht was schiefläuft.

Vier Muster stachen heraus:

1. Die Buchung ist verstreut.

⌄

Die Leute scrollten zurück, um ihre Daten zu prüfen, und wollten alle Buchungsdetails an einem Ort.

2. Weiterleitungen und neue Tabs zerstören Vertrauen.

⌄

Neue Tabs mit anderen Fotos, Preisen in USD oder einem geänderten Fahreralter waren der emotionalste Pain Point.

3. Schutz und Extras überfordern.

⌄

Zu viel Text, unklare Pakete und Extras, die sich nicht abwählen liessen.

4. Der Preis entscheidet, aber die Details fehlen.

⌄

Die Leute sortieren nach Preis und nehmen das günstigste Auto, wenn die Unterschiede unklar sind. Infos zur Kaution fehlten oder waren versteckt.

Insights & Design-Prinzipien

01. Eine Seite, von Anfang bis Ende.

⌄

Insight: Die Leute verlieren den Überblick, wenn Details über mehrere Seiten verteilt sind. Im Design: Datums-Pill im Header, Fortschrittsanzeige, fixierte Übersicht mit «Ändern»-Links.

02. Der Preis, den du siehst, ist der Preis, den du zahlst.

⌄

Insight: Vertrauen bricht, wenn sich der Preis ändert oder unvollständig ist. Im Design: Tagespreis und Gesamtpreis zusammen, Kaution vor der Zahlung, Rabatt fürs Vorauszahlen auf eigener Zeile.

03. Nichts wird für dich ausgewählt.

⌄

Insight: Vorausgewählte Standards fühlen sich an wie Kontrollverlust. Im Design: explizite Entscheidungen, «Inklusive» nur, wo es kostenlos ist, Extras als optionale Checkboxen.

UX-Prozess

Die Kette von der Research bis zum Screen:

Usability-Session

→

Affinity Diagram

→

User Journey

→

User Flow

→

Skizzen

→

Wireframes

→

Prototyp-Test

→

Iterationen

→

Finales Design

Usability-Session

Affinity Diagram

User Journey

User Flow

Skizzen

Wireframes

Prototyp-Test

Iterationen

Finales Design

User Journey

Ort & Daten

Autowahl

Extras

Schutz

Checkout

Emotion curve across the five booking phases: positive at location and dates, neutral at car selection, lowest at add-ons and protection, back to neutral at checkout

01 Ort & Daten

Ziel

Schnell einen Ort und Daten finden.

Pain Points

Weiterleitungen und neue Tabs, Buchungsdetails über mehrere Screens verteilt.

02 Autowahl

Ziel

Das günstigste passende Automatikauto.

Pain Points

Zu viele Optionen, unklare Unterschiede, kein Automatik-Filter.

03 Extras

Ziel

Überspringen, was man nicht braucht, Kosten tief halten.

Pain Points

Unklare Extras, Gebühren für CarPlay, Infos zur Kaution schwer zu finden.

04 Schutz

Ziel

Genug Schutz zum tiefsten Preis.

Pain Points

Zu viel Text, unklare Pakete, Optionen, die sich nicht abwählen lassen.

05 Checkout

Ziel

Schnell buchen, vor dem Bezahlen alles prüfen.

Pain Points

Überraschendes Zahlungs-Pop-up, Daten nicht gespeichert, keine Buchungsübersicht.

Ort & Daten. Ziel: schnell einen Ort und Daten finden. Pain Points: Weiterleitungen und neue Tabs, Buchungsdetails über mehrere Screens verteilt.

Die Tiefpunkte waren Extras und Schutz: Unklare Zusatzleistungen und Pakete liessen die Leute den Überblick über den Preis verlieren.

User Flow

Rund 20 Nutzeraktionen, jeweils dem Zustand des Screens gegenübergestellt, über sechs Seiten. Eine Änderung vom Flow zum Design: Der Schutz kommt jetzt vor den Extras, in der Reihenfolge, die man von anderen Mietwagen-Seiten kennt.

Der Flow hatte bereits geplant, was dem Prototyp später fehlte. Die Iterationen waren also eine Rückkehr zum Plan, keine neuen Ideen.

User Flow

Der Flow hatte bereits geplant, was dem Prototyp später fehlte. Die Iterationen waren also eine Rückkehr zum Plan, keine neuen Ideen.

Startseite, Teil 1: Abholort wählen.

Skizzen und Wireframes

Autodetails: Preis und Kaution auf der Karte.

Schritt 1: Suche und Daten

Prototyp-Test

Eine moderierte Session plus ein Review Screen für Screen. Die grössten Probleme brachen genau die Versprechen, auf denen das Design aufbaute.

Prototyp-Test

Eine moderierte Session plus ein Review Screen für Screen. Die grössten Probleme brachen genau die Versprechen, auf denen das Design aufbaute.

Iterationen

Der Test brachte vier Fixes, jeder verknüpft mit einem Versprechen des Designs: Die Kaution wanderte vom Checkout auf die Autokarte, die Summen stimmen jetzt auf jedem Screen und der Rabatt fürs Vorauszahlen steht auf einer eigenen Zeile, nur das kostenlose Schutzpaket heisst «Inklusive», und der Kalender zeigt korrekte Daten.

Iterationen

Finale Lösung

Vier zentrale Screens. Schutz und Extras sind oben als Wireframes zu sehen.

Die drei Versprechen aus der Research stehen direkt unter der Suche.

Startseite

Die drei Versprechen aus der Research stehen direkt unter der Suche.

Autowahl

• Specs in einer Zeile: Getriebe, Treibstoff, Sitze, Gepäck.

• Gesamtpreis und Kaution auf der aufgeklappten Karte.

• Ein Fortschrittsbalken durch die Buchung.

Checkout

• Die Übersicht bleibt sichtbar, und jede Position lässt sich ändern.

• Rabatt fürs Vorauszahlen auf eigener Zeile, Endbetrag auf dem Button.

Bestätigung

• Reservationsnummer, bezahlter Betrag, Kaution und Abholort.

Hinweis: Auto- und Hero-Bilder sind KI-generierte Platzhalter.

Validierung

Eine Session, eine Person. Klein, aber sie hat gezeigt, dass die erste Version ihre eigenen Versprechen gebrochen hat, vor allem bei Kaution und Preisen.

Als Nächstes: das finale Design mit 4 bis 5 Personen testen. Können sie Gesamtpreis und Kaution nennen, bevor sie bezahlen?

Reflexion

Ein Versprechen auf der Startseite ist eine Anforderung an jeden Screen. Eine falsche Summe genügt, um es zu brechen. Nächstes Mal prüfe ich jeden Screen vor dem Test gegen eine Checkliste der Prinzipien.

Kleine Research, konsequent genutzt. Jedes Prinzip und die meisten Iterationen gehen auf eine bestimmte Notiz zurück.

Konsistenz ist ein System, kein einzelner Durchgang. Auseinanderdriftende Kopien (Zeiten, E-Mail-Adressen, Summen) habe ich an der Wurzel behoben, mit gemeinsamen Komponenten und Variablen.

Socials

Navigation

Socials

Navigation

Fazit

Versteckte Kosten sahen aus wie ein Preisproblem. Es war ein Informationsproblem: Die Leute störte nicht der Preis, sondern dass sie ihn nicht sahen.

Nächster Schritt: die finalen Screens mit vier oder fünf Personen testen und eine Sache prüfen. Können sie sagen, was sie bezahlen, Kaution inklusive, bevor sie auf Bezahlen klicken?

Danke fürs Lesen.

Anhang: Designsystem

• Farben: Markengrün, Akzentgelb, Neutraltöne, Fehler und Erfolg, alle als Variablen.

• Typografie: Instrument Sans für Überschriften, Inter für Interface-Text.

• Komponenten: Buttons (primär, sekundär, ausgewählt, deaktiviert, Hover), Inputs (Standard, Hover, Fokus, ausgefüllt, Fehler), Chips, Karten.

• Abstände und Radien: 8 für Inputs und Buttons, 12 für Karten und Panels.

Color variables with names and hex values

Nächste Case Study

100 App-Store-Bewertungen codiert, um die Kosten der entfernten Live-Auslastung zu bestimmen. Daraus drei Designprinzipien und neue Flows für Homescreen, Check-in und Onboarding.

Zur PureGym-Case-Study →