Was ist ein UX-Audit, und wie läuft es ab?

Kurz erklärt

Ein UX-Audit heißt: Sie schauen mit den Augen eines Nutzers auf Ihr Produkt, mit einer Liste von Kriterien in der Hand. Ich gehe einen Flow von Anfang bis Ende durch und notiere jede Stelle, an der ich hängen bleibe. Dann ordne ich jede Notiz einer Heuristik zu und schreibe eine Lösung daneben.

Der Kern eines Audits ist eine heuristische Evaluation mit Nielsens 10 Usability-Heuristiken. Jakob Nielsen hat sie 1990 mit Rolf Molich entwickelt und 1994 in ihre heutige Form gebracht. Dazu kommen Prüfungen von Flow, Barrierefreiheit, Inhalt und Ladezeit.

Ein Audit ersetzt keinen Test mit Nutzern. Der Leitfaden der NN/g zur heuristischen Evaluation sagt das deutlich: Die Methode findet wahrscheinliche Probleme günstig, ist aber kein Ersatz für Nutzerforschung. Das Audit zeigt, wo Sie hinschauen sollten; echte Nutzer zeigen, warum sie hängen bleiben.

• Der Umfang kann ein einzelner Flow oder das ganze Produkt sein.
• Jeder Befund hat einen Screen, eine Heuristik und einen Schweregrad.

Wann Sie eines brauchen und wann nicht

Ein Audit hilft am meisten, wenn Sie wissen, dass etwas nicht stimmt, aber nicht wo. Die Abbrüche im Bezahlschritt sind gestiegen, oder Support-Tickets zeigen immer wieder auf denselben Screen.

Ich empfehle ein Audit:

• Vor einem großen Redesign. Wer neu zeichnet, ohne zu wissen, was kaputt ist, nimmt das Problem auf den neuen Screen mit.
• Wenn die Zahlen eines Flows fallen. Die Analytics zeigen, wo sie fallen; das Audit sucht nach dem Warum.
• Vor dem Launch. Wer mit einem Problem vom Schweregrad 4 live geht, riskiert seine ersten Nutzer.
• Wenn das Team sich zu sehr an das Produkt gewöhnt hat. Wer jeden Tag denselben Screen sieht, erkennt nicht mehr, wo Neue hängen bleiben.

Unnötig oder nicht ausreichend ist ein Audit, wenn:

• es noch keine Oberfläche gibt. Dann sagen ein Prototyp oder Gespräche mit Nutzern mehr.
• die eigentliche Frage lautet: „Bauen wir das richtige Produkt?“ Ein Audit prüft, ob das Produkt leicht zu bedienen ist. Ob der Markt es will, ist eine andere Untersuchung.
• niemand die Befunde umsetzt. Ein Audit, auf das niemand reagiert, bleibt ein PDF in der Schublade.

Umfang: was ein Audit prüft

Ein Audit deckt fünf Bereiche ab, aber nicht jeder wiegt in jedem Auftrag gleich viel. In einem Checkout steht die Flow-Analyse vorn, auf einer Content-Website sind es Inhalt und Struktur.

1. Heuristische Evaluation

Ich vergleiche jeden Screen einzeln mit den 10 Heuristiken. Zeigt das System, was es gerade tut? Kann der Nutzer einen falschen Schritt rückgängig machen? Ist eine Heuristik verletzt, schreibe ich einen Befund.

Stellen Sie sich eine Behörden-App vor, die nach dem Abruf offener Gebühren nur „Ihre Anfrage ist eingegangen“ anzeigt. Dieser Screen verletzt die Heuristik Sichtbarkeit des Systemstatus. Der Nutzer weiß nicht, ob die Anfrage fertig ist, und tippt erneut auf denselben Button.

Die NN/g warnt hier: Eine verletzte Heuristik ist nicht immer ein Problem, und die richtige Entscheidung hängt vom Kontext ab. Deshalb schreibe ich bei jedem Befund zuerst die Kosten für den Nutzer auf. Welche Regel verletzt ist, kommt danach.

2. Flow-Analyse

Ich zähle die Schritte, die ein Nutzer bis zum Ziel durchläuft. Gibt es einen überflüssigen Screen? Wird dieselbe Information zweimal abgefragt? Ich prüfe auch, ob der Flow zum mentalen Modell des Nutzers passt, also zu seiner Erwartung, wie die Aufgabe abläuft.

