How to Document Design Decisions

Du öffnest morgens den letzten Entwurf, findest drei neue Kommentare und erkennst sofort, dass zwei davon einander widersprechen. Eine Person bezieht sich auf die Version im E-Mail-Anhang, eine andere auf den Figma-Stand aus dem gestrigen Call. Niemand kann sicher sagen, welche Entscheidung gilt, wer sie getroffen hat oder warum die aktuelle Variante überhaupt so aussieht.

Genau hier beginnt die praktische Frage, wie man Designentscheidungen dokumentiert. Nicht als zusätzliche Bürokratie, sondern als prüfbare Verbindung zwischen Anlass, Abwägung, Entscheidung, Umsetzung und Freigabe. Gute Dokumentation hält den Kontext dort fest, wo er später wieder gebraucht wird, und macht aus verstreuten Meinungen einen belastbaren Arbeitsstand.

Inhaltsverzeichnis

• Warum Designentscheidungen unsichtbar verschwinden
  • Die versteckten Kosten fehlender Begründungen
• Die ADR-Logik als Fundament sauberer Dokumentation
  • Die sechs Felder eines Design-Records
  • Unveränderlich nach der Freigabe
• Entscheidungen im Alltag festhalten ohne Bürokratie
  • Ein Karussell als Beispiel
  • Freigabe mit klarer Verantwortung
• Versionierung, Marker und Freigaben als Prüfspur
  • Die Datei muss ihre Geschichte erzählen
  • Drift aktiv verhindern
• Wo Entscheidungen wirklich abgelegt werden sollten
  • Ein minimaler Zwei-Schritt-Aufbau
• Häufige Fehler bei der Dokumentation von Designentscheidungen
  • Vier Sätze, die Teams misstrauisch machen sollten
• Deine Routine für revisionssichere Designentscheidungen
  • Ein praktikabler Zeitrahmen
  • Selbstprüfung pro Sprint

Warum Designentscheidungen unsichtbar verschwinden

Ein Layout wurde dreimal angepasst. Zwei Designer haben Änderungen eingearbeitet, drei Kund:innen haben über Slack und E-Mail kommentiert, dazu kamen spontane Rückfragen im Call. Die Headline ist inzwischen größer, der Abstand zum Button kleiner und die Farbe des Pricing-Blocks zurückhaltender. Auf die Frage, warum die Headline jetzt 32 statt 28 Pixel hoch ist, folgt trotzdem nur Schweigen.

Das Problem ist nicht, dass Menschen diskutieren. Das Problem ist, dass die Diskussion keinen stabilen Ort hat. Eine Begründung steckt im Slack-Thread, die abweichende Kundenmeinung in einer E-Mail und die eigentliche Änderung in einer Datei, deren Name keinen verlässlichen Status verrät. Nach einem Personalwechsel interpretiert das nächste Team die Marke erneut, weil die ursprünglichen Kriterien nie festgehalten wurden.

In Deutschland ist diese Lücke besonders sichtbar. Die Studie Design in Business kommt zu dem Befund, dass nur 45 % der befragten Unternehmen Design überhaupt in ihrer Unternehmensstrategie einsetzen und nur 25 % Designer:innen an strategisch-unternehmerischen Entscheidungen beteiligen. Die Ergebnisse unterstreichen, dass Designentscheidungen vielerorts noch nicht vollständig in Führungs- und Entscheidungsprozesse eingebettet sind, obwohl die Studie einen Zusammenhang mit besseren Produkten beschreibt. Die Ergebnisse der Design-in-Business-Studie zeigen damit nicht nur ein Kulturthema, sondern auch ein Dokumentationsproblem.

Die versteckten Kosten fehlender Begründungen

Teams zahlen zuerst mit Kontextstunden. Designer:innen suchen alte Entwürfe, Projektleitungen rekonstruieren Gesprächsverläufe und Kund:innen müssen erneut erklären, was sie eigentlich freigegeben hatten. Später entstehen Rückfragen im Sprint, unnötige Revisionsschleifen und widersprüchliche Markeninterpretationen.

Auch Abnahmen werden schwieriger. Wenn nicht ersichtlich ist, welche Version verbindlich freigegeben wurde, fehlt bei Konflikten eine klare Prüfspur. Das ist nicht automatisch ein juristischer Streit, aber eine organisatorische Lücke mit potenziell rechtlicher Bedeutung.

