Ich baue eine Finanz App, Tag 5

Es gab mal eine kleine App namens "Sit or Squat", die einem angezeigt hat, wo sich die nächste Toilette befindet. Sie war sehr erfolgreich, bis sie vom Toilettenpapier Hersteller "Charmin" gekauft wurde. Danach wollte sie keiner mehr haben.

Warum? Nun, Charmin hat sich entschlossen auf der Startseite der App den Geburtstag des Users abzufragen. Wenn das nicht angegeben wurde, kam man nicht weiter. Zu allem Überfluss war der Date Picker so kompliziert, dass man das Datum nicht eingeben konnte, nur hoch- und runterklicken. War man also 40 Jahre alt, musste man 40 mal klicken. Und das, wenn man aufs Klo muss und eigentlich nur wissen will wo die nächste Toilette ist. Wenn man ein zu junges Alter angegeben hat, kam eine Anzeige, dass man nicht alt genug sei um ein Klo zu vermittelt bekommen (potty trained). Ein Scherz? Keine Ahnung, aber der User muss immer noch aufs Klo.

Im nächsten Screen kam dann aber nicht der Service, sondern man musste die AGBs bestätigen. Im Anschluss sollte man sich mit seinem Facebook Account einloggen. Danach wurde man gefragt ob man seinen Toillettengang auf Facebook posten will (what???). Im Anschluss kam noch eine Werbung von Charmin. Dann wurde man gefragt ob die App das GPS verwenden darf. Und dann, ja dann endlich kam eine Karte die einem die nächsten Klos angezeigt hat. Bis dahin hat sich wahrscheinlich jeder zweite User in die Hose gepieselt.




Das ist eine schlechte User Experience (UX). Um das zu vermeiden muss man versuchen zu verstehen was der User eigentlich will. Warum benutzt er die App? Was ist sein Ziel? Außerdem sollte man diese Dinge auf dem Schirm haben:

Was will der User?
- er will es so einfach wie möglich
- er will sofort ein Ergebnis


Was will der User nicht?
- suchen
- warten
- lesen


Wie kann man das nun anwenden, wenn man eine App baut? In meinem Fall ist es eine ziemlich trockene Sache: Finanzplanung. Während ich das Wort geschrieben habe, bin ich kurz eingeschlafen. Der User der da kommt hat keinen Bock auf Zahlen. Und er hat keine Lust irgendwas verstehen zu müssen oder ein Wort zu lesen, das er nicht kennt. Deswegen erstmal der Grundsatz meiner Herangehensweise: Alles was nicht unbedingt benötigt wird fliegt raus.

- Login oder Registrierung? raus, zumindest am Anfang
- Steuer Thematiken? raus.
- API zum eigenen Konto? raus.
- Links zu Social Media? raus.


Außerdem schmeiß ich auch noch raus: Speicher Buttons.
Das ist im Web Bereich eher ungewöhnlich, kann man aber 2020 schon machen.
Um das zu tun, lege ich auf jedes Eingabefeld einen sog. Listener, das ist eine Art Wachhund. Wenn etwas eingegeben wurde, bellt er sofort und ich rufe die gleiche Funktion auf, die beim Klick auf den Speicher Button los rennt. Alles kommt weg. Alles was irgendwie komplex ist, übernimmt der Code. Das macht so vieles leichter. Zum Einen: Die App ist viel schneller gebaut. Für jeden Button und jedes Textfeld braucht man schließlich Funktionen und Validierungen usw. Bis ein Wort, das am Bildschirm eingetippt wird in der Datenbank gespeichert wird muss ich den Namen des Textfeldes in das es eingetippt wird sechsmal schreiben (Datenbank Schema, Frontend Datenset, Validierung, Komponente, API Frontend, API Backend). Und zurück nochmal dasselbe.

Aber der beste Effekt an dieser Herangehensweise: Man hat mehr Platz für das Wesentliche und der User findet sich schneller zurecht, wenn es weniger zum hinschauen gibt. Außerdem will er das Tool vielleicht mal auf dem Handy nutzen und dort gibt es nur sehr wenig Platz.

Außerdem soll der User nur eingeben müssen was unbedingt notwendig ist. Und sehr wichtig: Schon nach der ersten Eingabe soll der User sofort ein Ergebniss sehen. In meiner Liquiditätsplanungs-App (wieder eingeschlafen) bedeutet das: Gibt er z.B. als Erstes ein, wie viel Miete seine Wohnung pro Monat kostet, dann soll sich sofort die Grafik verändern und ihm anzeigen, dass er stufenweise jeden Monat weniger Geld auf dem Konto hat, wenn er nicht noch ein Einkommen eingibt, usw. Und das ohne auf einen Speicher Button zu klicken. Evtl. muss der Server hier hart arbeiten, aber lieber der Server als der User.

Seine Eingaben zeige ich ihm in einer Übersicht, die man sofort versteht. Erst wenn er die Details sehen will oder sie bearbeiten, dann sieht er mehr. Ungefähr so:




Allerdings ist damit noch nicht alles getan, ein gutes Interface gibt noch keine gute User Experience.




Ob meine Herangehensweise am Ende die richtige ist, kann ich beim besten Willen nicht sagen. Das kann am Ende nur der User entscheiden. Deswegen ist es so wichtig, immer wieder Feedback einzuholen ob man auf dem richtigen Weg ist. Zum Beispiel bei Menschen wie Dir, der den Artikel bis hierhin gelesen hat. Bitte sag mir immer, wenn ich auf dem Holzweg bin. Denn Du bist der User, für den ich die App am Ende baue.