Wer UX-Verbesserungen priorisieren will, beginnt meist an der falschen Stelle: mit dem Streit, welche Anmerkung die wichtigste ist. Nach einer Stunde mit Heatmaps und Aufzeichnungen hast du ein Dutzend Beobachtungen, das Team aber nur Zeit für wenige Änderungen. Eine einfache ICE-Bewertung – Wirkung, Sicherheit, Einfachheit – entscheidet den Streit nicht für dich, zwingt aber dazu, aufzuschreiben, worauf jede Note beruht. Am meisten bewirkt der Buchstabe C, wenn du ihn nach der Stärke des Belegs vergibst und nicht nach der Überzeugung der Person, die die Anmerkung gemacht hat.
Dieser Leitfaden setzt dort an, wo das Sammeln von Beobachtungen endet. Wie du den Weg durch die Website durchgehst und Hypothesen sammelst, beschreibt der Conversion-Audit einer Website. Hier machst du aus fertigen Beobachtungen ein Backlog mit Links zu Belegen, bewertest sie von 1 bis 5, planst einen Sprint und prüfst, ob die Korrekturen gewirkt haben.
ICE-Bewertung in drei Fragen
Jeden Eintrag bewertest du mit drei Fragen. Wirkung: Wie stark hilft die Korrektur bei einem Schritt, der für das Unternehmen zählt, etwa beim Absenden einer Anfrage? Sicherheit: Wie stark ist der Beleg, dass das Problem existiert und diese Änderung es löst? Einfachheit: Wie wenig Arbeit kosten Umsetzung und anschließende Prüfung? Das Ergebnis ist das Produkt der drei Noten, eine schwache Note in einer Dimension zieht das Gesamtergebnis also deutlich nach unten.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Dimension | Frage | 1 Punkt | 5 Punkte |
|---|---|---|---|
| Wirkung (Impact) | Was ändert die Korrektur an einem wichtigen Schritt? | Element abseits des Hauptwegs | Blockiertes Formular, Preisseite oder Bestellung |
| Sicherheit (Confidence) | Wie stark ist der Beleg? | Meinung oder Geschmack | Wiederkehrendes Muster, von mehreren Quellen bestätigt |
| Einfachheit (Ease) | Wie viel Arbeit kosten Änderung und Prüfung? | Umbau mehrerer Seiten | Text- oder Einstellungsänderung in einer Stunde |
Itamar Gilad beschreibt ICE als Methode von Sean Ellis, bei der Wirkung, Sicherheit und Leichtigkeit multipliziert werden und die Sicherheit aus Belegen statt aus Meinungen entsteht. Der Text behandelt Produktideen; die Skala von 1 bis 5 und die Belegstufen für Aufzeichnungen in diesem Leitfaden sind unsere Anpassung: Itamar Gilad: ICE und Confidence Meter.
Jede Beobachtung als Backlog-Eintrag mit Beleg
Bewerte keine Notizen wie „Das Formular ist schwach“. Jeder Eintrag braucht die Seitenadresse, das Gerät, eine Beschreibung dessen, was zu sehen ist, und einen Link zu einer bestimmten Aufzeichnung oder Heatmap-Ansicht. Die Hypothese zur Ursache notierst du getrennt, denn genau sie prüfst du nach der Umsetzung. Geht es um wiederholte Klicks, kläre zuerst ihren Mechanismus mit dem Leitfaden zu Rage Clicks und Dead Clicks.
Ort: /angebot/, Smartphone, Formularschritt 2. Beobachtung: In 7 von 10 angesehenen Besuchen verdeckt das Einwilligungsbanner den Button „Senden“. Beleg: Links zu drei Aufzeichnungen und zur Klickkarte. Hypothese: Ein Teil der Besucher sieht den Button nicht und verlässt die Seite. ICE: I5 · C4 · E4 = 80. Prüfung: gleiche Bedingungen nach der Umsetzung.
In einem Monat weiß niemand mehr, warum ein Eintrag eine hohe Sicherheit bekam, und eine neue Person im Team erkennt das Problem nicht am Aufgabentitel. Aufzeichnungen werden nur begrenzt lange gespeichert, also übernimm die Beobachtung in die Aufgabe, statt nur zu verlinken. So bleibt die Bewertung nachvollziehbar. Dieselbe Beobachtung mit Aufzeichnungslink hilft dir später im UX-Bericht für Kunden, in dem die Empfehlung auf Freigabe wartet.
Sicherheit nach Belegstufe: Eine Aufzeichnung ist noch kein Muster
Der häufigste Fehler ist hohe Sicherheit nach einer einzigen eindrucksvollen Aufzeichnung. Ein Besuch zeigt, dass ein Problem auftreten kann, nicht wie oft. Statt nach Gefühl zu bewerten, koppelst du die Sicherheit an die Belegstufe und nutzt für alle Einträge dieselbe Tabelle. Aus dem Streit über die Note wird dann die Frage, welcher Beleg noch fehlt.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Sicherheit | Beleg | Beispiel |
|---|---|---|
| 1 | Meinung, Geschmack, Vergleich mit Wettbewerbern | „Die Überschrift ist langweilig“ |
| 2 | Eine einzelne Aufzeichnung oder eine Kundenfrage | Eine Person kehrt dreimal zur Preisseite zurück |
| 3 | Wiederkehrendes Muster in Aufzeichnungen eines Segments | Mehrere mobile Besuche enden im selben Feld |
| 4 | Muster plus Nachstellung oder Kundenfragen | Fehler auf einem Testgerät nachgestellt |
| 5 | Mehrere unabhängige Quellen und eine frühere erfolgreiche Änderung | Aufzeichnungen, Heatmap, Chat und ein früherer Test zeigen dasselbe |
Ein Muster zählst du in vergleichbaren Besuchen: dieselbe Seite, ähnliches Gerät, derselbe Schritt. Wie du eine Stichprobe auswählst, erklärt der Leitfaden zur Analyse von Sitzungsaufzeichnungen, und wann eine Karte dicht genug für Schlüsse ist, der Text darüber, wie viele Daten eine Heatmap braucht. Niedrige Sicherheit bei hoher Wirkung heißt nicht Ablehnung. Sie heißt: eine Aufgabe „Beleg sammeln“, die selbst in den Sprint kommen kann.
Wirkung und Einfachheit ohne Raterei
Die Wirkung bewertest du über die Position im Ablauf und die Reichweite. Ein Problem im Kontaktformular trifft alle, die sich melden wollen; ein Problem im Footer nur wenige. Berücksichtige, ob Besucher das Problem umgehen können und ob sie jedes Mal darauf stoßen. Trag keinen erwarteten Conversion-Anstieg in Prozent ein, wenn du dafür keine Messung hast.
Jakob Nielsen (1994) schlägt vor, den Schweregrad eines Usability-Problems nach Häufigkeit, Auswirkung auf Nutzer und Beständigkeit zu bewerten. Der Artikel behandelt die heuristische Evaluation, nicht Heatmaps, und nennt keine Methode, den Schweregrad mit den Kosten einer Korrektur zu verbinden: NN/g: Schweregrad von Usability-Problemen.
Einfachheit umfasst mehr als Entwicklerzeit. Rechne die Freigabe von Texten, die Abhängigkeit von externen Anbietern und die Arbeit für die Prüfung des Effekts mit ein. Eine Button-Beschriftung zu ändern ist oft eine 5, ein Formular in einem Fremdsystem eher eine 2. Ein bestätigter Fehler, der das Absenden blockiert, wartet nicht auf die Bewertung; den Unterschied zwischen Schwere und Zeitpunkt der Behebung erklärt der Leitfaden zu Priorität und Schweregrad.
Bewertungsbeispiel auf einer fiktiven Website
Ein fiktives Steuerbüro hat eine Website mit Preisseite und Angebotsformular. Nach der Durchsicht bleiben vier Einträge. Die Noten veranschaulichen die Methode und sind kein Ergebnis eines echten Projekts.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Eintrag | I | C | E | ICE |
|---|---|---|---|---|
| Einwilligungsbanner verdeckt „Senden“ auf dem Smartphone | 5 | 4 | 4 | 80 |
| Klicks auf nicht klickbare Kundenlogos | 2 | 3 | 5 | 30 |
| Chatfragen zu Einrichtungskosten, wenig Scrollen bis zu den FAQ | 4 | 2 | 3 | 24 |
| Neues Startseiten-Layout nach Anmerkung des Inhabers | 3 | 1 | 1 | 3 |
Der erste Eintrag kommt ohne Diskussion in den Sprint. Der dritte hat hohe Wirkung, aber schwache Belege, deshalb bekommt er zuerst eine Aufgabe: Besuche mit Einstieg auf der Preisseite ansehen und Fragen aus dem Chat sammeln. Die Logos sind leicht, aber unwichtig – erledige sie nur, wenn Zeit bleibt. Der Umbau der Startseite wartet, bis jemand einen Beleg bringt.
Sieh das Ergebnis als Ausgangspunkt für das Gespräch, nicht als Urteil: Der Abstand zwischen 30 und 24 bedeutet nichts, der zwischen 80 und 3 sehr wohl.
Plan für einen Sprint und Prüfung nach der Umsetzung
- Sprintziel festlegen.Ein Schritt im Ablauf, etwa das Absenden des Angebotsformulars, statt „UX verbessern“.
- Einträge mit dem höchsten Ergebnis nehmen.Zwei oder drei Korrekturen für dieses Ziel und eine Aufgabe zum Sammeln von Belegen für einen Eintrag mit niedriger Sicherheit.
- Prüfbedingung notieren.Zu jeder Korrektur: Seite, Gerät, Verhalten, das verschwinden soll, und Datum der Umsetzung.
- Umsetzen und vergleichbaren Zeitraum abwarten.Sieh dir Besuche aus demselben Segment nach dem Änderungsdatum an, nicht davor.
- Bewertung aktualisieren.Ein bestätigter Effekt erhöht die Sicherheit ähnlicher Einträge, kein Effekt senkt sie und der Eintrag geht zurück ins Backlog.
In Meetlead Projekte kann eine Aufgabe mit einer Aufzeichnung, einem Ticket und anderen Aufgaben verknüpft sein und hat eine hohe, mittlere oder niedrige Priorität, ein Epic sowie einen Platz im Backlog oder im aktiven Sprint. Die Klickkarte zeigt, wie viele gespeicherte Aufzeichnungen zu einem Punkt gehören, und öffnet ihre Liste. Meetlead berechnet keine ICE-Werte: Trag das Ergebnis in die Aufgabenbeschreibung ein und übersetze Bereiche in die Priorität, etwa ab 60 als hoch.
Halte nach der Umsetzung in einem Kommentar fest, was du geprüft hast und mit welchem Ergebnis. Weniger Klicks auf einen verdeckten Button reichen nicht, wenn das Formular weiterhin nicht abgeschickt wird. Lässt der Traffic einen Vergleich von Varianten zu, nutze A/B-Tests; bei wenig Traffic bleibt ein vorsichtiger Vorher-nachher-Vergleich. Dieselbe Logik für die Sicherheit hilft bei Funktionswünschen von Kunden, wie der Leitfaden zu Supportanfragen und Produktplanung zeigt.
Fragen zur ICE-Bewertung
Warum eine Skala von 1 bis 5 und nicht von 1 bis 10? Bei einem kleinen Team und einem Dutzend Einträgen erzeugen zehn Stufen falsche Genauigkeit: Den Unterschied zwischen 6 und 7 kann kaum jemand begründen. Fünf Stufen lassen sich jeweils in einem Satz beschreiben. Wichtiger als die Skala ist, das ganze Backlog mit derselben Tabelle und in einer Sitzung zu bewerten.
Reicht ICE oder brauche ich RICE? Für Korrekturen an einer Website reicht ICE meist, weil du die Reichweite über die Position im Ablauf ohnehin in der Wirkung berücksichtigst. Vergleichst du Änderungen auf vielen Seiten mit sehr unterschiedlichem Traffic, ist eine eigene Reichweitennote oft übersichtlicher. Egal welche Methode: Notiere zu jeder Note den Beleg, sonst ist die Bewertung nur eine ordentlich sortierte Meinung.
