Begriffsklärungen
Usability und User-Experience sind zwei anspruchsvolle und interdisziplinäre Aufgabengebiete, die in der Software-, Produkt- und Prozessentwicklung eine zentrale Rolle spielen. Sie verbinden nicht nur die Akteur:innen (Stakeholder) im Entwicklungsprozess miteinander (Auftraggebende, Fachexpert:innen, Entwickler:innen, Grafikdesigner:innen oder Benutzer:innen) und vermitteln zwischen diesen, sondern begleiten die Entwicklung auch durch alle Phasen: von der Ideenfindung bis zum Testen und Optimieren nach der Inbetriebnahme mit verschiedensten Methoden.
Doch was sind Usability und User-Experience?
Und was machen Expert:innen in diesen Bereichen eigentlich?
Usability ist ein Qualitätsmass, welches angibt, wie einfach, effizient und effektiv eine Software oder ein Produkt zu verwenden sind. Gleichzeitig bezieht sich die Bezeichnung Usability auch auf eine Disziplin, in der verschiedene Methoden eingesetzt werden, um die Bedienung eines Systems zu vereinfachen und zu verbessern.
Definition
Eine etwas überspitzte Definition hat David McQuillen geäussert: «Usability beschäftigt sich mit menschlichem Verhalten. Sie anerkennt, dass Menschen faul sind, dass sie emotional werden können und ganz generell Dinge oder Tätigkeiten bevorzugen, die einfach zu verstehen und zu handhaben sind im Gegensatz zu komplizierten und schweren Tätigkeiten (1).»
Der Begriff User-Experience (UX) umschreibt alle Eindrücke und Erlebnisse eines Nutzers bei der digitalen und/oder physischen Interaktion mit einem Produkt, Dienst oder einer Institution/Firma.
Im Gegensatz zur Usability ist die UX eines Produktes nicht mehr so einfach messbar, da sie auch viele hedonistische Aspekte (z.B. Freude, Stolz, Frustration, etc.) miteinbezieht und sich deshalb einfachen Messskalen entzieht.
Beiden Disziplinen ist gemeinsam, dass sie sich stark auf die Benutzerin/den Benutzer als das Mass aller Dinge beziehen. Dieser klare Bezug hat seine Wurzeln im User Centered Design (UCD), einer Philosophie oder Geisteshaltung, welche 1977 von Rob Kling (2) propagiert wurde und den Benutzer zum Zentrum der Aufmerksamkeit in der Produktentwicklung gemacht hat (im Gegensatz zum technologiezentrierten Ansatz, der bis dahin vorherrschend war).
Vereinfacht kann man sagen, dass Usability ein Bestandteil des UX Konzeptes ist – ein wichtiger Bestandteil von UX, denn ohne eine gute Usability wird es auch nie eine gute UX geben können.
(1) David McQuillen in «Taking Usability Offline» Darwin Magazine, June 2003.
(2) Kling, R. (1977). The organizational context of user-centered software designs. MIS quarterly, 41-52.
Usability & UX am IML
Am IML haben wir mit UX (U hoch X, früher U5) ein sehr erfahrenes und qualifiziertes Team von UX Expert:innen. Wir begleiten und beraten seit 15 Jahren die internen Entwicklungsprojekte (v.a. e-Assessment und e-Learning oder verschiedene Websites und -applikationen) des Instituts, arbeiten aber auch mit externen Auftraggebern zusammen, welche ein Bedürfnis nach qualifizierter UX-Begleitung haben.
Schwerpunkte
Angebot
- Contextual Inquiry (Beobachtungsinterview)
- Befragungen
- Expert-Evaluation
- Cognitive Walkthrough
- Usability-Evaluation
- Design Thinking Workshops
- Informationsarchitektur
- Interaction Design
- Prototyping
- Visual Design
Phasen der Produktentwicklung
Wie aber kann gute UX und Usability erreicht werden? Was sind dabei die Aufgaben von UX-Designer:innen und Usability-Expert:innen?
Die Vielseitigkeit dieser Berufsgattung können wir am besten aufzeigen, wenn wir uns die verschiedenen Phasen der Produktentwicklung genauer ansehen. Es gibt verschiedene Phasenmodelle, aber im Grundsatz sind sich diese Modelle alle ähnlich und unterscheiden sich v.a. im Detaillierungsgrad und den Bezeichnungen der Phasen.
1. Analyse («understand/research»)
In dieser Start-Phase ist es Aufgabe der UX, zusammen mit den Auftraggebenden die Ziele des Projektes genau festzulegen. Dabei werden die Benutzergruppen identifiziert (und daraus z.B «Personas» erstellt), bestehende Produkte oder Konkurrenzprodukte analysiert um v.a. die Probleme und Erwartungen der künftigen Nutzer:innen des Produktes in Erfahrung zu bringen (UCD), damit das System genau auf deren Bedürfnisse zugeschnitten werden kann.
Diese Phase ist sehr wichtig und wird oft unterschätzt (und stattdessen auf die Ideen der Firmenleitung abgestützt), ist aber in einem UCD Vorgehen unerlässlich. Typische angewandte Methoden in dieser Phase sind Interviews, Fragebogen, Beobachtungen (z.B. in einer «Contextual Inquiry» oder dem «Shadowing», wo die zukünftigen Benutzer begleitet und beobachtet werden bei ihrer Arbeit oder der Benutzung eines Produktes) oder die Analyse von bestehenden Nutzerdaten, z.B. von einem Vorgängerprodukt, oder die Analyse von Konkurrenzprodukten.
Im Anschluss muss Ordnung in diese Datensammlung gebracht werden. Aus all den verschiedenen Quellen werden Schlüsse gezogen und Prioritäten festgelegt. Während die Datensammlung meistens direkt und ausschliesslich vom UX Bereich vorgenommen wird, muss die Priorisierung unbedingt zusammen mit den Stakeholdern, nicht zuletzt dem Auftraggeber, vorgenommen werden. Diese Phase ist so wichtig (und oft auch langwierig), dass sie in einigen Phasenmodellen als eigenständige Phase gesehen wird.
Jetzt muss herausgearbeitet werden, welches die wichtigsten Bedürfnisse, Probleme und Anforderungen der Kund:innen und des Managements sind, wo die Entwicklung beginnen und wo der Hauptfokus im Projekt gelegt werden soll.
2. Design («ideate»)
Diese Phase besteht in der Regel aus ganz vielen, sich iterierenden Phasen, denn niemand kann allein auf Basis von Daten einen konkreten Design-Entwurf machen. Oft gibt es Dutzende möglicher Lösungen für ein bestimmtes Problem, selbst auf der konzeptuellen Ebene.
Die Arbeit der UX ist hier besonders wichtig: einerseits müssen möglichst viele Ideen generiert werden («ideate»), wie eine Problemstellung gelöst werden könnte, ein bestimmter Screen oder Dialog gestaltet werden könnte, wie die Grundmetapher der ganzen Applikation aufgebaut werden könnte. Andererseits geht es auch darum, den Stakeholdern in Workshops z.B. mit konkreten Skizzen («Wireframes») vor Augen zu führen, wie diese Ideen am Bildschirm aussehen würden.
Hier sind sowohl psychologische, organisatorische und kreative Skills von den UX Expert:innen gefragt, aber auch Gruppenführung und schlussendlich Durchsetzungsvermögen, um aus den vielen Ideen wenige, aber zielführende und konkrete Designs zu gestalten.
Der Grad, bis zu welchem in dieser Phase Designs bzw. Konzepte erstellt werden, variiert stark je nach Projekt und Reifegrad des Projektes. Während den Workshops werden oft nicht viel mehr als Skizzen oder sogar nur mit einem Stift hingekritzelte Details festgehalten. Oft ist es dann Aufgabe der UX, bis zum nächsten Workshop detaillierte Wireframes von allen Vorschlägen daraus zu machen, um allen Beteiligten die gleiche Ausgangslage bei den weiteren Diskussionen zu bieten.
Es kann aber auch sein, dass bereits in dieser Phase konkrete Visual Designs erstellt werden (z.B. weil bereits ein Styleguide vorliegt) oder sogar schon Applikationen mit einfachen Frameworks implementiert werden, z.B. wenn die Interaktion zw. den Benutzern und dem System zentral ist und diese mit statischen Wireframes nicht evaluiert werden kann.
3. Evaluation («validation»)
Teilweise kann die Design-Phase nicht von der Evaluations-Phase getrennt werden, weil die entstehenden Designs direkt evaluiert werden, statt immer weitere Varianten zu generieren. Dann wechseln sich Design und Evaluation in kurzen Iterationen ab.
Oft aber muss zuerst die übergreifende Methapher der ganzen Applikation geschaffen und nicht Details evaluiert werden. Trotzdem muss oft aus verschiedenen möglichen Varianten (es gibt immer eine Vielzahl an möglichen Lösungen für ein Problem) die ausgewählt werden, welche die Anforderungen der Benutzer:innen am ehesten erfüllt.
Die Evaluation wird deshalb möglichst wieder mit den zukünftigen Nutzern durchgeführt, denn nur sie können sagen oder zeigen, welche Lösung die passendste ist. Hierzu gibt es eine grössere Zahl von Evaluationsmethoden:
- «Guerilla Testing» (Tests nicht notwendigerweise mit der eigentlichen Zielgruppe, sondern einfach dort wo man gerade Leute findet die ein paar Minuten Zeit haben, z.B. in der Cafeteria)
- Expert-Evaluation (UX Expert:innen evaluieren die verschiedenen Vorschläge auf Basis von vorgegebenen Kriterien (Heuristiken))
- Cognitive Walkthrough (meist in der Gruppe werden verschiedene Aufgaben mit den Testdesigns gelöst)
- Labor Evaluation (klassische Usability-Evaluation in einem Labor, u.U. auch mit Eye-Tracking)
und viele mehr. Die Wahl der geeigneten Evaluationsmethode hängt schlussendlich auch von dem Reifegrad des Designs und der Zahl der Varianten ab sowie dem zur Verfügung stehenden Zeit- und Geld-Budget.
Die Evaluation ist eine Stärke der Usability Disziplin, da mit verschiedenen Metriken auch vergleichbare Resultate entstehen, die zu einer konkreten Entscheidung führen können. Wie oben erwähnt, ist es im UX Bereich deutlich schwieriger, z.B. hedonistische Attribute von verschiedenen Designs zu vergleichen.
3b. Iterationen
4. Implementation
Und schliesslich folgt die eigentliche Umsetzung der Applikation, die Implementation. Da diese Phase meist zeitaufwändig und entsprechend teuer ist, versucht man in den ersten drei Phasen möglichst viele Probleme bereits gelöst und Unklarheiten beseitigt zu haben.
Trotzdem wird oft erst in dieser Phase ein Grafikdesigner:in hinzugezogen, ein konkretes Corporate Design entworfen und entschieden, mit welchen Frameworks die Programmierer arbeiten werden. Das heisst, dass die UX wieder gefordert ist, aus den Mockups und Prototypen der vorherigen Phasen jetzt ganz konkrete, pixelgenaue Screens zu zeichnen – angelehnt an das Design Framework und in enger Zusammenarbeit mit der/dem Grafiker:in und oft auch dem Marketing/Management.
In dieser Phase geht es darum, jedes Element des User Interfaces (UI) so genau vorzugeben, dass die Entwickler:innen nicht davon abweichen und ein insgesamt kohärentes und attraktives UI und somit ein attraktives Benutzererlebnis im Endprodukt entsteht und bestehen bleibt.
UCD als Prozess
Heute durchläuft ein neu geplantes Produkt üblicherweise diese Phasen. Oft werden von Auftraggeber:innen aus Ressourcengründen leider Abkürzungen verlangt, die sich aber immer wieder in der Implementationsphase oder spätestens beim Kunden rächen, weil die UX eben doch nicht so grossartig ist wie gewünscht.
Auch bei Erweiterungen oder der Implementation von neuen Features in ein bestehendes Produkt sind diese Schritte wünschenswert, auch wenn sie nicht in jedem Fall ausführlich nötig sind. Für Produkte, gerade Software, gibt es eigentlich kein «es ist fertig» mehr, denn ständig verändern sich die Umstände, Technologie, Konkurrenz, wirtschaftliche Situation, Bedürfnisse der Benutzer:innen, Erwartungen der Firma oder der Entwickler an die Software, so dass sie immer im Status der Veränderung und somit UX Begleitung nötig ist.
UX als transdisziplinäre Disziplin
Die Aufgaben und Tätigkeiten von UX Expert:innen sind sehr vielfältig. Neben Kreativität, schneller Auffassungsgabe in neuen Aufgabengebieten, genauen Analysefähigkeiten oder einem Flair für Grafikdesign sind es vor allem auch die kommunikativen Fähigkeiten, die ein:en gute:n UX Designer:in auszeichnen.
Überhaupt ist es nicht selten so, dass die UX alle Stakeholder wieder zurück auf den Weg zum Ziel (oder der Vision) bringen muss im Verlauf der (manchmal mehrjährigen) Projektphasen. Sei es, weil es personelle Wechsel gibt oder weil sich die Stakeholder nach einer gewissen Zeit wieder in ihren Partikularinteressen verlieren. Oft liegt es an der UX, den kontinuierlichen Projektverlauf und ein konsistentes Projektresultat zu verteidigen, weil es für eine gute User Experience unabdingbar ist, die Wünsche & Bedürfnisse der Benutzer:innen immer im Fokus zu behalten und die festgelegten Ziele konsequent zu verfolgen.
In jeder Phase des UX Zyklus muss mit unterschiedlichsten Stakeholdern in verschiedenen Rollen kommuniziert werden:
- Ein Interview mit einem Benutzer, um an die gewünschten Informationen zu kommen für die Analyse.
- Dem Auftraggeber oder «Product Owner» zurückspiegeln, dass die Vorgaben oder spezifizierten Anforderungen nicht ausreichen.
- Einen Workshop oder eine Fokusgruppe leiten, damit auch wirklich nützliche Informationen fliessen.
- Mit den Programmierern aushandeln, inwiefern sie Vorgaben erfüllen müssen oder können.
- Die richtigen Leute in einem Projekt zusammenbringen, auch wenn sie sich noch nicht kennen.
- Jemand Fremdes in der Cafeteria ansprechen für einen Guerilla Test.
- Einen Prototypen (oder mehrere) vor dem Management einer Firma vorstellen und die Vor- und Nachteile aufzeigen.
- Und nicht zuletzt schriftliche Berichte verfassen, um die erarbeiteten Informationen Dritten zugänglich und somit verständlich zu machen.