Ein UX-Bericht für Kunden, den eine Agentur oder ein Freelancer schreibt, hat ein Ziel: eine Entscheidung herbeizuführen, was im nächsten Monat auf der Website geändert wird. Heatmaps und Sitzungsaufzeichnungen liefern das Material, aber das Material ist noch kein Bericht. Ein Kunde, der eine Galerie von Screenshots und ein vages „das Formular könnte besser sein“ bekommt, weiß weder, was er glauben, noch, was er freigeben soll. Die folgende Struktur führt dich von der Beobachtung zur Aufgabe mit Beleg.
Wir setzen voraus, dass die Analyse schon erledigt ist: Du weißt, welche Besuche du ansiehst, wie du eine Heatmap liest und wie du Verbesserungen ordnest. Die Beispiele beziehen sich auf eine fiktive Physiotherapiepraxis mit einem Formular für Terminanfragen und sind keine Ergebnisse eines echten Projekts.
Der UX-Bericht für Kunden in sechs Teilen
Ein Monatsbericht liest sich am besten von den Entscheidungen hin zu den Details. Auf der ersten Seite sieht der Kunde, was am wichtigsten ist und was du von ihm brauchst. Methodenbeschreibung und Rohdaten gehören in den Anhang: Die entscheidende Person liest sie selten, und die technische Ansprechperson fragt ohnehin nach Details.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Teil | Frage des Kunden | Was hineingehört |
|---|---|---|
| Zusammenfassung | Was ist diesen Monat am wichtigsten? | 3–5 Probleme und anstehende Entscheidungen |
| Umfang und Grenzen | Worauf stützen sich die Schlüsse? | Zeitraum, Seiten, Geräte, Anzahl Besuche, Lücken |
| Problemkarten | Woher wisst ihr, dass es ein Problem ist? | Beobachtung, Hypothese, Empfehlung, Prüfung |
| Belege | Kann ich das sehen? | Links zu Aufzeichnungen und zur Heatmap-Ansicht |
| Aufgaben | Was passiert nach der Freigabe? | Aufgabe, verantwortliche Person, Prüftermin |
| Wirkung früherer Änderungen | Haben die letzten Verbesserungen gewirkt? | Was geprüft wurde und mit welchem Ergebnis |
Der letzte Teil schließt den Kreis zum Vormonat. Wenn eine früher freigegebene Änderung noch nicht geprüft wurde, schreib das offen hin, statt den Punkt wegzulassen. Dieser Bericht ist kein laufendes Fortschrittsupdate: Dafür gibt es den Leitfaden zum Projektstatus für Kunden, hier geht es um Erkenntnisse aus dem Nutzerverhalten.
Zusammenfassung: drei bis fünf Probleme
Die Zusammenfassung passt auf eine Seite. Beschreibe jedes Problem mit einem Satz zum Verhalten, einem zur möglichen Ursache und einem dazu, was du vom Kunden brauchst. Fünf Punkte sind die Obergrenze, denn bei zehn kann der Kunde Wichtiges nicht mehr von Nebensächlichem unterscheiden. Weitere Beobachtungen kommen ohne Empfehlung in den Teil „Im Blick behalten“. Die Reihenfolge legst du vorher fest, etwa mit der Methode aus dem Leitfaden, um Website-Verbesserungen mit ICE zu priorisieren.
Auf Smartphones öffnen einige Personen das Anfrageformular, erreichen aber den Absendebutton nicht (9 von 14 angesehenen Besuchen mit diesem Schritt). Mögliche Ursache: Die Kalenderauswahl im Datumsfeld verdeckt den Button. Wir bitten um Freigabe, die Kalenderauswahl durch eine Terminliste zu ersetzen; die Wirkung prüfen wir im nächsten Bericht.
Schreib keinen erwarteten Anstieg von Conversion oder Umsatz in die Zusammenfassung. Ohne Messung ist so eine Zahl ein Versprechen, an dem dich der Kunde im nächsten Monat misst. Nenne lieber das Verhalten, das verschwinden soll, und wie du das prüfst.
Datenumfang und Grenzen vor den Schlussfolgerungen
Der Kunde sollte wissen, worauf die Schlüsse beruhen, bevor er die Empfehlungen liest.
- Analysezeitraum und Zeitpunkte wichtiger Änderungen an der Website in dieser Zeit.
- Seiten und Schritte der Nutzerreise, die geprüft wurden.
- Geräte, getrennt nach Smartphone und Desktop.
- Anzahl angesehener Aufzeichnungen und Art der Auswahl.
- Status der Heatmaps: bereit oder noch in der Datensammlung.
- Was der Bericht nicht abdeckt, und warum.
In Meetlead gilt eine Heatmap ab 50 Aufrufen einer Seite auf einem Gerätetyp als bereit; vorher zeigst du sie als Datensammlung, nicht als Beleg. Ob diese Stichprobe für einen konkreten Schluss reicht, behandelt der Artikel dazu, wie viele Besuche eine Heatmap braucht. Bei Aufzeichnungen gibst du an, dass es eine ausgewählte Stichprobe ist und nicht alle Besuche. „9 von 14 angesehenen“ ist ehrlicher als „die meisten Nutzer“.
Problemkarte: Beobachtung, Hypothese, Empfehlung, Prüfung
Jedes Problem aus der Zusammenfassung bekommt im Bericht eine eigene Karte mit vier Feldern in fester Reihenfolge. Die Beobachtung beschreibt, was zu sehen ist, ohne Deutung. Die Hypothese nennt eine mögliche Ursache und ist klar als Vermutung gekennzeichnet. Die Empfehlung ist eine konkrete Änderung zur Freigabe. Die Prüfung legt fest, welches Verhalten du nach dem Release vergleichst und unter welchen Bedingungen.
- Beobachtung
9 von 14 angesehenen mobilen Besuchen mit geöffnetem Formular enden vor dem Absendebutton
- Hypothese
Die Kalenderauswahl verdeckt den Button auf kleineren Bildschirmen
- Empfehlung
Kalenderauswahl durch eine Liste der nächsten freien Termine ersetzen
- Prüfung
Gleiche Seiten und Geräte in einem vergleichbaren Zeitraum nach dem Release
Die Trennung von Beobachtung und Hypothese zahlt sich im Gespräch aus. Der Kunde kann der Ursache widersprechen, aber ein Verhalten, das in der Aufzeichnung sichtbar ist, lässt sich schwer bestreiten. Die Diskussion dreht sich dann darum, wie die Hypothese geprüft wird, und nicht darum, wer recht hat. Wie du Aufzeichnungen so ansiehst, dass die Beobachtung trägt, zeigt der Leitfaden zur Analyse von Sitzungsaufzeichnungen; für die Heatmaps gibt es den Artikel, wie du Heatmaps auswertest.
Das GOV.UK Service Manual rät, genau festzuhalten, was gesehen oder gehört wurde, und Schlüsse in einem eigenen Schritt zu ziehen; als Ergebnis der Analyse nennt es unter anderem neue User Stories für das Backlog. Die Empfehlungen gelten für Nutzerforschung in Behördenteams, nicht für Agenturberichte aus Heatmaps: GOV.UK: Analyse einer Research-Sitzung.
Link zu einer bestimmten Aufzeichnung statt Screenshot
Ein Screenshot zeigt einen einzelnen Moment und lässt sich unterschiedlich deuten. Eine Aufzeichnung zeigt die Abfolge: was die Person vor dem Problem und danach getan hat. Füge jeder Karte ein bis drei Links zu Aufzeichnungen hinzu und notiere, ab welcher Minute man schauen sollte.
In Meetlead teilst du eine Aufzeichnung über einen öffentlichen Link, der 24 Stunden, 7 oder 30 Tage gültig ist. Der Link gilt nie länger als die Aufzeichnung selbst, deren Aufbewahrungsdauer vom Tarif abhängt, und Inhalte des Chat-Widgets werden aus der Wiedergabe entfernt. Im Player kannst du einen Kommentar an einen Zeitpunkt der Aufzeichnung heften, damit das Team zur richtigen Stelle zurückfindet. Übernimm die Beobachtung trotzdem in den Bericht, denn nach Ablauf funktioniert der Link nicht mehr.
Die Aufzeichnungen stammen von der Website des Kunden, also kläre mit ihm, wer die Links bekommen soll, und gib sie nicht weiter. Wähle die kürzeste Gültigkeit, die für die Freigabe des Berichts reicht. Zahlen aus der Analyse hängst du als CSV- oder XLSX-Export an, und ein gespeicherter Bericht kann monatlich als XLSX-Datei per E-Mail an ausgewählte Adressen gehen. Das ist eine Zahlentabelle; die Problemkarten mit Aufzeichnungen ersetzt sie nicht.
Das GOV.UK Service Manual schlägt unter anderem vor, Forschungsergebnisse mit kurzen Videoclips von ein bis zwei Minuten und Zitaten von Teilnehmenden zu teilen. Das ist ein Rat für Produktteams, kein Beweis, dass eine Aufzeichnung jeden Kunden überzeugt: GOV.UK: Forschungsergebnisse teilen.
Eine freigegebene Empfehlung wird zur Aufgabe mit Beleg
- Entscheidungen des Kunden sammeln.Halte bei jeder Karte fest: freigegeben, abgelehnt oder zu klären, mit Datum und entscheidender Person.
- Eine Aufgabe pro Empfehlung anlegen.Der Titel beschreibt die Änderung, die Beschreibung enthält Beobachtung, Hypothese und Prüfbedingung aus der Karte.
- Aufgabe mit dem Beleg verknüpfen.Verknüpfe die Aufzeichnung, in der das Problem sichtbar ist, und das Ticket, falls der Kunde im Chat danach gefragt hat.
- Prüfung einplanen.Notiere das Release-Datum und vergleiche im nächsten Bericht das Verhalten unter gleichen Bedingungen.
In Meetlead Projekte kann eine Aufgabe mit einer Aufzeichnung, einem Ticket und anderen Aufgaben verknüpft sein und hat Priorität, verantwortliche Person und Kommentare mit Änderungsverlauf. Projekte ist eine eigene App, verfügbar je nach Tarif. Meetlead schreibt den Bericht nicht für dich und macht aus Empfehlungen nicht automatisch Aufgaben: Du legst sie nach der Entscheidung des Kunden an. Der Leitfaden zu Abnahmekriterien für Aufgaben hilft dir festzulegen, wann eine Aufgabe erledigt ist.
Lass auch abgelehnte Empfehlungen mit kurzer Begründung im Bericht stehen. Aus Punkten, die noch zu klären sind, wird eine Aufgabe zum Sammeln weiterer Belege, keine Verbesserung.
Fragen zum UX-Bericht für Kunden
Wie oft solltest du einem Kunden einen UX-Bericht schicken? Bei laufender Betreuung einer Website reicht meist einmal im Monat, weil ein kürzerer Zeitraum oft nicht genug Besuche für einen Vergleich nach Änderungen liefert. Bei wenig Traffic kommt ein Rhythmus von zwei Monaten infrage; vermerke das im Datenumfang.
Was tun, wenn es in einem Monat keine wichtigen Probleme gibt? Schreib das in die Zusammenfassung und zeige das Ergebnis der Prüfung früherer Änderungen. Füll die Liste nicht mit schwachen Beobachtungen auf, nur damit sie fünf Punkte hat.
