Die Entscheidungen, die wir treffen. Die Gründe, die wir verlieren.

Wie ich ein Register für Designentscheidungen gebaut habe, das AI lesen kann, ohne sie entscheiden zu lassen.

Das Drei-Tage-Problem

Wir einigen uns in einem Meeting. Die Begründung ist im Raum klar. Ein Constraint, den niemand besonders mag. Eine Alternative, die wir erwogen und verworfen haben. Eine technische Grenze, die verändert, was wir realistisch liefern können.

Alle sind einverstanden. Die Arbeit beginnt.

Drei Tage später öffnet jemand ein Ticket und fragt, warum sich ein bestimmtes Element so verhält.

Die Entscheidung ist da. Die Begründung nicht.

Jemand erinnert sich an einen Teil der Diskussion. Jemand anderes an eine andere Version. Am Ende rekonstruieren wir das Argument oder treffen die Entscheidung neu.

Das ist mir besonders oft bei kleinen Designentscheidungen begegnet: die Position eines Elements, eine Interaktion, ein Verhalten, das in der Diskussion offensichtlich schien.

Wir verlieren nicht unbedingt Entscheidungen. Wir verlieren die Gründe dahinter.

Und wenn die Begründung verschwindet, wird es schwer, eine Entscheidung intelligent zu hinterfragen. Man kann ihr folgen, sie ignorieren oder die ganze Diskussion neu eröffnen.

Ich wollte eine andere Option.

Anfang 2023: Ich brauchte einen Weg, Schritt zu halten

Anfang 2023 arbeitete ich an Metaverse-Projekten und lernte parallel zu meinen UX-Aufgaben Unity und Blender. Wir mussten genug von der Experience entwickeln, um ihr Potenzial zu zeigen und das Budget für ein größeres Team zu sichern, also lief vieles parallel. Ich arbeitete mehr als sechzig Stunden pro Woche, samstags inklusive.

Die Projekte umfassten mehrere Disziplinen: 3D-Umgebungen, native Apps, Smart Glasses, WebXR, Research und Business-Fragen. Eine Änderung in einem Bereich konnte Entscheidungen in mehreren anderen beeinflussen.

Meine übliche Arbeitsorganisation kam nicht mehr mit. Ich hatte immer eher sequenziell gearbeitet: auf ein Thema fokussieren, Informationen ordnen, abschließen, Ordner schließen, zum nächsten. Das funktionierte, solange Themen unabhängig waren. Es wurde zunehmend ineffizient, als alles verbunden war.

Das Problem war nicht nur zu viel Information. Sondern dass Information, die ich für abgeschlossen hielt, plötzlich wieder relevant werden konnte. Ich musste schneller werden, verbrachte aber zu viel Zeit damit, Kontext zu rekonstruieren.

Also investierte ich Zeit, die ich kaum hatte, um meine Arbeitsorganisation zu ändern.

Ich begann mit Notion und baute etwas, das eher einer Projektdatenbank glich als einer klassischen Dokumentensammlung. Entscheidungen, Constraints und Themen konnten eigene Zustände haben, statt in geschlossenen Ordnern zu verschwinden. Später wechselte ich zu Obsidian, wegen seiner Flexibilität, Erweiterbarkeit und seines Automatisierungspotenzials.

Mit der Zeit wurde das System zu dem, was ich heute mein Register für Designentscheidungen nenne. Es wurde nicht gebaut, um mehr Dokumentation zu produzieren. Es wurde gebaut, um nicht mehr die Begründung zu verlieren, die Dokumentation erst nützlich macht.

Schließlich stellten wir einen 3D-Designer ein, was einen Teil der Last abnahm. Aber ich entwickelte das System weiter, denn das eigentliche Problem war nicht verschwunden.

Von isolierten Entscheidungen zu verbundenem Denken

Ein User Flow beschreibt einen Weg, den jemand gehen soll. Das ist nützlich, wenn die Abfolge von Interaktionen das Problem ist. Ich zeichne weiterhin User Flows, wenn sie gebraucht werden.

Aber ein Flow beschreibt nicht alles, was diesen Weg umgibt. Er erklärt nicht unbedingt den technischen Constraint, der eine Interaktion geformt hat, die Business-Anforderung, die eine Alternative ausgeschlossen hat, oder das unerwartete Verhalten, mit dem Nutzer eine Grenze umgehen.

