Das Decision Log: Warum Top-Designer die Entscheidungen dokumentieren, nach denen niemand gefragt hat

Ein Senior Designer und ein Mid-Level-Designer können denselben Screen ausliefern. Der Senior weiß noch, warum. Der Mid-Level weiß nur noch, was.

Diese Lücke ist ein einziges Artefakt. Ein kurzes, datiertes, strukturiertes Protokoll jeder Designentscheidung samt Begründung. Das Decision Log. Die meisten Designer führen keines, weil die Uni nie danach gefragt hat und das letzte Team auch keines hatte. Diese Praxis verbreitet sich nicht von allein.

Die Teams, die 2026 den Maßstab setzen, nutzen es längst. Linear hat Design-RFCs. Vercel liefert Produktspezifikationen neben den Engineering-Specs. Anthropic veröffentlicht Research Notes. Stripe betreibt Design-Review-Dokumente. Brian Lovin pflegt seines auf einer öffentlichen persönlichen Website. Jordan Singer veröffentlicht kleine Produkte mit öffentlichen Design-Tagebüchern. In jedem Raum dasselbe Artefakt.

Das hier ist das Playbook. Was ein Log ist, warum Hiring Manager es zuerst lesen, woher die Praxis kommt, die Vorlage mit sechs Feldern, wo man es ablegt, echte Beispiele, der typische Fehler und wie du morgen anfängst.

Das Artefakt, das die meisten Designer nicht führen

Das am meisten unterschätzte Artefakt im Design ist das Decision Log. Nicht die Case Study, nicht die Figma-Datei, nicht das Deck. Ein kurzes, strukturiertes, datiertes Protokoll jeder Designentscheidung samt Begründung, geschrieben, bevor die Arbeit live geht.

Die Kosten des Weglassens zeigen sich leise. Sechs Monate später kann die Designerin nicht mehr sagen, warum die Formularfelder gestapelt statt inline stehen, wer das entschieden hat oder was gestrichen wurde. Drei Jahre später hat das Portfolio sechs Projekte und null verteidigbare Entscheidungen. Die Designerin bleibt ein Leben lang Mid-Level.

Was ein Decision Log wirklich ist

Ein strukturiertes Protokoll von Designentscheidungen, geprüften Alternativen, geltenden Constraints, der Begründung der Entscheidung, dem Owner und dem Ergebnis. Sechs Felder, datiert, konkret, mit Artefakten verlinkt. Das ist die gesamte Definition.

Es ist keine Case Study. Case Studies stellen jede Entscheidung als unvermeidlich dar. Ein Log zeigt die Entscheidung so, wie sie getroffen wurde: mit den Alternativen auf dem Tisch, den Constraints, die sie ausgeschlossen haben, und dem Ergebnis, für das der Designer jetzt geradesteht.

Es ist auch kein Meeting-Protokoll. Ein Log hält fest, was entschieden wurde und warum, selbst wenn die Entscheidung in einer dreißigsekündigen Slack-Nachricht fiel. Die Roadmap blickt nach vorn. Das Log blickt zurück auf jede bereits getroffene Entscheidung, datiert, signiert, bereit zur Verteidigung.

Warum Hiring Manager es höher schätzen als Mockups

Polierte Mockups zeigen Output. Decision Logs zeigen Urteilsvermögen. Senior Hiring Manager lesen 2026 zuerst das Log, weil Output durch KI billig ist und Urteilsvermögen nicht.

Ein Modell liefert in acht Minuten eine polierte Landingpage. Der Hiring Manager, der diese Seite ansieht, erfährt nichts über die Designerin, die sie ausgeliefert hat. Dasselbe Modell, derselbe Prompt, dieselben Dribbble-Referenzen. Das Log ist das einzige Artefakt, das die KI-Kommoditisierung von Politur überlebt, denn das Log ist nicht der Output, sondern die Spur der Entscheidungen, die zu genau diesem Output geführt haben statt zu den achtzehn anderen.

Das Lesen dauert zwei Minuten. Der Hiring Manager öffnet das Log, überfliegt fünf Einträge und sieht, wie die Designerin denkt. Konkrete Alternativen, benannte Constraints, handfeste Begründungen, übernommene Ergebnisse, die Bereitschaft zu schreiben: „Das würde ich heute anders machen.“ Das ist das gesamte Interview, komprimiert in ein Dokument.

Woher die Praxis kommt

Das Decision Log ist älter als Software. Christopher Alexander schrieb Pattern Languages, die sich im Gebäudemaßstab wie Decision Logs lesen: jedes Pattern datiert, benannt, begründet, mit notierten Alternativen. Architekten führen seit Jahrhunderten Entwurfsbücher.