"

Praktische Regel: Eine Entscheidung, die nur im Kopf, Chat oder Meeting existiert, ist für das Projekt nicht belastbar.

Die Lösung braucht keinen langen Bericht. Ein kurzer Record mit Anlass, Entscheidung, Begründung, verantwortlicher Person, betroffenem Asset und Verweis auf die konkrete Version reicht oft aus. Teams, die ihre Team-Kommunikation verbessern wollen, sollten deshalb nicht zuerst mehr Kanäle einführen, sondern den Ort definieren, an dem eine Entscheidung verbindlich wird.

Dokumentation ist kein Selbstzweck. Sie beendet Diskussionen, macht Verantwortung sichtbar und verhindert, dass dieselbe Frage in jedem Sprint neu aufgerollt wird.

Die ADR-Logik als Fundament sauberer Dokumentation

Die Architecture Decision Record-Logik, kurz ADR, stammt aus der Softwarearchitektur. Ihr Kern ist einfach: Jede relevante Entscheidung wird als eigener Record mit Kontext, Optionen, Begründung und Konsequenzen festgehalten. Deutsche Fachquellen empfehlen zusätzlich Verweise auf Prototypen, Tests, Tickets oder Audits, damit die Entscheidung nicht isoliert bleibt, sondern überprüfbar wird. Die ADR-Logik für Architekturentscheidungen lässt sich direkt auf Design übertragen.

Eine Design-ADR sollte kurz bleiben. Eine Card auf einer Seite wird gelesen und gepflegt, ein mehrseitiger Bericht wird häufig nur noch abgelegt. Der Status verhindert Missverständnisse: Proposed bedeutet in Diskussion, Accepted gilt als verbindlich, Superseded wurde durch eine spätere Entscheidung ersetzt.

Die sechs Felder eines Design-Records

Die folgenden Felder bilden ein praktikables Minimum. Titel und ID machen den Record auffindbar, der Status zeigt seine Verbindlichkeit. Der Kontext beschreibt nicht die gesamte Projektgeschichte, sondern genau das Problem, das eine Entscheidung erforderlich macht.

Die Optionstabelle sollte nicht nur Vorlieben abbilden. Verknüpfe sie mit Kriterien wie Verständlichkeit, Barrierearmut, Markenpassung, technischer Aufwand, Fehlerrisiko oder einer messbaren Zielgröße. Die deutsche Designstudie beschreibt Design als Wertschöpfungsfaktor und verweist darauf, dass sich in über 70 Prozent der befragten Unternehmen Rendite, Marktanteile und Innovationsfähigkeit verbessern. Die Studienübersicht des German Design Council liefert dafür den relevanten Hintergrund. Für die Praxis folgt daraus: Dokumentiere nicht nur, was schöner wirkt, sondern welche Erfolgsmetrik die Wahl beeinflussen soll.

Unveränderlich nach der Freigabe

Nach dem Status Accepted sollte der ursprüngliche Record nicht still überschrieben werden. Eine spätere Änderung erzeugt einen neuen Record mit Verweis auf den alten. So bleibt sichtbar, welche Annahmen zuerst galten und wann sich die Rahmenbedingungen geändert haben.

Ein ADR ersetzt keine Designdatei. Er erklärt, warum die Datei so aussieht, und verweist auf den relevanten Frame, Prototyp, Test oder Proof. Eine strukturierte Entwurfsvorlage kann dabei helfen, diese Felder im Team einheitlich zu erfassen.

Entscheidungen im Alltag festhalten ohne Bürokratie

Eine gute Routine beginnt nicht mit einem Formular, sondern mit einem konkreten Auslöser. Das kann ein widersprüchlicher Kommentar im Proof sein, eine Einschränkung des CMS, ein aktualisiertes Brand-Element oder eine technische Rückmeldung aus der Entwicklung. Sobald die Entscheidung mehrere Personen, Assets oder Folgearbeiten betrifft, gehört sie in einen Record.

Die Card entsteht unmittelbar im Arbeitsfluss. Eine Designer:in formuliert den Kontext in wenigen Sätzen, verlinkt das betroffene Asset und nennt zwei oder drei realistische Optionen. Jede Option bekommt eine knappe Bewertung nach Aufwand, Risiko und Wirkung. Danach wird die Wahl mit einem klaren Satz begründet.

Ein Karussell als Beispiel

