
User Experience (UX) in 3 Sätzen erklärt
- Der Wurm muss dem Fisch schmecken, nicht dem Fischer.
- Design ≠ Layout ≠ UX
(Design und Layout können jedoch helfen UX zu verbessern, wenn sie richtig angewendet werden) - Konventionen einhalten!
Ein paar Grund-Begriffe:
Usability = Use + ability
Bedeutung: Verwendbarkeit, Brauchbarkeit, Bedienbarkeit, Nutzbarkeit, Gebrauchstauglich
User Experience = User + Experience
(Experience: Erfahrung(en), Erlebnis, Praxis, Erfahrungswert, Sachkenntnis)
Software-Ergonomie in Duden:
benutzerfreundliche Ausrichtung von Datenverarbeitungsprogrammen.
Software-Ergonomie in Wikipedia:
Software-Ergonomie (zur Wortherkunft siehe Software und Ergonomie) ist die Arbeit hin zu leicht verständlicher und schnell benutzbarer Software unter den gebotenen technischen Möglichkeiten und unter der Einhaltung definierter bzw. empirisch entstandener Standards und Styleguides. Die Software-Ergonomie ist ein Teilgebiet der Mensch-Computer-Interaktion, und ihr Ergebnis ist die Gebrauchstauglichkeit von Computerprogrammen.
Gegenstandsbereich der Software-Ergonomie im eigentlichen Sinne ist der arbeitende Mensch im Kontext (Softwarenutzung an Arbeitsplätzen). Allgemein wird heute die Benutzung von bzw. die Interaktion mit Computern betrachtet. Dies bedeutet die Berücksichtigung (neuro)psychologischer Aspekte beim Entwerfen der Software – wie dies methodisch auch die Ingenieurpsychologie anstrebt –, um eine optimale Mensch-Maschine-Schnittstelle zur Verfügung zu stellen. Dies soll sich in besonders leicht verständlichen funktionalen Einheiten ausdrücken (Bsp. einfache Dialoge bei Systemen mit GUI). Die Entwicklung gebrauchstauglicher Software wird im Rahmen des Usability-Engineering geleistet.
Wer ist der User?
Zu einem System gehören nicht nur Hardware u. Software, sondern auch Anwender (User).
Der User unterscheidet sich durch:
- Kultur (Sprache, Symbole, Farben),
- Bildungs-Niveau,
- domänenspezifisches Wissen,
- Kontaktfreudigkeit,
- Gemütszustand (schlechter Tag, private Probleme, Eile, Stress, Müdigkeit,…)
- …
Und einiges mehr.
Es ist wichtig sich bewusst zu sein, dass viele Anwendungs-User in sogenannte Dritte-Welt-Länder, noch nie einen PC mit Maus und Tastatur gehabt, oder damit gearbeitet haben.
Diese besitzen jedoch meist ein Smartphone. Genauso wie das Festnetz-Telefon durch den Einsatz und schnelle Verbreitung von Handys und Handy-Masten übersprungen wurde, wurden in viele Länder die PCs durch Smartphones (und teilweise Tablets) übersprungen.
Somit ist es verständlich das Einigen die Verwendung von Tasten-Kombinationen („Tastatur-Kung-Fu“), Kontext-Menüs, F1 – F12 und Escape-Tasten, sowie Tool-Tipps teilweise oder gar völlig unbekannt sind.
Das sollte auch bei der Einschulung der User sowie schreiben der Manuals berücksichtigt werden.
UX Eigenschaften
Allgemein gebräuchliche Eigenschaften von Usability:
- Nützlich:
Kann es etwas, das die Leute brauchen? - Erlernbar:
Können Leute herausfinden wie es funktioniert? - Einprägsam:
Müssen die User es für jeden Gebrauch erneut lernen? - Effektiv:
Erledigt es seinen Job? - Effizienz:
Tut es das in einem angemessenen Zeitraum und mit zumutbarem Aufwand? - Begehrenswert:
Werden die User es mögen? - Reizvoll:
Ist der Gebrauch erfreulich oder macht er sogar Spaß?
UX Definition von Steve KRUG:
„Eine Person mit durchschnittlicher (oder sogar unterdurchschnittlicher) Fähigkeit und Erfahrung versteht, wie man das Ding benutzt, um etwas zu erreichen, ohne dass dabei der Aufwand größer als der Nutzen ist.“
KRUGs erstes Gesetz der Usability
Was ist Usability?
Eine Anwendung sollte – so weit, wie es nach menschlichem Ermessen möglich ist – klar sein.
Der User sollte in der Lage sein „es zu kapieren“ – was die Ansicht darstellt und was man mit ihr machen kann –, ohne lange überlegen zu müssen.
Wie viel Klarheit?
Wenn der User sich denkt:
„Oh, das ist ja ein Menü → ich kann es anklicken.“
„Ah ja, da ist der Button zum Speichern.“
„Da ist ja das Bestellformular → was ich wollte.“
Was ist Unklarheit?
Wenn der User eine Ansicht (gilt auch für Sektionen und Steuer-Elemente) ansieht, die ihn zum Überlegen zwingt, sind alle Gedankenblasen über seinem Kopf voller Fragezeichen.