Das bekannteste Beispiel ist die Geschichte vom 300-Millionen-Dollar-Button. In dem Fall, den Jared Spool 2009 erzählte, landeten Käufer mit vollem Warenkorb vor dem Bezahlen auf einem Formular zum Anmelden oder Registrieren. Laut Spool stiegen die Käufe um 45 %, als der Button „Register“ entfernt und durch „Continue“ ersetzt wurde.

Ein solches Problem sieht man nicht, wenn man Screens einzeln betrachtet. Das Formular ist für sich in Ordnung. Das Problem ist seine Stelle im Flow.

3. Barrierefreiheit

Der Maßstab ist der W3C-Standard WCAG 2.2. Die WCAG beruhen auf vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust. Es gibt drei Konformitätsstufen: A als unterste, dann AA und AAA als höchste.

Im Audit prüfe ich die grundlegenden Kriterien. Einige Beispiele:

• Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1, großer Text mindestens 3:1 (WCAG 2.2, 1.4.3).
• Touch- und Klickziele sollten mindestens 24 × 24 CSS-Pixel groß sein oder genug Abstand haben (2.5.8, neu in WCAG 2.2).
• Ein Element mit Tastaturfokus darf nicht ganz unter etwas wie einem fixierten Header oder einem Cookie-Banner verschwinden (2.4.11).
• Verlangt die Anmeldung einen kognitiven Test, etwa ein Passwort merken oder ein Rätsel lösen, braucht es eine Alternative oder eine Hilfe (3.3.8).

Dazu kommt ein Durchgang mit der Tastatur. Ich lege die Maus weg und versuche, den Flow nur mit Tab und Enter abzuschließen. Ist der Fokusrahmen unsichtbar oder komme ich aus einem Menü nicht heraus, ist das ein Befund.

Diese Prüfungen sind kein vollständiges Konformitätsaudit. Aber sie finden die häufigen Probleme, die viele Menschen ausschließen.

In Deutschland kommt das Barrierefreiheitsstärkungsgesetz (BFSG) hinzu. Laut der Bundesfachstelle Barrierefreiheit gilt es seit dem 28. Juni 2025, unter anderem für Bankdienstleistungen und den elektronischen Geschäftsverkehr. Kleinstunternehmen, die Dienstleistungen anbieten, also weniger als zehn Beschäftigte und ein Jahresumsatz oder eine Jahresbilanzsumme von höchstens 2 Millionen €, sind ausgenommen. Ob das Gesetz für Ihr Angebot gilt, ist eine rechtliche Frage; das Audit zeigt, wo Ihr Flow von den WCAG-Kriterien abweicht.

4. Inhalt

Ich lese die Texte der Oberfläche: Button-Beschriftungen, Fehlermeldungen, leere Zustände, Hinweise in Formularen. Sprechen sie die Sprache der Nutzer oder den internen Jargon des Teams? Eine Fehlermeldung „Vorgang fehlgeschlagen“ sagt niemandem, was zu tun ist.

Angenommen, das Feld im Überweisungsscreen einer Banking-App heißt „Kennung des Gegenkontos“ statt „Kontonummer des Empfängers“. Der Nutzer muss raten, was gemeint ist. In der Inhaltsprüfung liste ich solche Labels auf und schlage für jedes eine Formulierung in den Worten der Nutzer vor.

Dazu gehören auch Menüs und Überschriften. Finden Nutzer etwas nicht dort, wo sie es erwarten, liegt das Problem meist in der Informationsarchitektur.

5. Ladezeit

Langsamkeit macht auch eine gut gestaltete Seite unbrauchbar. Hier schaue ich auf Googles Core Web Vitals. web.dev nennt die Schwellen für „gut“ beim 75. Perzentil der Seitenaufrufe:

• LCP (Laden des größten Inhalts): höchstens 2,5 Sekunden.
• INP (Reaktion auf eine Interaktion): höchstens 200 Millisekunden.
• CLS (visuelle Verschiebung): höchstens 0,1.

Diese Werte stammen aus der Verteilung echter Nutzererfahrungen. Ein Ergebnis von Ihrem eigenen Rechner ist nur ein Punkt in dieser Verteilung.

web.dev empfiehlt, die Schwellen für Mobil und Desktop getrennt zu bewerten, also schaue ich mir das mobile Ergebnis eigens an. Ich schreibe keinen Technikbericht, sondern achte darauf, was der Nutzer spürt. Passiert etwas, wenn man auf den Button tippt? Springt Inhalt, während die Seite lädt?

Ein UX-Audit Schritt für Schritt