Nehmen wir eine Produktseite mit einem Karussell für Kundenlogos. Die erste Variante zeigt mehrere Logos gleichzeitig, die zweite nutzt ein einzelnes Logo mit Navigation, die dritte verzichtet auf Bewegung und ordnet die Logos in einem Raster an. Der Auslöser ist ein Review-Kommentar: Die Kundenseite möchte mehr Logos zeigen, das Accessibility-Review warnt jedoch vor automatisch wechselnden Inhalten.

Die ADR-Card könnte so aussehen:

• Kontext: Der Bereich soll Vertrauen schaffen, muss auf kleinen Displays funktionieren und darf keine automatische Bewegung voraussetzen.
• Optionen: Mehrere Logos mit Autoplay, ein manuell steuerbares Karussell oder ein statisches Raster.
• Entscheidung: Statisches Raster auf Desktop und eine reduzierte, manuell steuerbare Darstellung auf kleineren Screens.
• Begründung: Die Lösung hält die Inhalte sichtbar, reduziert Interaktionsrisiken und vermeidet eine zusätzliche Abhängigkeit vom Autoplay.
• Konsequenzen: Die Komponente braucht responsive Regeln, neue Content-Limits und einen dokumentierten QA-Fall.

Diese Card muss nicht jede Diskussion wiedergeben. Sie hält den entscheidenden Kontext fest, sodass ein späteres Team die Wahl nachvollziehen kann, ohne den gesamten Review-Verlauf zu durchsuchen.

Freigabe mit klarer Verantwortung

Im Review prüft nicht jede Person jedes Detail. Die zuständige Designer:in verantwortet die visuelle Lösung, die Projektleitung bestätigt Scope und Priorität, die Kundenseite gibt den vereinbarten Entwurf frei. Je nach Entscheidung kann zusätzlich Entwicklung, Accessibility oder Compliance gegenzeichnen.

Eine Entscheidung wird Superseded, wenn eine neue Card sie ersetzt. Der alte Record bleibt erhalten und bekommt einen Link zur neuen Version. So entsteht keine scheinbare Stabilität durch Überschreiben.

"

Was funktioniert: kurze Cards, klare Zuständigkeit und direkte Links zum betroffenen Asset.
Was nicht funktioniert: ein Formular, das erst am Ende des Projekts nachgepflegt werden soll.

Die Routine passt auch in verteilte Teams. Asynchrone Kommunikation im Designprozess funktioniert dann, wenn Kommentare nicht nur gesammelt, sondern in eine verbindliche Entscheidung überführt werden.

Versionierung, Marker und Freigaben als Prüfspur

Bei einem Pricing-Block kann eine kleine Farbänderung schnell mehrere Bedeutungsebenen berühren. Zuerst schlägt ein Designer einen neuen Hintergrund vor. Im ersten Kunden-Review wird eine kontrastreichere Variante verlangt. Danach arbeitet eine zweite Person am Entwurf weiter, bevor ein später Compliance-Hinweis die Frage aufwirft, ob die visuelle Hervorhebung eine unerwünschte Aussage erzeugt.

Ohne saubere Versionierung ist am Ende nicht mehr klar, welche Farbe aus welchem Grund eingeführt wurde. Ein Kommentar wie „bitte dunkler“ hilft nur so lange, wie alle Beteiligten dieselbe Datei geöffnet haben. Nach weiteren Reviews wird daraus eine Interpretationsfrage.

Die Datei muss ihre Geschichte erzählen

Semantische Dateinamen schaffen eine erste Orientierung. pricing-block-review-02 sagt mehr aus als final_v3_END. Noch wichtiger ist eine fortlaufende Version, die im Projekt eindeutig bleibt und mit dem Proof verknüpft wird. Der Marker sitzt direkt am betroffenen Element, nicht in einer separaten Kommentarspalte ohne räumlichen Bezug.

Ein belastbarer Verlauf enthält mindestens:

• Version: Welche Fassung wurde kommentiert oder freigegeben?
• Marker: Wo genau liegt die Änderung im Design?
• Kommentar: Was soll geändert oder geprüft werden?
• Autor:in: Wer hat den Hinweis eingebracht?
• Zeitpunkt: Wann entstand der Eintrag?
• Status: Ist der Hinweis offen, umgesetzt, zurückgestellt oder abgenommen?
• Freigabe: Wer hat welche Version verbindlich bestätigt?