Mich interessiert das System, in dem der Flow operiert: die Entscheidungen, Constraints, Annahmen und Beziehungen, die die Experience möglich machen.

Ich habe auch eine besondere Arbeitsweise. Mein Hintergrund verbindet Design und Unternehmertum. Ich bewege mich eher schnell: testen, beobachten, ändern, neu versuchen. Das kann effektiv sein, ist in hierarchischeren Organisationen aber manchmal schwer zu vermitteln. Ein gutes Ergebnis erklärt nicht, wie man dorthin kam.

Wenn die Begründung nicht sichtbar ist, kann eine Entscheidung wie Intuition wirken. Selbst wiederholte Erfolge können als Glück statt als Ergebnis eines bewussten Prozesses gelesen werden. Dieses Problem kenne ich.

Das Register wurde zu einem Weg, die Begründung offenzulegen, ohne alle zu zwingen, so zu denken oder zu arbeiten wie ich. Das wusste ich. Das sind die Constraints A, B und D. Darum habe ich C geändert. Das sind die erwogenen Alternativen, und warum ich sie verworfen habe.

Das beweist nicht, dass die Entscheidung richtig war. Es macht sie verständlich, und damit anfechtbar. Diese Unterscheidung ist mir wichtig: Ein Design-Register soll nicht jede vergangene Entscheidung verteidigen; es soll sie leichter überprüfbar machen, wenn sich der Kontext ändert.

Es schafft auch Kontinuität. Ich habe den Ansatz mit Designern geteilt, mit denen ich gearbeitet habe, und nutze ihn mit Kollaborateuren in meinem Studio. Wenn ein anderer Designer zu einem Projekt stößt, soll er mehr erben als eine Sammlung von Screens, Komponenten und unerklärten Konventionen. Er soll die Begründung hinter diesen Entscheidungen verstehen und sich frei fühlen, sie zu hinterfragen.

Dem Register eine AI geben

Mit der Zeit wurde das Register strukturierter, und ich begann, AI-Agents daran anzubinden.

Heute umfasst es einige hundert Notizen in meiner Arbeitsumgebung: das Register selbst, dazu Research, Monitoring-Notizen und Projektakten, die es speisen. Die Informationen liegen in getrennten privaten Vaults, und ich habe Teile der Organisation und Synchronisierung automatisiert, die früher Handarbeit waren.

Ich nutze ein hybrides Setup: lokal gehostete Open-Weight-Modelle für manche Aufgaben, externe Modelle über APIs für andere. GPT, Claude und Qwen gehören zu den Modellfamilien, mit denen ich je nach Aufgabe und Deployment arbeite.

Die meisten Aufrufe laufen noch über eine API, ein Kompromiss, den ich akzeptiere, und ein Risiko, das ich managen muss.

Die Agents haben nicht alle dieselben Berechtigungen. Manche sind auf bestimmte Ressourcen oder lokale Umgebungen beschränkt; externe Dienste stehen nur dort zur Verfügung, wo sie nötig und autorisiert sind.

Das ist wichtig, weil UX-Entscheidungen sensible Informationen über Produkte, Strategie, Nutzer und interne Diskussionen enthalten können.

Dateien lokal zu halten macht ein System nicht automatisch sicher, besonders wenn externe Modelle beteiligt sind. Zugriff auf Information und die Fähigkeit, sie weiterzugeben, müssen getrennt kontrolliert werden.

Aber der interessante Teil ist nicht die Infrastruktur. Sondern was passiert, wenn die Agents anfangen, Informationen zu verbinden.

Wenn ich an einem Thema zu arbeiten beginne, startet der Agent mit dem verfügbaren Kontext. Nach einigen Austauschen kann er Beziehungen zu früheren Diskussionen, Constraints und Entscheidungen erkennen. Ich kann ihn auch auf bestimmte Informationen lenken oder bitten, bestimmte Abhängigkeiten zu prüfen.

Ich sehe es als ein Netz von Verbindungen. Nicht unbedingt ein technischer Knowledge Graph, sondern eine Arbeitsweise, in der Themen nicht isoliert sind, nur weil sie zu verschiedenen Ordnern oder Projektphasen gehören.

