Fintech-UX: Wie gestaltet man Apps, die mit Geld arbeiten?

Kurz gesagt

Beim Design einer Fintech-App steuert eine einzige Frage jeden Screen: Kann der Nutzer auf diesem Screen Geld verlieren? Lautet die Antwort ja, braucht dieser Screen mehr Sorgfalt als die anderen.

Im Onlineshop das falsche Produkt in den Warenkorb zu legen, ist ein kleines Problem. Geld an eine falsche IBAN zu überweisen, kann dagegen zu tagelangem Aufwand werden. Die Aufgabe von Fintech-UX ist, diesen Unterschied ins Design zu übertragen.

Wenn ich mir ein Produkt ansehe, das mit Geld arbeitet, prüfe ich sechs Bereiche einzeln. Die Abschnitte unten folgen dieser Reihenfolge.

Womit Vertrauen entsteht

Nutzer vertrauen einem Fintech-Produkt, wenn sie bei jedem Tippen vorher wissen, was passiert. Auf einem Screen mit Geld erzeugt alles Unerwartete Unruhe.

Die erste von Jakob Nielsens 10 Usability-Heuristiken ist hier die Grundregel: Das System soll den Nutzer in angemessener Zeit und mit passender Rückmeldung darüber informieren, was gerade passiert. Auf Screens mit Geld heißt das konkret:

• Entgelte, Gebühren und Wechselkurs stehen auf dem Screen, bevor der Button gedrückt wird. Ein Entgelt, das erst auf dem Beleg auftaucht, reicht, damit der Nutzer diesem Screen nie wieder traut.
• Der Status der Transaktion wird klar benannt: überwiesen, ausstehend oder abgelehnt. „Ihr Auftrag wurde entgegengenommen“ sagt nicht, welcher der drei es ist.
• Der Kontostand aktualisiert sich direkt nach der Transaktion. Geht das nicht, steht der Grund auf dem Screen.
• Die Sprache bleibt schlicht. „1.500 € an Anna M. überwiesen“ ist kürzer als „Ihr Überweisungsauftrag wurde zur Ausführung angenommen“ und sagt mehr.

Noch etwas zerstört Vertrauen: Tricks in der Oberfläche, die den Nutzer lenken. Ein vorangekreuztes Versicherungskästchen oder ein versteckter Weg zur Kündigung bringen kurzfristig Umsatz und langfristig Beschwerden. Diese Muster beschreibe ich einzeln im Ratgeber zu Dark Patterns.

KYC und Authentifizierung

KYC (know your customer, „Kenne deinen Kunden“) ist der Prozess, in dem ein Finanzinstitut die Identität seiner Kunden prüft. Für den Nutzer heißt das, bei der Kontoeröffnung Ausweis und Gesicht in die Kamera zu halten. Manche Produkte ergänzen ein Videogespräch.

Im KYC-Schritt hat der Nutzer das Produkt meist noch gar nicht benutzt, gibt aber gerade jetzt die meisten Daten preis. Deshalb halte ich diesen Schritt für die empfindlichste Stelle des Onboardings. In meiner Arbeit achte ich auf Folgendes:

• Vor dem Start steht, was gebraucht wird: Ausweis und gutes Licht. So sucht niemand mittendrin seinen Ausweis.
• Jedes Dokument wird mit einem Satz begründet.
• Der Kamerascreen gibt Live-Rückmeldung: „Halten Sie den Ausweis näher an den Rahmen“, „Zu wenig Licht“. Nur „Prüfung fehlgeschlagen“ zu melden, lässt den Nutzer denselben Fehler wiederholen.
• Der Fortschritt wird gespeichert. Schließt sich die App, beginnt der Nutzer nicht von vorn.
• Für jemanden, der die Kamera nicht nutzen kann, gibt es einen anderen Weg, und er wird nicht versteckt.

Den Ablauf Schritt für Schritt beschreibe ich im Ratgeber zum KYC-Ablauf.

Login und Freigabe

In Deutschland regelt das Zahlungsdiensteaufsichtsgesetz (ZAG), wann eine starke Kundenauthentifizierung nötig ist. Nach § 55 Abs. 1 ZAG muss der Zahlungsdienstleister sie verlangen, wenn der Zahler online auf sein Zahlungskonto zugreift, einen elektronischen Zahlungsvorgang auslöst oder über einen Fernzugang eine Handlung mit Betrugs- oder Missbrauchsrisiko vornimmt.

§ 1 Abs. 24 ZAG definiert, was „stark“ heißt: mindestens zwei voneinander unabhängige Elemente aus den Kategorien Wissen, Besitz und Inhärenz. Für elektronische Fernzahlungen verlangt § 55 Abs. 2 ZAG außerdem Elemente, die den Vorgang dynamisch mit einem bestimmten Betrag und einem bestimmten Empfänger verknüpfen. Das ist keine Rechtsberatung; maßgeblich sind der aktuelle Text und Ihr Compliance-Team.