Abbildung: die fünf Phasen eines Audits. Jedes Kästchen entspricht einem der nummerierten Schritte unten.

1. Den Umfang festhalten. Die NN/g empfiehlt, die Evaluation auf eine Aufgabe, einen Bereich, eine Nutzergruppe oder ein Gerät einzugrenzen. „Gastkauf auf dem Handy“ ist ein guter Umfang; „die ganze Website“ ist zu breit.

2. Ziel und vorhandene Daten sammeln. Wozu dient der Flow, und woran wird Erfolg gemessen? Zeigen die Analytics eine Abbruchstelle oder wiederholen Support-Tickets dieselbe Beschwerde, will ich das vorher sehen.

3. Erster Durchgang: das Produkt kennenlernen. Wie die NN/g vorschlägt, bewerte ich in der ersten Runde nicht, sondern lerne das Produkt kennen. Ich erledige die Aufgabe des Nutzers einmal von Anfang bis Ende mit realistischen Daten.

4. Zweiter Durchgang: die Probleme aufschreiben. Jetzt vergleiche ich jeden Screen mit den Heuristiken und den Kriterien der Barrierefreiheit und lese jeden Text. Jeder Befund kommt in eine eigene Zeile, mit Screenshot und zugehöriger Heuristik.

5. Befunde zusammenführen. Probleme mit derselben Ursache fasse ich zu einem Befund zusammen. Eine unklare Fehlermeldung, die auf fünf Screens auftaucht, wird als ein Systemproblem notiert.

6. Schweregrad bewerten. Jeder Befund bekommt einen Wert auf der Skala von 0 bis 4 unten. Laut Nielsen verbindet die Bewertung drei Dinge: wie oft das Problem auftritt, wie schwer es zu überwinden ist und wie hartnäckig es ist. Dazu kommt die Wirkung am Markt.

7. Eine Lösung empfehlen. „Das ist schlecht“ reicht nicht. Neben jeden Befund schreibe ich eine konkrete Änderung, etwa einen neuen Text oder eine neue Position für ein Feld. Das Team soll den Befund lesen und noch am selben Tag anfangen können.

8. Ordnen und übergeben. Die Liste ist nach Schweregrad und Aufwand sortiert. Ich liefere sie als Loom-Video und als schriftliche Liste. Ein Problem, das man am Bildschirm sieht, versteht man schneller als ein beschriebenes.

Wie schreibt man einen Befund?

Ich schreibe jeden Befund im selben Format. So kann das Team die Liste schnell überfliegen, weil die nötige Information auf jeder Karte an derselben Stelle steht.

• Titel: das Problem selbst, in einem Satz, aus Sicht des Nutzers.
• Ort: Flow, Schritt und Screen. Wenn möglich ein Screenshot.
• Was passiert: was der Nutzer erlebt, in zwei oder drei Sätzen.
• Heuristik: welche Usability-Heuristik oder welches WCAG-Kriterium betroffen ist.
• Schweregrad: 0 bis 4, mit Begründung.
• Empfehlung: eine konkrete Änderung, die das Team umsetzen kann.

„Gutscheinvalidierung fehlerhaft“ ist eine Notiz für Entwickler. „Der Gutschein-Fehler ist nicht zu sehen“ ist ein Titel aus Sicht des Nutzers, den jeder im Team versteht.

Wie sieht das Ergebnis aus?

Am Ende eines Audits sollten Sie zwei Dinge haben. Erstens eine Liste der Befunde, sortiert nach Schweregrad. Zweitens einen Durchgang, der diese Liste am Bildschirm zeigt: ein Video oder eine kurze Präsentation.

Die Liste beginnt mit einer Zusammenfassung in wenigen Punkten. Welche Probleme sollten den Launch aufhalten, welche können warten? Eine Führungskraft sollte nur diese Zusammenfassung lesen und entscheiden können.

Neben dem Schweregrad markiere ich bei jedem Befund auch den Aufwand. Befunde mit hohem Schweregrad und günstiger Lösung stehen oben. Mit ihnen erreicht das Team in der ersten Woche am meisten.

Wie lange dauert es?

Das hängt vom Umfang ab. Die NN/g empfiehlt, die unabhängige Sitzung jedes Prüfers auf etwa 1 bis 2 Stunden zu begrenzen. Laut Nielsen dauert die getrennte Bewertung der Schweregrade danach meist etwa 30 Minuten pro Prüfer.

