Bild: Mit KI generiert

KI im Designprozess professionell einzusetzen trennt eine Fähigkeit von allen anderen: nicht Prompt-Kreativität, nicht Tool-Kenntnis — sondern Context Engineering. Wer AI-Tools im Design einsetzt und unzuverlässige, inkonsistente oder markenfremde Outputs bekommt, hat meist kein Prompt-Problem — sondern ein Kontextproblem.

In diesem Artikel erfährst du, was Context Engineering von Prompt Engineering unterscheidet, wie System-Prompts und Design Tokens als Kontext funktionieren und wie Multi-turn Co-Creation strukturiert werden muss, um reproduzierbare Ergebnisse zu liefern.

 

AI Context Engineering vs. Prompt Engineering: Der eigentliche Unterschied

Prompt Engineering beschäftigt sich mit der Qualität einzelner Eingaben: Wie formuliere ich eine Anfrage präzise genug, um das gewünschte Ergebnis zu erhalten? Das ist eine sinnvolle Fähigkeit, aber sie hat eine strukturelle Schwäche. Ein gut formulierter Prompt produziert einmal ein gutes Ergebnis. Beim nächsten Durchlauf, mit leicht verändertem Kontext oder einem anderen Modell, produziert er etwas anderes.

Context Engineering stellt eine andere Frage: Was muss die KI über mein Projekt, mein Designsystem, meine Zielgruppe und meine Qualitätsstandards wissen, bevor ich auch nur die erste Anfrage stelle?

Der Unterschied ist nicht graduell, sondern fundamental:

• Prompt Engineering ist reaktiv: Ein Problem taucht auf, ein Prompt löst es
• Context Engineering ist strukturell: Rahmenbedingungen werden einmal definiert und gelten für alle nachfolgenden Interaktionen

In der Praxis bedeutet das: Wer Context Engineering beherrscht, bekommt beim zehnten Aufruf dieselbe Qualität wie beim ersten — weil das Modell in jedem Schritt denselben Informationsrahmen hat. Wer nur promptet, bekommt Zufall.

 

System-Prompts als Designentscheidung

Der System-Prompt ist die wichtigste Investition im Context Engineering. Er definiert, mit welchem Rollenverständnis, welcher Tonalität und welchen Rahmenbedingungen eine KI operiert: und zwar persistent, über alle nachfolgenden Turns hinweg.

Was ein durchdachter Design-System-Prompt enthält:

Rollendeklaration: Nicht „Du bist ein Designer" — sondern präzise: „Du bist Senior UX-Designer:in in einem Produktteam, das für Enterprise-SaaS-Anwendungen gestaltet. Deine Entscheidungen folgen Material Design 3 Prinzipien, priorisieren Accessibility und berücksichtigen Desktop-First-Workflows."

Qualitätskriterien: Was gilt als gutes Ergebnis? Ein System-Prompt, der definiert, dass jede Komponente alle fünf UI-States (Default, Hover, Focus, Disabled, Error) berücksichtigt, produziert konsistent vollständigere Outputs als einer ohne diese Anforderung.

Ablehnungsregeln: Was soll die KI explizit nicht tun? „Schlage keine visuellen Lösungen vor, die von etablierten Plattform-Guidelines abweichen, ohne die Abweichung zu begründen" ist eine Kontextinformation, die Outputs erheblich zuverlässiger macht.

Ein System-Prompt ist keine Anweisung. Er ist eine Designentscheidung über die Arbeitsbeziehung zwischen Designer:in und KI — und sollte mit derselben Sorgfalt entwickelt werden wie ein Design Brief.

 

Design Tokens als Kontext

Einer der stärksten Hebel im Context Engineering für Designer:innen ist die systematische Übergabe von Design-System-Informationen an AI-Tools. Was auf den ersten Blick technisch klingt, ist in der Praxis eine der direktesten Wege zu markenkonsistenten AI-Outputs.

Design Tokens sind atomare Designentscheidungen in maschinenlesbarer Form: Farbwerte, Typografie-Skalen, Spacing-Systeme, Border-Radii. Tools wie v0 oder Figma Make können diese Tokens direkt als Kontext entgegennehmen und daraus konsistente UI-Komponenten generieren, statt generische Defaults zu verwenden.

Ein konkretes Beispiel: Ein Prompt wie „Erstelle eine Card-Komponente mit primärer Aktion" ohne Kontext produziert etwas, das nach Standard-UI aussieht. Derselbe Prompt mit übergebenen Tokens für Primärfarbe, Typografieskala, Border-Radius und Spacing-System produziert etwas, das tatsächlich zum Designsystem passt.