Ein Beispiel: Als ich für einen Kunden an der Hochformat-Ausrichtung eines Tablet-Produkts arbeitete, holte ein Agent eine Information aus einem Meeting fünf Wochen zuvor zurück. Ein anderer Designer hatte in einem kurzen Austausch eine Änderung erwähnt, vielleicht zwei Minuten lang. Ich zeichne Meetings systematisch auf und mache Notizen, die Information war also erfasst. Aber sie war nicht in die Dokumentation gelangt, die ich für diese Aufgabe nutzte.

Ich hatte sie vergessen. Der Agent brachte sie zurück in den Kontext.

Dasselbe Prinzip hilft bei Entscheidungen, die noch nicht getroffen sind. Manchmal kann eine anstehende Diskussion einen Constraint beeinflussen, auf den ich gerade reagieren will. Das System kann diese Abhängigkeit sichtbar machen und mir einen Grund geben, eine Abwägung zu verschieben, statt unnötige Nacharbeit zu erzeugen.

Diese Art von Unterstützung finde ich wertvoll. Keine AI, die mir sagt, was ich gestalten soll. Eine AI, die mir hilft, mich daran zu erinnern, was ich vor dem Gestalten bedenken muss.

Ein Register ist nur nützlich, wenn man es hinterfragen kann

Das System hat Fehler gemacht.

Agents haben falsche Verbindungen, veraltete Informationen und Schlüsse geliefert, die einer Prüfung nicht standhielten. Das hat mich dazu gebracht, den Workflow zu ändern.

Statt mich auf eine einzige Interpretation zu verlassen, begann ich, spezialisierte Agents mit unterschiedlichen Review-Rollen einzusetzen: Manche prüfen die Qualität des Research, andere hinterfragen Faktenaussagen, rechtliche Verweise oder redaktionelle Kohärenz.

Ihre Ergebnisse gehen an einen redaktionellen Agent, der die Korrekturen in eine neue Version einarbeitet. Frühere Versionen, Review-Berichte und Entscheidungsprotokolle bleiben erhalten, damit Änderungen nachvollziehbar sind.

Dieser Artikel ist durch diesen Prozess gegangen.

In einem Review hat ein Research-Agent einen Satz angefochten, in dem ich behauptete, das Öffnen genau bestimmter Dateien erlaube mir zu erkennen, welche Datei jeden Satz erzeugt hat.

Das war falsch.

Zu wissen, welche Dateien einem Modell zur Verfügung standen, belegt nicht den Ursprung jeder Aussage, die es erzeugt. Ein reproduzierbarer Kontext ist keine überprüfbare Zuordnung. Letztere erfordert eine eigene Disziplin: Aussagen mit Quellen verknüpfen und prüfen, ob diese Quellen sie tatsächlich stützen.

Diese Korrektur hat das Argument stärker gemacht.

Ein anderer Agent hat die Anzahl der Notizen im Register angezweifelt. Er zählte 574; ich prüfte das Verzeichnis selbst, fand 4.090 Markdown-Dateien und wies die Korrektur zurück.

Beim zweiten Hinsehen hatte der Agent in der Sache recht. Die meisten dieser Dateien waren Dependency-READMEs tief in node_modules; das Register selbst umfasst einige hundert echte Notizen.

Ich hatte die Zahl geprüft, statt zu prüfen, was gezählt wurde.

Eine Korrektur angenommen, eine fälschlich abgelehnt, und der Fehler später von genau dem System gefunden, das die Prüfung erst möglich machte.

Die Agents stimmen nicht darüber ab, was wahr ist. Sie legen Fragen offen, die geprüft werden müssen. Selbst wenn mehrere Agents übereinstimmen, können sie dasselbe Missverständnis teilen.

Deshalb nimmt mir der Review-Prozess nicht die Verantwortung für das, was veröffentlicht wird.

Für jedes wesentliche Deliverable halte ich Zustand, Quellen, Reviews und Designentscheidungen fest, bei Bedarf mit früheren Versionen.

Konkret sieht ein Ordner so aus:

