Stell dir vor, du arbeitest im Kundenservice für eine große Campervermietung. Du musst einer Kundin mitteilen, dass sie auf ein anderes Modell umgebucht werden muss, da ihr gewünschter Camper 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:
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:
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
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 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
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.
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:
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.