UX-Qualität messbar machen – und damit steuerbar.

• UX wird per Meinung entschieden

  Produktmanagement, Entwicklung und Design haben jeweils eine Vorstellung davon, was Nutzer brauchen. Ohne gemeinsame Messgröße gewinnt die lauteste Stimme oder die letzte Kundenbeschwerde. Jede Diskussion fängt pro Screen von vorne an.

• Tickets statt Kennzahlen

  Der einzige Indikator für Bedienbarkeit ist das Supportaufkommen. Das zeigt Schmerz, aber nicht Ursache – und es zeigt nichts über die Nutzer, die stillschweigend eine Excel-Liste neben dem System führen.

• Neues Modul, keine Baseline

  Ein Reporting-Modul oder ein Konfigurationswerkzeug geht live, und niemand hat vorher gemessen. Ob es besser oder schlechter läuft als der alte Weg, lässt sich nach dem Go-live nicht mehr belegen.

• Adoption bleibt eine Vermutung

  Lizenzen sind gekauft, Schulungen gehalten. Wie viele Key User und Sachbearbeiter das System tatsächlich für den vorgesehenen Prozess nutzen – und wie viele es umgehen –, weiß die Projektleitung nicht. Der Lenkungsausschuss fragt trotzdem.

• SLA-Risiko erst sichtbar, wenn die Frist reißt

  In regulierten Workflows gibt es feste Fristen. Das System zeigt den Rückstand oft erst, wenn er nicht mehr aufzuholen ist. Frühindikatoren wie Zeit bis zur Fehlererkennung oder Nacharbeitsquote fehlen im Produkt und im Reporting.

• OKRs ohne UX, UX ohne OKRs

  Das Unternehmen steuert mit Zielen und Kennzahlen, aber Usability taucht darin nicht auf. Also bleibt UX ein Abnahmeschritt am Ende – nicht Teil des Zielsystems, in dem über Kapazität entschieden wird.

• Pragmatische und hedonische Qualität
• User Experience Questionnaire (UEQ, UEQ-S)
• System Usability Scale (SUS)
• HEART: Happiness, Engagement, Adoption, Retention, Task Success
• Goals → Signals → Metrics
• Task Success, Time-on-Task, Fehlerrate
• Adoption und Nutzung
• Baseline und UX-Benchmark
• Qualitätsrituale: UX-Review, Design-Critique, Benchmark-Runde
• OKRs und UX-Key-Results
• UX-Tension, Design-Prinzip, Design-Regel
• Kritische Momente und SLA-Risikoindikatoren
• Usability nach ISO 9241-11: Effektivität, Effizienz, Zufriedenstellung
• Interaction Capability nach ISO/IEC 25010:2023

Pragmatische Qualität

Der Teil der UX-Qualität, der sich auf die Aufgabe bezieht: Erledigen Nutzer ihre Aufgabe erfolgreich, effizient und mit wenigen vermeidbaren Fehlern? Messbar über Task Success, Time-on-Task, Fehlerrate und die Skalen Durchschaubarkeit, Effizienz und Steuerbarkeit im UEQ.

Hedonische Qualität

Nach Hassenzahl der Teil der UX-Qualität, der über die Aufgabe hinausgeht: Stimulation (wirkt das Produkt interessant, anregend?) und Identifikation (passt es zu dem, wie Nutzer sich selbst und ihre Arbeit sehen?). In Fachsoftware entscheidet sie über Vertrauen – und Vertrauen über Adoption.

UEQ

User Experience Questionnaire von Laugwitz, Held und Schrepp (2008): 26 Gegensatzpaare auf sechs Skalen – Attraktivität, Durchschaubarkeit, Effizienz, Steuerbarkeit, Stimulation, Originalität. Deckt pragmatische und hedonische Qualität ab; die Kurzform UEQ-S hat acht Items. Frei verfügbar, mit Benchmark-Datensatz.

SUS

System Usability Scale von John Brooke (1996): zehn Aussagen mit fünfstufiger Zustimmung, verrechnet zu einem Wert von 0 bis 100. Technologieunabhängig und schnell – gut für Vergleiche zwischen Releases, schwach bei der Frage nach Ursachen.

HEART

Metrik-Rahmen von Rodden, Hutchinson und Fu (Google, CHI 2010): Happiness, Engagement, Adoption, Retention, Task Success. Für jede Dimension werden Ziele, Signale und Metriken definiert – statt mit den Daten zu beginnen, die zufällig vorhanden sind.

