Über unsMediaKontaktImpressum
Marcel Bagemihl & Miriam Becker 19. März 2024

Warum UX-Design ein Fullstack-Job ist...

und wieso das ganze Team für User-Experience verantwortlich ist

Komplexe Software-Projekte haben immer häufiger einen UI/UX-Designer an Bord, damit sich ein Fachmann um die nötigen Maßnahmen kümmert, die eine Anwendung auch für User zugänglich machen. Glaubt man einigen Vorurteilen, streiten sich diese Designer normalerweise mit den Frontend-Engineers über die pixelgenaue Positionierung von Buttons und anderer Elemente sowie die CI-konforme Gestaltung jeder einzelnen UI. Es steckt jedoch deutlich mehr hinter UX!

UX ist mehr als "nur" UI-Design

Das User-Interface ist das erste, was der Anwender sieht. Wer aber genauer darüber nachdenkt, stellt schnell fest: Ein schönes Produkt ist nicht gleich ein gutes. Ist es schön, aber nicht nutzbar, führt das zu Frustration. Wie findet man jetzt aber heraus, was Einfluss darauf hat? Hier kommt die User-Experience (UX) ins Spiel. Der Begriff User-Experience bezeichnet das Erlebnis, die Erwartungen und Wahrnehmungen, die ein User während der Nutzung eines Produkts hat. Ziel ist es, ein positives Nutzererlebnis zu schaffen. Dies wird erreicht, wenn die Anwender mit dem Erlebnis zufrieden sind und die Ziele schnell, einfach und intuitiv erreicht werden. Die Usability und das UI sind Teil der User-Experience. Ist etwas schlecht bedienbar oder durch das Design schwer erkennbar und dadurch nicht intuitiv, führt das automatisch zu einem schlechten Nutzererlebnis.

Um das zu verdeutlichen, gehen wir einen Schritt weg von der Software und nehmen uns alltägliche Dinge als Beispiel: Eine kleine Parkanlage mitten in der Stadt, die Wege sind kunstvoll verschlungen in einer Wiese angeordnet. Aber was passiert nun, wenn die gepflasterten Wege nicht den Bedürfnissen der Bürger und Bürgerinnen entsprechen? Sie nehmen eine Abkürzung und laufen querfeldein. Hier ist leicht zu erkennen, wenn die UX nicht stimmt. Aber wie findet man das bei einer Software heraus?

Es beginnt bei der Vision

Bereits vor Beginn der Entwicklung sollte man sich Gedanken machen, welches Problem man mit dem Produkt überhaupt lösen möchte. Methoden wie Design Thinking, Interviews mit potenziellen oder bereits bestehenden Anwendern sind hier eine Möglichkeit, um neue Ideen und Wissen zu generieren, die bei der Produktentwicklung notwendig sind. Es ist wichtig, ein Verständnis dafür zu entwickeln, welche Probleme und Bedürfnisse die zukünftigen Anwender haben und wie diese gelöst werden könnten. Eine weitere Möglichkeit ist hier auch eine Markt- und Wettbewerbsanalyse. Dabei schaut man sich die Zielgruppe und existierende Konkurrenzlösungen an. Anhand derer wird der eigene Unique Selling Point ermittelt, also der Grund, warum Anwender die eigene Lösung die der Konkurrenz vorziehen sollten.

Durch User-Research die richtigen Prioritäten setzen

User-Research ist essenziell für die Produktentwicklung. Nur wenn man die Anwender und ihre Bedürfnisse kennt, ist es möglich, ein gutes Produkt zu entwickeln. Erfüllt ein Produkt diese Bedürfnisse nicht, wird es zwangsläufig scheitern. Contextual Inquiry gehört zu den klassischen UX-Research-Methoden. Dabei wird den Anwendern über die Schulter geschaut, während sie die Anwendung nutzen. Für optimale Ergebnisse ist es wichtig, dies selbst mit den Usern durchzuführen und "Mittelsmänner" oder Stellvertreter der Anwender zu vermeiden. Ziel ist es, die tatsächlichen Anwender in ihrem tatsächlichen Umfeld zu beobachten, denn nur so ist es möglich, echte Daten zu sammeln und die echten User kennenzulernen. Wird beispielsweise eine neue Küchenmaschine entwickelt, so findet die Beobachtung der Anwender am besten bei ihnen zuhause in der Küche statt. Gibt es bereits ein Vorgängermodell, wird diese Methode mit diesem durchgeführt, andernfalls besteht hier auch die Möglichkeit, ein Konkurrenzprodukt zu verwenden und zu sehen, wie die Anwender dieses nutzen. Dies deckt auf, wie Kunden das Produkt verwenden, an welcher Stelle Abläufe noch nicht reibungslos funktionieren oder ob Funktionen fehlen. Das Gleiche lässt sich auch bei Software-Produkten durchführen, hierzu beobachtet man die Anwender direkt an ihrem Arbeitsplatz. Zusammen mit anderen User-Research-Methoden, wie Zielgruppenanalysen, Empathy-Mapping, User-Story-Mapping und Szenarios entsteht so ein sehr gutes Bild von den Nutzern und ihren Bedürfnissen.