Grundprinzip von UX: Eliminierung der Fragezeichen.
Mann kann nicht alles offensichtlich machen! Aber das Ziel sollte sein, dass jede Ansicht (gilt auch für Sektionen und Steuer-Elemente) offensichtlich ist, damit der Durchschnittsanwender beim Ansehen weiß, worum es geht und wie man sie nutzt. Er kapiert es, ohne darüber nachzudenken.
Warum müssen die Fragezeichen eliminiert werden?
Wenn wir (User) die Anwendung benutzen, trägt jedes Fragezeichen zu unserer kognitiven Belastung bei und lenkt unsere Aufmerksamkeit von der momentanen Aufgabe ab.
Die Ablenkungen mögen nur gering sein, aber sie addieren sich, und ein Tropfen bringt das Fass zum Überlaufen.
Grundregel:
Die Leute mögen es nicht, darüber nachzugrübeln, wie man etwas macht (Wer liest gerne die Manuals zuerst durch? „TL;DR“* in Kommentaren, Chats und Blogs,… Anm. d. A.). Die Tatsache, dass die Ersteller der Anwendung sich keine große Mühe gaben, die Dinge offensichtlich – und einfach – zu gestalten, kann unser Vertrauen in die Anwendung und ihre Herausgeber untergraben.
*) Abkürzung des Internet-Kunstbegriffs „Too Long; Didn’t Read!“
Beispiel für Dinge die den User zum Nachdenken zwingen:
- Niedliche oder clevere Namen, falsche oder nicht gebräuchliche Begriffe
- firmenspezifische oder fremdartige technische Bezeichnungen
- nicht offensichtlich anklickbare Buttons, Drop-Down-Listen, Listen-Elemente, Links,…
- „Datum von“, „Datum bis“: ist das inklusive oder exklusive heute/gestern/…?
- Ich habe die Uhrzeit in Datum-UI eingegeben, aber die Uhrzeit-UI zeigt immer noch XYZ an. Was habe ich falsch gemacht?
- Muss ich jetzt die Anwendung Neustarten (um die Einstellungen anzuwenden) oder nicht?
- Wurde die Aktion XYZ durchgeführt oder nicht?
- Muss ich auf „Speichern“ oder „Übernehmen“ klicken?
- Muss ich auf „Cancel“ oder „Close“ klicken? Was ist der Unterschied?
- Ich klicke auf dem Button „Kopieren“ aber es tut Nichts! Warum? Habe ich was falsch gemacht?
- Was ist „Initialisieren“?
- Uuups! Fehlermeldung „Object XYZ throw NullReferenceException….“. Was heißt das? Hab ich was falsch gemacht? Kann ich es nochmal probieren? Muss ich jemandem davon benachrichtigen? Kann ich weiter damit arbeiten oder muss ich die Anwendung Neustarten?
An welche Support-E-Mail-Adresse muss ich schreiben? Welche Hotline-Nummer muss ich wählen? Was soll ich dem Support-/Hotline-/Techniker sagen? - …
Also warum UX?
Die Ansichten offensichtlich zu gestalten, ist wie die gute Beleuchtung in einem Geschäft: Alles erscheint einfach besser. Die Nutzung einer Anwendung, die uns nicht zum Nachdenken über Unwichtiges zwingt, fühlt sich mühelos an, wogegen das Kopfzerbrechen über Dinge, die uns nichts bedeuten, Energie, Nerven, Enthusiasmus und Zeit raubt.
Die meisten User haben weit weniger Zeit mit dem Betrachten der von uns designten Ansichten/Fenster/Manuals, als uns lieb ist.
Ergebnis: Klarheit oder zumindest selbsterklärend.
Die User haben ein Ziel. Sie wissen, dass sie nicht alles lesen müssen. Sie sind gut darin Dinge zu überfliegen. Darin sind sie geübt (in der Sprache der Neurologen: konditioniert).
Deswegen: die User wählen in der Realität die erste annehmbare Option (Satisficing1), also ausreichend befriedigend. Zur Erinnerung: Gemütszustand der User!
Die User befassen sich nicht damit, wie etwas funktioniert, sondern wursteln sich durch (Beispiel: Manuals/Bedienungs-Anleitungen).
Woher kommt das?
- Den meisten von uns ist es egal, ob wir die Funktionsweise verstehen, solange wir etwas benutzen können
- Wenn wir etwas finden, das funktioniert, bleiben wir dabei. Wir neigen dazu keinen besseren Weg zu suchen.
- Wenn die User eine Ansicht kapieren ist die Wahrscheinlichkeit viel größer, dass:
- sie das Gesuchte finden (was gut für User und Hersteller ist)
- sie die gesamte Anwendung verstehen
- sie sich schlauer fühlen und haben mehr das Gefühl der Kontrolle
Ein paar Punkte zum Überfliegen von Design und Layout:
- Vorteile von Konventionen nutzen
- Effektive visuelle Hierarchien erzeugen
- Einteilung der Ansichten in klar definierte Bereiche
- Keine Zweifel darüber lassen, was anklickbar ist
- Minimierung des „Rauschens“
- Formatierung der Inhalt, damit er sich leichter überfliegen lässt
Wichtigste über Navigation:
- Wo bin ich (da)? und
- Wo möchte ich hin (dort)? Daraus resultiert
- Wie komme ich dorthin (Strecke/Weg, Route)?
1 Satisficing ist ein Kunstbegriff bestehend aus: Satisfaction + Sufficient
Vorgehensweise bei Projekt-Beginn
- UML Use Case Diagramm:
- welche Akteure (User) werden
- welche Funktionen (Was)
- wann und
- wo aufrufen/anwenden
- UML Zustands Diagramm:
- In welcher/welches Ansicht/Fenster/Menüpunkt beginnt das Ganze?
- Was sind die nächsten Schritte?
- Durch welche Daten/Zustände werden welche UI-Elemente aktiviert/deaktiviert?
- Was sind illegale Eingaben/Aktionen? Wie soll darauf reagiert werden?
- Was wenn bei der Aktion XYZ (Laden, Speichern,…) ein Fehler auftritt?
- Muss der User alle bisherige Angaben (z. B. in Formular) nochmal eingeben? Zumutbar?
- Muss der User die Anwendung Neustarten? Oder Admin benachrichtigen bzw. Hotline anrufen?
- …
- Wie kann dem User am Ende der Aktions-Kette signalisiert werden, dass alles gut gegangen oder etwas Fehlgeschlagen ist?
- Sind Zusatz-Informationen notwendig?
- Kann dem User Vorschläge unterbreitet werden, was er/sie tun kann damit es funktioniert?
- Wo bzw. in welche Dokumentation oder Manual kann der User mehr darüber lesen?
- …
- Wireframes / Mockups erstellen!
- Reviews!
- Test von Wireframes / Mockups auf dem Papier…
- Verbessern und nochmal Testen!
- Erst, wenn Tests erfolgreich sind, wird mit der GUI-Entwicklung begonnen
- Jetzt kann die GUI qualitativ auf UX getestet werden (periodisch/zyklisch!)
- Falls in neue Anwendungs-Version neue Funktionen hinzugekommen sind (Menüs, Menü-Punkte, Buttons, Listen udg.) → auf UX nochmal Testen!
Standards & Konventionen
Die Standards und Konventionen sind nicht aus Langweile oder einfach aus der Luft gegriffen.
Irgendjemand hatte die Idee zuerst. Wenn die Idee gut war und sich als nützlich erwies, wurde es mehr und mehr kopiert und verbessert. Irgendwann haben die Leute das Ding öfters überall gesehen und wissen worum es sich handelt und wie es funktioniert. Sie müssen nicht nachdenken (in der Sprache der Neurologen und Pädagogen: Model-Lernen, oder einfach Kopieren).
Die Aufgabe von Layout und Design ist nicht, das Rad neu zu erfinden!