Der Unterschied zwischen einem Kommentar und einer Prüfspur liegt in der Verknüpfung. Ein Marker erklärt die Stelle, die Version erklärt den Stand und die Freigabe erklärt die Verbindlichkeit. Fehlt eines davon, müssen Teams später wieder rekonstruieren.

Drift aktiv verhindern

Dokumentation und Umsetzung können auseinanderlaufen, wenn eine Entscheidung zwar festgehalten, aber nicht mit dem aktuellen Asset synchronisiert wird. Eine deutsche Hochschularbeit zu Architekturentscheidungen beschreibt genau dieses Problem und berichtet für das untersuchte Repository eine sehr geringe Abdeckung von 0,3 Prozent. Die Untersuchung zu doppelten und auseinanderlaufenden Entscheidungsständen macht deutlich, dass Drift nur sichtbar wird, wenn Teams Abgleich und Statuspflege systematisch unterstützen.

Für Design bedeutet das: Die ADR verweist auf die Version, der Proof zeigt die Marker und die Freigabe wird am selben Asset protokolliert. Ein späterer Re-Check prüft, ob die Entscheidung noch gilt oder durch neue Anforderungen ersetzt werden muss.

Ein Version-Control-Workflow für Designteams sollte deshalb nicht nur Dateien archivieren. Er muss sichtbar machen, welche Version geprüft, verändert und freigegeben wurde.

Wo Entscheidungen wirklich abgelegt werden sollten

Der beste Ablageort ist nicht das Tool mit den meisten Funktionen, sondern der Ort, an dem Entscheidung, Asset und Freigabe zusammen auffindbar bleiben. Notion ist flexibel und schnell, doch Seiten verteilen sich leicht über Projekte. Klassische Wikis eignen sich für dauerhafte Prinzipien, veralten aber, wenn niemand eine verantwortliche Pflege übernimmt. Jira und Linear verbinden Entscheidungen gut mit Entwicklungsarbeit, bieten jedoch oft keine präzise Designansicht.

Online-Proofing-Tools liegen näher am tatsächlichen Review. Sie können Kommentare, Marker und Versionen direkt am Entwurf führen. Dafür sind sie nicht immer der richtige Ort für übergeordnete Designprinzipien oder Architekturentscheidungen.

Ein minimaler Zwei-Schritt-Aufbau

Erstens braucht jedes Projekt eine zentrale Entscheidungsübersicht. Dort liegen ADRs, Status, Verantwortliche, Kriterien und Links zu Tickets oder Assets. Notion, ein Wiki oder ein Projektbereich kann diese Rolle übernehmen.

Zweitens braucht jedes relevante Asset einen Review-Verlauf. Kommentare, Marker, Versionen und Freigaben müssen dort bleiben, wo die konkrete Änderung sichtbar ist.

draftgo ist eine mögliche Lösung für diesen zweiten Schritt. Die Plattform bündelt Kommentare, Versionen und Freigaben direkt am Asset, unterstützt Marker für Designs sowie zeitbezogene Kommentare bei Videos und ermöglicht externe Reviews per Link ohne Kontoanlage. Für die übergeordnete ADR bleibt ein verlinktes Wiki oder Ticketsystem sinnvoll. Mehr Kontext zur Auswahl eines Dokumenten-Management-Systems hilft, die Archiv- und Berechtigungsseite getrennt von der Review-Frage zu bewerten.

Häufige Fehler bei der Dokumentation von Designentscheidungen

„Ein Slack-Thread reicht.“ Nein, er reicht für eine schnelle Abstimmung. Er reicht nicht als verbindlicher Record. Threads verlieren Sichtbarkeit, werden durch neue Antworten unübersichtlich und enthalten häufig keine eindeutige Aussage dazu, welche Version tatsächlich gilt.

„Im Confluence findet sich schon etwas.“ Das ist keine Strategie, sondern eine Hoffnung. Ein Wiki kann wertvoll sein, wenn Titel, Status, Verantwortliche und Verlinkungen gepflegt werden. Ohne diese Regeln liegen dort jedoch oft veraltete Prinzipien neben aktuellen Entscheidungen.

Vier Sätze, die Teams misstrauisch machen sollten

