UX-Metriken: Usability, Task Success, Time-to-Completion, NPS

Der Großteil von UX-Arbeit wird nicht gemessen. "Usern gefällt der neue Flow" bringt Ihnen ein Nicken aus dem Raum. Der PM kommt mit einem Churn-Chart. Sie kommen mit einer Figma-Datei. Wer gewinnt das Roadmap-Argument?

Wenn Sie jemals in einem Quarterly Business Review gesessen und zugesehen haben, wie Ihr Scope schrumpft, während der Engineering-Manager ein Refactoring mit Durchsatz-Zahlen verteidigt, dann wissen Sie bereits, worum es geht. Design braucht eigene Zahlen. Keine Vanity-Dashboards. Kein "Engagement um 4% gestiegen." Einen kurzen, vertretbaren Stack, der einem Head of Product in unter 60 Sekunden sagt, ob das Design funktioniert.

Hier ist der Stack, den ich verwende, die Diagnose, die den Fehlermodus aufdeckt, über den niemand spricht, und die QBR-Folie, die ohne Änderungen weitergeleitet wird.

Warum das gerade jetzt wichtig ist

Design Leads werden gebeten, Headcount gegen KI-Tooling zu verteidigen. "Wir haben 14 design tokens geliefert" ist keine Verteidigung. "Die Task-Success-Rate ist beim Signup-Flow von 71 % auf 88 % gestiegen, und Tickets pro tausend User sind um 22 % gefallen" schon.

Das ist keine Übertreibung. In den letzten zwei Performance-Zyklen, die ich beobachtet habe, hatten alle UX-Teams, die Headcount verloren, eines gemeinsam: Sie konnten keine Zahl produzieren, die für das Unternehmen relevant war. Die Teams, die gewachsen sind, teilten ein Vokabular mit dem Produkt und hatten eine Baseline, die sie jedes Quartal aktualisierten. Das ist der gesamte Unterschied.

Zahlen ersetzen kein Handwerk. Sie schützen es.

Die fünf Metriken

Wählen Sie diese fünf. Fügen Sie keine sechste hinzu, bis Sie diese zwei Quartale in Folge berichtet haben. Mehr Metriken machen Ihre Folie schwächer, nicht stärker.

1. Task-Success-Rate

Die Task eng definieren. Nicht "das Dashboard nutzen." Sagen Sie "ein neues Projekt erstellen, ein Teammitglied einladen und die erste Aufgabe zuweisen." Dann zählen, wie viele User abschließen, ohne Hilfe, ohne Zurückgehen, ohne Abbrechen.

Ziel: über 85 % für jeden Core-Flow, der Umsatz oder Retention treibt. Unter 70 % bei einem Flow, den Sie an zahlende Kunden liefern, ist ein Bug, keine Design-Präferenz.

Wie zu instrumentieren: Session-Replay (FullStory, LogRocket, Hotjar) für Traffic-starke Flows, moderierte Tests mit n=12 oder mehr für alles Neue. Zwölf ist der Schwellenwert, ab dem Sie dasselbe Problem zweimal sehen. Darunter raten Sie.

Der häufigste Fehler: Teams messen Task Success nur auf dem Happy Path. Fügen Sie die zwei häufigsten Edge Cases hinzu (Empty State und Error Recovery) und messen Sie neu. Die Zahl sinkt, und dieser Rückgang ist, wo Ihre eigentliche Arbeit liegt.

2. Time-to-Completion

Den Median verwenden, nicht den Durchschnitt. Ein Enterprise-Kunde mit einem benutzerdefinierten Workflow verzerrt den Durchschnitt ins Unsinnige. Der Median zeigt, was der typische User tatsächlich erlebt.

Nach neuen und wiederkehrenden Usern segmentieren. Neue User bei einem Core-Flow über 90 Sekunden sind ein Warnsignal. Wiederkehrende User über 30 Sekunden bei etwas, das sie täglich tun, ist ebenfalls eines. Das ist Muskelgedächtnis, das Sie ihnen nicht ermöglichen.