Selten führt das Neuerfinden des Rades zu einem revolutionärem, neuen Fahrgerät. Aber oft geht dabei einfach nur Zeit drauf.
Wenn man, eine existierende Konvention nicht nutzen kann/will, muss man sicher sein, dass der Ersatzvorschlag:
- Offensichtlich und
- selbsterklärend ist und
- kein Anlernen benötigt oder
- es einen so extrem großen Wertzuwachs bedeutet, dass etwas Anlernzeit gerechtfertigt ist.
Klarheit übertrumpft Konsistenz!
Was bringt es, wenn etwas konsistent unverständlich ist?
Beispiele für Konventionen:
Form und Farben:
Egal wo Sie mit dem Auto fahren, ob in: Iran, Chile, Mongolei, Mexiko, Marokko, Québec, Thailand oder China,… die wichtigsten und notwendigsten Verkehrszeichen sehen alle gleich aus (bis auf die Schrift).

Positionierung der Funktionen:
Egal wer das Auto gebaut hat, egal ob manuelle oder automatische Schaltung, und egal welches Model das Auto ist: Die Positionen und Funktionen der Pedalen sind eindeutig. Man muss nicht nachdenken.

Abgerundete Ecken bei Schalter und Tastatur:
Beim Überfliegen einer Ansicht suchen wir nach Hinweisen, die Dinge als anklickbar kennzeichnen.