Lädt eine Anwendung zu lang, zweifeln Anwender an der Funktionalität.

Auf Basis dieser Vorarbeiten entwickelt anschließend der UX-Designer ein erstes Konzept der Anwendung. Dazu werden User-Flows erstellt, ein stimmiges Interaktionskonzept überlegt und alle Erkenntnisse aus der Research-Phase beachtet. Während der gesamten Konzeptionsphase ist es wichtig, sich immer und immer wieder die Anwender und ihre Bedürfnisse vor Augen zu führen und sich in diese hineinzuversetzen. Nicht nur die daraus resultierenden Wireframes und Mockups spielen eine Rolle, sondern auch, dass die Systemarchitektur und vor allem die Informationsarchitektur darauf ausgelegt sind, alle geplanten Features effizient umsetzen zu können. Hier findet ein Zusammenspiel zwischen UX-Designer und Developer statt.

Während der gesamten Entwicklung gilt es vor allem, die gesetzten Ziele und Metriken nicht aus den Augen zu verlieren. Hierfür sollten ständig sowohl die Performance der Anwendung, als auch die Antwortzeiten der APIs im Blick behalten und verbessert werden. Dies hat wieder Auswirkung auf die UX, denn dauert etwas zu lange, kann es zu Frustration bei den Anwendern führen. Ist es einmal nicht möglich, die gewünschte Performance zu erreichen und die Wartezeit für die Anwender wird zu lang, gibt es Mittel, mit deren Hilfe zumindest die gefühlte Performance erhöht werden kann. Dazu kann man den Request bzw. die Funktionalität hinter dem Endpunkt so in mehrere Endpunkte aufteilen, dass ein Request schnell beantwortet wird, während der zweite, aufwändigere Request auf sich warten lässt. So kann die Anwendung bereits die schnell verfügbaren Informationen anzeigen und die Anwender beschäftigen, bis die zweite Antwort verfügbar ist. Ein Beispiel hierfür ist, das Laden eines skalierten Bildes so aufzuteilen, dass die Metadaten schnell verfügbar sind und das eigentliche Bild erst im Anschluss "lazy" nachgeladen wird. Ist auch das nicht möglich, gibt es erstmal nur eins zu tun: Den Anwendern zeigen, dass alles okay ist! Denn lädt eine Anwendung unerwartet lang, zweifeln Anwender an deren einwandfreier Funktionalität.

Was, wenn etwas schief geht?

Gibt es ein Problem, sollte man die Anwender selbstverständlich darüber informieren, keine Frage! Aber wie viele Details verrate ich ihnen? Die Anwender möchten zumindest wissen, was sie tun müssen bzw. können, um das Problem zu beheben. Der Detailgrad hängt dabei auch davon ab, wer meine Anwender sind und um welches Produkt es sich handelt. Selbst hier ist das Ergebnis einer Nutzeranalyse relevant, um herauszufinden, wie viel technische Expertise man erwarten kann und wie viele technische Details die Anwender verarbeiten können. Es macht hier einen Unterschied, ob eine Software beispielsweise für technische Administratoren oder eine Website für örtliche Senioren-Veranstaltungen entwickelt wurde. Ein Admin, der selbst technisch affin ist und viel eigenständig wieder zum Laufen bekommen kann, benötigt andere Informationen als die gängigen Anwender einer Veranstaltungswebsite für Senioren. Aussagekräftige Fehlermeldungen entlasten oft nicht nur die Entwickler beim Debuggen des Problems, sie helfen den Anwendern auch zu verstehen, was sie tun können, um den Fehler künftig zu vermeiden. Ist beispielsweise ein Service im eigenen System ausgefallen, sollte die Fehlermeldung dem Nutzer sagen, dass der Fehler im System liegt und ein späterer Versuch erfolgreich sein sollte. Fachliche Informationen, gerade bei Fehlfunktionen, sind oft schützenswert und wollen nicht herausgegeben werden. Also was macht man in diesem Fall?

"Ein unbekannter Fehler ist aufgetreten!"

Für frustrierte Anwender gibt es kein schlimmeres Signal als die Aussage, dass etwas defekt ist und niemand die Ursache kennt! Software soll Probleme lösen. Wenn der Problemlöser selbst Probleme hat, wollen Anwender zumindest wissen, was sie tun müssen, um diese zu beheben. Die Nutzer wünschen sich Unterstützung und das Gefühl, nicht machtlos zu sein. Statt eines "unbekannten Fehlers" ohne weitere Details sollte man also zumindest noch hinzufügen, wie man das Problem zu beheben gedenkt. Ein Kontaktformular, eine Support-Hotline, mit deren Hilfe die Anwender sich an jemanden wenden können, würde man sich als Anwender wünschen, sollte sich das Problem nicht von selbst lösen.