status.md       der Zustand, die Quellen und Vorbehalte zu diesen Quellen
reviews/        getrennte Fakten-, Research- und redaktionelle Reviews, plus Integration
decisions.md    was entschieden wurde, welche Optionen verworfen wurden, und warum
article-v1.txt  die vorherige Version, damit der Unterschied nachvollziehbar bleibt

Ziel ist keine perfekte Nachverfolgbarkeit. Sondern die Begründung und ihre Grenzen sichtbar zu machen.

Es gibt auch einen praktischen Preis.

Nicht jede Entscheidung verdient dieselbe Aufmerksamkeit. Bei einem Quick Win setze ich die Änderung vielleicht zuerst um und dokumentiere die Begründung danach.

Bei größeren Problemen, einem Epic, einer Interaktion über mehrere Teile eines Produkts, entsteht die Begründung parallel zur Arbeit: Constraints, Alternativen und offene Fragen werden dokumentiert, sobald sie auftauchen.

Diese beiden Arten von Aufzeichnungen sind nicht gleichwertig.

Eine nachträglich dokumentierte Entscheidung ist eine Rekonstruktion. Eine während der Erkundung dokumentierte Entscheidung bewahrt mehr von der Begründung, wie sie entstanden ist.

Ich möchte, dass das Register diesen Unterschied sichtbar macht, statt jedem Eintrag einen künstlichen Anschein von Gewissheit zu geben.

Mehr Dokumentation, weniger mentale Last

Ich habe dieses System gebaut, weil ich schneller arbeiten musste.

Heute ist der wichtigste Nutzen nicht nur die gesparte Zeit.

Es ist die Aufmerksamkeit, die ich zurückbekomme.

In Meetings muss ich weniger Energie darauf verwenden, jedes Detail zu erfassen, zu ordnen und mir zu merken. Ich kann genauer zuhören. Noch eine Frage stellen. Einer unerwarteten Antwort folgen, statt mich zu sorgen, die vorherige zu verlieren.

Die Gespräche werden natürlicher.

Ich zeichne Meetings weiterhin auf und mache Notizen. Aber ich muss mich nicht mehr allein auf mein Gedächtnis verlassen, um jede Verbindung zwischen Themen zu bewahren.

Das System übernimmt einen Teil der repetitiven Arbeit des Ordnens, Wiederfindens und Abgleichens von Informationen.

Das macht mich nicht automatisch zu einem besseren Designer. Es schafft mehr Raum für die Teile des Designs, die menschliche Aufmerksamkeit brauchen.

Die nächste Herausforderung ist, das für andere funktionieren zu lassen.

Ich nutze den Ansatz derzeit persönlich und mit Kollaborateuren, möchte ihn aber über längere Zeiträume mit anderen Designern erproben: verstehen, wo er hilft, wo er Reibung erzeugt und was ihn leichter adoptierbar machen würde, ohne eine komplette technische Umgebung aufbauen zu müssen.

Langfristig möchte ich daraus ein einsatzbereites Design Registry machen. Etwas, das ein Designer oder ein Team installieren und an die eigene Arbeitsweise anpassen kann.

Das ist noch eine Richtung, kein fertiges Produkt.

Für den Moment möchte ich klar sagen, was dieser Artikel ist.

Die Daten in diesem Text sind meine, keine Archiveinträge: 2023 ist Erinnerung, keine Datei. Was Sie lesen, ist das, was ich im Oktober 2026 vertreten kann, keine Aufzeichnung dessen, was ich damals im Raum dachte.

Das Register garantiert nicht, dass jede Entscheidung richtig war. Es ersetzt weder Diskussion noch Widerspruch noch Urteilsvermögen.

Es gibt diesen Diskussionen einen Ausgangspunkt.

Wenn jemand fragt, warum wir etwas auf eine bestimmte Weise gestaltet haben, können wir die Begründung prüfen, die Constraints hinterfragen und entscheiden, ob die Wahl noch Sinn ergibt.

Und wenn ich einem anderen Designer, einer Kollegin oder einem Nutzer gegenübersitze, muss ich das Gespräch nicht damit verbringen, mich an alles zu erinnern.

Das Register bewahrt den Kontext. Damit ich meine Aufmerksamkeit den Menschen vor mir schenken kann.