Adoption

Der Anteil der vorgesehenen Nutzer, die einen Prozess tatsächlich im System erledigen – nicht nur eingeloggt sind. Wir definieren Adoption je Rolle und Kernprozess und messen sie gegen den Zustand vor der Einführung.

Benchmark

Eine wiederholbare Messung von UX-Qualität mit festen Aufgaben, festen Instrumenten und festem Nutzerprofil, deren erster Durchlauf die Baseline bildet. Erst der zweite Durchlauf macht aus Zahlen eine Aussage über Veränderung.

UX-Tension

Ein Gegensatzpaar legitimer Ziele, das das Produkt nicht beiden gleichzeitig voll erfüllen kann – etwa Geschwindigkeit gegen Sicherheit oder Transparenz gegen Abstraktion. Wird im Team entschieden und dokumentiert, bevor über Interfaces gestritten wird.

Design-Prinzip

Die entschiedene Seite einer UX-Tension, formuliert als Vorrangregel: „Sicherheit vor Geschwindigkeit“, „Führung vor freier Exploration“. Ein Prinzip beantwortet, wie sich das System standardmäßig verhalten soll, und wird in prüfbare Design-Regeln übersetzt.

Task Success

Der Anteil der Nutzer, die eine definierte Aufgabe ohne Hilfe vollständig und korrekt abschließen. Die grundlegendste pragmatische Kennzahl – in fristgebundenen Fachprozessen wichtiger als jede Zufriedenheitsskala.

1. 01

   Messen statt streiten

   Ein UX-Benchmark mit Ausgangswert verwandelt Designdiskussionen in Entscheidungen. Er muss nicht akademisch sein; er muss wiederholbar sein und an Ziele gekoppelt, die das Produktteam ohnehin verfolgt – etwa als OKR-Input. Sobald Benchmark-Ergebnisse im Zielsystem auftauchen, wird UX gegen Features priorisierbar. Vorher ist sie ein Wunsch.

2. 02

   Pragmatische Qualität zuerst, hedonische nicht vergessen

   In Fachanwendungen zählt zuerst, ob Nutzer ihre Aufgaben effizient, sicher und mit wenigen vermeidbaren Problemen erledigen. Aber ein Produkt, das sich altmodisch oder widersprüchlich anfühlt, verliert Vertrauen – und Vertrauen entscheidet über Adoption und Nutzung. Deshalb gehören beide Dimensionen in den Benchmark und beide in die Priorisierung, auch wenn die hedonische in Fachsoftware nie den Vorrang bekommt.

3. 03

   Tensions entscheiden lassen, bevor jemand über ein UI streitet

   Sicherheit oder Geschwindigkeit, Führung oder Exploration: In regulierten Systemen sind das Geschäftsentscheidungen, keine Designfragen. Wer sie als Gegensatzpaare benennt und das Team entscheiden lässt, bekommt Prinzipien, die niemand mehr pro Screen anzweifelt. Aus den Prinzipien werden Regeln, aus Regeln Interface-Verhalten – und jede Entscheidung bleibt rückführbar.

4. 04

   Messgrößen vor der Umsetzung definieren, keine Ergebnisse behaupten

   Eine Strategie- und Prototyp-Phase liefert keine SLA-Quoten. Sie liefert die Indikatoren, mit denen die Umsetzung später bewertet wird: Zeit bis zum richtigen Report, Zeit bis zur Erkennung blockierender Fehler, Kontextwechsel, Nacharbeit, Support-Bedarf. Wer das vorher festlegt, kann nach dem Go-live ehrlich messen – und muss im Case nichts erfinden.

5. 05

   Rituale schlagen Einzelprojekte

   Ein einmaliger Benchmark ist ein Foto. Erst UX-Reviews, Design-Critiques und wiederkehrende Benchmark-Runden machen daraus eine Kurve, an der ein Team sich orientieren kann. Rituale brauchen Formate, Rollen und Entscheidungsregeln – sonst werden sie zur Statusrunde, in der gemessen, aber nicht entschieden wird.

6. 06

   Konsistenz ist Schulungsersatz

   Jedes Bedienmuster, das Nutzer nur einmal lernen müssen, spart Schulungsaufwand und Supportanfragen. Design-Regeln, die im Design System landen, wirken deshalb direkt auf Adoptionsmetriken und Hypercare-Last – beim Hersteller ebenso wie beim Anwenderunternehmen, das Masken und Workflows selbst konfiguriert.

