Design-Critique-Frameworks: So führst du Reviews, die die Arbeit wirklich besser machen
Ein Praxisleitfaden für Designer, um Design-Critique zu leiten und zu überstehen. Die Frameworks, die Regeln und die Struktur, die Reviews von Ego-Verteidigung in echtes Feedback verwandeln.
Die meisten Design-Reviews sind Theater. Die Senior-Designerin redet 20 Minuten über eine Button-Farbe, der Junior nickt, und die Arbeit geht unverändert oder schlechter live. Niemand lernt etwas, die Arbeit wird nicht besser, und das Team fürchtet bald das Meeting, das es eigentlich schärfer machen sollte.
Dieses Paper ist die Arbeitsversion. Die Frameworks, die Critique zum Werkzeug machen, die Regeln, die das Ego aus dem Raum halten, und die Struktur, die Feedback für die Person, deren Arbeit auf dem Bildschirm liegt, wirklich nützlich macht. Keine „Designkultur"-Floskeln, keine Manifeste, nur die Betriebsanleitung eines Teams, das bessere Arbeit liefert, weil es sie gut reviewt.
Was Design-Critique wirklich ist
Design-Critique ist strukturiertes Peer-Review von Arbeit im Entstehen. Das Ziel: Probleme sichtbar machen, die der Designer aus dem eigenen Entwurf heraus nicht sehen kann, und die Arbeit vor dem Release gegen Nutzer, Briefing und System zu testen. Critique ist keine Freigabe, keine Empfehlung und keine Abstimmung.
Eine Critique ist auch keine Präsentation. Der Designer ist nicht da, um die Arbeit zu verteidigen. Die Reviewer sind nicht da, um sie zu bewundern. Beide Seiten sind da, um die nächste Iteration besser zu machen als die aktuelle.
Der Design-Portfolio-Guide zeigt, wie einzelne Arbeiten extern bewertet werden. Dieses Paper geht tief in das interne Team-Review, das andere Ziele und sehr andere Regeln hat.
Warum die meisten Critiques scheitern
Dieselben fünf Fehler tauchen in fast jedem Team auf, das mit Critique kämpft. Wenn sich das Meeting zäh anfühlt und die Arbeit nicht besser wird, schau zuerst hier.
Der Designer präsentiert, statt zu fragen. Die Arbeit wird von vorne bis hinten durchgegangen, die Reviewer warten höflich, es wird kein konkretes Feedback erbeten. Die Reviewer fallen auf Reaktionen auf hoher Flughöhe zurück, weil nichts eingegrenzt wurde.
Reviewer konkurrieren. Jeder will das klügste Problem als Erster finden. Das Gespräch driftet zu dem, der am seniorsten klingt. Der Designer geht mit zwölf widersprüchlichen Meinungen und ohne klaren Weg nach vorn.
Persönlicher Geschmack wird als Prinzip verkleidet. Ein Reviewer mag die Schrift nicht und nennt es ein Hierarchieproblem. Ein anderer bevorzugt ein anderes Layout-Pattern und nennt es Barrierefreiheit. Ohne Framework gewinnt der Geschmack.
Niemand schreibt etwas auf. Das Gespräch findet statt, das Meeting endet, der Designer erinnert sich an vielleicht 30 % davon. Die nächste Critique deckt dasselbe Terrain ab.
Die Critique kommt zu spät. Die Arbeit ist schon zu 90 % fertig. Feedback zu größeren Umbauten wird ignoriert, weil keine Zeit bleibt. Critique schrumpft auf Politur.
Jeder dieser Fehler ist behebbar. Die Lösungen sind der Rest dieses Papers.
Das Drei-Ebenen-Feedbackmodell
Jedes nützliche Design-Feedback passt in eine von drei Ebenen. Reviewer, die benennen können, auf welcher Ebene sie gerade sind, bleiben fokussiert. Reviewer, die das nicht können, driften in Geschmack ab.
Ebene 1: Beobachtung
Beobachtung ist das, was der Reviewer buchstäblich auf dem Bildschirm sieht. Keine Interpretation, kein Urteil.
„Der CTA liegt bei einem 1440 breiten Viewport unterhalb des sichtbaren Bereichs." Das ist Beobachtung. „Der Button ist klein." Das ist Beobachtung. „Auf dieser Seite sind drei verschiedene Sans-Serifen sichtbar." Das ist Beobachtung.
Beobachtungen sind nicht verhandelbar. Der Designer kann sie in Echtzeit am Bildschirm prüfen. Sie sind die sicherste Ebene, weil keine Seite sie widerlegen kann.
Ebene 2: Interpretation
Interpretation ist das, was die Beobachtung für Nutzer, Marke oder System bedeuten könnte.
„Dass der CTA unterhalb des sichtbaren Bereichs liegt, heißt, dass mobile Nutzer ihn wahrscheinlich überscrollen, bevor sie merken, was die Seite von ihnen will." Das ist Interpretation. „Die drei Sans-Serifs wirken inkonsistent, was dem Nutzer signalisiert, dass die Markenstimme unklar ist." Das ist Interpretation.
Interpretationen sind diskutierbar. Zwei Menschen können dieselbe Beobachtung unterschiedlich deuten. Das ist der produktive Teil der Critique. Bei der Interpretation bringt die kollektive Erfahrung des Teams Wert in den individuellen Entwurf.
Ebene 3: Vorschlag
Vorschlag ist das, was der Reviewer angesichts der Interpretation in Betracht ziehen würde.
„Du könntest testen, den CTA above the fold zu setzen oder beim Scrollen einen Sticky CTA einzublenden." Das ist ein Vorschlag. „Du könntest auf eine Sans-Serif für den Fließtext und eine Display-Schrift reduzieren und die Hierarchie dann mit einem schnellen Squint-Test prüfen." Das ist ein Vorschlag.
Vorschläge kann der Designer annehmen oder lassen. Der Designer besitzt die Arbeit. Der Reviewer bietet Optionen an, keine Befehle. Eine Critique mit verpflichtenden Vorschlägen ist keine Critique, sondern eine Befehlskette.
Critique-Frameworks, die wirklich funktionieren
Ein Framework ist ein Skript für das Meeting. Es nimmt die kognitive Last ab, im Moment herauszufinden, wie man Feedback gibt, und lässt die Reviewer sich auf die Arbeit selbst konzentrieren.
Framework 1: Ziel, Begründung, Feedback
Das am schnellsten einzuführende Framework. Drei Schritte, zehn Minuten pro Arbeit.
Schritt eins: Der Designer nennt das Ziel. „Ich will einen Nutzer mit einem Klick von der Startseite zu einer bezahlten Anmeldung bringen." Maximal zwei Sätze.
Schritt zwei: Der Designer erläutert die Begründung. „Ich habe den CTA in den Hero gesetzt, weil der letzte Test zeigte, dass 60 % der Conversions above the fold passieren. Ich habe das Grün gewählt, weil die Marke es für primäre Aktionen nutzt." Maximal drei Minuten.
Schritt drei: Die Reviewer geben Feedback gegen das Ziel. Jeder Kommentar muss auf das genannte Ziel zurückführen. „Unterstützt der CTA das Ziel?" statt „Ist der CTA im richtigen Grünton?"
Feedback, das nicht zum Ziel passt, landet auf einer separaten Liste für später. Das Meeting bleibt fokussiert. Der Designer geht mit einem klaren Weg nach vorn.
Framework 2: I Like, I Wish, What If
Von IDEO übernommen und für Design-Teams angepasst. Nützlich, wenn die Arbeit früh und explorativ ist.
I like: Was funktioniert. Reviewer benennen konkrete Elemente, die die Arbeit behalten sollte. Erzwingt positive Beobachtung, die die meiste Critique überspringt.
I wish: Was der Reviewer ändern würde. Als Wunsch formuliert, nicht als Befehl. „Ich wünschte, der Kontrast zwischen Headline und Fließtext wäre stärker."
What if: Spekulative Alternativen. „Was, wenn der CTA ein Sticky-Element statt inline wäre?" Öffnet Richtungen, die der Designer vielleicht nicht bedacht hat.
Das Framework funktioniert, weil es den Einsatz senkt. Wünsche und Was-wäre-wenn-Fragen fühlen sich kollaborativ an. Direkte Kritik fühlt sich oft konfrontativ an, auch wenn sie es nicht ist.
Framework 3: Der Decision Stack
Am besten für späte Phasen, in denen das Team entscheidet, was live geht.
Decision required: Wofür genau braucht der Designer eine Entscheidung? „Soll der sekundäre CTA bleiben oder gestrichen werden?" Nicht „Schaut euch dieses Mockup an."
Options on the table: Was hat der Designer erwogen? Zeig die verworfenen Alternativen. Reviewer können fragen, warum bestimmte Optionen ausgeschieden sind.
Recommendation: Was empfiehlt der Designer und warum?
Risks: Was könnte bei der Empfehlung schiefgehen?
Die Aufgabe des Reviewers ist es, die Empfehlung gegen die Risiken zu testen. Hat der Designer ein Risiko übersehen? Sind die Risiken richtig gewichtet? Ist die Empfehlung wirklich die stärkste der gezeigten Optionen?
Dieses Framework zwingt Designer, die Arbeit vor dem Meeting zu erledigen. Das Meeting wird zum Test des Denkens, nicht zur Neuerzeugung von Denken aus dem Nichts.
Regeln, die den Raum funktionsfähig halten
Frameworks strukturieren das Meeting. Regeln steuern das Verhalten darin. Ohne Regeln kollabiert selbst das beste Framework in dasselbe lose Gespräch, das schon letztes Mal nicht funktioniert hat.
Regel 1: Der Designer grenzt das Feedback ein
Bevor die Critique beginnt, sagt der Designer, welche Art von Feedback er will. „Ich suche Feedback zur Hierarchie und zum CTA. Die Farbpalette steht fest, der Text ist final." Das schützt die Zeit des Designers und die Aufmerksamkeit der Reviewer.
Will ein Reviewer etwas außerhalb des Rahmens kommentieren, notiert er es für nach dem Meeting oder für eine separate Session. Er bringt die Critique nicht aus dem Gleis.
Regel 2: Immer nur ein Gespräch
Nebengespräche töten Critique. Der ganze Sinn ist kollektive Aufmerksamkeit auf einer Arbeit. Fangen zwei Reviewer an, untereinander zu debattieren, holt der Facilitator sie zurück in die Gruppe. Müssen drei Dinge besprochen werden, werden sie nacheinander besprochen, nicht parallel.
Regel 3: Konkret statt allgemein
„Das fühlt sich falsch an" ist kein Feedback. „Der CTA verliert Kontrast gegen den Verlaufshintergrund, was die Sichtbarkeit im Light Mode vermutlich beeinträchtigt" ist Feedback. Reviewer, die allgemeine Reaktionen geben, werden gebeten, konkret zu werden oder zu passen.
Regel 4: Keine Vorschriften ohne Beobachtung
Ein Reviewer darf keine Änderung empfehlen, ohne zuerst die Beobachtung zu nennen, die sie auslöst. „Mach den Button blau" ist eine Vorschrift ohne Beobachtung. „Der aktuelle rote Button wirkt fast wie dein Fehlerzustand, was Nutzer in kritischen Flows verwirren könnte. Du könntest Blau oder ein anderes Rot probieren" ist Beobachtung, Interpretation, Vorschlag.
Diese Regel ist die wirkungsvollste einzelne Änderung, die ein Team einführen kann. Sie zwingt Reviewer, vor dem Sprechen zu denken, und gibt dem Designer die Begründung, nicht nur die Forderung.
Regel 5: Alles festhalten
Jemand im Raum macht Notizen. Beobachtungen, Interpretationen, Vorschläge, Entscheidungen, Follow-ups. Der Designer sollte nicht der Notizenschreiber sein, weil er mit der Reaktion auf das Feedback kognitiv ausgelastet ist.
Die Notizen gehen direkt nach dem Meeting an den Designer. Der Designer markiert jede Notiz als angenommen, mit Begründung abgelehnt oder für später geparkt. Die nächste Critique beginnt damit, was sich seit dem letzten Mal geändert hat.
Regel 6: Zeitlich begrenzt und ergebnisdefiniert
Ein Critique-Meeting hat ein hartes Ende. Jede Arbeit bekommt einen festen Slot, meist 15 bis 30 Minuten. Der Facilitator setzt ihn durch. Überziehen ist der schnellste Weg, die Energie im Team zu verlieren und Leute davon abzubringen, überhaupt noch Arbeit ins Meeting zu bringen.
Jeder Slot endet mit einem benannten Ergebnis. „Designer verschiebt den CTA above the fold und testet den Kontrast auf dem Verlaufshintergrund. Teilt v2 in der nächsten Critique." Gibt es kein Ergebnis, hat das Meeting keinen Wert erzeugt.
Wann Critique stattfinden sollte
Späte Critique kommt fast immer zu spät. Den größten Hebel hat Critique dort, wo sich die Richtung noch billig ändern lässt.
Drei Critique-Punkte pro Projekt
Der Mindestplan, der ausgelieferte Arbeit hervorbringt, die sich mit der Zeit verbessert:
| Phase | Ziel | Framework |
|---|---|---|
| Richtung | Lösen wir das richtige Problem? | I Like, I Wish, What If |
| Mittlere Fidelity | Stimmt die Struktur? | Ziel, Begründung, Feedback |
| Vor dem Release | Ist das bereit für den Release? | Decision Stack |
Jede Phase hat andere Ziele und profitiert von einem anderen Framework. Wer eine davon überspringt, erzeugt vorhersehbare Fehlerbilder.
Die Richtungs-Critique zu überspringen heißt, dass das Team ein poliertes Mockup der falschen Lösung fertigstellt. Wird das zu spät entdeckt, ist es der teuerste Fehler, den ein Team machen kann.
Die Critique bei mittlerer Fidelity zu überspringen heißt, dass strukturelle Probleme erst bei hoher Fidelity auffallen, wo sie fünfmal mehr kosten. Das Team liefert Kompromissarbeit aus, weil keine Zeit für einen Neustart bleibt.
Die Critique vor dem Release zu überspringen heißt, dass vermeidbare Probleme in Produktion gehen. Das Ship-Doc wird ohne zweites Paar Augen geschrieben, und das Team erfährt vom kaputten Zustand im Nutzerfeedback.
Die Aufschlüsselung zum AI-Design-Workflow zeigt, wie Critique in KI-beschleunigte Design-Loops integriert wird. Schnellere Generierung macht Critique wichtiger, nicht unwichtiger.
Die Rolle des Facilitators
Die meisten Design-Critiques haben keinen Facilitator, und deshalb fallen sie auseinander. Der Facilitator ist nicht die Senior-Designerin im Raum. Der Facilitator ist, wer dafür verantwortlich ist, das Meeting funktionsfähig zu halten.
Was der Facilitator tut
Der Facilitator verantwortet drei Dinge:
- Zeit. Jede Arbeit bekommt ihren Slot. Harter Schnitt, wenn die Zeit abläuft. Geparkte Punkte wandern auf eine Follow-up-Liste.
- Fokus. Reviewer zurückholen, wenn sie abdriften, Rückfragen stellen, wenn Feedback vage ist, benennen, wenn das Gespräch den Rahmen verlassen hat.
- Festhalten. Entweder selbst Notizen machen oder sicherstellen, dass es jemand tut. Die Notizen sind nicht optional, sie sind das Artefakt des Meetings.
Der Facilitator ist nicht da, um Critique zu geben. Er darf Critique erst geben, wenn die Meeting-Struktur erledigt ist. Facilitation mit Critique zu mischen spaltet die Aufmerksamkeit und führt fast immer bei beidem zu einem schlechteren Ergebnis.
Die Rolle rotieren lassen
Wenn dieselbe Person jede Critique moderiert, wird sie zum Flaschenhals. Rotiere die Rolle wöchentlich oder alle zwei Wochen durchs Team. Junior-Designer profitieren enorm vom Moderieren, weil sie so strukturell über das Meeting nachdenken müssen, nicht nur über die Arbeit.
Auch Seniors profitieren. Moderieren statt kritisieren zwingt einen Senior zuzuhören statt zu dominieren, eine Fähigkeit, die die meisten Senior-Designer unterschätzen.
Wie man Critique empfängt
Die andere Hälfte der Critique ist, der Designer auf dem Stuhl zu sein. Die meiste Design-Ausbildung überspringt das komplett. Das Ergebnis ist eine Generation von Designern, die defensiv werden, wenn ihre Arbeit geprüft wird, und genau das Feedback abtun, das ihnen am meisten geholfen hätte.
Fünf Regeln für den Designer
Hör vollständig zu, bevor du antwortest. Unterbrich nicht, um eine Entscheidung zu verteidigen. Nimm das Feedback auf, schreib es auf, stell dann Rückfragen. Der Verteidigungsinstinkt tötet den Wert des Meetings.
Trenne die Beobachtung vom Vorschlag. Ein Reviewer schlägt vielleicht eine Lösung vor, der du nicht zustimmst, aber die zugrunde liegende Beobachtung kann trotzdem stimmen. Nimm die Beobachtung, lass den Vorschlag, finde deine eigene Lösung.
Frag nach dem Warum, nicht nach dem Ob. „Warum glaubst du, dass der CTA Kontrast verliert?" liefert nützliche Anschlussgespräche. „Glaubst du, dass der CTA Kontrast verliert?" liefert ein Ja oder Nein, das das Gespräch beendet.
Parke deine Reaktionen. Trifft dich ein Feedback hart, schreib es auf und antworte später. Verteidigung in Echtzeit erzeugt auf beiden Seiten schlechte Antworten. Eine Pause von 24 Stunden liefert fast immer eine bessere Antwort.
Besitze die Entscheidung. Der Designer besitzt die Arbeit. Nach der Critique entscheidet der Designer, worauf er reagiert. Reviewer bieten Optionen an, keine Befehle. Die Aufgabe des Designers ist es, das Feedback gegen alles andere abzuwägen, was er über das Projekt weiß, und zu entscheiden.
Critique unter den Bedingungen von 2026
Drei Veränderungen haben verändert, wie Design-Critique funktioniert. Das System muss sich an alle drei anpassen.
Remote- und asynchrone Critique sind der Standard. Das All-Hands-Meeting im Raum ist selten. Critique findet heute in Figma-Kommentaren, Loom-Aufnahmen und geteilten Dokumenten statt. Die Frameworks funktionieren weiter, die Moderation zählt weiter, aber das Timing ändert sich. Asynchrone Critique braucht eine klare Anfrage, eine klare Deadline und einen klaren Entscheidungspunkt. Ohne das wird sie zum Kommentarfriedhof.
KI-generierte Arbeit braucht mehr Critique, nicht weniger. Tools, die in Sekunden Optionen erzeugen, verleiten dazu, Critique zu überspringen, weil die Arbeit „nur KI-Output" ist. Genau dann zählt Critique am meisten. KI-generierte Arbeit ist standardmäßig niemandem rechenschaftspflichtig. Menschliche Critique macht sie verantwortbar.
Funktionsübergreifende Critique ist inzwischen Standard. Engineers, PMs und Content-Designer sitzen in derselben Critique wie visuelle Designer. Die Frameworks funktionieren für alle. Das Vokabular muss flacher werden. „Affordance" und „above the fold" sind in Ordnung, aber das ganze Meeting darf nicht aus Designer-Jargon bestehen, sonst klinken sich die Nicht-Designer aus.
Das Glossar zum Design-Handoff zeigt, wie Critique mit der breiteren Handoff-Disziplin zusammenhängt. Critique, die kein teilbares Artefakt erzeugt, überlebt den Handoff nicht.
FAQ
Was ist ein Design-Critique-Framework?
Ein Framework ist ein strukturiertes Skript für ein Design-Review-Meeting. Es legt fest, wer wann spricht, welche Art von Feedback erbeten wird und wie das Meeting endet. Die gängigsten Frameworks sind Goal-Rationale-Feedback, I Like-I Wish-What If und der Decision Stack. Jedes passt zu einer anderen Phase der Arbeit.
Wie gibt man gutes Design-Feedback?
Nutze das Drei-Ebenen-Modell. Beginne mit der Beobachtung (was du siehst), dann die Interpretation (was es bedeuten könnte), dann der Vorschlag (was du in Betracht ziehen würdest). Lässt du eine Ebene aus, wird das Feedback schwächer. Lässt du die Beobachtung ganz weg, wird das Feedback zur Vorschrift, die der Designer abtun kann.
Wie lang sollte ein Design-Critique-Meeting sein?
15 bis 30 Minuten pro Arbeit, hart begrenzt. Eine 60-minütige Critique zu einer einzigen Arbeit ist fast immer entweder überladen oder läuft auf einem schlechten Framework. Begrenze jeden Slot, halte die Ergebnisse fest und geh weiter. Die meisten Teams besprechen 2 bis 4 Arbeiten pro Session.
Wie oft sollte ein Design-Team Critique abhalten?
Wöchentlich ist die Basis für ein kleines Team, das regelmäßig ausliefert. Zweiwöchentlich funktioniert bei längeren Projektzyklen. Der Rhythmus zählt weniger als die Konsequenz. Ein Team, das ein Jahr lang wöchentlich Critique macht, wird schneller besser als ein Team, das ad hoc Critique macht, wann immer jemand fragt.
Wie verhindert man, dass Critique persönlich wird?
Führe das Framework ein, führe die Regeln ein und lass den Facilitator rotieren. Die Frameworks trennen Beobachtung von Vorschrift, und genau dort beginnt die meiste persönlich wirkende Kritik. Der Facilitator fängt die Ausrutscher ab. Mit der Zeit verinnerlicht das Team die Struktur, und persönlich wirkende Kritik hört auf, weil die Sprache sie nicht mehr trägt.
Wie gibt man einer Senior-Designerin Critique?
Genauso wie jedem anderen. Nutze das Drei-Ebenen-Modell, verknüpfe das Feedback mit dem genannten Ziel und lass die Senior-Designerin die Entscheidung besitzen. Senior-Designer, die keine Critique vertragen, sind ein größeres Problem als die Critique selbst. Ein Team, das stillschweigend vermeidet, Senior-Arbeit zu prüfen, ist ein Team, das kompromittierte Senior-Arbeit ausliefert.
Critique ist eine Disziplin, kein Meeting
Das Team, das Critique gut betreibt, liefert bessere Arbeit, weil es Probleme früher findet, mehr Perspektiven auf jede Entscheidung bekommt und ein gemeinsames Vokabular für Designqualität entwickelt. Das Team, das Critique schlecht betreibt, liefert entweder ungleichmäßige oder polierte, aber falsche Arbeit, und wundert sich, warum das Meeting, das es jede Woche abhält, nicht hilft.
Die Lösung ist strukturell. Wähle ein Framework. Führe die Regeln ein. Plane Critique an drei Punkten pro Projekt, nicht am Ende. Halte die Ergebnisse fest. Lass den Facilitator rotieren. Empfange Critique ohne Verteidigung. Gib Critique ohne Vorschrift.
Die Kosten dieser Disziplin sind zwei oder drei Meetings mit leichtem Unbehagen, während sich das Team einstellt. Der Gewinn ist ein Team, das mit jedem Projekt schärfer wird, und ein Werk, das sich mit der Zeit verbessert, statt in Richtung der lautesten Meinung zu regredieren.
Wenn du ein Team willst, das diese Disziplin in jedes Projekt einbaut, hol dir Brainy. Wir arbeiten eingebettet mit internen Design-Teams und installieren Critique-Systeme neben der Marken- und Produktarbeit.
Weiterführende Lektüre
Want a design team that critiques without the drama and ships better work because of it? Brainy embeds with internal teams to install critique systems and ship product with the rigor baked in.
Get Started