Vorbereitung, Zusammenführen und Bericht kommen dazu. Für einen einzelnen Flow liefere ich mein eigenes UX Audit innerhalb von 48 Stunden. Das ganze Produkt dauert länger.

Eine Beispielkarte und die Schweregradskala von 0 bis 4

Der Schweregrad sagt Ihnen, wofür Sie Ihre knappe Zeit einsetzen. Die Skala hier ist die von Jakob Nielsen 1994 veröffentlichte Skala von 0 bis 4.

Wert	Name	Bedeutung
0	Kein Problem.	Der Prüfer hält das überhaupt nicht für ein Usability-Problem.
1	Kosmetisch.	Nur ein kosmetisches Problem. Muss nicht behoben werden, außer es bleibt Zeit im Projekt.
2	Kleines Problem.	Kleines Usability-Problem. Die Behebung hat niedrige Priorität.
3	Großes Problem.	Großes Usability-Problem. Wichtig zu beheben, deshalb hohe Priorität.
4	Katastrophe.	Usability-Katastrophe. Muss vor dem Release behoben werden.

Nielsen gibt einen praktischen Hinweis: Bleiben ein paar Probleme auf Katastrophenniveau in der Oberfläche, ist ein Launch wohl keine gute Idee. Sind alle verbleibenden Probleme kosmetisch, können Sie launchen.

Die Karte unten zeigt, wie ein Befund geschrieben wird. Mit dem Wert ändert sich auch, wie dringend das Team hinschauen sollte.

Ausprobieren

Notiz 02 · Produktseite

Den Button „In den Warenkorb“ blau machen.

Was passiert: Jemand im Team wünscht sich den orangefarbenen Button in Blau. Der Kontrast passt, und alle Nutzer in den Sitzungen haben ihn sofort gefunden und benutzt.

Heuristik: Ästhetisches und minimalistisches Design (Nielsen, Heuristik 8). Die Heuristik ist nicht verletzt; der Wunsch ist Geschmackssache.

Empfehlung: Nicht ändern. Die Notiz von der Befundliste nehmen und in einem Satz begründen, warum.

Schweregrad: 0 · Kein Problem

Der Prüfer hält das überhaupt nicht für ein Usability-Problem.

Befund 11 · Bestellübersicht

Das Warenkorb-Icon sitzt nicht auf Höhe der Beschriftung.

Was passiert: In der Bestellübersicht sitzt das Warenkorb-Icon ein paar Pixel unter dem Text daneben. Niemand bleibt deswegen hängen, aber der Screen wirkt nachlässig.

Heuristik: Konsistenz und Standards (Nielsen, Heuristik 4). Auf allen anderen Screens sind Icons mittig zum Text ausgerichtet.

Empfehlung: Das Icon mittig zum Text ausrichten. Nicht dringend; das kann warten, bis das Team Luft hat.

Schweregrad: 1 · Kosmetisch

Nur ein kosmetisches Problem. Muss nicht behoben werden, außer es bleibt Zeit im Projekt.

Befund 09 · Kasse · Schritt 1 von 3

Die gewählte Lieferadresse ist schwer zu erkennen.

Was passiert: Unter den gespeicherten Adressen hebt sich die gewählte nur durch einen dünnen grauen Rahmen ab. Nutzer zögern kurz, wählen aber die richtige Adresse und machen weiter.

Heuristik: Sichtbarkeit des Systemstatus (Nielsen, Heuristik 1).

Empfehlung: Der gewählten Adresse eine klare Markierung und das Label „Ausgewählt“ geben.

Schweregrad: 2 · Kleines Problem

Kleines Usability-Problem. Die Behebung hat niedrige Priorität.

Befund 07 · Kasse · Schritt 2 von 3

Der Gutschein-Fehler ist nicht zu sehen.

Was passiert: Bei einem ungültigen Gutscheincode erscheint der Fehler ganz oben auf der Seite statt neben dem Feld. Auf dem Handy ist die Seite nach unten gescrollt, also sieht ihn der Nutzer nie.

Heuristik: Nutzern helfen, Fehler zu erkennen, zu verstehen und zu beheben (Nielsen, Heuristik 9).

Empfehlung: Die Meldung direkt unter das Feld setzen und das Feld als ungültig markieren.

Schweregrad: 3 · Großes Problem

Großes Usability-Problem. Wichtig zu beheben, deshalb hohe Priorität.

Befund 01 · Kasse · Schritt 3 von 3

Auf dem Handy funktioniert „Zahlung abschließen“ nicht.

