User Experience – Ein Drama in drei Akten
In der Welt der Produktentwicklung gibt es eine Rolle, die oft missverstanden und manchmal sogar unterschätzt wird: der Arbeitsbereich User Experience (UX). Vielleicht haben sich einige von Euch, ob als Entwickler, Product Owner oder jemand aus einem anderen Bereich, schon mal gefragt, was diese UXler eigentlich genau tun und ob deren Einsatz wirklich einen positiven Beitrag zum Produkt hat. Oder habt Ihr Euch als UX-Experte selbst schon mal in die rein ausführende Rolle des "Pixel-Schubsers" gedrängt gefühlt? Lasst mich Euch sagen, dass die User Experience weit über hübsche Oberflächen und ansprechende Designs hinausgeht. User Experience ist eine Teamaufgabe, bei der jeder eine wesentliche Rolle spielt.
Um eine gute User Experience zu erreichen, gilt es zahlreiche Herausforderungen, häufig Missverständnisse und manchmal regelrechte Dramen, die sich durch die verschiedenen Phasen eines Projekts ziehen, zu meistern. Als UX-Experte sehe ich immer wieder ähnliche Stolpersteine, die der User Experience im Weg stehen. Deshalb möchte ich Euch in diesem Artikel aufzeigen, worin diese Herausforderungen bestehen und wie alle Teammitglieder gemeinsam diese Hindernisse überwinden können.
In diesem Artikel werde ich:
- die häufigsten Missverständnisse und Vorurteile gegenüber der UX-Arbeit erläutern
- konkrete Herausforderungen und Beispiele aus dem Projektalltag vorstellen
- exemplarische Methoden vorstellen, die euch zeigen, wie eine erfolgreiche und kollaborative UX-Arbeit gestaltet werden kann.
Ganz egal, ob Ihr Entwickler, Product Owner, UXler seid oder eine andere wichtige Rolle im Team innehabt – dieses Drama ist für Euch alle. Gemeinsam werden wir Licht ins Dunkel bringen und Wege finden, wie wir als Team dazu beitragen können, unseren Nutzern eine wirklich großartige Erfahrung zu bieten. Bühne frei für Akt 1!
User Experience, Akt 1: "Mach das mal hübsch!"
Eines der häufigsten Missverständnisse in der Welt der Produktentwicklung ist die Annahme, dass UX (User Experience) und UI (User Interface) dasselbe seien. Diesem Missverständnis begegnet man nicht nur in der alltäglichen Zusammenarbeit, sondern es zeigt sich auch in vielen Stellenanzeigen, wie Abb. 1 verdeutlicht.
Firmen suchen nach sogenannten UX/UI-Designern und setzen oft beide Begriffe gleich. Ich frage mich dann manchmal, welche Aufgabe der Experte dann wirklich in einem solchen Unternehmen übernehmen soll. Die Wirklichkeit sieht jedoch anders aus. UX ist ein viel umfassenderes Arbeitsgebiet als die rein visuelle Gestaltung der Benutzeroberfläche.Dahinter stecken falsche Annahmen, die ich als das "UX-Fee Antipattern" bezeichne.
Das "User-Experience-Fee Antipattern"
Dieses Antipattern tritt auf, wenn Unternehmen erst sehr spät im Entwicklungsprozess UX-Experten hinzuziehen. Oft geschieht dies mit der Erwartung: "Mach das mal hübsch!" Dies ist jedoch keine sehr effektive Strategie, weil eine gute User Experience nicht im Nachhinein auf ein bereits bestehendes Produkt "aufgepfropft" werden kann. Wenn die Grundlagen nicht von Anfang an richtig gelegt werden, ist es fast unmöglich, im späteren Verlauf eine wirklich gute UX zu schaffen.
Aber bevor wir darüber sprechen, wie wir diese Situation verbessern können, müssen wir zunächst definieren, was User Experience eigentlich ist. UX bezeichnet das Erlebnis (User Experience = die Nutzer-Erfahrung) eines Anwenders im Kontakt mit einem Produkt oder einer Dienstleistung. Dies sowohl vor, während, aber auch nach der Nutzung.
Lasst uns einen Blick auf die Interaktion mit dem Produkt selbst werfen. Wir erwarten von einer modernen Lösung, dass sie eine Reihe von Kriterien erfüllt. Exemplarisch habe ich einige dieser Kriterien in der Abb. 3 dargestellt.
Die UX-Pyramide
Die UX-Pyramide zeigt, dass eine gute User Experience auf zwei Hauptklassen von Kriterien beruht: den pragmatischen und den sogenannten hedonischen Kriterien.
Pragmatische Kriterien
Die Grundlage der Pyramide bilden die sogenannten pragmatischen Kriterien. Dazu gehören Eigenschaften wie Zuverlässigkeit, Verständlichkeit und Effizienz. Wenn diese Kriterien erfüllt sind, spricht man von einer guten Usability. Das bedeutet, dass das Produkt funktional ist und die Nutzer ihre Ziele effektiv und effizient erreichen können.
Hedonische Kriterien
Aufbauend auf diesen Grundlagen gibt es eine weitere Klasse von Kriterien, die hedonischen Kriterien. Diese betreffen die ästhetischen und emotionalen Aspekte eines Produkts. Ein Produkt sollte nicht nur funktional sein, sondern mich auch motivieren, mich ästhetisch ansprechen und originell sein. Diese Kriterien beschreiben den "Joy of Use", also die Freude, die der Nutzer bei der Verwendung des Produkts empfindet.
Beispiele
Das klingt jetzt vielleicht etwas abstrakt. Deswegen lasst uns einen Blick auf zwei konkrete Beispiele werfen: Für Nutzer einer Tabellenkalkulation stehen wohl eher die pragmatischen Kriterien im Vordergrund: Wir wollen z. B., dass Berechnungen korrekt durchgeführt werden und dass die Anwendung zuverlässig funktioniert. Wenn ich hingegen auf meinem Handy mit einer App eine Fremdsprache lerne, ist es mir wahrscheinlich wichtig, dass die Anwendung mich motiviert, am Ball zu bleiben.
Die richtige Balance
Eine herausragende User Experience erreicht man also nur, wenn beide Kriterienklassen ausgewogen sind und dem Nutzungskontext angemessen berücksichtigt werden. Vereinfacht gesagt beinhaltet der Nutzungskontext die Umgebung und Bedingungen, unter denen ein Benutzer ein Produkt verwendet, einschließlich der Aufgaben und Ziele des Benutzers.
Konzentriert man sich ausschließlich auf die pragmatischen Kriterien, erhält man ein funktionales, aber möglicherweise langweiliges Produkt. Legt man hingegen nur Wert auf die hedonischen Kriterien, könnte das Ergebnis zwar ästhetisch ansprechend sein, aber wichtige Grundfunktionalitäten sind vielleicht schwer oder gar nicht zugänglich. Diese Balance zu finden, ist der Schlüssel zu einer erfolgreichen UX.
Die hedonischen Kriterien alleine können keine schlechten pragmatischen Grundlagen wettmachen. Dies wird oft durch das Sprichwort veranschaulicht: "You could put lipstick on a pig, but it is still a pig." Es hilft nichts, einem Produkt einen schönen Anstrich zu verpassen, wenn die grundlegenden Funktionalitäten nicht stimmen.
Zusammenfassend lässt sich sagen, dass User Experience weit mehr ist als nur das visuelle Design eines Produkts. Es geht um die gesamte Interaktion und das Gesamterlebnis des Nutzers. Diese Erkenntnis muss tief im gesamten Team und Entwicklungsprozess verankert sein. Nur so kann man verhindern, dass UX auf ein Late-Stage-Finishing reduziert wird und stattdessen als fundamentaler Bestandteil der Produktentwicklung betrachtet wird. Aber auch wenn wir dies verinnerlicht haben, lauert schon die nächste Herausforderung auf uns. Erstaunlicherweise ist es unsere eigene Lösungsorientiertheit.
User Experience, Akt 2: "Wenn man das Problem vor lauter Lösungen nicht sieht"
Ein Grundproblem, warum viele Produkte nicht ihr volles Potenzial entfalten, ist die Tendenz von uns Menschen, zu lösungsorientiert zu sein. Das mag zunächst widersprüchlich klingen, denn Lösungsorientiertheit ist in vielen Situationen erst einmal eine gute Sache. Doch im Kontext der Produktentwicklung ist es nicht immer sinnvoll, sofort nach einer Lösung zu suchen, ohne das eigentliche Problem wirklich verstanden zu haben.
Anwender kommen oft mit einer Liste an "Anforderungen" zu uns. Es wäre keine gute Idee, diese einfach ungefragt umzusetzen. Lasst uns einmal ansehen warum:
Der Unterschied zwischen Forderung und Anforderung
Bei genauerem Hinsehen entpuppt sich eine "Anforderung" unserer Nutzer häufig als pure Forderung. Eine Forderung ist meist ein konkreter Wunsch nach einem Feature. Sie beschreibt einen Lösungswunsch. Eine Anforderung hingegen beschreibt eine Fähigkeit einer Lösung, die einem Anwender hilft, seine Ziele zu erreichen.
An einem Beispiel veranschaulicht: Ich habe eine Zeit lang in der Produktentwicklung eines Business-Intelligence-Herstellers gearbeitet. Mit unserem Produkt konnte man Anwendungen bauen, die Informationen aus diversen Informationsquellen aggregierten. Eine "Anforderung" eines Anwenders war der Wunsch, dass es eine Möglichkeit geben solle, ein Kontextmenü nach einer bestimmten Zeitspanne automatisch wieder zu schließen. Diese Forderung war etwas überraschend und ich stelle mir vor, dass die meisten Anwender nicht positiv darauf reagieren würden, wenn sich ein Kontextmenü, welches sie geöffnet haben, automatisch wieder schließt, ohne dass sie eine Auswahl getroffen haben.
Es stellte sich heraus, dass der Kunde in diesem Fall versucht hat, mit dem Kontextmenü Hilfetexte für Endanwender zu realisieren. Der Anwender sollte also bestimmte Elemente in der Endanwendung anklicken können, um dann zu dem entsprechenden User Interface einen Hilfetext eingeblendet zu bekommen. Hinter der Forderung nach einem sich selbst schließenden Kontextmenü steckte also die Anforderung, dass unser System es erlaubt, Anwender mit kontextbezogenen Hilfetexten zu unterstützen.
Es ist typisch, dass Anwender eine sehr konkrete Vorstellung davon haben, was sie umgesetzt bekommen möchten. Unsere Aufgabe ist es dann, einen Schritt zurückzutreten und zu hinterfragen: Warum möchte der Anwender dies? Welches konkrete Problem möchte er damit lösen? Welche Ziele hat der Anwender?
Die zentrale Frage, die wir vor der Umsetzung beantworten müssen, lautet: "Was brauchen unsere Anwender wirklich?". Eine große Hilfe, um eine wirklich passende Lösung für ein Problem zu finden, ist der sogenannte Double Diamond (Abb. 4).
User Experience und der Double Diamond
Der Double Diamond, ein Modell, entwickelt vom British Design Council, beschreibt den Designprozess in zwei Hauptphasen: den Problemraum und den Lösungsraum. Seinen Namen hat der Double Diamond daher, dass er diese beiden Räume als Rauten (engl. "diamond") darstellt. Doch warum als Rauten?
Jede der beiden Phasen wird durch divergente und konvergente Denkschritte charakterisiert, die gemeinsam den "doppeldiamantförmigen" Prozess darstellen.
Problemraum
- Diese erste Phase (divergent) beinhaltet die Forschung und das Sammeln von Informationen, um das Problem und die Bedürfnisse der Benutzer gut genug zu verstehen. Hierbei wird ein möglichst breiter Blick auf das Problemfeld geworfen, um alle Aspekte und Perspektiven zu berücksichtigen.
- Nach der Sammlung der Informationen wird der Fokus auf die Definition des eigentlichen Problems gelenkt. Diese Phase beinhaltet das Analysieren und Synthetisieren der gesammelten Daten, um ein klares “Problemstatement” zu formulieren. Der Umfang des Problems wird dabei kontinuierlich verengt (konvergent).
Lösungsraum
- Die erste Phase im Lösungsraum konzentriert sich auf das Generieren von Ideen und das Entwickeln von Lösungsoptionen. Es werden viele mögliche Lösungen exploriert und getestet. Auch hier wird zunächst breit gedacht (divergent), um eine Vielzahl von Möglichkeiten zu prüfen.
- In der letzten Phase wird die gewählte Lösung verfeinert und realisiert. Dieser Schritt beinhaltet Prototyping, Tests und die finale Implementierung der Lösung. Der Fokus liegt darauf, die beste Lösung zu identifizieren und umzusetzen, wodurch der Fokus erneut verengt wird.
Der Double Diamond als Gedankenmodell
Ich nutze den Double Diamond nicht als starres Vorgehensmodell, bei dem streng nacheinander erst der Problemraum und dann der Lösungsraum bearbeitet werden. Ich finde, es ist nicht nur okay, sondern durchaus erwünscht, zwischen beiden Phasen zu alternieren. Für mich dient der Double Diamond als Gedankenmodell, um die Unterschiede zwischen Problemraum und Lösungsraum zu verdeutlichen.
Der Vorteil des Double Diamond ist seine Einfachheit. Für mich ist es so was wie ein Einsteigermodell, gut geeignet um Grundlagen zu erklären. Wer allerdings nach einem Vorgehensmodell sucht, welches zusätzlich mit agilen Methoden kompatibel ist, dem sei an dieser Stelle das UX-Thinking-Prozessmodell von Dr. Herbert Meyer und Hias Wrba ans Herz gelegt [1].
Vom Problemraum zur Lösung: Ein Beispiel
In der Produktentwicklung sind wir heute schon recht gut darin, im Lösungsraum Hypothesen aufzustellen, Alternativen nebeneinander zu stellen, verschiedene Lösungsideen zu entwickeln, zu bewerten und anschließend zu konsolidieren. Doch wie funktioniert dies im Problemraum? Ein bekanntes Beispiel zeigt, wie durch die Analyse des Problemraums erfolgreich neue Lösungen entwickelt wurden.
Beispiel: Der Eierkocher
Ein Hersteller eines Eierkochers stellte sich die Frage nach einer neuen Produktversion. Wie sieht unser nächster Eierkocher aus? Fragt man sich nun: Welches Problem löst ein Eierkocher, ist die Antwort zunächst vermeintlich einfach: Er kocht Eier. Und wenn heute in der Produktabteilung eines Herstellers für Eierkocher die Frage nach der nächsten Produktgeneration gestellt würde, wäre die Antwort vermutlich ein neues Gerät mit WLAN-Anbindung und einem Touchscreen. Vielleicht gar "irgendwas mit KI"?.
Doch ist das wirklich das Ziel, was Nutzer eines Eierkochers erreichen wollen, wirklich einfach "Eier kochen"? Vielleicht lebt unser Nutzer nicht allein, sondern in einer Partnerschaft. Und es existiert ein gemeinsames Kind. Jeder der drei möchte morgens zum Frühstück ein Ei essen, aber jeder mag sein Ei auf eine andere Weise gekocht haben. Der Vater möchte sein Ei weich gekocht, die Tochter mag es hart gekocht und die Mutter bevorzugt etwas dazwischen. Also wäre der Wunsch: jedem Familienmitglied ein Ei im gewünschten Gargrad zur Verfügung zu stellen. Dies ist ein komplexeres Ziel als nur "Der Nutzer möchte ein Ei kochen." Unser Nutzer muss mehrere Eier in unterschiedlichen Gargraden zum Frühstück servieren können – eine Anforderung, die ein klassischer Eierkocher nicht so einfach umsetzen kann.
Nachdem der Hersteller diese Anforderung verstanden hatte, konnte er ein völlig neues Produkt entwickeln: das sogenannte Piep-Ei [2]. Dieses Produkt hat die Form und Größe eines normalen Hühnereis und wird mit den echten Eiern zusammen gelagert, sodass es die gleiche Temperatur hat wie die Eier, die evtl. gerade frisch aus dem Kühlschrank kommen. Die Eier werden dann zusammen mit dem Piep-Ei in einem gewöhnlichen Topf gekocht. Sobald ein bestimmter Gargrad erreicht ist, spielt das Piep-Ei verschiedene Melodien ab, sodass man das Ei zur passenden Zeit entnehmen und perfekt auf die eigenen Anforderungen passend haben kann. Dieses Beispiel zeigt eindrücklich, wie wichtig es ist, den Problemraum gründlich zu analysieren, bevor man zu Lösungen übergeht.
Die Bedeutung des richtigen Problems
Das Beispiel mit dem Piep-Ei zeigt eindrucksvoll, wie wichtig es ist, sich auf das richtige Problem zu konzentrieren, bevor man Lösungen entwickelt. Im Zentrum steht immer die Frage, was unsere Anwender wirklich brauchen. Diese Herangehensweise wird auch durch den UX Honeycomb von Peter Morville verdeutlicht (s. Abb. 5). Was diese Darstellung besonders gut transportiert, ist, dass der Wert, den wir für unsere Nutzer schaffen wollen, im Zentrum unserer Bemühungen stehen muss.
"Don't listen to what they say. Watch what they do."
Ein besseres Verständnis für die tatsächlichen Bedürfnisse unserer Anwender erreichen wir durch genaue Beobachtung und Analyse. Alan Cooper, ein Experte im Bereich User Experience und Erfinder von Personas, bringt es auf den Punkt: "Don't listen to what they say. Watch what they do." Diese Aussage mag auf den ersten Blick hart klingen, trifft aber genau das titelgebende Problem dieses Kapitels. Menschen sind oft zu lösungsorientiert. Daher nehmen wir das Feedback und die Wünsche unserer Anwender zwar gerne auf, aber unsere eigentliche Aufgabe besteht darin, tiefere Bedürfnisse herauszuarbeiten.
Es gibt unterschiedliche Ansätze, die uns dabei helfen können, die Ziele unserer Nutzer besser zu verstehen. Wichtig ist: Geht raus und sprecht mit euren Anwendern.
Geht raus zum Anwender
Werfen wir exemplarisch einen Blick auf die Methode "Contextual Inquiry" nach Karen Holtzblatt und Hugh Beyer [3]. Diese Methode hat ein enormes Potenzial, welches in der Praxis aus meiner Sicht zu selten abgerufen wird. Hierbei führen wir Interviews direkt vor Ort durch, um den Nutzungskontext umfassend zu erfassen.
Contextual Inquiry im Detail
Eine der großen Stärken der Contextual Inquiry ist ihre Einfachheit und Flexibilität. Sie kann problemlos auch ohne dedizierte UX-Person von anderen Teammitgliedern übernommen werden.
Inhalte der Interviews:
- Artefakte zeigen lassen: Während der Interviews lassen wir uns von den Anwendern die für ihren Arbeitsprozess relevanten Artefakte zeigen.
- Beobachtung: Wir beobachten die Anwender direkt bei der Arbeit, um ihre Handlungsstrategien und Arbeitssequenzen besser zu verstehen.
- Kontext verstehen: Es ist ebenfalls wichtig zu beobachten, wie die Arbeit in eine physikalische, soziale und kulturelle Umgebung eingebettet ist.
Aber mit dem Interview ist natürlich nicht Schluss. Wir wollen nicht ein Interviewprotokoll erzeugen, welches anschließend ein tristes, wenig beachtetes Leben in einem Sharepoint- oder Confluence-Server verbringt. Nein, die Interviews werden gemeinsam mit dem PO und gerne auch interessierten Entwickler:innen ausgewertet. Ziel ist ein gemeinsames, einheitliches Verständnis unserer Aufgabe, damit jeder im Team in der Lage ist, Dinge kritisch zu hinterfragen.
Zwischenfazit
Der Weg zu einer besseren User Experience beginnt mit einem tiefen Verständnis der tatsächlichen Bedürfnisse und Probleme unserer Anwender und nicht mit Lösungen. Modelle wie der Double Diamond und Methoden wie die Contextual Inquiry helfen uns dabei, uns und anderen die richtigen Fragen zu stellen und die richtigen Probleme anzugehen. Nur so können wir sicherstellen, dass der Wert, den wir für unsere Nutzer schaffen, wirklich im Zentrum unserer Bemühungen steht.
Wenn wir dieses Verständnis erreicht haben, geht es endlich in den Lösungsraum. Hier fühlen wir uns wohl. Da kann doch eigentlich nichts mehr schief gehen, oder?
User Experience, Akt 3: "Du bist nicht der User!"
Bisher haben wir darüber gesprochen, wie wichtig es ist, das richtige Problem für unsere Anwender zu lösen. Nun wollen wir die Lösung tatsächlich umsetzen. Auch hier lauern einige Fallstricke. Einer der größten aus meiner Sicht: Wenn wir etwas umsetzen und die Lösung logisch und nachvollziehbar finden, gehen wir davon aus, dass auch unsere Anwender die Lösung ebenso verständlich finden werden. Nach dem Motto: "Wenn ich das verstehe, wird der Anwender das auch verstehen."
Was wir dabei aus den Augen verlieren, ist, dass wir (in den meisten Fällen) nicht selbst die Anwender unserer eigenen Lösung sind. Und selbst wenn, haben wir nicht mehr die notwendige Distanz zur Lösung, weil wir sie ja selbst mitentwickelt haben. Warum Anwender unsere Anwendung mit komplett anderen Augen sehen als wir, ist nur bedingt intuitiv. Mir hilft hier sehr das Verständnis von mentalen Modellen:
Das mentale Modell
Wann immer ein Anwender mit einem Produkt interagiert, hat er eine Vorstellung davon, wie dieses Produkt funktionieren wird. Dies ist sein "mentales Modell". Don Norman skizziert ein eingängiges Beispiel, um das Konzept des mentalen Modells zu erklären [4].
Nehmen wir an, du hältst einen Vortrag und nutzt einen sogenannten Clicker – eine kleine Fernbedienung, die es dir erlaubt, sich frei im Raum zu bewegen und dabei deine Präsentation fernzusteuern. Stellen wir uns vor, dieser Clicker sieht aus wie in Abb. 6. Welchen Knopf würdest du drücken, um zur nächsten Folie in der Präsentation zu gelangen?
Ich habe dieses Beispiel schon mehrfach in Vorträgen verwendet, und die Verteilung unter den Teilnehmern ist oft grob 60/40. Interessanterweise erhält meist die Option den größeren Zuspruch, die zuerst abgefragt wurde.
Offensichtlich ist die Benutzerschnittstelle des Clickers nicht so eindeutig, dass jeder intuitiv das gleiche Verständnis der Funktionsweise hat. Verschiedene Anwender wählen spontan unterschiedliche Knöpfe, und für jeden Einzelnen ist seine Wahl logisch und eindeutig.
UX und die unterschiedlichen mentalen Modelle
Die Anwender haben also unterschiedliche mentale Modelle davon, wie der Clicker funktionieren könnte. Im konkreten Fall können wir diese Modelle wie folgt erklären:
Modell 1: Die bewegliche Kamera
- Ansatz: Wir schauen durch eine Kamera auf die Folien, die alle untereinander an einer virtuellen Wand hängen. Durch die Betätigung des Clickers bewegen wir die Kamera.
- Aktion: Um zur nächsten Folie zu gelangen, muss ich die Kamera nach unten bewegen. Ich drücke also den unteren Knopf.
Modell 2: Das Endlospapier
- Ansatz: Die Kamera steht starr an einer Stelle, und die Folien hängen aneinander – wie Drucker-Endlospapier.
- Aktion: Um zur nächsten Folie zu gelangen, ziehe ich die Folien an der Kamera vorbei. Ich drücke also den oberen Knopf, um den Satz Folien nach oben zu ziehen und die nächste Folie zu sehen.
Beide Modelle begegnen uns auch bei der Arbeit mit Desktop-PCs und Touchgeräten: Das Modell der beweglichen Kamera passt zur Interaktion mit dem Rollbalken eines Fensters. Wenn wir zur nächsten Seite wollen, bewegen wir den Rollbalken nach unten. Auf einem Touchgerät schieben wir die Seite mit dem Finger nach oben, um weitere Seiten sichtbar zu machen.
Keines der Modelle ist besser oder schlechter als das andere. Das mentale Modell ist einfach da und variiert zwischen verschiedenen Anwendern. Dieses Beispiel veranschaulicht, dass man im UX-Design von einer Lösung absolut überzeugt sein kann, der Anwender im Zweifelsfall aber trotzdem eine andere Sicht hat.
Unser Ziel ist es also, das mentale Modell unserer Anwender zu verstehen, wenn sie mit unserer Anwendung interagieren. Oder besser gesagt: die verschiedenen mentalen Modelle. Denn wie gesagt gibt es nicht das eine gültige Modell – sondern viele, teilweise widersprüchliche Modelle. Nutzer eines Clickers können davon ein Lied singen, wenn sie mit einem "fremden" Clicker arbeiten, dessen Tasten anders belegt sind, als sie es erwarten.
Nach Möglichkeit sollten wir unsere Benutzeroberfläche so gestalten, dass ihr Bedienkonzept dem mentalen Modell möglichst vieler Nutzer entspricht. Wie könnte das obige Beispiel optimiert werden? Eine Möglichkeit wäre, die beiden Knöpfe nebeneinander anzuordnen. In dieser Anordnung gibt es eine größere Mehrheit dafür, dass der rechte Knopf weiter blättert und der linke zurück. Vermutlich, weil uns diese Form der Interaktion häufig am Computer begegnet, etwa in Wizards und bei Bildergalerien und wir – zumindest in der westlichen Welt – typischerweise Zeitachsen von links nach rechts aufzeichnen.
Das Verständnis der mentalen Modelle unserer Anwender hilft uns dabei, eine Lösung zu finden, die nicht nur wir, sondern auch unsere Anwender intuitiv bedienen können. Wir möchten, dass unsere Lösung die Erwartung der Anwender erfüllt. Das Stichwort hier ist: "Erwartungskonformität":
Erwartungskonformität als Schlüssel
Erwartungskonformität wird in der Norm DIN-ISO 9241-110 wie folgt definiert: "Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z. B. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Ausbildung und seiner Erfahrung sowie den allgemein anerkannten Konventionen."
Usability Testing
Um zu prüfen, ob unsere Lösung erwartungskonform zu unseren Anwendern ist, bieten sich Usability-Tests an. Diese sollten aus meiner Sicht in jedem Projekt zum Standard-Repertoire gehören. Ich kann mich in meiner Laufbahn an keinen einzigen Test erinnern, der nicht hilfreich gewesen wäre.
Usability-Tests dienen dazu, eine Lösung oder eine Lösungsidee mit einem Anwender zu verproben. Wir stellen also nicht einfach unsere Lösung vor und bitten um Feedback, sondern geben unseren Anwendern eine konkrete Aufgabe, die sie erfüllen sollen. Die Herausforderung für den Moderator eines Usability-Tests ist es dabei, die Tests möglichst realistisch durchzuführen. Dazu gehört auch, den Probanden idealerweise nicht zu helfen.
Usability-Tests erfüllen mich oft mit einer seltsamen Mischung aus Scham und Befriedigung: Scham, wenn man – als verantwortlicher Product Owner oder Entwickler – sieht, wie der Anwender an Dingen scheitert, die man einfach nicht bedacht hat. Befriedigung, wenn man wertvolle Dinge gelernt hat und wenn Designs und Designanpassungen so funktionieren wie gewollt.
Eine der ersten Fragen, die sich im Zusammenhang mit Usability-Tests stellt, ist die Frage, wann der geeignete Zeitpunkt für Tests ist. Diese Frage lässt sich erstaunlich einfach beantworten: So früh wie möglich. Und das bedeutet wirklich früh: lange bevor wir die erste Version der Software freigeben.
Ganz im Sinne der agilen Softwareentwicklung bevorzugen wir kurze Feedbackzyklen. Aus dieser Sicht macht es keinen Sinn, ein Design erst komplett fertig zu implementieren, wenn wir es bereits vorher hätten verproben können.
Usability-Tests sind bereits sehr früh im Projekt möglich, sei es auf Basis von Papier-Prototypen, Klick-Dummies oder schon etwas weitergehenden Prototypen. Dabei reicht es, wenn wir zum Zeitpunkt des Tests nur einen ganz bestimmten Pfad abbilden können.
Die Usability-Tests sind aber nicht mit der Durchführung der Tests selbst abgeschlossen. Mindestens ebenso bedeutsam wie Tests ist das anschließende Debriefing. Hier werden Beobachtungen ausgetauscht und es wird entschieden, welche Findings nun konkret angegangen werden. Wichtig ist auch hier, das gesamte Team einzubeziehen, um das gemeinsame Verständnis zu schärfen. So sind Probleme der aktuellen Lösung für alle transparent und jeder im Team kann Ideen zu Verbesserungen beitragen. Entwickler haben hier oft einen anderen Blick auf die Erkenntnisse und können alternative Lösungsansätze präsentieren, wenn die gemeinsamen Ziele und Herausforderungen klar sind. Deswegen freue ich mich in Projekten über Diskussionen auf Augenhöhe, die durch die gemeinsame Arbeit möglich werden.
User Experience Design – Fazit
Die drei Akte in unserem Drama zeigen typische Hindernisse auf dem Weg, eine gute User Experience zu erreichen und wie man sie überwinden kann. Wir haben es selbst in der Hand, und jeder von Euch kann aktiv daran mitarbeiten, dass Eure Projekte erfolgreich werden.
- Nehmt User Experience ernst und versucht sie bereits frühzeitig in euren Entwicklungsprozess zu integrieren! UX ist mehr als nur das Design Eurer Anwendung.
- Seid kritisch! Hinterfragt vorgegebene Lösungen, um sicherzustellen, dass Ihr wirklich Wert für Eure Anwender schafft! Dafür müsst Ihr die Ziele Eurer Anwender verstehen.
- UX ist dabei eine Teamaufgabe. Wir brauchen einen Dialog auf Augenhöhe zwischen beteiligten Experten.
- Verprobt Eure Lösungen und Lösungsideen! Und zwar so früh wie möglich. Nur dann ist sichergestellt, dass die Anwender damit auch so zurechtkommen, wie Ihr das erwartet.
Wenn Ihr alle diese Punkte berücksichtigt, werdet Ihr feststellen, wie viel Freude die Arbeit an einer guten Lösung bieten kann. Natürlich sind die in diesem Artikel angerissenen Methoden nur die Spitze des Eisbergs. Es existieren viele weitere Methoden, die je nach Kontext besser oder schlechter passen können. Die vorgestellten Methoden geben aber einen Einblick, wie Ihr mit wenig Aufwand viel Wirkung erzielen könnt.
Wenn Ihr die erwähnten Methoden vertiefen und weitere kennenlernen wollt, findet Ihr auf "Papperlapapp – Spaß mit Klammern" Videos, die sich intensiv mit Themen rund um User Experience und die Integration in agile Teams beschäftigen [5]. Oder aber Ihr sprecht mich direkt an, ich würde mich freuen, mich darüber mit euch auszutauschen.
User Experience Design auf den diesjährigen IT-Tagen
Spannende Vorträge und Workshops zum Thema UX-Design erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
- UX Thinking
- Das Piep-Ei
- Karen Holtzblatt und Hugh Beyer: Contextual Design: Evolved
- Don Norman: The Design Of Everyday Things
- Youtube: Papperlapapp - Spaß mit Klammern