Echtes Beispiel: ein Billing-Page-Redesign bewegte die mediane Bearbeitungszeit für wiederkehrende User von 47 Sekunden auf 31 Sekunden. Das ist eine Reduktion von 34 %. Der PM interessierte sich nicht für das Redesign. Er interessierte sich dafür, dass Support-Tickets über "Wo ist der Rechnung-Download-Button" im selben Quartal auf null sanken. Dasselbe Ergebnis, andere Sprache. Verwenden Sie beide.

Was Time-to-Completion nicht aussagt: ob der User es genossen hat, ob er zurückgekehrt ist oder ob der Flow überhaupt der richtige ist. Es ist ein Tacho, kein Zielcheck.

3. Fehlerquote

Drei Dinge verfolgen:

• Formularfehler: falsch ausgefüllte Felder, ausgelöste Validierung, Wiederholungsversuche vor dem Erfolg
• Sackgassen-Klicks: Klicks auf nicht-interaktive Elemente (ein Label, das wie ein Button aussieht, ein Icon ohne Aktion)
• Rage-Clicks: drei oder mehr Klicks auf dasselbe Element in unter zwei Sekunden

Pro Session ist die richtige Einheit. "Fehler pro User pro Woche" verbirgt Flow-Brände.

Kritische Regel: Baseline vor dem Redesign festlegen. Wenn Sie ein Redesign liefern und "Fehlerquote beträgt 1,2 pro Session" berichten, ist diese Zahl ohne die Baseline vor dem Redesign bedeutungslos. Ich habe Designer gesehen, die eine Verbesserung von 30 % geliefert haben und sie nicht einfordern konnten, weil sie den Ausgangspunkt nie gemessen hatten. Die Baseline in Woche eins festlegen. Immer.

Rage-Clicks sind unterschätzt. Sie sind das Nächste, was UX einem Kunden hat, der auf den Bildschirm schreit. Jeder Flow mit Rage-Clicks über 0,5 pro Session kommuniziert etwas Konkretes: Der User denkt, etwas sollte funktionieren, und es tut es nicht.

4. SUS Score

Die System Usability Scale. Zehn Fragen, auf einer Skala von 0-100, quartalsweise durchgeführt.

Durchschnitt über alle Software: 68. Unter 50 ist ein Brand. Ihre User kämpfen aktiv. Über 80 ist wirklich gut. Über 85 ist selten und bedeutet wahrscheinlich eine kleine, selbstselektierte Stichprobe.

SUS nicht für das gesamte Produkt durchführen. Für die drei Flows durchführen, die Umsatz oder Retention treiben. Diese mit Ihrem PM wählen. Andernfalls mitteln Sie ein gutes Onboarding mit einem mittelmäßigen Admin-Panel und berichten eine bedeutungslose 71.

Die zehn Fragen (paraphrasiert; verwenden Sie die Standardformulierung, wenn Sie es versenden):

1. Ich denke, dass ich dieses System häufig nutzen würde.
2. Ich fand das System unnötig komplex.
3. Ich dachte, das System sei einfach zu bedienen.
4. Ich würde die Unterstützung einer technischen Person brauchen, um dieses System zu nutzen.
5. Die verschiedenen Funktionen in diesem System waren gut integriert.
6. Es gab zu viel Inkonsistenz in diesem System.
7. Ich vermute, dass die meisten Menschen sehr schnell lernen würden, dieses System zu nutzen.
8. Ich fand das System sehr umständlich zu bedienen.
9. Ich fühlte mich bei der Nutzung dieses Systems sehr sicher.
10. Ich musste viele Dinge lernen, bevor ich mit diesem System loslegen konnte.

Fünf-Punkte-Skala, abwechselnd positive und negative Formulierung. Die Mathematik ist gut dokumentiert; bitte nicht neu erfinden.

Jeden Quartal in derselben Woche, an denselben Flows, mit mindestens n=20 Befragten pro Flow durchführen. Der Trend ist wichtiger als die absolute Zahl.

5. Post-Launch-NPS-Delta

Net Promoter Score ist ein stumpfes Instrument. Allein ist er eine Vanity-Metrik. Segmentiert ist er eines der stärksten Signale, die Sie einem Head of Product zeigen können.