Was das für die Praxis bedeutet:

• Figma-zu-Code-Kontext: Wer in Figma mit einem durchdachten Tokensystem arbeitet, kann diesen Kontext direkt an Code-generierendes AI-Tooling übergeben. Das ist kein Automatisierungsversprechen — es ist eine Qualitätsinvestition, die sich in jedem Prototyping-Schritt amortisiert
• Prompt-Sequenzen statt Einzelprompts: Ein gut aufgebautes Tokensystem erlaubt es, in Multi-turn-Dialogen konsistent auf denselben visuellen Standard zurückzugreifen, ohne bei jedem Prompt von vorne zu beginnen

Für Designer:innen, die tiefer in den Browser App Design Kontext einsteigen, ist das Zusammenspiel von Atomic Design, Tokens und AI-gestütztem Prototyping besonders relevant: Hier zahlt sich jede Kontextinvestition direkt in Komponentenqualität aus.

 

Multi-turn Co-Creation: KI als Denkpartner strukturieren

Der häufigste Fehler im AI-gestützten Designprozess ist nicht ein schlechter erster Prompt — es ist die fehlende Planung der Konversationsstruktur. Wer AI als Werkzeug für Einzelaufgaben behandelt, verschenkt das größte Potenzial: iterative, mehrstufige Zusammenarbeit, in der frühere Entscheidungen explizit in späteren Schritten referenziert werden.

Multi-turn Co-Creation bedeutet, Konversationen als Prozess zu gestalten:

Turn 1 — Kontext aufbauen: Bevor eine Designlösung angefragt wird, wird der Problemrahmen explizit gemacht. Zielgruppe, Use Case, Constraints, Qualitätskriterien. Die KI wird nicht gebeten, etwas zu gestalten — sie wird gebeten, das Problem zu verstehen.

Turn 2 — Optionen explorieren: Statt einer Lösung werden drei bis fünf konzeptionell unterschiedliche Richtungen angefragt. Das erzeugt Divergenz, ohne Konvergenz zu erzwingen.

Turn 3 — Entscheidung dokumentieren: Welche Richtung wird weiterverfolgt und warum? Diese Entscheidung wird explizit in den Konversationskontext eingebracht — damit spätere Turns auf derselben Grundlage aufbauen.

Turn 4+ — Iteration mit Kontextbindung: Jede Änderungsanfrage referenziert explizit, was sie verändert und was sie beibehält. „Passe die Navigation an, behalte aber die Komponentenstruktur aus Turn 3" ist ein anderer Kontext als „Ändere die Navigation."

Dieser Prozess klingt aufwändiger als ein einzelner Prompt — er ist es auch. Aber er produziert Ergebnisse, die tatsächlich weiterverwendet werden können, statt Outputs, die nach dem ersten Review verworfen werden.

 

Wann Context Engineering scheitert

Context Engineering ist kein Allheilmittel. Es gibt Situationen, in denen auch der beste Kontext nicht hilft und diese zu kennen ist genauso wichtig wie die Methode selbst.

Zu enger Kontext verhindert kreative Outputs. Wer jeden Parameter des System-Prompts durchdefiniert, bekommt sehr konsistente, aber auch sehr vorhersehbare Ergebnisse. Context Engineering sollte Rahmenbedingungen setzen, nicht jeden Freiheitsgrad eliminieren.

Veralteter Kontext produziert Inkonsistenz. Wenn sich das Designsystem weiterentwickelt, muss der System-Prompt aktualisiert werden. Ein System-Prompt, der auf einem Designstand von vor sechs Monaten basiert, ist schlimmer als gar kein System-Prompt, weil er aktiv in die falsche Richtung führt.

Context Engineering ersetzt kein Urteilsvermögen. AI-Outputs, auch bei perfektem Kontext, müssen kuratorisch bewertet werden. Die Fähigkeit zu entscheiden, welcher Output gut ist und warum, bleibt die nicht delegierbare Kernkompetenz im AI-gestützten Design. Context Engineering verbessert die Trefferquote — aber es eliminiert nicht die Notwendigkeit, zu urteilen.

 

Take Away Message

Context Engineering ist die Designentscheidung, die vor dem ersten Prompt getroffen wird. Wer AI-Tools strukturiert einsetzt, investiert in System-Prompts, übergibt Design Tokens als maschinenlesbaren Kontext und plant Konversationsstrukturen als Prozess, nicht als Einzelanfragen. Das Ergebnis sind keine besseren Prompts. Es sind reproduzierbare, qualitätskonsistente Outputs, die tatsächlich in Designsysteme integriert werden können. Der Prompt ist das letzte Glied in der Kette — nicht das erste.