Kurz gesagt
Ein Design-Review läuft in vier Phasen ab: Vorbereitung, Sichtung, Konsolidierung und Freigabe. Jede Phase hat eine eigene Rolle als Verantwortlichen und eine eigene Zeitspanne, damit Feedback nicht endlos weiterläuft.
Warum Design-Reviews oft ausufern
Ohne festen Ablauf wird ein Design-Review zu einer offenen Diskussion, bei der jede Beteiligte zu jedem Zeitpunkt neue Punkte einbringen kann. Eine Phasenstruktur begrenzt, wann welches Feedback zulässig ist.
Phase 1: Vorbereitung
Der Designer oder das Team stellt den zu prüfenden Stand bereit – auf einer Staging-Seite, nicht als statisches Bild, damit Reviewer echtes Verhalten sehen. Verantwortlich: Design-Lead.
Phase 2: Sichtung
Alle Reviewer sehen sich den Stand unabhängig voneinander an und hinterlassen Notizen direkt am Element. Diese Phase läuft asynchron und braucht kein gemeinsames Meeting. Verantwortlich: jeder Reviewer einzeln.
Phase 3: Konsolidierung
Eine verantwortliche Person sichtet alle Notizen, entfernt Duplikate, klärt Widersprüche und priorisiert. Diese Phase braucht klare Entscheidungsbefugnis, sonst bleiben Widersprüche stehen. Verantwortlich: Projektleitung oder Design-Lead.
Phase 4: Freigabe
Nach Umsetzung der priorisierten Punkte bestätigt eine benannte Person die Freigabe schriftlich. Verantwortlich: Auftraggeber oder Product Owner.
Realistischer Zeitplan
Für ein mittleres Projekt hat sich folgender Rahmen bewährt:
- Vorbereitung: 1 Tag
- Sichtung: 2–3 Tage, parallel für alle Reviewer
- Konsolidierung: 1 Tag
- Umsetzung priorisierter Punkte: 2–5 Tage je nach Umfang
- Freigabe: 1 Tag
Wer sollte ein Design-Review durchführen?
Reviewer-Rollen unterscheiden sich in der Perspektive, nicht nur in der Hierarchie:
- Design-Lead: Konsistenz mit dem Designsystem
- Entwicklung: technische Umsetzbarkeit
- Fachabteilung/Kunde: inhaltliche Richtigkeit
- Barrierefreiheits-Check: Kontraste, Lesbarkeit, Tastaturbedienung
Synchron oder asynchron?
Ein gemeinsames Meeting eignet sich für Grundsatzentscheidungen, ist aber ineffizient für Detailfeedback. Asynchrone Notizen direkt am Element erlauben paralleles Arbeiten ohne Terminabstimmung.
Design-Feedback vs. Geschmacksfragen
Ein Review sollte zwischen Verstößen gegen das Designsystem (objektiv) und persönlichen Präferenzen (subjektiv) trennen. Nur Ersteres sollte automatisch zu einer Änderung führen.
Design-Reviews remote und über Zeitzonen hinweg
Bei verteilten Teams verschiebt sich der Schwerpunkt fast vollständig auf die asynchrone Sichtungsphase, da ein gemeinsames Meeting für alle Zeitzonen selten praktikabel ist. Notizen direkt am Element ersetzen dabei das Meeting: Jeder Reviewer hinterlässt Kommentar, Screenshot-Kontext und Priorität, ohne auf eine Antwort in Echtzeit zu warten. Wichtig ist eine klar kommunizierte Frist in einer neutralen Zeitzone (z. B. UTC) und ein tägliches kurzes Update der konsolidierenden Person, damit Reviewer in anderen Zeitzonen den Fortschritt sehen, ohne nachfragen zu müssen. Ein optionales, kurzes synchrones Meeting am Ende der Sichtungsphase klärt nur die Punkte, die schriftlich nicht eindeutig zu lösen waren.
Wie misst man den Erfolg eines Design-Reviews?
Ein Design-Review war erfolgreich, wenn drei Dinge zutreffen: Die Freigabe erfolgt innerhalb des geplanten Zeitrahmens, es gibt nach der Freigabe keine grundlegenden Änderungswünsche mehr, und die Anzahl offener Punkte sinkt mit jeder Iteration spürbar statt zu wachsen. Ein einfacher Indikator ist die Zeit von der ersten Notiz bis zur finalen Freigabe – wird dieser Zeitraum über mehrere Projekte hinweg kürzer, funktioniert der Prozess. Steigt stattdessen die Zahl der Iterationen oder tauchen in Runde drei noch Punkte auf, die in Runde eins hätten auffallen müssen, deutet das auf eine unklare Rollenverteilung oder eine zu späte Einbindung wichtiger Reviewer hin.
Häufige Fehler im Review-Prozess
Diese Muster verlängern ein Design-Review unnötig:
- Feedback kommt über mehrere Kanäle gleichzeitig herein
- Es gibt keine benannte Person für die Konsolidierung
- Reviewer erhalten kein Feedback zum Status ihrer eigenen Punkte
- Die letzte Phase (Freigabe) wird nicht explizit eingefordert
Checkliste für ein strukturiertes Review
Vor dem Start eines Reviews:
- Staging-Link mit aktuellem Stand bereit
- Reviewer-Liste mit klaren Rollen festgelegt
- Frist für die Sichtungsphase kommuniziert
- Verantwortliche Person für die Konsolidierung benannt
Häufige Fragen
Wie viele Reviewer sind sinnvoll?
Drei bis fünf mit klar unterschiedlicher Perspektive; mehr Reviewer erzeugen meist mehr Widersprüche als Erkenntnis.
Sollte ein Design-Review vor oder nach der Entwicklung stattfinden?
Idealerweise beides: einmal am Entwurf, einmal am umgesetzten Stand, da sich Details erst live zeigen.
Wie geht man mit widersprüchlichem Feedback zweier Reviewer um?
Die konsolidierende Person entscheidet anhand des Designsystems oder eskaliert an den Product Owner.
Was, wenn die Konsolidierungsphase zu lange dauert?
Meist fehlt eine klar benannte, entscheidungsbefugte Person – das ist die häufigste Ursache.
Braucht jedes Projekt vier Phasen?
Kleine Projekte können Vorbereitung und Sichtung zusammenlegen, sollten aber Konsolidierung und Freigabe trotzdem trennen.
Wie dokumentiert man die Freigabe eines Reviews?
Schriftlich, mit Datum, geprüfter Version und Name der freigebenden Person.
Wie lässt sich Feedback aus einem Meeting nachträglich strukturieren?
Jeden im Meeting genannten Punkt sofort als Notiz am betroffenen Element festhalten, statt aus dem Protokoll zu rekonstruieren.