Die Methode: Segmentieren Sie in den 30 Tagen nach einem Redesign die NPS-Antworten nach Usern, die tatsächlich den neu gestalteten Flow durchlaufen haben, gegenüber Usern, die das nicht getan haben. Vergleichen Sie die beiden Kohorten. Wenn die Kohorte mit dem neuen Flow um +8 NPS-Punkte höher bewertet, haben Sie einen vertretbaren Anspruch. Wenn sie gleich oder niedriger bewertet, haben Sie ein Problem, das es zu untersuchen gilt.

Das ist die einzige NPS-Zahl, die ich je auf einer UX-Folie präsentieren würde. Aggregierter Unternehmens-NPS gehört dem CEO. Kohorten-segmentierter Post-Launch-NPS gehört Ihnen.

Achtung vor dieser Falle: Nicht mit dem NPS des vorherigen Quartals des gesamten Unternehmens vergleichen. Sie messen einen Flow, kein Unternehmen. Kohorte mit Kohorte vergleichen, gleiches Zeitfenster.

Die "High-Task-Success-but-High-Churn"-Diagnose

Das ist der Fall, vor dem niemand warnt.

Der Flow funktioniert. SUS liegt bei 76. Task Success beträgt 91 %. Time-to-Completion ist gesunken. Sie liefern. Sie feiern. Drei Monate später hat sich Churn nicht bewegt. Manchmal wird es schlechter.

Was ist passiert?

Meistens eines von drei Dingen:

Sie haben den falschen Jobs-to-be-Done optimiert. User haben die von Ihnen gemessene Task abgeschlossen, aber die Task war nicht das, was sie eigentlich erreichen wollten. Klassisches Beispiel: ein neu gestalteter Import-Flow mit 94 % Erfolg, aber User importierten CSVs, weil sie die API nicht zum Laufen brachten. Die eigentliche Aufgabe war "meine Daten schnell einbringen." Sie haben den Workaround optimiert.

Der nächste Schritt ist kaputt. Sie haben Onboarding abgeschlossen. Dann haben sie den Empty State erreicht und sind abgesprungen. Oder sie haben eine unerwartete Preisschranke getroffen. Oder sie wurden an einen Sales-Rep übergeben, der vier Tage zum Antworten brauchte. Der von Ihnen gemessene Flow war erfolgreich; die Journey ist gescheitert.

Sie haben für erstmalige User optimiert und dabei wiederkehrende User verschlechtert. Task Success für neue User um 22 % gestiegen. Task Success für wiederkehrende User um 8 % gesunken. Wiederkehrende User sind die zahlenden. Sie sind gegangen.

Wie man es vor dem QBR erkennt:

1. Die abgewanderten User der letzten 30 Tage in einer Kohorte zusammenfassen.
2. Session-Replays für diese Kohorte ziehen, 7 Tage vor dem Churn.
3. Nach Zögerungsmomenten suchen: lange Pausen auf einem Screen, Zurückgehen zum vorherigen Schritt, Öffnen eines Hilfe-Artikels in einem neuen Tab.
4. Den Screen identifizieren, auf dem sie gezögert haben, auch wenn die Session-Metriken zeigen, dass sie "erfolgreich" waren.
5. Dieser Screen ist das eigentliche Problem. Nicht der, den Sie neu gestaltet haben.

Fünf Churn-User-Replays lehren mehr als fünfzig Happy-Path-Tests. Der Aufwand ist zwei Stunden. Das Ergebnis ist eine Liste mit drei bis fünf Korrekturen, die Retention bewegen, keine Vanity-Metriken. Das monatlich tun.

Die QBR-Folie

Eine Folie. Vier Zahlen. Ein diagnostischer Hinweis. Nicht schön machen. Überfliegbar machen.

Layout (von links nach rechts, von oben nach unten):

Unter der Tabelle, eine Zeile:

Diagnose: Onboarding-Abschluss ist um 17 % gestiegen, aber Woche-2-Retention ist unverändert. Kohorte-Replay zeigt auf den leeren Dashboard-State. Korrektur für den nächsten Sprint eingegrenzt.

Das ist die gesamte Folie. Keine Screenshots des Redesigns. Keine Vorher/Nachher-Figma-Frames. Keine "User waren begeistert"-Zitate. Der Head of Product wird das nicht lesen. Er wird die Tabelle, das Delta und die Diagnose lesen.

