Der Nutzer im Fokus des Frontends

Der Weg zum intuitiven UI

So wie Häuser für ihre Bewohner gebaut werden, sollten auch bei der Entwicklung eines Frontends seine zukünftigen Benutzer mit einbezogen werden. Im Projektalltag basieren Entscheidungen jedoch meist auf geschäftlichen oder technologischen Überlegungen. Um unzufriedene Kunden und die Entwicklung überflüssiger Frontend Elemente zu vermeiden, zeigen wir im Folgenden einen Weg die Benutzer in den Fokus zu rücken. Wie wäre es, wenn wir damit unseren Entwicklern auch noch einen Gefallen tun?

Die Erkenntnis, dass etwas im Frontend nicht rund läuft, ist zunächst unabhängig von der eigenen Rolle im Projekt: egal ob Sie Projektmanager/in, Produktverantwortliche/r, Entwickler/in, Designer/in, Abteilungsleiter/in oder die Geschäftsführung sind, die das bemerken. Aktiv werden können und sollten Sie in jedem Fall. Die Probleme der Nutzer werden im Unternehmen nämlich oft übersehen und es gibt in der Regel noch keine etablierten Prozesse sie zu erkennen und zu beheben.

Je mehr Software unseren Arbeitsalltag definiert, desto wichtiger wird es, dass sie uns dabei nicht frustriert. Im Idealfall geht Software auf unser mentales Modell ein: sie bildet die Realität in einer Weise ab, die wir intuitiv verstehen. So können wir mit ihr zusammenarbeiten, um unser eigentliches Ziel zu erreichen. Ist das nicht ein schönes Bild? Das Frontend und der Nutzer, Hand in Hand, am gleichen Strang ziehend? Doch wie wird der Nutzer zur gehörten Stimme in Ihrem Unternehmen? Wir wollen das Produkt, und vor allem den Teil mit dem der Benutzer direkt interagiert, in fünf Schritten zielgerichteter und intuitiv bedienbar machen. Der Weg dorthin ist anspruchsvoll.

Wir werden auf technische, prozessurale sowie soziale Herausforderungen treffen. Doch den Weg zu beschreiten lohnt sich: am Ende können wir schnell und flexibler entwickeln und dabei mehr erreichen. Los geht’s!

‍

Schritt 1: Undercover Ermittlung

Bevor wir unser Team und unsere Vorgesetzten in den Prozess involvieren, werden wir zunächst selbst der Vermutung nachgehen, dass etwas in unserem Frontend nicht rund läuft. Dazu brauchen wir Fakten, die zeigen wie nutzerorientiert unser Frontend schon ist und wo Handlungsbedarf besteht. Versuchen wir zunächst folgende Fragen aus der nachfolgenden Checkliste zu beantworten und über einen Zeitraum von 4–6 Wochen zu beobachten.

• Wie oft wird ein Design in einem Meeting oder von einem Komitee entschieden?
• Wie oft stellen sich anfängliche Aussagen und Annahmen später als falsch heraus?
• Freuen sich die Endkunden auf neue Features im Frontend oder haben sie Angst, dass wieder alles verschlimmbessert wurde?
• Werden Daten über das Nutzerverhalten regelmäßig gesammelt und ausgewertet?
• Gibt es einen Informationsfluss vom Kundenservice zum Produktverantwortlichen?
• Gibt es einzelne Entscheider im Unternehmen, die unabhängig von gesammeltem Wissen die Richtung vorgeben?
• Wieviel Zeit geht verloren, weil wir ein Feature zum x-ten mal umbauen?
• Verlieren Designer oder Entwickler häufig die Motivation und kündigen sie sogar?

