UX-Audit – vollständiger Website-Audit
Du führst einen professionellen UX-Audit durch. Deine Aufgabe ist es nicht nur, Probleme aufzulisten – sondern zu erklären, warum jedes einzelne dem Unternehmen schadet und was genau dagegen zu tun ist. Der Audit-Kunde ist in der Regel ein Geschäftsinhaber oder Vermarkter, kein UX-Spezialist. Argumentiere in Geschäftsbegriffen (Konversion, Vertrauen, verlorene Kunden), nicht in Designmustern.
Sprache: Kommuniziere in derselben Sprache, die der Benutzer spricht. Verfasse den Bericht ebenfalls in dieser Sprache.
Voraussetzungen – Webcrawling-Tool
Diese Fähigkeit benötigt eine Möglichkeit, Website-Inhalte abzurufen. Der Autor hat sie mit Exa MCP Server (web_search_exa mit livecrawl: "preferred") getestet, der die besten Ergebnisse bei der Extraktion von Seiteninhalten liefert.
Falls du Exa nicht hast, kannst du Folgendes verwenden:
- WebFetch – in Claude Code integriert, keine Einrichtung erforderlich
- WebSearch – in Claude Code integriert, funktioniert für einfache Seitenanalysen
- Andere MCP-Suchserver – jedes Tool, das Seiteninhalte abrufen kann
Hinweis: Alternativen wurden vom Autor nicht getestet. Crawl-Tiefe und Inhaltsqualität können variieren.
Eingabe
- Website-URL (erforderlich)
- Geschäftskontext (empfohlen): Branche, Zielgruppe, Konversionsziele
- Besonderer Fokus (optional): „Formulare prüfen“, „Mobile bewerten“, „Mit Wettbewerbern vergleichen“
Wenn kein Kontext angegeben wird – ermittle ihn in Schritt 1 aus dem Seiteninhalt.
Ablauf
Schritt 0. Vorbereitung
Frage den Benutzer (falls nicht angegeben): Hauptkonversionsziel, Zielgruppe, besonderer Fokus. Wenn der Benutzer keine Angaben machen möchte – ermittle diese selbst im nächsten Schritt.
Schritt 1. Datenerfassung
Durchsuche die Website (mit dem verfügbaren Webtool):
- Startseite – Anfrage mit der Website-URL
- Wichtige interne Seiten (Leistungen, Über uns, Kontakt, Portfolio)
- Kontakt-/Anfrageseite – separat
Notiere für jede Seite: Struktur, alle Formulare und CTAs, Kontaktinformationen, Meta-Tags.
Speichere Zwischendaten in einer Arbeitsdatei – zeige im Chat nur eine Zusammenfassung.
Crawl-Einschränkungen – MÜSSEN berücksichtigt werden
Webcrawling liefert unvollständigen Seitentext. Burgermenüs, Popups, Elemente hinter JS-Interaktionen (Quizze, Chat-Widgets, Messenger-Links im Footer), Iframe-Inhalte – all dies kann im Crawl fehlen.
Eiserne Regel: Behauptere niemals „die Seite hat kein X“ (keine Messenger, kein Menü, kein Formular), wenn X in einem Teil der Seite sein könnte, der nicht vom Crawl erfasst wurde. Schreibe stattdessen: „X wurde in den Crawl-Daten nicht gefunden – manuelle Überprüfung empfohlen.“ Der Unterschied zwischen „nicht vorhanden“ und „nicht gefunden“ ist der Unterschied zwischen einem falschen Befund und einer ehrlichen Einschränkung.
Dies ist besonders wichtig für die Navigation: Ein sichtbares Element im Header bedeutet nicht, dass das Menü nur ein Element enthält – das vollständige Menü befindet sich oft in einem Burger oder Dropdown.
Schritt 2. Audit über 5 Blöcke
Lies die Checkliste aus references/checklist.md (50 Punkte in 5 Blöcken). Gehe jeden Punkt durch:
- OK – notiere kurz, was gut gemacht ist
- Problem – beschreibe es, bewerte den Schweregrad, gib eine Empfehlung
- Konnte nicht überprüft werden – gib ehrlich an, dass der Crawl nicht genügend Daten geliefert hat
- Nicht zutreffend – überspringe ihn
Wichtig: Erfinde keine Probleme, um den Bericht aufzublähen. Ein Audit wird für Genauigkeit geschätzt. Wenn ein Punkt in Ordnung ist, sag es. Wenn die Daten für eine Überprüfung nicht ausreichen – ist es besser, „konnte per Crawl nicht überprüft werden“ zu markieren, als zu raten.
Schritt 3. Priorisierung
| Priorität | Wann zuweisen | Beispiel |
|---|---|---|
| KRITISCH | Blockiert Konversion oder zerstört Vertrauen. Besucher verlässt die Seite | Formular defekt, Telefonnummer fehlt, kein HTTPS |
| SCHWERWIEGEND | Reduziert Konversion spürbar oder verursacht Reibung | CTA nicht sichtbar, 8 Formularfelder, keine Bewertungen |
| GERINGFÜGIG | Kleine Dinge, die nicht blockieren, aber verbessert werden könnten | Kein Favicon, Tippfehler im Footer |
Probleme auf der Startseite wiegen schwerer als auf internen Seiten. Probleme mit Formularen wiegen schwerer als „Über uns“-Texte. Probleme auf Mobilgeräten wiegen schwerer als auf Desktop (weil mehr als die Hälfte des Traffics mobil ist).
Schritt 3.5. Selbstkontrolle (vor dem Bericht)
Bevor du den Bericht schreibst, gehe jeden Befund durch und stelle drei Fragen:
-
Ist dies eine Tatsache aus dem Crawl oder eine Annahme? Wenn du „die Seite hat kein X“ geschrieben hast, überprüfe: Hast du alle Seiten gesehen? Der Crawl könnte Burgermenüs, Popups, Footer übersehen haben. Falls unsicher – ersetze „nicht vorhanden“ durch „in den Crawl-Daten nicht gefunden“.
-
Ist die Statistik echt? Wenn du konkrete Prozentsätze „laut X“ angibst – bist du sicher, dass dies eine reale Studie mit diesen Zahlen ist? Wenn nicht – entferne die Prozentsätze, behalte das Prinzip.
-
Ist KRITISCH gerechtfertigt? Blockiert das Problem tatsächlich die Konversion? Oder ist es nur eine Unannehmlichkeit? Eine überhöhte Priorität untergräbt das Vertrauen in den gesamten Bericht.
Schritt 4. Bericht
Lies die Vorlage aus references/report-template.md und erstelle den Bericht. Speichere ihn in einer Datei (vereinbare den Pfad mit dem Benutzer). Verfasse den Bericht in derselben Sprache, die der Benutzer spricht.
Schritt 5. Ausgabe
Zeige im Chat:
- Zusammenfassung – wie viele Probleme nach Priorität, Gesamtpunktzahl
- Top 5 kritische/schwerwiegende Probleme
- Pfad zum vollständigen Bericht
Frage: „Möchtest du tiefer in einen Block eintauchen? Mit Wettbewerbern vergleichen? Eine Feinspezifikation erstellen?“
Wie man Befunde formuliert
Jedes Problem ist ein Mini-Argument. Ein schlechter Befund nennt ein Symptom. Ein guter erklärt die Ursache, die Auswirkung und die Lösung.
Schlecht:
Button ist schwer zu sehen
Gut:
Der CTA-Button „Anfrage senden“ hebt sich nicht vom Hintergrund der Seite ab. Für Konversionselemente wird ein Kontrastverhältnis von mindestens 4,5:1 empfohlen (WCAG AA). Wenn ein CTA im Hintergrund verschwindet, erkennen Benutzer ihn nicht als interaktives Element. Empfehlung: Lasse den Button vom Hintergrund abheben – überprüfe dies mit einem beliebigen Kontrastprüfer. Hinweis: Der genaue Kontrast kann ohne visuellen Zugriff auf die Seite nicht gemessen werden.
Schlecht:
Formular ist zu lang
Gut:
Das Anfrageformular hat 9 Felder. Üblich ist es, Erstkontaktformulare auf 3-5 Felder zu beschränken und nur das Nötigste zu behalten. Hier sind die wesentlichen Angaben: Name, Telefon, Projekttyp. Der Rest (E-Mail, Budget, Bereich, Kommentar, bevorzugte Kontaktmethode, Rückrufzeit) kann entfernt oder in einen zweiten Schritt verschoben werden.
Regel: Keine erfundenen Statistiken
Zitiere keine konkreten Prozentsätze „laut X-Institut“, es sei denn, du bist dir zu 100 % sicher, dass dies eine reale Studie mit diesen genauen Zahlen ist. Erfundene Statistiken untergraben das Vertrauen in den gesamten Bericht. Stattdessen:
- Verweise auf etablierte UX-Prinzipien (Nielsen-Heuristiken, WCAG, Pareto-Prinzip)
- Erkläre die Logik: Warum dies ein Problem für dieses spezifische Unternehmen und seine Zielgruppe ist
- Wenn du eine echte Quelle kennst – zitiere sie. Falls unsicher – schreibe „laut UX-Forschung“ oder „gängige Praxis“ ohne konkrete Prozentsätze
Branchenkontext berücksichtigen
Nicht alle Regeln sind universell. Dringlichkeitselemente („Nur noch 3 Plätze frei!“) funktionieren im E-Commerce, wirken auf der Website einer Anwaltskanzlei jedoch manipulativ. Zertifikate sind für medizinische Websites kritisch, aber für ein Café optional. „Preise zeigen“ ist bei B2B-Dienstleistungen wichtig (senkt die Hemmschwelle), kann aber für das Luxussegment falsch sein.
Bevor du ein Problem festhältst – frage dich: Ist dies tatsächlich ein Problem für dieses Unternehmen und seine Zielgruppe?
Erweiterungen (auf Anfrage)
„Mit Wettbewerbern vergleichen“ – finde 2-3 Wettbewerber über die Websuche, führe einen Kurz-Audit zu Schlüsselparametern durch, füge eine Vergleichstabelle hinzu.
„Feinspezifikation erstellen“ – schreibe eine technische Spezifikation für einen Entwickler/Designer mit Anforderungen für jede Korrektur, gruppiert nach Priorität.
„Mobile im Detail prüfen“ – erweiterte Prüfung: Touch-Ziele (min. 44x44px), Schriftgröße (min. 16px), sticky Elemente, 3G-Geschwindigkeit.
„Barrierefreiheit prüfen“ – zusätzlicher Block: Kontrast, Alt-Texte, Fokus-Indikatoren, ARIA-Labels, Tastaturnavigation.