Für das Design ist dieser zweite Punkt ein Geschenk. Wenn die Freigabe ohnehin an Betrag und Empfänger hängt, zeigen Sie beides auch im Freigabescreen oder in der Push-Nachricht groß an. Der Nutzer gibt dann nicht „eine Zahlung“ frei, sondern „1.500 € an Anna M.“.

Die eigentliche Designfrage ist, wie sehr diese Sicherheitsschritte den Nutzer ermüden. Kriterium 3.3.8 der WCAG 2.2 (AA) ist hier deutlich: Laut der Erläuterung des W3C muss ein Bestätigungscode per SMS mindestens eingefügt werden können. Ein Dienst, der den Code zwingend von Hand abtippen lässt, erfüllt das Kriterium nicht.

Dieselbe Erläuterung nennt das Ausfüllen per Passwortmanager und Kopieren und Einfügen als Wege, das Kriterium zu erfüllen. Einfügen im Passwortfeld zu sperren, wirkt wie Sicherheit. Meiner Meinung nach drängt es Nutzer nur zu kürzeren, leicht zu merkenden Passwörtern.

Auch die Sitzungsdauer gehört hierher. Wer kurz die Rechnungsnummer sucht und zurückkommt, verliert alles Eingegebene, wenn die Sitzung inzwischen abgelaufen ist.

Kriterium 2.2.1 der WCAG 2.2 (A) beschreibt dafür einen Weg: Der Nutzer wird gewarnt, bevor die Zeit abläuft. Er bekommt mindestens 20 Sekunden, um die Zeit mit einer einfachen Aktion zu verlängern.

Bestätigen und Rückgängig bei Geldflüssen

Auf dem Überweisungsscreen fangen zwei Werkzeuge Fehler ab: Bestätigung und Rückgängig. Die Bestätigung versucht, den Fehler vor der Ausführung abzufangen. Rückgängig gibt dem Nutzer einen Ausweg, nachdem der Fehler passiert ist.

Nielsens dritte Heuristik verlangt diesen Ausweg: Nutzer tun oft versehentlich etwas und sollten eine ungewollte Aktion ohne langen Prozess verlassen können. Die fünfte Heuristik dreht sich um Fehlervermeidung: fehleranfällige Bedingungen beseitigen oder vor der Aktion eine Bestätigung einholen.

Kriterium 3.3.4 der WCAG 2.2 (AA) schreibt das für finanzielle Transaktionen ausdrücklich vor. Auf einer Seite, die im Namen des Nutzers eine finanzielle Transaktion ausführt, muss mindestens eines davon gelten:

• Die Übermittlung lässt sich rückgängig machen.
• Die Eingaben werden auf Fehler geprüft, und der Nutzer bekommt Gelegenheit, sie zu korrigieren.
• Vor dem endgültigen Abschluss gibt es die Möglichkeit, die Angaben zu prüfen, zu bestätigen und zu korrigieren.

Wie ein Bestätigungsscreen funktioniert

Nielsen schreibt in seinem Artikel über Bestätigungsdialoge: Wer bei jeder Aktion nachfragt, bringt Nutzern bei, ohne Lesen weiterzuklicken. Deshalb schützt ein allgemeiner Dialog „Sind Sie sicher?“ niemanden.

Seine Empfehlungen passen genau auf Fintech. Der Bestätigungsscreen wiederholt die Absicht des Nutzers mit erkennbaren Details. Statt „Ja / Nein“ tragen die Buttons Labels, die sagen, was passiert.

Im Artikel steht auch ein Bankbeispiel. Eine Bestätigung könnte nur bei Zahlungen verlangt werden, die mindestens doppelt so hoch sind wie die üblichen Zahlungen des Nutzers. Nielsen fügt hinzu, dass diese Schwelle nur ein Beispiel ist und der echte Wert aus der Nutzerforschung kommen muss.

Bei einer Überweisung muss der Nutzer zwei Dinge prüfen: an wen und wie viel. Beides gehört an die sichtbarste Stelle des Screens.

• An wen: Niemand liest eine IBAN Zeichen für Zeichen, aber den maskierten Namen des Kontoinhabers erkennt man auf einen Blick. In Großbritannien läuft seit 2020 ein Namensabgleich namens Confirmation of Payee. Pay.UK beschreibt ihn als Dienst, der fehlgeleitete Zahlungen verringern soll.
• Wie viel: Der Betrag steht groß und wiederholt sich im Button. Liegt er außerhalb des Üblichen, kommt eine eigene Warnung.

Frist zum Rückgängigmachen

