Oder wie ich dazu kam, eine Anrufliste zu bauen, um festzustellen, dass ich sie eigentlich gar nicht wollte. Und was ich als Entwickler dabei über UX-Design gelernt habe.

Wegen einer fehlenden Mobilfunk-Flatrate kam ich vor einiger Zeit dazu, den Festnetzanschluss meiner DSL-Leitung nicht nur zu bezahlen, sondern ihn tatsächlich auch als solchen zu benutzen. Weil es ein VoIP-Anschluss war und ich keine passende Hardware zur Hand hatte, entschied ich mich für eine Software-Lösung in Form eines Raspberry Pi mit Asterisk Server und dazu einer App, um mein Smartphone quasi als Telefon zu nutzen. So weit, so einfach (mehr oder weniger jedenfalls).

Der einzige Haken an dieser Lösung war, dass ich verpasste Anrufe nur dann sehen konnte, wenn mein Smartphone während des Anrufs mit der Anlage verbunden war. Die gesamte Anrufhistorie konnte ich zwar per SSH-Verbindung auf dem Pi in einer SQL-Tabelle einsehen, das schien mir langfristig aber nicht besonders erfreulich. Also kam mir die Idee, die Daten in einer Weboberfläche anzuzeigen.

Die Wahl der Technologie richtete sich eher danach, was mir für das derzeitige Kundenprojekt hilfreich erschien, als nach den tatsächlichen Anforderungen der Anwendung. Deshalb fiel die Wahl auf Angular mit Material im Frontend und Spring Boot im Backend.

1. Iteration – viel Potential für Verbesserung

Wenn man als Entwickler Daten anzeigen will, die in einer relationalen Datenbank gespeichert sind und keine klare Vorstellung der Oberfläche hat, neigt man schnell dazu, die Daten auch tabellarisch anzuzeigen. Das ist auch genau, was ich hier zuerst gemacht habe.

In dieser ersten Version der Anwendung sind im Gegensatz zum direkten Blick in die Datenbank immerhin Zeit- und Datumswerte sinnvoll formatiert. Außerdem sind die Anrufrichtung und ob abgenommen wurde in Form eines farbigen Icons dargestellt. Trotzdem könnte man sagen, dass es sich im Wesentlichen um dieselbe Tabelle handelt – nur in bunt.

2. Iteration – Grobe Aufräumarbeiten

Was mich in der ersten Version am meisten gestört hat, war, dass für jeden Anruf beide beteiligten Nummern angezeigt wurden. Da eine davon immer dieselbe (nämlich meine eigene) war, hat sich der Informationsgewinn durch die zusätzlich angezeigten Daten in Grenzen gehalten. Und weil nach source und destination unterschieden wurde, hat sich die relevante Nummer je nach Anrufrichtung in einer anderen Spalte befunden.

Nur noch die fremde Nummer anzuzeigen, bringt sofort einen Gewinn. Informationen, die aus Nutzersicht gleichartig sind, befinden jetzt immer in einer Flucht – nicht mehr im Zickzackmuster. Außerdem wurde das Icon-Set gewechselt. Wo vorher eigentlich als login/logout gedachte Icons umfunktioniert wurden, finden sich jetzt die „echten“ Anruf-Icons von Material Design. Ein erster Schritt hin zu einer gewohnteren Ansicht.

Eher in den Bereich UI als UX fällt in dieser Änderung noch, dass der Schatten der Tabelle entfernt wurde. Wovon sollte die Tabelle hier durch einen Rahmen oder Schatten abgegrenzt werden? Und um unmissverständlich klar zu machen, was der Nutzer hier vor sich sieht, wurde eine Überschrift hinzugefügt.

3. Iteration – So, wie man es kennt

Auch nach der zweiten Iteration hatte die Anrufliste noch eine leicht technische Anmutung. Das wäre vielleicht in Ordnung, wenn es eine Anwendung für Callcenter-Mitarbeiter wäre. Die bräuchten vermutlich viele Informationen auf einen Blick und wären mit so einer Ansicht happy. Nun bin ich in diesem Fall nicht so ein Power-User, sondern gucke eher alle paar Tage einmal für höchstens einige Minuten in die Anwendung. Und die hatte bisher wenig gemein mit dem, wie andere Anruflisten aussehen, die ich nutze. Aber warum eigentlich? Wäre es nicht einfacher, wenn diese Anrufliste ähnlich aussieht wie andere Anruflisten auch? Versuch macht klug.