Häufige Fragen

Wie messen Sie UX-Qualität?

Mit zwei Arten von Daten. Verhaltensdaten aus Usability-Tests und, wo vorhanden, aus dem Produkt: Task Success, Time-on-Task, Fehlerrate, Adoption, Nutzung. Und wahrgenommene Qualität über standardisierte Fragebögen wie UEQ oder SUS. Beides wird mit festen Aufgaben und festem Nutzerprofil erhoben, damit die Messung wiederholbar ist und ein zweiter Durchlauf Veränderung zeigt.

Was ist der Unterschied zwischen pragmatischer und hedonischer Qualität?

Pragmatische Qualität meint: Erledigen Nutzer ihre Aufgabe effizient, sicher und mit wenigen vermeidbaren Problemen? Hedonische Qualität meint nach Hassenzahl: Wirkt das Produkt anregend und passt es zu dem, wie Nutzer ihre Arbeit sehen – stimmig, modern, vertrauenswürdig? In Fachsoftware hat die pragmatische Vorrang; die hedonische entscheidet mit über Vertrauen und damit über Adoption.

Brauchen wir dafür ein Analytics-Tool?

Nein, nicht zu Beginn. Eine Baseline entsteht aus Usability-Tests und Fragebögen mit Fachanwendern. Produktanalytik kommt dazu, wenn Sie Adoption und Nutzung laufend beobachten wollen; dafür erarbeiten wir mit Engineering und Datenschutz einen Instrumentierungsplan, der nur die Ereignisse protokolliert, die eine definierte Metrik braucht.

Wie hängt das mit OKRs zusammen?

UX-Kennzahlen werden zu Key Results oder zu deren Inputs: etwa ein Task-Success-Ziel für einen Kernprozess oder ein Adoptionsziel für ein neues Modul. So taucht Usability im Zielsystem auf, in dem über Kapazität entschieden wird – und wird gegen Features priorisierbar, statt am Ende abgenommen zu werden.

Arbeiten Sie mit unserem Produktmanagement oder gegen es?

Mit ihm. UX-Strategie funktioniert nur, wenn Produktmanagement die Ziele mitformuliert und die Kennzahlen trägt. Wir bringen Methode, Instrumente und eine Außensicht ein; Prioritäten setzt weiterhin das Produktteam – jetzt mit Befunden statt Meinungen.

Wir haben schon ein UX-Team. Wozu dann UX-Strategie von außen?

Für den Teil, der im Alltag liegen bleibt: Baseline, Messsystem, Entscheidungsregeln, OKR-Anbindung. Wir arbeiten mit Ihrem UX Research und Design zusammen, nicht an ihnen vorbei, und übergeben so, dass Rituale und Benchmarks ohne uns weiterlaufen.

Wir führen ein Fachsystem ein, statt eines zu bauen – passt das?

Ja. Dann messen wir Adoption, Nutzung, Fehler und Nacharbeit gegen den Zustand vor der Umstellung und verbinden das mit unserer Einführungsbegleitung: Fachkonzept, UAT, Key-User-Schulung, Go-live und Hypercare bekommen definierte Messgrößen, über die der Lenkungsausschuss steuern kann.

Was ist eine UX-Tension, und warum sollte das Team darüber abstimmen?

Ein Gegensatzpaar legitimer Ziele – Geschwindigkeit gegen Sicherheit, Transparenz gegen Abstraktion –, das nicht beides voll erfüllt werden kann. In regulierter Software sind das Geschäftsentscheidungen. Wenn das Team sie einmal bewusst entscheidet, entstehen Design-Prinzipien, die nicht pro Screen neu verhandelt werden.

Veröffentlichen Sie Benchmark-Werte Ihrer Kunden?

Nein. Interne Benchmark-Werte, Kundennamen und Produktinterna bleiben vertraulich. In Cases beschreiben wir Vorher und Nachher qualitativ und nennen nur die Instrumente und Indikatoren, mit denen gemessen wurde.

Für Intermediäre: Welches Profil suchen Sie, wenn Sie uns anfragen?

UX Strategist, UX Lead oder Senior UX Consultant für komplexe B2B- und Fachsoftware, mit UX Research, Usability-Tests, Benchmarks, OKR-Arbeit, Design System und Figma; Deutsch verhandlungssicher, Englisch fließend. Einsatz remote, in München oder vor Ort nach Absprache.