Die Softwarewelt hat es über die RFC-Kultur geerbt. Die IETF veröffentlicht seit 1969 Request-for-Comments-Dokumente. ADRs (Architecture Decision Records) bei Spotify, Pivotal und Thoughtworks sind dasselbe Artefakt im kleineren Maßstab. Das jüngste Erbe stammt aus Forschungslaboren. Anthropic veröffentlicht Research Notes, die sich wie Decision Logs auf Modellebene lesen.

Drei Linien, ein Artefakt. Designer sind die Spätzünder, und die Latte steigt so schnell, dass „spät“ langsam nach „Junior“ klingt.

Die Vorlage mit sechs Feldern, kopier sie

Sechs Felder. Decision, Alternatives, Constraints, Reasoning, Owner, Outcome. Die Vorlage ist absichtlich kurz. Die Disziplin liegt im Schreiben, nicht im Gestalten. Kopier diesen Block. Nutze ihn morgen.

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

Ein Eintrag pro echter Entscheidung. Fünf bis zehn Einträge pro Projekt. Spar dir das Deckblatt. Der Block oben ist die Arbeit.

Wie du jedes Feld ohne Ausflüchte schreibst

Jedes Feld hat eine Regel. Ignorierst du sie, wird das Log zum Theater.

Decision. Ein Satz, Präsens, konkret. „Email und Passwort vertikal stapeln.“ Nicht „wir hatten das Gefühl, vertikal könnte funktionieren.“ Wurde die Entscheidung noch nicht getroffen, schreib den Eintrag noch nicht.

Alternatives. Nummerierte Liste, zwei bis vier echte Optionen, die auf dem Tisch lagen. Keine Strohmänner. Wurde nur eine geprüft, schreib das und erkläre, warum die Suche endete.

Constraints. Aufzählung, benannt, mit Quelle. Engineering-Kapazität, Markenregeln, Support-Tickets, Accessibility-Untergrenze, Performance Budget. Ohne sie liest sich das Log wie Geschmackswäsche.

Reasoning. Drei bis fünf Sätze, kein „wir fanden“. Benutze „weil“. Benutze „im Vergleich zu“. Nenne den Constraint oder die Daten, die entschieden haben. Verlinke das Artefakt.

Owner. Nenne die Designerin. Nenne den Reviewer. Anonyme Logs überleben keinen Kontakt mit einem Senior Reviewer.

Outcome. Zwei Wochen bis zwei Monate nach dem Launch ausgefüllt, datiert. Was die Metrik getan hat, was neu bewertet wurde, was sich nächstes Mal ändern würde. Die Bereitschaft zu schreiben „Ich lag bei der Magic-Link-Sperre falsch“ ist das stärkste Vertrauenssignal im Log.

Wo du das Log ablegst

Das Log lebt dort, wo das Team es tatsächlich öffnet. Das Speichermedium zählt weniger als der Rhythmus.

Notion. Das einfachste Setup fürs ganze Team. Eine Datenbank, ein Eintrag pro Entscheidung, sechs Felder als Spalten. Die meisten Produktteams zahlen ohnehin dafür, und ein Designer richtet es in einer Stunde ein.

Linear Docs. Die richtige Wahl, wenn Engineering und Design schon dort leben. Entscheidungen stehen neben den Issues, die sie ausgelöst haben, und der Übergang in Engineering-RFCs ist ein Klick.

Eine Markdown-Datei im Repo. Die richtige Wahl für Design Engineers und Verantwortliche für Design Systems. Eine decisions.md im Repo-Root oder unter /docs/decisions/ wirkt seriös, weil sie zusammen mit dem Code versioniert wird. Engineers respektieren dieses Format auf den ersten Blick.

Ein kleiner privater Blog oder eine persönliche Website. Die richtige Wahl für einzelne Designer, die einen öffentlichen Trail aufbauen. Brian Lovin macht es so. Statische Seite, datierte Einträge, öffentliche Links. Das Stück dient zugleich als Portfolio-Fläche und Recruiting-Präsenz.

Wähl eins. Betreib es ein Quartal lang. Der erste Fehler ist, ein Tool zu wählen und nie wieder zu öffnen.

Linears Design-RFCs und Vercels Produktspezifikationen

Linear behandelt Design-RFCs als erstklassige Artefakte in ihren Docs. Jede relevante Designentscheidung kommt mit einem RFC, geschrieben vor der Arbeit, von Design- und Engineering-Leads geprüft, mit dem Projekt archiviert. Der RFC ist Teil der Arbeit, kein Nachtrag.

Vercel liefert Produktspezifikationen neben den Engineering-Specs im selben Repo. Die Design- und die Engineering-Entscheidung stehen im selben Dokument, datiert, mit Owner, geprüft. Das Team behandelt die Spec als Vertrag. Wenn v0 eine neue Oberfläche ausliefert, gehört die Spec zum Launch-Artefakt.