Diese Iteration hat dementsprechend eine große Ähnlichkeit mit den für mich gewohnten Anruflisten. Konkret mit der Telefon-App und der VoIP-App auf meinem Smartphone, vermutlich aber auch mit denen anderer Hersteller. Wenn ich zum Beispiel vorher in die VoIP-App auf meinem Smartphone geschaut habe, erleichtert es mir diese Ansicht, schnell zu erkennen, ob sich Anrufe in der Liste befinden, die nicht bei mir angekommen sind. Die Tabellenstruktur ist komplett weggefallen und plötzlich funktioniert die Seite auch gut auf dem Smartphone. Überschriften für die einzelnen Daten (wie vorher in der Tabelle) sind gar nicht notwendig, weil das gewohnte Layout recht selbsterklärend ist.

4. Iteration – Neue Anforderungen abdecken

Beim Nutzen der mittlerweile recht passablen Anrufliste begann ich mich zu fragen, wie ich die Anlage eigentlich nutze. Zum Beispiel, mit wem und wie lange ich damit telefoniere – natürlich nicht davon ausgehend, dass die Sprechzeit auch nur ansatzweise an den Arbeitsaufwand für die Weboberfläche oder die initiale Konfiguration der Anlage heranreichen würde. Aber ein bisschen sollte ja auch der Weg das Ziel sein und dass ich irgendwas dabei lernen würde, hatte ich schon gehofft.

Diese Iteration erfüllt nun also Anforderungen, die sich überhaupt erst durch die Benutzung der Anwendung ergeben haben. Einen so kurzen und direkten Kommunikationsweg zum Anwender – und dadurch die Möglichkeit, quasi in Echtzeit auf neue Anforderungen zu reagieren – findet man in Kundenprojekten eher selten.

5. Iteration – Die Grundidee nachschärfen

Was sich nach dem Hinzufügen der neuen Features nicht geändert hatte, war, dass ich immer noch selbst die Anrufliste durchgehen musste, um festzustellen, ob sich ein neuer verpasster Anruf darin fand. Und nachdem mir die Anwendung abgenommen hatte, mitzuzählen, mit wem ich wie oft und wie lange telefoniere, wurde das etwas trist und langweilig.

Dabei kam mir eine verrückte Idee, nämlich die Information, ob neue entgangene Anrufe vorliegen, separat anzuzeigen. Wenn schon neue Anwendungsfälle durch weitere Features abgedeckt werden, warum dann nicht auch der ursprüngliche, der überhaupt erst Grund war, die Anwendung zu bauen?

Weil es eben der Hauptanwendungsfall ist, wird der Zähler der entgangenen Anrufe (der letzten 7 Tage) besonders prominent oberhalb der anderen Elementen angezeigt. Die Nutzungszeit der Anwendung hat sich dadurch deutlich verringert, die Zufriedenheit aber im gleichen Maße erhöht.

Hätte ich die Anlage nicht mittlerweile schon außer Betrieb genommen, hätte die nächste Iteration vielleicht die unteren Elemente initial ausgeblendet und nur auf Knopfdruck eingeblendet, dann würde man nicht sofort mit so vielen Informationen konfrontiert.

Fazit

Am Ende dieser Reise ist eine Anwendung entstanden, die mich an das Ei des Kolumbus erinnert: Wenn man wissen will, ob man verpasste Anrufe hat, baut man halt eine Anwendung, die einem genau die verpassten Anrufe anzeigt. Ist doch logisch, oder?

Der Weg dahin war für den Lerneffekt sehr anschaulich, aber sicherlich nicht der, der am schnellsten ans Ziel führt. Richtigerweise hätte man sich die Gedanken über die genauen Anforderungen machen sollen, bevor man mit der Umsetzung beginnt. In einem umfangreicheren Projekt würde es schnell Wochen oder länger dauern, alles mehrfach umzubauen. Das wäre weder für die Entwickler noch für die Stakeholder besonders zufriedenstellend.

Was ich am Ende gelernt habe, mag sehr offensichtlich klingen, wird aber oft vergessen. In einem Projekt ohne UX-Designer sollte man sich auch als Entwickler ruhig trauen, zuerst einen Moment innezuhalten und nicht sofort die erstbeste Lösung zu bauen, die einem in den Kopf schießt.

Und wer sich dafür interessiert, wie das ganze technisch umgesetzt wurde (oder ebenfalls zur obskuren Randgruppe derer gehört, die einen heimischen Festnetzanschluss mit einer enterprisetauglichen Software-Telefon-Anlage betreiben und gern eine nette UI dazu hätten) findet den Code auf Github: https://www.github.com/mrm1st3r/pound

Titelbild: Boston Public Library/Unsplash.com