Was passiert: Auf manchen Handys passiert beim Tippen nichts. Kein Ladeindikator, keine Fehlermeldung. Der Nutzer kann nicht bestellen und geht.

Heuristik: Sichtbarkeit des Systemstatus (Nielsen, Heuristik 1).

Empfehlung: Vor dem Release beheben. Den Button in mobilen Browsern testen, beim Tippen einen Ladezustand zeigen und bei einem Fehlschlag eine klare Meldung.

Schweregrad: 4 · Katastrophe

Usability-Katastrophe. Muss vor dem Release behoben werden.

Die Beispielkarten stammen von keinem echten Kunden. Wählen Sie einen Schweregrad, und die Karte zeigt ihren eigenen Beispielbefund dazu: Titel, Heuristik, Empfehlung und Erklärung ändern sich gemeinsam. Die Skala folgt Jakob Nielsens Schweregradskala von 0 bis 4.

Eine gute Befundkarte enthält vier Dinge: was es ist, wo es ist, welche Heuristik betroffen ist und was zu tun ist. Fehlt eines davon, versteht das Team die Karte nicht oder kann sie nicht einordnen.

Häufige Fehler

Den Bewertungen einer einzelnen Person vertrauen. Nielsen hält die Schweregrade eines einzelnen Prüfers nicht für verlässlich und den Durchschnitt von dreien für die meisten praktischen Zwecke für ausreichend. Auch die NN/g empfiehlt, dass idealerweise drei bis fünf Personen dieselbe Oberfläche unabhängig prüfen.

Während der Evaluation bewerten. Nielsen empfiehlt, die Werte danach zu sammeln, nicht in der Sitzung selbst. In der Sitzung gehört die Aufmerksamkeit dem Finden neuer Probleme.

Persönlichen Geschmack als Befund notieren. „Die Farbe gefällt mir nicht“ ist kein Befund. Jeder Befund braucht eine Heuristik und Kosten für den Nutzer.

Probleme unsortiert übergeben. Eine Liste mit 80 Punkten ohne Schweregrade lähmt ein Team. Die Liste sollte kurz und sortiert sein.

Den Umfang offenlassen. Ein Audit, das mit „schauen wir mal über die Website“ beginnt, endet, ohne einen Flow richtig angeschaut zu haben.

Barrierefreiheit als eigenes Thema behandeln. Ein Formular, das sich nicht mit der Tastatur bedienen lässt, ist für alle ein schlechtes Formular. Die Prüfung der Barrierefreiheit gehört ins Audit.

Screen für Screen schauen und den Flow übersehen. Jeder Screen kann für sich in Ordnung aussehen. Das Problem kann im Übergang liegen, in einer doppelt abgefragten Information oder in der falschen Reihenfolge.

Mit einem leeren Konto prüfen. In einem leeren Konto sehen Sie nie einen Warenkorb oder frühere Bestellungen. Ohne Testkonto mit realistischen Daten übersieht das Audit die Hälfte des Produkts.

Nur am Desktop prüfen. Kommen die meisten Nutzer vom Handy, gehört das Audit aufs Handy. Das Problem mit der Fehlermeldung in der Beispielkarte zeigt sich am Desktop vielleicht nie.

Ein Audit statt eines Tests mit Nutzern. Ein Audit liefert Hypothesen. Vor großen Entscheidungen sollten diese Hypothesen mit echten Nutzern geprüft werden.

Meine Notiz

Das Problem, das ich in Audits am häufigsten sehe, ist ein Produkt, das die Sprache des Teams spricht. Im Menü steht der Name eines internen Systems, in der Fehlermeldung ein Code. Das Team sieht es seit Jahren, also fällt es niemandem auf.

An zweiter Stelle stehen Fehlermeldungen. Entweder erscheinen sie an der falschen Stelle, oder sie sagen nicht, was zu tun ist. Der Gutschein-Fehler in der Beispielkarte gehört zur ersten Sorte.

Teams polieren oft den sichtbarsten Screen, während der eigentliche Verlust an einem unscheinbaren Schritt mitten im Flow passiert. Deshalb beginne ich ein Audit nicht auf der Startseite. Zuerst schaue ich auf den Schritt, an dem der Nutzer Geld oder Zeit ausgibt.

Weil ich allein arbeite, nehme ich Nielsens Warnung ernst. Ich bewerte Befunde nicht beim Schreiben, sondern in einer eigenen Runde, wenn die Liste fertig ist. Und einen Befund, bei dem ich unsicher bin, markiere ich genau so.