Falls man den Usern keine fachlichen Details nennen darf oder will, gibt es die Möglichkeit, diese zu kaschieren bzw. hinter Fehlercodes zu verstecken. Ist der Support der Anwendung sonst ordentlich organisiert und sind Kontaktmöglichkeiten vorhanden, ist es psychologisch dann immer noch ein Unterschied, ob ich mich beim Support mit einem "unbekannten Fehler" melde oder mit Fehlercode "Schildkröte". Zumindest solange der Support den Anwendern dann auch das Gefühl gibt, dass sich jemand um ihr Problem kümmert.

Es gibt Features, die dürfen nicht ausfallen!

Nicht immer kann man die Anwender – und somit Kunden – damit besänftigen, dass man daran arbeitet, das Problem zu beheben. Meist sind es die Main-Features einer Anwendung oder eines Produkts, die zuverlässig, ohne Ausfall funktionieren müssen.

Man stelle sich vor, der eigene Wecker arbeite nicht zuverlässig und man verschlafe eine wichtige Geschäftsreise. Beim ersten Auftreten dieses Problems macht man seinem Ärger noch Luft. Verschläft man aber wiederholt, weil der Wecker seine wichtigste Funktion nicht erfüllt, landet er vermutlich im Müll. Zudem merkt man sich den Hersteller, um ihn künftig zu meiden. Dadurch verliert der Anbeiter den Kunden nachhaltig.

Oft gibt es in diesem Bezug Diskussionen über die Sicherheit der Software, da Sicherheitsmaßnahmen häufig das Potenzial haben, einen Nutzer bspw. aus der Anwendung auszusperren, weil unter anderem die DOS-Prävention etwas zu vorsichtig eingestellt ist oder bei einem Auto die elektronische Wegfahrsperre aktiviert wird, obwohl der Schlüssel in der Hosentasche des Fahrers ist. Wenn ein Sicherheitsmechanismus dafür sorgt, dass das Produkt – wenn auch nur für diesen einen Anwender – nicht nutzbar ist, schießt man über das Ziel hinaus.

Durch richtiges Testen zu besserer UX

Dass die richtige Teststrategie und eine ausreichend hohe Testabdeckung die Fehleranfälligkeit verringern und damit die UX verbessern, sollte bekannt sein. Sind alle Edge Cases in Unit- oder Integration-Tests abgedeckt, hat man einige potenzielle Fehlerquellen und somit Ärger der Anwender behoben. Hat man die entscheidenden Metriken für UX definiert, lassen sich diese oft auch in Tests abbilden. Regelmäßige Lasttests des Systems lassen bspw. darauf schließen, dass ein potenzielles Performance-Problem zu befürchten ist oder wie viele Aktionen ein User benötigt, um einen gewissen Use Case abzuschließen.

Wichtig ist, sich nicht nur auf automatisierte Unit-Tests zu verlassen, die lokal oder in der Pipeline ausgeführt werden, sondern auch den User-Kontext nachzustellen oder ihm zumindest möglichst nahe zu kommen. Entwickelt man eine Mobile-App für Kanalarbeiter auf dem Land, sollte man die End-to-End-Tests z. B. mit sehr gedrosselter Netzwerkverbindung und die UI ebenso mit (simuliertem) mobilem Gerät durchführen. Besteht die Möglichkeit, das Produkt direkt mit den echten Anwendern zu testen, ist das die beste Möglichkeit. Hierzu wird ein kleiner Kreis von Usern eingeladen. Ein Usability-Test liefert echte und sehr brauchbare Informationen über die Nutzung des Produktes. Das Testing kann am Ende der Produktentwicklung stattfinden. Aber auch zu Beginn, als Einstieg in die User-Research-Phase, um vorhandene Probleme eines Produktes und Bedürfnisse von Anwendern vorab aufzudecken und diese bei der neuen oder verbesserten Version des Produktes einzubauen.

Eine andere Möglichkeit ist ein Usability-Test während der Konzeptphase. Hier können Anwendungen mithilfe eines klickbaren Prototyps, beispielsweise erstellt in Figma, zum Testen verwendet werden. Wichtig ist hierbei, so gut es geht, die Realität nachzustellen, damit es sich für die Anwender echt anfühlt. Führt man Usability-Testing bereits in der Konzeptphase durch, kann man durch das Vermeiden von unnötiger Entwicklung auch Geld sparen, da ein Figma-Prototyp oder ein früher Produktprototyp schnell erstellt sind und noch kein großer Entwicklungsaufwand dahintersteckt. Ein Usability-Test am Ende der Entwicklungsphase garantiert keine einwandfreie Funktionalität ohne Fehler. Es ist aber eine Möglichkeit, um vorab schon mal den einen oder anderen Fehler aufzudecken.

