Fallstudie: UX-Optimierung eines komplexen Buchungsmodals

Portrait of Christian Reichart

Zusammenfassung: Durch das Verstecken von unwichtigen Informationen, Reduzierung von Komplexität und die klare Kommunikation von Resultaten konnte die Fehlerquote bei Buchungsanpassungen drastisch reduziert werden.

Stell dir vor, du arbeitest im Kundenservice für eine große Fahrzeugvermietung. Du musst einer Kundin mitteilen, dass sie auf ein anderes Modell umgebucht werden muss, da ihr gewünschter Fahrzeug nicht verfügbar ist. Die Person entscheidet sich dafür, die gesamte Buchung zu stornieren, da sie mit dem neuen Modell nicht zufrieden ist. Als du diesem Wunsch in der internen Software nachkommen und die Buchung kostenfrei stornieren willst, wird dir folgendes Modal präsentiert:

Altes Modal einer internen Administrationssoftware, das bei Stornierungen angezeigt wurde
Altes Modal einer internen Administrationssoftware, das bei Stornierungen angezeigt wurde

Wüsstest du intuitiv, was beim Bestätigen des Modals passieren würde? Wenn du diese Frage verneinen musst, dann geht es dir ähnlich wie den Anwendern der Software, in der dieses Modal zum Einsatz kam. Das Team hat sich untereinander geschult und in internen Dokumenten mit Screenshots ausführlich dokumentiert, wann welcher Knopf zu drücken ist, um diesen Arbeitsschritt einigermaßen verständlich zu halten.

Neben der reinen Komplexität des Modals kam zu einem bestimmten Zeitpunkt auch noch ein unregelmäßig auftretender, fataler Softwarefehler hinzu, der zu falsch versendeten E-Mails und schwer korrigierbaren Fehlern in der Datenbank führte. Das alles endete letztlich darin, dass die Interaktion mit diesem Screen große Unsicherheit und regelrechten Stress auslöste, und damit eine Neugestaltung des Prozesses dringend notwendig machte.

Keine Zeit, weiter zu lesen? Hier ist das Endergebnis der Neugestaltung:

Überarbeitetes Modal mit Fokus auf Bedienbarkeit und Verständlichkeit
Überarbeitetes Modal mit Fokus auf Bedienbarkeit und Verständlichkeit

Eine genaue Aufschlüsselung der einzelnen Überarbeitungsschritte und deren Auswirkungen zeige ich dir im folgenden Deep-Dive. 🤿

Der Differenzbereich - zu viel Information überfordert die Anwender

Der Differenzbereich des alten Modals, der mit Informationen überladen ist
Der Differenzbereich des alten Modals, der mit Informationen überladen ist

Dieser Bereich schlüsselt extrem detailliert und technisch alle relevanten Beträge auf, die zur Buchungsänderung gehören. Links sieht man die reine Vorher-Nachher-Auflistung der Änderung, rechts werden noch andere relevante Summen, wie bereits bezahlte oder in Rechnung gestellte Beträge aufgelistet – sehr überfordernd, und in den meisten Fällen nicht wirklich relevant. Letztendlich wichtig ist im Prinzip nur die Gesamtdifferenz der Änderung, denn diese ist die Grundlage für die weitere Abhandlung.

Aus diesem Grund habe ich diesen Bereich zu einer klassischen Ausklappsektion umgestaltet. Alle detaillierten Informationen sind immer noch da, falls sie einmal aus Gründen der Nachvollziehbarkeit benötigt werden, nur eben versteckt.

Der Differenzbereich reduziert auf das nötigste, ausklappbar für Sonderfälle
Der Differenzbereich reduziert auf das nötigste, ausklappbar für Sonderfälle

Der Aktionsbereich - Kryptische Button-Bezeichnungen und unklare Resultate