Beide Teams verstehen die schriftliche Begründung als Teil des Handwerks. Kein Mittwochnachmittags-Nachtrag. Nicht optional. Das Artefakt ist die Arbeit, genauso wie die Figma-Datei die Arbeit ist, und ein Designer, der ohne eines auftaucht, wirkt unfertig.

Anthropics Research Notes und Stripes Design-Review-Dokumente

Anthropic veröffentlicht Research Notes, die sich wie Decision Logs auf Modellebene lesen. Was versucht wurde, was funktionierte, was nicht, was der nächste Schritt ist. Kurz, datiert, mit Owner, verlinkt. Lies drei, und die Praxis wird offensichtlich. Die Notes sind das Protokoll, nicht der Spin.

Stripe betreibt Design-Review-Dokumente, die Produktzyklen überdauern. Stripe Press ist die öffentliche Fläche, die interne Praxis ist älter. Reviews werden geschrieben, archiviert und wieder aufgegriffen, wenn der nächste Zyklus vor einer ähnlichen Entscheidung steht. Institutionelles Gedächtnis, das über Jahre wächst, statt zu gehen, wenn eine Senior Designerin das Unternehmen verlässt.

Wenn du Hilfe brauchst, das in die Craft deines Teams einzubauen, hire Brainy. BrandBrainy liefert die Craft-Ebene, die KI nicht fälschen kann. ClaudeBrainy liefert die Skill Packs und Prompt-Bibliotheken, die das Log von einer Disziplin zum Standard machen.

Brian Lovin und Jordan Singer führen ihre öffentlich

Brian Lovin betreibt eine langjährige persönliche Website, die sich wie ein öffentliches Decision Log seiner eigenen Arbeit liest. Kurze Seiten, direktes Schreiben, Designentscheidungen in drei oder vier Sätzen erklärt, datiert, mit dem Live-Produkt verlinkt. Jahre an Einträgen. Die Seite dient zugleich als Portfolio und Recruiting-Präsenz, genau die Doppelnutzung, auf die das Anti-Portfolio-Playbook setzt.

Jordan Singer veröffentlicht kleine Produkte mit öffentlichen Design-Tagebüchern. Jedes Projekt hat ein schriftliches Protokoll der Entscheidungen dahinter, öffentlich gepostet, mit der Bereitschaft, laut zu sagen: „Das hat nicht funktioniert.“ Das Tagebuch ist Marketing, Protokoll und Hiring-Artefakt in einem.

Beides sind Vorlagen, die jeder arbeitende Designer diese Woche kopieren kann. Statische Seite, Einträge mit sechs Feldern, datiert, öffentlich, verlinkt. Fünfzehn Minuten pro Eintrag. Drei im Monat. Nach einem Jahr wirkt das öffentliche Log senior, wie es keine Behance-Case-Study je schafft.

Der Warnhinweis: nachträgliche Rationalisierung

Ein Decision Log, das geschrieben wird, nachdem die Arbeit live ist und das Ergebnis feststeht, ist kein Log, sondern ein Verkaufsgespräch. Senior Hiring Manager erkennen den Unterschied in zwei Minuten.

Verräterisch ist das Alternatives-Feld. Ein lebendiges Log listet Alternativen, die wirklich auf dem Tisch lagen, oft mit einer, die stark klingt. Ein nachträgliches Log listet drei Optionen, die der Autor nie ernsthaft erwogen hat, damit die gewählte Option offensichtlich aussieht. Der Hiring Manager hat dieselbe Übung hundertmal gemacht. Er weiß, wie Spin aussieht.

Verräterisch ist auch das Outcome-Feld. Lebendige Logs enthalten Ergebnisse, die nicht zur Prognose passten. „Ich habe einen Conversion-Anstieg erwartet, der Test war flach, hier ist, was schiefging.“ Theater-Logs enthalten nur Erfolge, vorab aufgerundet, damit sie besser aussehen, als sie waren.

Die Lösung ist unbequem. Schreib den Eintrag, bevor die Arbeit live geht. Datier ihn. Gib ihn einem Reviewer, der widerspricht. Fülle das Outcome zwei Wochen später aus, auch wenn die Nachricht schlecht ist. Besonders dann. Der ehrliche Eintrag zahlt sich aus.

Wie du das Log in Interviews und Reviews nutzt

Ein Log verdient seinen Platz zweimal. Einmal, wenn die Arbeit live geht, und noch einmal, wenn die Designerin einen Hiring Manager oder Senior Reviewer durch die Entscheidung führt.

Im Interview ersetzt das Log den Case-Study-Walkthrough. Öffne das Dokument. Such drei Einträge aus. Lies jeweils die Decision vor, nenne die stärkste Alternative, nenne den bindenden Constraint, erkläre die Begründung in zwei Sätzen, teile das Ergebnis samt dem, was sich nächstes Mal ändern würde. Fünf Minuten pro Eintrag, fünfzehn insgesamt. Der Hiring Manager lernt mehr über dein Urteilsvermögen, als ein fünfundvierzigminütiges Case-Study-Deck zeigen würde.