Eine hervorragende Möglichkeit für diesen Schritt ist es ein oder zwei Tage im Kundenservice zu verbringen und sich mit den dort auftreffenden Problemen — ungefiltert — zu konfrontieren. Gehen Sie mit dem Außendienst zum Endkunden, beobachten Sie Ungereimtheiten und erkundigen Sie sich nach Verbesserungsideen. Fragen Sie aktiv nach! Auch ein Blick in die Statistiken oder Analytics-Daten kann helfen Schwachstellen zu identifizieren. Wenn Sie an einem Tag weniger als 10 neue Verbesserungsvorschläge gesammelt haben, können Sie sich glücklich schätzen. Es ist aber wahrscheinlicher, dass Sie seitenweise Probleme und Ideen finden. Weitere Techniken zu diesem Schritt finden Sie auch in [Bow10]. Und die nehmen wir am besten direkt mit in den nächsten Schritt.

Schritt 2: Eine Allianz aufbauen

Wenn erste Ergebnisse vorliegen und Ihnen klarer geworden ist, wie groß das Problem ist und wo man ansetzen könnte, geht es im zweiten Schritt darum, Verbündete zu finden und zusammen Experimente durchzuführen, die die im ersten Schritt gewonnenen Erkenntnisse mit weiteren Fakten untermauert und mögliche Lösungsansätze evaluieren. So können wir einen Überblick gewinnen wie groß unser UX Debt ist und welche Möglichkeiten es gibt. UX Debt ist vergleichbar mit Technical Debt, nur während Technical Debt oft verzögerte und langfristige Konsequenzen hat, sind die negativen Konsequenzen von UX Debt sofort und für alle Nutzer direkt spürbar. Doch wie können wir Verbündete im Ringen um eine gute User Experience finden?

Unterstützung kann von vielen Positionen kommen. Gibt es etwa Entwickler, die den Kundenkontakt suchen? Oder Produktverantwortliche, die oft eine Lanze für den Endnutzer brechen? Wer im Team denkt schon oft an die Nutzer, kann das aber vielleicht bisher nicht zur Umsetzung bringen? Diese Personen sind natürliche Verbündete, um weiteres Wissen zu sammeln und Lösungsansätze zu erarbeiten. Jetzt fragen Sie sich vielleicht wie Sie diese möglichen Verbündeten am besten überzeugen. Nehmen Sie sie mit zu dem, was Sie selbst erlebt haben! Treffen Sie sich zusammen mit den Service-Kollegen. Beobachten Sie gemeinsam Endnutzer. Teilen Sie Ihre Videos und Aufzeichnungen aus Schritt 1. Überzeugen Sie mit den realen Problemen und Emotionen echter Nutzer, denn nichts hat mehr Argumentationskraft. Haben Sie Ihr Team beisammen, sammeln Sie weitere Probleme.

Ihre Verbündeten sollten sich unabhängig — genau wie Sie vorher — auf die Suche machen und verschiedene Kanäle anzapfen, um Feedback von realen Benutzern zu bekommen. Überlegen Sie sich zudem welche Messgrößen Sie verwenden können, um Auswirkungen zu messen. Gängige Messgrößen sind die Anzahl Anfragen, die täglich an das Service-Team gestellt werden, die Zeit, die es braucht neue Benutzer zu schulen, und die Anzahl Nutzer, die bis zu einem gewissen Punkt kommen. Letzteres wird gerne ins Verhältnis zur Anzahl Nutzer gestellt, die einen Prozess angefangen haben, wodurch sich die Rate der erfolgreichen Abschlüsse eines Prozesses errechnen lässt. Anhand dieser Messgrößen können wir später verschiedene Alternativen gegeneinander abwägen und so Entscheidungen daten-getrieben fällen. Zusammen mit den Problemen, die Ihre Verbündeten gefunden haben ist Ihre Liste nun vermutlich so lang geworden, dass Sie gar nicht wissen, wo sie anfangen sollen. Daher gewichten wir nun die Probleme nach Häufigkeit und Beeinträchtigung, um so den Lösungsbedarf zu ermitteln. Eine Vorlage hierzu finden Sie in Abb. 2. Zur Illustration der nächsten Schritte soll uns ein Beispiel aus dem Maschinenbau dienen: stellen Sie sich eine Produktionsmaschine vor, die an einem Werkstück aus Rohmaterial einen Bearbeitungsprozess durchführt. Das Frontend zur Steuerung ist auf einem Touchscreen sichtbar, der bei der Maschine steht.

