KI-Workflow für Konzeption und Design

Ein typischer Ablauf in der Konzeption sieht ungefähr so aus:

Miro unterstützt die gemeinsame Arbeit. Interviews liefern Einblicke in tatsächliche Bedürfnisse. Figma macht Strukturen und Gestaltung konkret. Jeder dieser Schritte hat seinen Zweck.

Bei den Übergängen entsteht allerdings Aufwand. Aus einer Beobachtung wird eine Zusammenfassung, daraus eine User Story und später ein Screen. Die Verbindung zwischen diesen Ergebnissen muss jemand mitführen.

Ein konstruiertes Beispiel: In einem Interview für eine Kursplattform zeigt sich, dass Menschen vor der Anmeldung vor allem ihren Zeitaufwand einschätzen wollen. Daraus entstehen Anforderungen an die Kursübersicht und die Detailseite. Wenn diese Information später anders gewichtet wird, reicht es nicht, einen Text im Interviewdokument zu ändern.

Diese Zusammenhänge lassen sich auch ohne KI dokumentieren. Für die Arbeit mit KI werden sie besonders wichtig: Was nur im Kopf der Beteiligten existiert, steht dem Modell bei der nächsten Aufgabe nicht zuverlässig zur Verfügung.

AI First bedeutet für mich deshalb zunächst eine Anforderung an die Arbeitsweise: Jedes beteiligte Tool muss Daten annehmen und herausgeben können, je nach Aufgabe über eine API, MCP oder ein offenes Dateiformat.

MCP, das Model Context Protocol, verbindet KI-Anwendungen mit Daten und Werkzeugfunktionen. Welche Inhalte gelesen oder verändert werden können, bestimmt die jeweilige Integration. Quelle: MCP-Architektur

Verbindlich ist damit der gepflegte Projektkontext, die Source of Truth: Quellen, Anforderungen, Entscheidungen und ihr aktueller Status. Der Chat ist ein Arbeitsraum. Verbindliche Ergebnisse gehören in eine dauerhafte Ablage.

Für konzeptionelle Inhalte bieten sich Markdown-Dateien an. Sie sind lesbar, versionierbar und lassen sich mit unterschiedlichen Werkzeugen bearbeiten. Beispielsweise:

kontext/
  projekt.md
  erkenntnisse.md
  personas.md
  user-stories.md
  flows/
  wireframes/
  entscheidungen.md

Eine Wireframe-Datei beschreibt dann Seitenziel, Inhaltshierarchie, Komponenten, Interaktionen und Sonderzustände. Dazu kommen Quellenverweise und offene Fragen. Die visuelle Qualität muss weiterhin am Entwurf geprüft werden.

Markdown muss dabei nicht alles aufnehmen. Bilder bleiben Bilder, Komponenten bleiben Code. Für Design Tokens gibt es beispielsweise ein eigenes JSON-basiertes Austauschformat der Design Tokens Community Group. Der Kontext verbindet diese Quellen und legt fest, welcher Stand gilt. Quelle: Design Tokens Format

Der Ablauf verändert sich damit an mehreren Stellen:

Ein Skill bündelt Anweisungen, Vorlagen und gegebenenfalls Skripte für eine wiederkehrende Aufgabe. Ein Research-Skill könnte verlangen, jede Erkenntnis mit einer Interviewstelle zu verbinden. Ein Review-Skill könnte fehlende Zustände und widersprüchliche Anforderungen suchen. Skills machen die Vorgehensweise wiederverwendbar; ihre Ergebnisse brauchen weiterhin Prüfung. Quelle: Agent Skills. Wie ein solcher Skill in der Praxis aussieht, zeigt der Design-Thinking-Skill für Claude.

Ein Workflow-Graph legt Arbeitsschritte mit Abhängigkeiten, Prüfpunkten und Rückwegen fest. Erst auswerten, dann belegen, dann freigeben, dann gestalten. Der Entwurf eines solchen Ablaufs heißt Graph Engineering; umsetzen lässt er sich etwa mit LangGraph. Quelle: Workflows und Agents

Die Komponentenbibliothek wähle ich vor der detaillierten Gestaltung. Sie muss zum technischen Aufbau passen. Eine passende Figma-Bibliothek und ein MCP-Zugang erleichtern die Verbindung: daisyUI etwa bietet neben dem Code, jeweils kostenpflichtig, eine Figma-Bibliothek und mit Blueprint einen MCP-Server. Synchron halten muss man beides trotzdem selbst. Aus der Bibliothek entsteht das projektspezifische Designsystem mit Farben, Typografie, Abständen und Zuständen.