Waren alle Tests erfolgreich, so geschieht in der Regel das, wofür man eine Software entwickelt: Sie geht live. Auch das Deployment und Release von Software(-Updates) hat Einfluss auf UX. Nach dem initialen Release einer neuen Applikation muss man sich Gedanken über ein Onboarding neuer Anwender machen, denn niemand außerhalb des Projektteams hat die Anwendung bisher gesehen. Für diesen Task gibt es in der Regel zwei Ansätze: In B2B-Projekten werden meist Mitarbeitende persönlich geschult und ein Handbuch geschrieben und bereitgestellt. Im B2C-Bereich gibt es meist Features innerhalb der Applikation, die diese beim ersten Nutzen kurz erklären.

Ein Feature sollte erst releast werden, wenn es fertiggestellt ist und nicht vorab, nur um das Release-Datum einzuhalten.

Aber auch danach gilt es, die Anwender mit kleinen, häufigen Releases und somit kleinen stetigen Änderungen nicht zu überfordern. Müssen sich Nutzer mit jedem Release an eine neue UI oder komplett überarbeitete Prozesse gewöhnen, überlegen sie vielleicht, diese Gelegenheit direkt für einen Anbieterwechsel zu nutzen, sollte es Konkurrenten geben.

Nach Möglichkeit finden die Releases ohne Ausfallzeit statt, mittels Blue-Green-Deployment und – eigentlich selbstverständlich – erst wenn ein Feature fertigbestellt ist, sollte es releast werden und nicht bereits vorab, nur um das Release-Datum einzuhalten.

Mit Monitoring und Alerting zu kurzen Reaktionszeiten

Nun ist die Applikation deployt, funktioniert wie gewünscht und ist bereits mehrfach getestet. Diese Tests wurden von Experten erstellt, die sich monatelang mit dem Produkt und dem Kontext auseinandergesetzt haben, um anschließend alle denkbaren Fälle abzudecken. Die Anwender wiederum kennen das Produkt, wie erwähnt, noch nicht, haben eventuell andere Gewohnheiten und Arbeitsweisen und machen einige Dinge eben auf ihre Art und Weise. Dies führt in der Regel zu einigen kleinen Bugs und Entdeckungen von "komischem" Verhalten der Anwendung. Manche dieser Bugs sind nicht so schlimm und können schnell behoben werden. Aber gehen wir mal davon aus, dass aus Entwicklersicht der Worst Case an Fehlermeldungen eintritt: ein "unbekannter Fehler" (natürlich mit Code "Schildkröte"). Schon bevor man die Nachricht vom Support erhält, bekommt man hoffentlich durch das eigene Monitoring-System die Info, dass irgendwo in der Anwendung etwas schiefgelaufen ist. Allgemein sollte man während der Entwicklung deshalb stets regen Austausch mit den UX-Kollegen pflegen, um pragmatisch und agil auch vermeintliche Kleinigkeiten schnell anpassen zu können und die Kosten für UX nicht unnötig in die Höhe zu treiben.

Aus UX-Sicht – und so haben wir es auch in den meisten Scrum-Teams erlebt – sollte sich jetzt das ganze Team darauf fokussieren, die Ursache zu finden und das Problem zumindest für diesen Anwender zu beheben. Währenddessen kommt die Meldung aus dem Support mit der Nachfrage, was den Anwendern gesagt werden soll. Ist man hier schon über die Analysephase hinaus, kann oft schon eingeschätzt werden, wie bzw. wann das Problem behoben sein sollte. Analog zu den Fehlermeldungen ist auch hier für die Anwender wichtig, möglichst viel zu erfahren. Denn jede Information schafft Vertrauen darin, dass man das Problem im Griff hat und die Anwendung bald wieder wie gewohnt funktioniert.

Nimmt man alle genannten Punkte zusammen, mag es für den einen oder anderen vielleicht nach einigem Mehraufwand klingen. Aus unserer Projekterfahrung können wir jedoch beruhigt sagen, dass die große Mehrheit an Software-Projekten bereits sehr viel besser unterwegs ist, als manche Entwickler annehmen. Motivierte Entwickler ziehen oft bereits Metriken zu Rate, die indirekt oder direkt positiven Einfluss auf UX haben. Es müssen auch nicht immer alle Faktoren komplett erfüllt werden, hat man aber in den richtigen Momenten UX im Hinterkopf, wird das nächste Projekt für Stakeholder und Anwender gleichermaßen zum Erfolg!

Autor:innen
Das könnte Sie auch interessieren

Neuen Kommentar schreiben

Kommentare (0)