Sie zeigt beispielhaft welche Personen (P1 bis P10) welche Probleme hatten und welche Folgen dies hatte. Der Grad der Beeinträchtigung ergibt sich aus der Einschätzung der Folgen für den Nutzer. Kann der Benutzer auf Grund des Problems nicht zum Ziel kommen, ist dies eine schwerwiegende Beeinträchtigung (10 Punkte). Kann er oder sie jedoch durch einen kleinen Umweg das Problem umschiffen, wird das Problem als marginal eingestuft (1 Punkt). Um eine übersichtliche Grundlage für spätere Diskussionen zu haben, können wir die Probleme nun in ein Impact-Chart — siehe Abb. 2— einordnen.

‍

Je weiter rechts ein Problems steht, desto mehr beeinträchtigt es den Nutzer. Je weiter oben es steht, desto häufiger ist es. Die dringendsten Probleme sind also ganz rechts oben zu finden. Jetzt haben Sie ein recht konkretes Bild, was alles schiefläuft und an welchen Stellen Verbesserungen am nötigsten sind. Zeit, diese Erkenntnisse in Schritt 3 mit Ihrer Organisation zu teilen!

Schritt 3: Coming

Out Die gesammelten Fakten werden nun zusammen aufbereitet und strategisch genutzt, um weitere Kollegen zu überzeugen. Um damit erfolgreich zu sein, müssen auch konkrete Vorschläge zur Lösung der Probleme sowie generell einer Verbesserung des Entwicklungsprozesses mitgebracht werden, um das Team nicht mit einem Problem ohne Lösung zu konfrontieren. Es gilt also, mit möglichst wenig Aufwand herauszufinden, wie man die wichtigsten Probleme lösen könnte. Zeit für Prototyping! Selbst mit einer kleinen Gruppe und wenig Zeit ist es möglich, sinnvolle und nützliche Lösungsideen prototypisch zu entwickeln und zu testen. Wie? Auf Papier! Stellen Sie sich vor, jeder Screen wäre eine DIN A4 Seite (siehe Abb. 4). Der Benutzer “klickt” oder “tippt” auf einen skizzierten “Button”, dann “lädt” der nächste Screen (Sie selbst tauschen das Papier aus) und es geht weiter. Für weitere Tipps zum Erstellen von Papier-Prototyphen siehe [Sny03]. Klar ist das etwas anderes als ein Bildschirm, aber laut den Forschern von usability.gov [Bai05] gelingt einer Testperson der mentale Transfer von Bildschirm zu Papier gut — damit sind Testergebnisse auf Papier-Prototypen valide. Unserer Erfahrung nach kann man mit zwei Personen innerhalb von zwei Stunden den Prototyp für ein Feature bauen, die Evaluation dauert dann noch mal etwa eine Stunde.