Entstandene (Ideen) Standards:


Signal-Stärke und Rauschen (= Lärm)
Beispiel fürs Rauschen/Lärm:
- Zu viele/lange Texte (Absätze kurz halten)
- viele Ausrufezeichen
- verschiedene Schriften und bunte Farben
- automatische Animationen (hineinfahren/hinausfahren von mehreren Steuer-Elementen, wenn mit der Maus über die Ansicht gefahren wird)
- Keine oder wenige Listen mit Gliederungspunkten (Manuals, Fehler-Behebungs-Vorschläge,…)
- Nicht hervorgehobene Schlüsselbegriffe (= Signal)
Unordnung:
- Jede Ansicht ist anders aufgeteilt
- Durch zu große Dimensionierung verliert ein Steuer-Element seine Wieder-Erkennbarkeit
- Dinge mit gleicher Funktion (Status-Texte, Labels, Buttons,…) haben unterschiedliche Größe, Position, Form, Schriftart oder Farbe (bei mindestens einer Ansicht)
- Neue Schriften oder Farben auf mindestens einer Ansicht
- Nicht genug Abstand
- Nicht eindeutig Zuordenbar
- Nicht betitelt oder beschriftet (Was kann ich in dieser Drop-Down-Liste auswählen?)
- Unnötige Umrandung(en) oder Rahmen suggerieren das Element (z. B. Button oder Combo-Box) ist etwas Eigenes und hat nichts mit den UI Elementen darunter/darüber zu tun
Erstes Beispiel für UX-Test: Wo bin ich?
Schichtwechsel! User Anton geht. User Bernd kommt.
- Was sieht er?
- Muss Bernd nachdenken/grübeln welche Ansicht er sieht?
Vor den UX Verbesserungen

Nach den UX Verbesserungen

Zweites Beispiel für UX-Test: Wo finde ich XYZ?
Die Produktion steht! Der für die Produktion verantwortlicher User (Maschinen-/Hallen-Chef oder Produktions-Leiter) eilt gestresst und genervt zum Bildschirm. Er hat die Fehler-Meldung „Unbekannte Produkt-Nummer!“ bekommen und nun sucht er (ungeduldig) nach Anweisungen für die Konfiguration.
Er versucht möglichst schnell (durch Überfliegen) die interessante Sektion zu finden.
- Muss er alles durchlesen?
- Muss er viel nachdenke/grübeln?
- Warum?
- Was ist hier das Rauschen/Lärm?
- Wo sind die Signale?
Vor den UX Verbesserungen

Nach den UX Verbesserungen