Sicherlich hast du dich schon gefragt, was die kryptischen Zahlen-Buchstaben-Kombination in der Mitte des Modals zu bedeuten haben. Eine Verringerung des Buchungswerts kann auf drei verschiedene Arten abgehandelt werden:

  • Rückerstattung (Refund)
  • Gutschein (Coupon)
  • Stornierungsgebühr (Fee)

Je nach ausgewählten Stornierungsbedingungen und Zeitpunkt der Buchungsänderung kann es auch eine Kombination aus mehreren Arten sein, z.B. 50% des Buchungswerts als Rückerstattung, und 50% als Gutschein. Die Bezeichnungen stehen also für die Auflösungsart der Differenz:

  • 100R bedeutet 100% Refund
  • 50R/50C bedeutet 50% Refund und 50% Coupon
  • 100C bedeutet 100% Coupon
  • … und so weiter

Der Aktionsbereich des alten Modals mit kryptischen Button-Bezeichnungen
Der Aktionsbereich des alten Modals mit kryptischen Button-Bezeichnungen

Ein Klick auf einen dieser „Codes“ verändert die absoluten Werte in den ausgegrauten Eingabefeldern darunter und bestimmt damit letztendlich, wie der Buchungswert verrechnet wird. Ja, richtig gelesen, die wichtigste Information des ganzen Modals, nämlich was nach dem Bestätigen passiert, befindet sich in diesen extrem schwer lesbaren Eingabefeldern. Standardmäßig sind diese nämlich nicht bearbeitbar, nur der „Manual override“ ermöglicht die Eingabe eigener Werte.

Diese sagen wir „gewöhnungsbedürftige“ UI habe ich durch eine klare Frage und einen Tab-Switcher ersetzt.

Alle Optionen des neuen Aktionsbereichs
Alle Optionen des neuen Aktionsbereichs

Um Fehler zu vermeiden, ist standardmäßig keine Option vorausgewählt. Die Anwenderin muss sich bewusst für eine Abhandlung entscheiden, bevor sie die Aktion abschließen kann.

Die erste Option „As Booked“ handelt den Differenzbetrag ohne weiteres Zutun nach den gebuchten Stornierungsbedingungen ab. Möchte der Kundenservice aus Kulanzgründen von dieser Regelung abweichen, sind die häufigsten Arten davon die komplette Rückerstattung oder die Ausstellung eines Gutscheins. Für alle anderen Sonderfälle gibt es den Tab „Custom“, hinter dem sich die bekannten Eingabefelder verbergen.

Der Abschlussbereich - „Cancelling the Cancel“

Ein letztes UX-Problem gab es noch zu lösen. Normalerweise nutzt die Anwendung das Wort „Cancel“, um eine Aktion abzubrechen. Im Falle einer „Cancellation“ jedoch ist „Cancel“ ja eigentlich das richtige Wort, um den Vorgang zu bestätigen. Die Lösung war hier, in diesem speziellen Fall mit einem alternativen Wort „Abort“ zu arbeiten, um Verwirrung zu minimieren.

Hier siehst du nochmal das komplette überarbeitete Modal:

Das komplett überarbeitete Modal mit Fokus auf Bedienbarkeit und Verständlichkeit
Das komplett überarbeitete Modal mit Fokus auf Bedienbarkeit und Verständlichkeit

Nachdem die Neugestaltung von mir umgesetzt wurde und ins Produktivsystem eingeflossen ist, haben sich die Nutzungsfehler bei Buchungsanpassungen/Stornierungen drastisch reduziert und damit das Service-Team stark entlastet und ihnen das Vertrauen in die Software zurückgegeben.

Auch das Technik-Team, welches für die manuellen Fehlerbehebungen in der Datenbank verantwortlich war, hat von der geringen Fehlerquote profitiert. Statt wie vorher ca. drei bis fünf Fehler pro Monat in der Hochsaison beheben zu müssen, waren es nach der Neugestaltung nur noch zwei bis drei pro Jahr, und das auch nur aufgrund von extremen Sonderfällen.

Kein Anmelden nötig 🤯