Nielsen schreibt im selben Artikel, dass Bestätigungsdialoge den Arbeitsfluss bremsen. Er empfiehlt, viel Aufwand in eine Rückgängig-Funktion zu stecken.

Geht das Geld sofort auf das Empfängerkonto, bleibt für Rückgängig kein Platz. Rückgängig ist nur möglich, wenn die Überweisung kurz zurückgehalten wird.

Diese Wartezeit ist eine Produktentscheidung und passt nicht zu jeder Transaktion. Ich finde, dass ein paar Sekunden beim Überweisen an einen gespeicherten Kontakt kaum stören. Für einen Tippfehler reichen sie aber.

1. EmpfängerIBAN oder gespeicherten Kontakt wählen.
2. NamensabgleichDer maskierte Name des Kontoinhabers wird gezeigt.
3. Betrag wiederholenDer Betrag steht groß, bei Ungewöhnlichem kommt eine Warnung.
4. Senden und wartenEine kurze Frist zum Rückgängigmachen beginnt.
5. BelegMitteilung und Umsatzverlauf zeigen dieselbe Information.

Abbildung: Fünf Stellen, an denen der Nutzer bei einer Überweisung einen Fehler bemerken kann. Die Reihenfolge ist mein Vorschlag.

Bestätigungsscreen einer Überweisung

Zwei Bestätigungsscreens für dieselbe Überweisung, untereinander. Der Nutzer wollte 1.500 € eingeben und hat eine Null zu viel getippt.

ÜberweisenBestätigung

IBAN EmpfängerDE89 3704 0044 0532 0130 00

VerwendungszweckMiete

Betrag: 15.000,00 €. Es können Entgelte anfallen.

Bestätigen

Fehlerhafte Version

• Auf dem Screen steht nur die IBAN. Niemand liest 22 Zeichen einzeln, der Nutzer sieht nicht, an wen das Geld geht.
• Der Betrag steht klein und grau in einem Satz. Eine Null zu viel fällt nicht auf.
• Der Button sagt „Bestätigen“. Er sagt nicht, was Sie bestätigen.
• Nach dem Tippen geht das Geld sofort raus. Es gibt keinen Weg zurück.

ÜberweisenBestätigung

Name des Kontoinhabers AN** MÜL**** DE89 3704 0044 0532 0130 00 Der Name kommt aus den Daten der Empfängerbank. Kennen Sie die Person nicht, überweisen Sie nicht.

Betrag 15.000,00 € Fünfzehntausend Euro Entgelt: 0,00 €

An diese Person haben Sie bisher höchstens 1.500 € überwiesen. Prüfen Sie den Betrag noch einmal.

15.000 € überweisen Betrag korrigieren

Gute Version

• Der Name des Empfängers ist maskiert, aber erkennbar. Der Nutzer sieht auf einen Blick, an wen er überweist.
• Der Betrag steht groß in Ziffern und darunter noch einmal in Worten. Für einen ungewöhnlichen Betrag gibt es eine eigene Warnung.
• Der Button sagt, was passiert: Betrag und Aktion. Daneben gibt es einen Weg, den Betrag zu korrigieren.
• Die Überweisung wird kurz zurückgehalten. In dieser Zeit lässt sie sich mit „Rückgängig“ abbrechen.

Screens, Bank und Namen sind erfunden. Szenario: Der Nutzer wollte 1.500 € eingeben und hat eine Null zu viel getippt. Wechseln Sie zwischen fehlerhafter und guter Version und tippen Sie auf die Buttons. In der guten Version wird die Überweisung 10 Sekunden zurückgehalten und lässt sich abbrechen.

Auf beiden Screens stehen IBAN und Betrag. Der Unterschied ist, wo und wie groß diese Information steht. Auf dem fehlerhaften Screen ist der Betrag da, fällt aber nicht ins Auge.

Fehlervermeidung

Bevor Sie eine Fehlermeldung schreiben, versuchen Sie, den Fehler zu verhindern. Page Laubheimer beschreibt in seinem NN/g-Artikel Wege, unbewusste Ausrutscher zu vermeiden, also Fehler aus Unachtsamkeit. Auf Screens mit Geld sieht das so aus:

• Einschränkungen. Wenn die zulässigen Werte feststehen, begrenzen Sie die Eingabe. Eine deutsche IBAN beginnt mit „DE“ und nimmt keine Zeichen zu viel an. Ist der Betrag höher als der Kontostand, wird der Nutzer gewarnt, bevor er den Button drückt.
• Flexibles Format. Der Nutzer kann die IBAN mit oder ohne Leerzeichen einfügen. Das System bereinigt das im Hintergrund und zeigt keinen Fehler. Auch eine Telefonnummer formatiert sich beim Tippen.
• Gute Voreinstellungen. Die letzten Empfänger stehen oben in der Liste. Niemand tippt jeden Monat dieselbe IBAN neu.
• Vorschläge. Gespeicherte Kontakte werden beim Tippen vorgeschlagen. Der Nutzer erkennt, statt sich zu erinnern.