Bei komplexen Features müssen Sie abwägen, was der Fokus für den Prototyp ist. Ab einer bestimmten Komplexität ist es leichter und schneller das Feature prototypisch zu implementieren und in der bestehenden Oberfläche zu testen. Nutzen Sie das Prototyping um für die zwei wichtigsten Probleme Lösungen auszuprobieren. Iterieren Sie ein paar mal und prüfen Sie, ob Ihre Lösung besser verstanden wird. Nach zwei Iterationen werden Sie schon Ergebnisse haben, die sich vorzeigen lassen. Sie haben nun nicht nur mit wenig Aufwand ein besseres User Interface entwickelt, Sie haben auch einen neuen Entwicklungsprozess getestet. Und er macht auch noch Spaß! Vergleichen Sie Ihr Ergebnis mit dem Entwicklungsprozess vorher. Höchstwahrscheinlich waren Sie schneller und haben weniger Entwicklerkapazität gebraucht. Das sind sicher Argumente, mit denen sich Entscheider weiter oben in der Unternehmenshierarchie überzeugen lassen. Auch eine kurze Aufrechnung der Einsparmöglichkeiten kann bei der Argumentation helfen. Nehmen wir an, dass verbesserte Fehlermeldungen dem Kundendienst pro Tag 10 Anfragen à 12 Minuten sparen würden. Das klingt erstmal nicht nach sehr viel, hochgerechnet auf ein Kalenderjahr ergeben sich daraus jedoch 60 Arbeitstage. Eine Summe, die die Investition in aussagekräftige Fehlermeldungen und mögliche Lösungswege klar rechtfertigt. Bereiten Sie nun in einer Präsentation auf, was Sie gelernt haben. Behalten Sie dabei im Hinterkopf, dass Manager meist aus Business-Perspektive denken, nicht aus Nutzer-Perspektive. Folgende Vorteile eines guten UX Prozesses können Ihnen dabei als Vorlage dienen:

• Erhöhte Anzahl neuer Kunden, die sich nach einer Testphase zum Kauf entscheiden.
• Bessere Kundenbindung (und ggf. zusätzlicher Umsatz) durch neue, gut integrierte und getestete Features.
• Erhöhter Wert des Produkts, so dass ggf. der Preis erhöht werden kann.
• Reduzierte Entwicklungskosten. Sicher das stärkste Argument, denn hier sind massive Einsparung möglich, wenn genau geprüft wird, was man wie entwickeln sollte, bevor viel Zeit investiert wurde.
• Reduzierte UX Debt und damit weniger Nacharbeiten und Korrekturen, was zu einem einem nachhaltigeren, langlebigeren Produkt führt.

Grundsätzlich gibt es zwei verschiedene Ansätze, UX Debt iterativ aufzuarbeiten: 1) man nutzt interne Kapazitäten und passt den Entwicklungsprozess an oder 2) man engagiert Berater, die damit schon Erfahrung haben, um kurzfristig nicht in Kapazitätsengpässe zu kommen. Je nach Situation in Ihrem Unternehmen sollten Sie die passende Variante vorschlagen. Gerne können wir Sie dazu beraten und in einem ersten Gespräch mögliche Lösungswege evaluieren.

Schritt 4: Prozess einführen & optimieren In den vorherigen Schritten haben wir zweierlei ausprobiert: einerseits wissensschaffende Methoden wie Beobachtungen und das Analysieren von Kundenservice-Anfragen sowie andererseits einen iterativen Lösungsansatz mit schnellem Prototyping. Diese beiden wollen wir nun kombinieren und in unseren normalen Entwicklungsprozess integrieren. Das erfordert besondere Rücksicht auf die soziale Kompetenz und die Teamstruktur. Am Ende steht ein für das jeweilige Team funktionierender und etablierter Prozess, der Iterationen und deren Evaluation im Kern hat.

‍

‍

Ein häufig auftretender Fehler in der Frontend Entwicklung ist es, die Meinung des Endkunden nur sporadisch einzuholen, wenn es denn gerade zufällig klappt, oder gar nur einmal in einer großen Hau-Ruck Aktion. Häufig sehen wir den Ansatz, zu Beginn eines Projektes eine ausgedehnte Studie zu machen, bei der bestehende Produkte untersucht und der Endkunde intensiv befragt wird. Erkenntnisse aus dieser Studie sind durchaus hilfreich, jedoch niemals ausreichend für einen erfolgreichen Frontend Entwicklungsprozess. Dokumentiert man Annahmen und gefundene Antworten schriftlich, etwa in Personas oder einem Annahmenkatalog, so kann das Entwicklungsteam später alle neuen Entscheidungen darauf basieren und den Katalog ständig weiterentwickeln. Gießt man jedoch das Ergebnis der initialen Studie ohne schriftliche Dokumentation nur in Richtlinien, wie z.B. in einen Design-Guide, gehen diese Informationen verloren und man versteift sich auf die zum Zeitpunkt der Erhebung vorliegende Faktenlage.