Figma kann inzwischen über den Remote-MCP-Server native Frames, Komponenten und Variablen erstellen und verändern. Dafür sind ein Full Seat und die entsprechenden Bearbeitungsrechte nötig. Bilder und eigene Schriften unterstützt diese Schnittstelle laut Dokumentation derzeit noch nicht. Quelle: Figma Write to canvas

Paper bietet ebenfalls lesenden und schreibenden MCP-Zugriff und basiert auf HTML und CSS. Das macht es zu einer weiteren Option für diesen Ablauf. Quelle: Paper MCP

Eine automatische Synchronisation entsteht dadurch noch nicht. Wird eine Entscheidung im Design geändert, muss sie wieder in den verbindlichen Kontext gelangen. Sonst produziert die nächste Generierung womöglich den alten Stand.

Mit wachsendem Projektumfang reicht es nicht mehr, die richtigen Dateien abzulegen. Man muss auch beschreiben, wie ihre Inhalte zusammenhängen. Graph Engineering lässt sich dafür auf das Projektwissen übertragen: Erkenntnisse, Anforderungen und Entwürfe werden gezielt miteinander verknüpft.

Am konstruierten Beispiel der Kursplattform sieht das so aus:

Die Elemente sind die Knoten, die Verbindungen ihre Beziehungen: belegt, begründet, wird erfüllt durch, enthält, verwendet, wird geprüft durch. So bleibt sichtbar, welche Beobachtung eine Anforderung begründet und in welchen Screens sie umgesetzt wird.

Ändert sich eine Anforderung, lässt sich entlang dieser Beziehungen gezielt nach betroffenen Flows, Screens und Prüfungen suchen. Claude kann die relevanten Dateien laden und einen Änderungsvorschlag vorbereiten. Das funktioniert nur so gut wie die gepflegten Verbindungen: Fehlende oder falsche Beziehungen muss jemand erkennen und korrigieren.

Für den Einstieg können eindeutige IDs und Querverweise in Markdown genügen. Eine Graphdatenbank ist dafür keine Voraussetzung. Bei größeren Beständen können zusätzliche Abfragen und automatisierte Prüfungen sinnvoll werden.

Der Zusammenhangsgraph beschreibt damit das Projektwissen. Der Workflow-Graph steuert die Bearbeitung.

In Claude Code lässt sich diese Arbeit auf Skills und Subagenten verteilen. Ein Skill beschreibt ein wiederverwendbares Vorgehen. Ein Subagent übernimmt eine abgegrenzte Aufgabe mit eigenem Kontext und konfigurierbaren Werkzeugrechten. Passende Skills lassen sich ihm gezielt mitgeben. Quellen: Claude-Code-Skills, Subagenten

Für einen Konzeptions- und Designworkflow könnten eigene Skills beispielsweise so aussehen:

Nach dem Einrichten ließe sich etwa /wireframe-spezifizieren gezielt aufrufen. Diese Namen sind Vorschläge für projektspezifische Skills, keine mitgelieferten Claude-Funktionen. Fertige Beispiele sind unsere Open-Source-Skills für KI-Agenten.

Passende Subagenten könnten folgende Teilaufgaben übernehmen:

Ein konkreter Ablauf: Claude lädt die mit einer User Story verknüpften Erkenntnisse und Flows und erstellt mit dem Wireframe-Skill eine Spezifikation. Der Informationsarchitektur-Reviewer prüft sie in einer separaten Teilaufgabe gegen diese Grundlagen. Claude führt die Rückmeldung zusammen; ich entscheide über die Änderungen.

Der getrennte Kontext kann die Prüfung fokussieren. Er garantiert keine unabhängige fachliche Meinung. Reviewer brauchen eindeutige Quellen, Kriterien und passende Zugriffsrechte. Deshalb würde ich sie zunächst Befunde liefern lassen. Die Freigabe bleibt bei der verantwortlichen Person.

Sollen mehrere Agenten gleichzeitig an Dateien arbeiten, brauchen sie getrennte Arbeitsverzeichnisse. Wie das geht, steht im Artikel über paralleles Arbeiten mit Git-Worktrees und Claude Code.