Wenn er die Figma-Datei möchte, wird er fragen. Er fragt fast nie.

Vanity-Metrik-Fallen

Dinge, die wie UX-Metriken aussehen, es aber nicht sind:

Engagement-Minuten allein. Längere Sessions können Verwirrung bedeuten. Ein User, der 12 Minuten damit verbringt, den Export-Button zu finden, ist nicht engaged. Er steckt fest. Mit Task Success kombinieren oder nicht berichten.

Gelieferte design tokens. Das ist ein Output, kein Outcome. Engineers berichten nicht "geschriebene Code-Zeilen" aus einem bestimmten Grund. Das auch nicht berichten.

NPS ohne Segmentierung. Aggregierter NPS gehört dem CEO. Wenn Sie unsegmentierten NPS auf eine UX-Folie setzen, nehmen Sie entweder Lorbeeren für Dinge in Anspruch, die Sie nicht getan haben, oder Schuld für Dinge, die Sie nicht gebrochen haben.

CSAT nach einem Support-Ticket. Misst den Support-Agenten, nicht das Produkt. Nützlich für die Support-Leitung. Nicht nützlich für Sie.

Bounce Rate als UX-Metrik. Bounce Rate ist eine Marketing-Metrik auf Landing Pages. Auf Produktoberflächen ist sie fast immer irreführend.

Anzahl der durchgeführten Usability-Tests. Aktivität, kein Ergebnis. Die richtige Zahl ist "Tests, die eine Design-Entscheidung verändert haben", und das ist eine schwierige Zahl zu berichten, weshalb niemand es tut. Trotzdem versuchen.

Instrumentierungs-Checkliste

Bevor Sie sich verpflichten, diese Metriken zu berichten, stellen Sie sicher, dass Sie sie tatsächlich messen können. Diese Liste mit Ihrem PM und einem Engineer durchgehen:

• Session-Replay-Tool deployed und PII-bereinigt (FullStory, LogRocket, Hotjar, Heap)
• Event-Tracking auf allen Core-Flow-Start/Abschluss-Paaren (Onboarding starten, Onboarding abschließen usw.)
• Funnel-Definitionen dokumentiert und mit der Produkt-Analytik geteilt
• SUS-Umfrage-Infrastruktur (Typeform, In-App-Modal oder quartalsweises E-Mail) mit mindestens n=20 pro Flow
• NPS-Umfrage segmentiert nach Feature/Flow-Exposition, nicht nur nach Sendedatum
• Baseline-Messungen vor dem Launch jedes Redesigns
• Ein geteiltes Dashboard, das der PM öffnen kann, ohne Sie zu fragen

Wenn Sie nicht alle acht abhaken können, schließen Sie die Lücke, bevor Sie sich auf die Metrik verpflichten. Eine Zahl zu berichten, der Sie nicht vertrauen können, ist schlimmer als gar nicht zu berichten.

Den eigenen Erfolg messen

Sie wissen, dass das funktioniert, wenn:

• Sie "Funktioniert das Design?" in unter 60 Sekunden mit Zahlen, nicht Adjektiven, beantworten können.
• Ihre Design Lead Ihre QBR-Folie ohne Änderungen an den Head of Product weiterleitet.
• Der PM aufhört, nach "User-Feedback" zu fragen, und beginnt, nach "der aktuellen Task-Success-Zahl" zu fragen.
• Ein Engineer vor einem Refactoring nach der Baseline fragt, weil er das Format gesehen hat.
• Sie einen High-Success-High-Churn-Fall vor dem QBR erkennen, nicht danach.

Das Ziel ist nicht, Datenanalystin zu werden. Es ist, aufzuhören, die Person im Raum ohne Zahlen zu sein.

Fünf Metriken. Eine Diagnose. Eine Folie. Führen Sie es zwei Quartale durch, und das Gespräch über UX in Ihrem Unternehmen wird sich leise verändern.

Mehr erfahren

• Design-Critique, die nicht entgleist
• Usability-Testing mit kleinem Budget
• Mit PMs arbeiten, die Design nicht verstehen
• Product Designer Job Description