Die Erfahrung im Bezug auf benutzerorientierte Entwicklung zeigt: mit einem kontinuierlichen Verbesserungsprozess geht es am besten voran — siehe dazu auch [Got16]. Egal ob Sie agil, cross-funktional, in einem oder in vielen Teams an einem Produkt arbeiten, beachten Sie die folgenden Punkte:

• Wie in Schritt 3 beschrieben starten wir vor der eigentlichen Entwicklung immer einen so genannten Design Sprint, in dem wir Prototypen erstellen und testen.
• Keine Entscheidung wird ohne Datengrundlage getroffen. Nehmen Sie Ihre vorher definierten Messgrößen zu Hilfe.
• Jede wichtige Entscheidung wird mit einem Prototyp evaluiert.
• Jedes Team hat mindestens einen UX Designer und einen Frontend Entwickler.
• Gute Kommunikation und regelmäßige Abstimmung zwischen UX Designern und Frontend Entwicklern. Entwickler sollten z. B. die Prototypen regelmäßig sehen und ausprobieren können

Mit diesen Mechanismen und einem kontinuierlichen Feedback-Prozess aus dem Projektteam wird es gelingen, Anforderungen an das Frontend und seine Architektur frühzeitig zu erkennen und den Entwicklungsprozess nachhaltig zu verbessern. Doch wie optimieren wir nun auch die technische Seite des Frontends und dessen Architektur in Hinsicht auf nutzerorientierte Entwicklung?

Schritt 5: Technische Umsetzung

Da wir nicht von vornherein alle Anforderungen und die ideale Teamzusammensetzung kennen können, brauchen wir eine flexible Architektur. Gerade in den letzten Jahren hat sich hierfür eine Komponenten-basierte Architektur als besonders gut herauskristallisiert. Hierbei werden alle Elemente einer Applikation als einzelne Komponenten betrachtet, die dann wie in einem Baukasten zusammengesteckt werden können. Damit lässt sich die enge Abstimmung zwischen UX Designern und Entwicklern auch technisch erleichtern. So können selbst Backend-Entwickler ohne Frontend Expertise, ihre Ideen einbringen und Hypothesen testen — ohne sich dafür mit dem Styling auskennen zu müssen. Sie können einfach die bestehenden Komponenten wiederverwenden.

Ein Vorteil, der es uns erleichtert, Entwickler für den Prozess zu begeistern. Für die Produktionsmaschine aus unserem Beispiel kann es sinnvoll sein, die Frontends für normale Bediener und das für die hauseigenen Service-Techniker technisch komplett zu trennen. Service-Techniker brauchen oft viel mehr Zugriff auf erweiterte Funktionen und Diagnose-Möglichkeiten, wohingegen normale Bediener ggf. darauf hingewiesen werden müssen, nun doch einen Service-Techniker anzurufen.

Eine Trennung in zwei Frontend Anwendungen vereinfacht hier die Entwicklungsprozesse für beide, weil man nicht alle Anforderungen unter einen Hut bekommen muss. Verknüpfungen an bestimmten Punkten (z. B. wenn ein Fehler besteht und der Service-Techniker nun an die Maschine kommt), sind natürlich trotzdem möglich und sinnvoll. Damit die UX Designer dabei auf die Einhaltung eines einheitlichen Erscheinungsbildes achten können — unabhängig davon, wie viele technisch unabhängige Frontends es gibt — und jeder Entwickler sehen kann, welche Komponenten es schon gibt, empfiehlt es sich statt des üblichen Design-Guides im Pfd-Format einen “lebendigen” Styleguide zu verwenden. Dieser sollte jede Komponente beispielhaft enthalten und ihre Funktions- und Verwendungsweise erläutern. So wird auch das Erstellen neuer, kontextunabhängiger Komponenten erleichtert.