Für eine Agentur habe ich an der Konzeption für den Relaunch einer der ersten MOOC-Plattformen Europas gearbeitet. Sie zählt mehr als eine Million Kurseinschreibungen. Meine Aufgabe war die Informationsarchitektur und die Vorbereitung der Wireframes. Diesen Teil habe ich in einem durchgängigen KI-Workflow erstellt. Die Beispiele weiter oben sind konstruiert und stammen nicht aus dem Projekt.

Die inhaltliche Arbeit blieb bei mir: Welche Informationen sind wichtig, wie hängen sie zusammen, welche Struktur trägt die Nutzung? Die KI hat aufbereitet und ausgearbeitet.

Ein wesentlicher Teil der Arbeit war Context Engineering. Also festzulegen, welche Informationen, Regeln und Entscheidungen die KI für den jeweiligen Schritt benötigt. Anthropic beschreibt dieses gezielte Zusammenstellen und Pflegen des Arbeitskontexts als Weiterentwicklung des Prompt Engineering. Quelle: Context Engineering

Als Komponentenbibliothek habe ich daisyUI ausgewählt, weil sie zu den im Projekt verwendeten Technologien passte. Sie stellt Komponenten auf Basis von Tailwind CSS bereit. Quelle: daisyUI

Die ersten Entwürfe entstanden in Pencil, das inzwischen pen.dev heißt. Etwa eine Woche später konnte ich in Figma weiterarbeiten, nachdem dort die benötigte Schnittstelle verfügbar war.

Der Wechsel hat mich wenig gekostet: Informationsarchitektur und Wireframe-Vorbereitung waren bereits als Kontext beschrieben. Getauscht habe ich nur das Werkzeug für die visuelle Ausarbeitung.

Ein einzelner, mit Claude erzeugter Screen kann überzeugend aussehen. Ein komplexes System muss zusätzlich Rollen, Inhalte, Zustände und Ausnahmen zusammenbringen. Dafür braucht es Iterationen und Erfahrung im Context Engineering.

Die Vorteile liegen vor allem hier:

• Schnelles Prototyping: Ideen werden früh sichtbar und lassen sich besprechen.

• Erweiterbarkeit: Neue Anforderungen und alternative Lösungswege bauen auf derselben dokumentierten Grundlage auf.

• Transparenz: Quellen, Annahmen und Entscheidungen bleiben nachvollziehbar. Das Team kann sehen, warum ein Flow oder Screen so aufgebaut ist und wer Änderungen freigegeben hat.

• Tool-Unabhängigkeit: Der konzeptionelle Kontext bleibt außerhalb einzelner Apps nutzbar. So lässt sich zwischen pen.dev, Figma oder Paper wechseln. Schnittstellen und Dateiformate begrenzen, wie viel sich direkt übertragen lässt.

• Weniger Fleißarbeit: Bildschirmvarianten sowie Light und Dark Mode lassen sich bei sauberen Layoutregeln und Tokens schneller ableiten. Kontraste, Umbrüche und Bedienbarkeit bleiben Prüfaufgaben. Quelle: daisyUI-Themes

Der Aufwand verschwindet trotzdem nicht:

• Context Rot: Längere Eingaben können die Zuverlässigkeit verschlechtern. Das Ausmaß hängt von Modell und Aufgabe ab. Quelle: Chroma-Bericht

• Lost in the Middle: Informationen mitten in langen Kontexten können schlechter berücksichtigt werden. Quelle: Liu et al.

• Halluzinationen: Plausible Ergänzungen können unbelegt sein; NIST nennt das Konfabulation. Werden sie ungeprüft weiterverwendet, tragen die daraus abgeleiteten Ergebnisse den Fehler weiter. Quelle: NIST AI 600-1

• Zu viel Zustimmung: Eine KI-Bewertung kann die vorgegebene Richtung bestätigen, obwohl Kritik nötig wäre. Quelle: Sycophancy-Forschung

• Zeit und Tokens: Wiederholtes Lesen, Generieren und Prüfen kostet. Auch die Pflege des Kontexts und das Erlernen der Arbeitsweise brauchen Zeit.

Deshalb würde ich den Erfolg an der Zeit bis zu einem geprüften Ergebnis messen. Ein schneller erster Entwurf sagt darüber wenig aus.

An dieser Verbindung von Design und AI Engineering arbeite ich. Wenn ihr eure Konzeption mit KI weiterentwickeln wollt, schauen wir uns euren Workflow gemeinsam an.