Maximale Anzahl der Klicks für die Navigation oder Erledigung einer Aufgabe:
Die Anzahl ist relativ egal, solange diese Klicks unüberlegt getätigt werden können.
Als Richtlinie: ca. max. 3 Klicks.
Warum sollte der User N Mal klicken um zu XYZ zu kommen?
Warum sollte der User N Ansichten/Views oder gar andere Stellen/Fenster/Dokumente (User Manual, PDF) suchen um alle benötigte Informationen zusammenzubekommen?
Kann man den XYZ klickbar machen, damit der User mit nur einem Klick darauf, sofort das Dokument öffnen/speichern/sehen kann?
Einige Wahrheiten über UX-Tests
- Wenn man eine großartige Anwendung haben will, muss man es testen.
- Einen einzigen User testen ist auf jeden Fall besser als gar keine Tests.
- Einen User zu Beginn des Projekts testen zu lassen, ist besser als 50 gegen Ende.
Was wird getestet?
Qualitative UX-Eigenschaften:
- Klarheit
- Offensichtlichkeit
- Wiedererkennbarkeit
- Einhaltung von Konventionen/Standards
- Navigation
- Wie lange der User, für die Erledigung bestimmter Aufgaben benötigt hatte
- Woran der User, während der Erledigung der Aufgaben gegrübelt/gedacht, bzw. welche Fragen er sich gestellt hat
Welche Outputs nach dem UX-Test gibt es?
- Video
- Analyse-Bericht mit:
- Liste von erledigte oder nicht-erledigte Aufgaben (wenn nicht erledigt: der Grund)
- Liste der gröbsten Mängel (max. 10)
- Verbesserungsvorschläge
Wie wird entschieden welche der Mängel sofort zu beheben sind?
Nach Return-on-Investment (RoI):
Es wird eine engere Auswahl-Liste erstellt. Der Zweck der Auswertung ist, die schwerwiegendsten Probleme zu identifizieren, damit diese zuerst behoben werden.
Vorgehensweise:
- Verbesserungen die leicht und schnell umgesetzt werden können zuerst.
- Verbesserungen die etwas mehr Zeit benötigen fürs Später einplanen.
- Falls die Anwendung (das Projekt) kurz vor dem Liefer-Termin steht und die Behebung eines der Mängel inklusive dessen UX-Test nicht zu schaffen ist, dann für nächste
Roll-Out planen. - Re-Design ausschließlich, wenn das Projekt noch in Anfangs-/Entwicklungs-Phase befindet, sonst nie (diese müssen leider dann akzeptiert/hingenommen werden!).
Vorschläge für mehr Effizienz, Zeit- und Kosten-Ersparnis bei den GUI-/Anwendungs-Projekten:
- Fürs Layout (Ausrichtung, Positionierung/Platzierung, Abstände, Dimensionen) ein möglichst einfaches Konzept/Model ausarbeiten (Wireframes) und das Layout minimal halten. Später können diese leicht und schnell hinzugefügt, präzisiert, angepasst und detaillierter gestalten werden, und zwar einmalig.
- Design (Schrift-Arten, Farben, Symbole udg.) weglassen, oder sehr einfach und „global“ änderbar halten. Global bedeutet wie z. B. die einmalige Definition von Hintergrund-Farbe oder Schrift-Größe für Buttons (Schaltflächen) unter einzigartigen Namen in einer globalen Stil-Datei („styles.xaml“) wie z. B.:
- Button-Background-Color = Light-Gray
- Button-Font-Size = 14 pixels
Alle Buttons nutzen dann die in Stil-Datei definierte und benannte Werte.
Dadurch kann man durch das Anpassen/Ändern des Wertes (z. B. für die Schrift-Größe) an einer einzigen Stelle (in „styles.xaml“), alle Buttons einheitlich anpassen. Funktioniert extrem leicht und schnell. RETURN ON INVESTMENT!
Kurzes Beispiel für einen UX-Test-Bericht mit Liste der Mängel sowie deren Verbesserungsvorschläge:
Anwendung: ProductionControlClient
Version: 1.2.3.4
Test-Leiter: Pedram GANJEH-HADIDI
Test-User: Anna BERGER
Datum: 2022-03-04
Aufgaben–Liste/Tabelle:
Nr. | IST | SOLL | Erledigt/Grund |
1. | Angemeldet als Admin, gezeigt wird die Ansicht Produktion | Weiß der User welche Ansicht er vor sich hat? | Nein! Weil… |
2. | Wie 1. | Der User soll neue Produktion mit dem Namen „P123“ anlegen. | Ja |
3. | Gezeigt wird die Ansicht Produktions-Klassen | Umbenennen der „P123“ in „Q456“ | Nein! Weil… |
4. | Wie 2. | Der Wert von System-Einstellung XYZ soll auf 1,23 geändert u. gespeichert werden | Ja |
… | … | … | … |
Worüber der User gegrübelt hat:
- Bei Aufgabe 1 hat er die Drop-Down-Liste XYZ nicht als solches erkannt und hat danach gesucht.
- Bei Aufgabe 3 könnte der User nicht herausfinden wie der Name der P-Klasse geändert werden kann.
- Während der Aufgabe N wurde eine Fehler-Meldung Error-0815 ausgelöst. Der User war sich nicht sicher, ob er weiterarbeiten kann oder die Anwendung neu-starten muss.
- …
Verbesserungsvorschläge:
- Die Drop-Down-Liste XYZ beschriften (mit einem Label über oder Links davon) und ein Tooltip (Balloon-Text) hinzufügen mit dem Text „Hier können Sie XYZ auswählen“.
- Der Text für die Fehler-Meldung Error-0815 ändern, damit der User weiß, dass er die Anwendung neu-starten muss.
- …
Wie werden die Testaufgaben gewählt?
- Return-on-Investment (RoI)
- Relevanz
- Pareto-Prinzip (80% / 20% Regel)