Dazu kommt das Problem der doppelten Überweisung: Ist das Netz langsam, drückt der Nutzer ein zweites Mal auf „Überweisen“. Der Button muss nach dem ersten Tippen sofort in den Zustand „Wird überwiesen“ wechseln und kein zweites Tippen annehmen. Dieselbe Transaktion darf unter keinen Umständen zweimal rausgehen.

Für den Rest des Formulars gelten die Regeln aus dem Formulardesign auch hier. Das Label steht über dem Feld, der Fehler direkt darunter und sagt, was zu tun ist.

Mitteilungen

Im Fintech-Bereich gehört die Transaktionsmitteilung zur Transaktion selbst. Verlässt Geld das Konto, sollte der Nutzer das erfahren, ohne die App zu öffnen. Wer an der ersten Mitteilung eine Transaktion erkennt, die er nicht gemacht hat, kann seine Karte sofort sperren.

Meine Checkliste für eine gute Transaktionsmitteilung:

• Betrag und Währung.
• Gegenseite: der erkennbare Name des Empfängers oder Händlers.
• Status: überwiesen, ausstehend oder abgelehnt.
• Was der Nutzer tun soll, wenn er die Transaktion nicht kennt, und wie das mit einem Tippen geht.

Transaktionsmitteilungen in denselben Kanal wie Werbemitteilungen zu legen, ist ein Fehler. Um die Werbung loszuwerden, schaltet der Nutzer vielleicht alle Mitteilungen ab und bemerkt dann eine Abbuchung zu spät. In den Einstellungen müssen sich beide Arten getrennt abschalten lassen.

Mitteilung und App müssen dasselbe sagen. Steht in der Mitteilung „überwiesen“ und im Umsatzverlauf „ausstehend“, weiß der Nutzer nicht, was er glauben soll.

Barrierefreiheit

Auch wer schlecht sieht oder einen Screenreader nutzt, bezahlt Rechnungen. Eine nicht barrierefreie Finanz-App zwingt diese Person, um Hilfe zu bitten. Bei Geld heißt Hilfe holen manchmal, das Passwort mit jemand anderem zu teilen.

Die WCAG-2.2-Kriterien von oben habe ich in einer Tabelle zusammengefasst.

Kriterium	Stufe	Bedeutung im Fintech-Bereich
3.3.4 Fehlervermeidung (rechtlich, finanziell, Daten)	AA	Die Überweisung lässt sich rückgängig machen, wird geprüft oder vor dem Absenden überprüft.
3.3.8 Barrierefreie Authentifizierung	AA	Der SMS-Code lässt sich einfügen, der Passwortmanager funktioniert.
2.2.1 Zeitbegrenzungen anpassbar	A	Vor Ablauf der Sitzung kommt eine Warnung, die Zeit lässt sich mit einer einfachen Aktion verlängern.
4.1.3 Statusmeldungen	AA	Die Meldung „Überwiesen“ erreicht den Screenreader, ohne dass der Fokus wandert.

Diese vier Kriterien sind nur ein Anfang. Grundlegende Kriterien wie Kontrast, Tippbereich und Tastatur beschreibe ich im WCAG-Ratgeber.

Beim Countdown in der Demo habe ich an 4.1.3 gedacht. Die Zeit steht als Text auf dem Screen und wird zu Beginn einmal an den Screenreader gemeldet. Würde jede Sekunde angesagt, hörte der Nutzer nichts anderes mehr.

Meine Notiz

Ein Problem, das ich in Fintech-Produkten oft sehe: Die Last der Sicherheit trägt der Nutzer. Codes, die sich nicht einfügen lassen, oder Meldungen wie „Transaktion abgelehnt“ ohne Grund sind Beispiele dafür. Das Team verteidigt sie als Sicherheit, der Nutzer erlebt sie als Hindernis.

Meine Regel: Jeder Sicherheitsschritt sagt dem Nutzer, warum er da ist. Über einen Screen, der sagt „Dieser Betrag ist höher als üblich, deshalb fragen wir noch einmal nach“, ärgert sich niemand. Man ärgert sich über Hindernisse ohne Begründung.

Meine zweite Regel: Dem Bestätigungsscreen widme ich mehr Zeit als den anderen Screens. Der Nutzer bleibt dort nur ein paar Sekunden, aber dort passieren die teuersten Fehler. Wenn ich ein Fintech-Produkt im End-to-End-Audit prüfe, teste ich die Überweisungsbestätigung immer eigens, mit echten Beträgen.