Im Senior Review ist das Log das Gespräch. Der Reviewer liest den Eintrag, widerspricht der Begründung, fragt, warum die stärkste Alternative gestrichen wurde. Die Diskussion schärft die nächste Entscheidung, bevor sie getroffen wird. Genau das ist gutes Design Review. Nicht Feedback zu gerenderten Pixeln, sondern Debatte über die Entscheidung dahinter.

Wer das Log verteidigen kann, verteidigt die Arbeit. Wer kein Log hat, verteidigt nichts.

Die neue Latte: Senior-Arbeit ohne Log liest sich wie Junior

Das Decision Log ist kein Senior-Extra mehr. Es ist das billigste Signal für Senior-Urteilsvermögen, das ein Designer liefern kann, und die Kosten des Weglassens steigen.

Ein Senior-Portfolio mit öffentlichem Log liest sich senior. Eines ohne liest sich wie Arbeit, die senior gewesen sein könnte, schwer zu sagen. Hiring Manager lesen beides. Das erste bekommt den Rückruf. Ein Junior mit einem Log zu drei kleinen Projekten wirkt seinem Level voraus. Ein Junior mit zwölf perfekten Dribbble-Shots und ohne Log wirkt wie derselbe Junior wie vor einem Jahr.

Taste ist der letzte Burggraben im Jahr 2026, weil Produktion zur Massenware wurde, und das Log ist das öffentliche Artefakt, das beweist, dass Taste in der Arbeit steckt. Wenn du als Design-Engineering-Hybrid arbeitest, dient das Log zugleich als Engineering-RFC auf der Designebene. Wenn du die neue Design-Karriereleiter hochkletterst, ist das Log das Artefakt, auf dem die Leiter ruht.

FAQ

Was ist ein Design Decision Log?

Ein kurzes strukturiertes Protokoll von Designentscheidungen samt Begründung. Sechs Felder pro Eintrag: Decision, Alternatives, Constraints, Reasoning, Owner, Outcome. Datiert, konkret, mit Artefakten verlinkt.

Wie unterscheidet es sich von einer Case Study?

Eine Case Study stellt jede Entscheidung als unvermeidlich dar. Ein Log zeigt die Entscheidungen so, wie sie tatsächlich getroffen wurden: mit den Alternativen auf dem Tisch, den Constraints, die die Entscheidung binden, und dem übernommenen Ergebnis. Case Studies verkaufen. Logs dokumentieren.

Wo sollte ich es ablegen?

Dort, wo dein Team es tatsächlich öffnet. Notion für Produktteams, Linear Docs für Teams, die schon dort sind, eine Markdown-Datei im Repo für Design Engineers, eine kleine private Website für einen individuellen öffentlichen Trail.

Wie lang sollte jeder Eintrag sein?

Kurz. Die ganze Vorlage passt auf einen Bildschirm. Fünfzehn Minuten pro Eintrag.

Was, wenn meine Firma das nicht übernimmt?

Führ es persönlich. Das individuelle Log einer Designerin wächst über Jobs hinweg. Brian Lovin und Jordan Singer führen ihre öffentlich. Die Praxis gehört dir, nicht deinem Arbeitgeber, und das Artefakt zieht mit dir um.

Starte das Log diese Woche

Drei Schritte. Richte die Ablage ein. Wähl Notion, Linear, das Repo oder eine kleine Website. Setz es in dreißig Minuten auf. Nimm das, was du morgen öffnen wirst.

Schreib drei Einträge zu bereits getroffenen Entscheidungen. Echte Entscheidungen aus diesem Quartal. Je sechs Felder. Ehrliche Alternativen, echte Constraints, keine Ausflüchte, Ergebnisse datiert und ungeschönt. Die ersten drei sind die schwersten, der Rest geht schneller.

Zeig das Log einem Senior Reviewer. Bitte ihn, der Begründung zu widersprechen. Nimm den Widerspruch als Signal. Aktualisiere die Einträge. Beim ersten Review beginnt das Log, sich auszuzahlen.

Wenn du Hilfe brauchst, die Decision-Log-Praxis in die Craft deines Teams einzubauen, hire Brainy. BrandBrainy liefert die Marken- und Craft-Ebene, die KI nicht fälschen kann. ClaudeBrainy liefert die Skill Packs und Prompt-Bibliotheken, die das Log von einer Disziplin zum Standard machen. Die Teams, die es schon nutzen, ziehen davon. Die Latte steigt, und die Designerin, die diese Woche anfängt, ist diejenige, die die genannten Teams in einem Quartal lesen werden.