• „Das machen wir mündlich beim Daily.“ Mündliche Entscheidungen sind schnell, aber für abwesende Personen unsichtbar. Spätestens beim Personalwechsel fehlt die Begründung.
• „Die Datei heißt final_v3_END.psd.“ Der Name beschreibt weder den tatsächlichen Stand noch die freigebende Person.
• „Das war doch im letzten Review klar.“ Klarheit ohne protokollierten Status verschwindet, sobald mehrere Varianten im Umlauf sind.
• „Wir tragen das später nach.“ Später fehlt der Kontext, und die Card wird zur nachträglichen Erzählung statt zur zeitnahen Dokumentation.

Der häufigste Fehler liegt nicht im fehlenden Tool, sondern in unvollständigen Inhalten. Teams notieren die Entscheidung, vergessen aber den Anlass. Sie nennen die Option, erklären jedoch nicht, warum Alternativen verworfen wurden. Oder sie dokumentieren die Begründung, halten aber die Auswirkungen auf Komponenten, Content oder Entwicklung nicht fest.

"

Eine Entscheidung ohne Konsequenzen ist nur eine Meinung mit Statusfeld.

Wer später die Lücke schließt, trägt die Kosten. Das sind oft neue Designer:innen, Projektleiter:innen oder Entwickler:innen, die eine alte Änderung ausbaden müssen. In Workshops hilft deshalb eine klare Moderation, besonders wenn mehrere Stakeholder unterschiedliche Ziele verfolgen.

Die wichtigste Gegenmaßnahme ist banal: Nach der Entscheidung wird eine Person benannt, die den Record aktualisiert, den Status setzt und den Link zur freigegebenen Version einträgt. Ohne diesen letzten Schritt bleibt auch ein gutes Gespräch vorläufig.

Deine Routine für revisionssichere Designentscheidungen

Eine belastbare Wochenroutine braucht feste Momente, aber keine starre Zeremonie. Montags sammelt das Team offene Entscheidungen aus Reviews, Tickets, Calls und laufenden Entwürfen. Die wichtigsten Fälle werden priorisiert, besonders wenn sie mehrere Personen, Komponenten oder Kund:innen betreffen.

Am Mittag entsteht der ADR-Eintrag. Der Kontext beschreibt das Ziel, die Optionen zeigen die relevanten Trade-offs und die Begründung benennt die gewählte Richtung. Donnerstag prüft die zuständige Runde die offenen Cards. Freigegebene Entscheidungen werden anschließend mit Status, Version und Verweisen abgeschlossen.

Ein praktikabler Zeitrahmen

• 15 Minuten für die Sammlung: Offene Fragen, widersprüchliche Kommentare und blockierte Freigaben zusammentragen.
• 25 Minuten für den ADR: Kontext, Optionen, Entscheidung, Begründung und Konsequenzen erfassen.
• 10 Minuten für die Freigabe: Relevante Stakeholder prüfen die Card und bestätigen den Status.
• 5 Minuten für die Versionsnotiz: Asset-Version, Marker, Freigabeperson und Zeitpunkt verknüpfen.

Diese Zeitfenster sind keine Leistungsversprechen, sondern ein bewusst knappes Betriebsmodell. Wenn eine Entscheidung mehr Kontext braucht, wird sie nicht künstlich verkürzt. Sie wird als größere Entscheidung markiert und aus dem Wochenformat in einen eigenen Workshop oder Review überführt.

Selbstprüfung pro Sprint

Am Ende des Sprints beantwortet das Team vier Fragen:

1. Welche Entscheidungen waren zu unscharf formuliert?
2. Wo entstand Drift zwischen Record, Design und Umsetzung?
3. Welche Belege oder Verweise fehlen noch?
4. Wer hätte früher eingebunden werden müssen?

Die Antworten gehören nicht in eine allgemeine Retrospektive ohne Verantwortlichkeit. Jede erkannte Lücke bekommt eine konkrete Folgeaktion, einen Owner und einen Link zum betroffenen Record. So wird Dokumentation zu einer wiederholbaren Arbeitsweise, nicht zu einer Aufräumaktion kurz vor dem Projektabschluss.

---

Wenn du Designentscheidungen direkt am Asset mit Kommentaren, Markern, Versionen und Freigaben nachvollziehbar halten willst, kannst du dafür draftgo nutzen. Richte einen zentralen Review-Verlauf ein, lade Kund:innen per Link ein und verknüpfe die freigegebene Version mit deiner ADR.