‍

Darüber hinaus kann der Styleguide allgemein gültige UX Prinzipien in Checklistenform enthalten, um eine einheitliche Nutzererfahrung über verschiedene Applikationen hinweg zu gewährleisten:

• Lesbarkeit:

Sind alle Texte gut lesbar und verständlich formuliert?

• Feedback & Status:

Zeigt das Frontend in jedem Zustand unmissverständlich an, was gerade passiert?

• Mentales Modell:

‍Werden durchgängig die gleichen Bezeichnungen (z. B. “Produktions-Job”) verwendet und sehen diese auch immer gleich aus?

• Robustheit:

Was wird von den Nutzern in welchem Fehlerfall erwartet und wie wird ihnen das kommuniziert? Wurden alle Fehlerfälle bedacht?

• Zugänglichkeit:

Sind alle Kontraste deutlich genug? Können auch Bediener mit bestimmten Einschränkungen (z. B. Rot/Grün-Schwäche) das Frontend uneingeschränkt verstehen?

• Performance:

Muss der Bediener irgendwo länger warten als nötig?

Auf Basis einer solchen Frontend Architektur ist es uns möglich auf neue Erkenntnisse schnell und flexibel zu reagieren — ganz im Sinne unserer Nutzer.

Effekte & Perspektiven

Das Ziel, den Nutzer in den Fokus zu rücken, hat viele Auswirkungen, die sich nicht auf die Qualität des Frontends beschränken:

1. Höhere Entwicklerzufriedenheit und Mitarbeiterbindung, da die Entscheidungsprozesse einfach und direkt sind, weniger diskutiert wird und wenig Code hinterher nutzlos ist und weggeworfen werden muss.
2. Entspannteres Management, da man weniger rät und hofft, dass man das Richtige tut, sondern es weiß, da man es schon geprüft hat.
3. Auch bei den wichtigen Architektur-Entscheidungen können nun Erkenntnisse aus der Nutzerforschung mit einfließen, sodass kostspielige Nacharbeiten vermieden werden.

Am Ende unserer fünf Schritte steht also ein Projektteam, welches selbstständig neue Erkenntnisse gewinnt, aufkommende Probleme löst und den Benutzer immer im Blick behält. Damit kann dieses Team als Vorbild für andere Teams im Unternehmen dienen, denn was funktioniert macht Schule!

Trotzdem sind damit nur der ersten Schritte getan, denn die Rahmenbedingungen eines Produkts ändern sich ständig. Teams wachsen, der Markt verschiebt sich oder das Unternehmen verändert sich. Wenn wir aber das hier Gelernte immer wieder neu anwenden und uns selbst aufs Neue hinterfragen, können wir uns an jede Veränderung anpassen und diese als Chance sehen und nutzen.

Referenzen

1. [Bai05] Validität von Papier-Prototypen auf https://www.usability.gov/getinvolved/blog/2005/06/paper-prototypes-and-software-prototypes.html
2. (11.01.2019)
3. [Bow10] Buch: Undercover User Experience von Cennydd Bowles & James Box im New Riders Verlag erschienen
4. [Got16] Buch: Lean UX: Designing Great Products with Agile Teams von Jeff Gothelf & Josh Seiden im O’Reilly Verlag erschienen
5. [Sny03] Buch: Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces von Carolyn Snyder im Morgan Kaufmann Verlag erschienen
6. [StyleG] Zum Erstellen von lebendigen Styleguides: https://patternlab.io & Beispiel der Autoren: https://interfacewerk.github.io/iwerk-angular-ui