AI Design Behavior
Leitprinzipien
KI als Praktikant, Mensch als Senior. KI-Output ist immer ein erster Entwurf — kein Ergebnis. Ein Praktikant wird nicht alleine zum Kunden geschickt. KI-Output auch nicht.
WAS wird vorgegeben — WIE bleibt bei den Experten.
| Rolle | Definiert das WAS | Definiert das WIE |
|---|---|---|
| Product Manager | ✅ Welches Problem, welche Anforderungen | ❌ Nicht wie es aussieht oder gebaut wird |
| UX/UI Designer | ✅ Wie es aussieht, welcher Flow | ❌ Nicht wie es technisch implementiert wird |
| Developer | ✅ Wie gebaut, welche Technologie | ❌ Nicht welche Features oder wie sie aussehen |
KI-Tools dürfen innerhalb der eigenen Zuständigkeit eingesetzt werden — nicht um in die Zuständigkeit anderer Rollen einzugreifen.
Wer darf Prototypen erstellen
| Rolle | Darf Prototypen… | Begründung |
|---|---|---|
| UX/UI Designer | ✅ Erstellen · freigeben · präsentieren | Vollständiges Wissen über Design System, Brand, UX-Patterns |
| Product Manager | ✅ Briefen · reviewen · präsentieren | Strategischer Kontext |
| Sales | ✅ Anfragen und präsentieren | Präsentiert freigegebene Prototypen — erstellt keine eigenen |
| Development | ✅ Technisches Feedback geben | Beurteilt Machbarkeit — gestaltet keine Flows |
| Sales / CS / BD mit KI | ❌ Selbst erstellen | Kein Design-System-Wissen, Brand-Risiko |
| Dev nach „Best Practice" | ❌ Selbst erstellen | Best Practice ≠ unsere Marke, kein UX-Kontext |
Kein KI-generierter Output geht ohne menschliche Freigabe in eine Kundenpräsentation.
Prototype-Request-Prozess
Sales / PM identifiziert Bedarf
↓ Briefing an UX/UI (Notion Template)
↓ UX/UI schätzt Aufwand & Termin
↓ Erstellung (mit KI-Unterstützung)
↓ Internes Review (UX/UI + PM)
↓ Freigabe → [DONE] in Figma
↓ Sales präsentiert beim Kunden
Vibe Coding & POCs
Vibe-Code-Prototypen werden nicht in Kunden-Meetings gezeigt und nicht an Dev übergeben.
POCs sind erlaubt — aber nur auf Basis der POC-Bibliothek (Untitled UI React + Spherity Design Tokens).
| Rolle | POC Vibe Coding | Voraussetzung | Nicht erlaubt |
|---|---|---|---|
| UX/UI Designer | ✅ Erste Wahl | POC-Bibliothek, Figma Make bevorzugen | Kein Production-Code |
| Product Manager | ✅ Konzept-Explorations | POC-Bibliothek, 15-min UX/UI Check | Keine Kunden-Demos ohne Freigabe |
| UX/UI Researcher | ✅ Forschungsprototypen | POC-Bibliothek, nur Dummy-Daten | Keine echten Kundendaten |
| Developer | ⚠️ Nur wenn beauftragt | Sauberer Stack, POC-Bibliothek | POC-Code nicht in Production |
| Sales | ❌ Nein | — | Keine POCs, keine „schnellen Demos" |
| Marketing | ❌ Nein | — | Keine Produkt-POCs |
POC-Pflichtregeln
- Immer von der POC-Bibliothek starten (Marken-Tokens automatisch drin)
- Nur mit Dummy-Daten — keine Kundendaten, keine Ausnahmen
- Klar als „POC — nicht Produkt" kennzeichnen
- UX/UI vor Außenpräsentation einbeziehen (15-Minuten-Check reicht)
- Kein POC-Code in Production-Codebase
| Tool | Wenn… |
|---|---|
| Figma Make | POC soll eng am echten Produkt bleiben |
| v0.dev | Einzelne UI-Komponenten mit Untitled UI |
| Lovable | POC braucht echte Interaktionen und Daten |
| Bolt.new | Explorative Demos ohne Dev-Kapazität |
| Cursor | PM/Designer mit technischem Hintergrund |
Wann wir KEINE KI einsetzen
- Nutzerbedürfnisse und Research — echtes Nutzerverstehen erfordert menschliche Empathie
- Strategische Design-Entscheidungen — Navigation, Interaktionsmodell, IA bleibt beim Team
- Brand und Ästhetik — was zur Marke passt, entscheidet der Mensch
- Accessibility und Inklusion — Barrierefreiheit erfordert Expertise
- Finale Kundenpräsentationen ohne Review — jeder externe Output wird freigegeben
- Neue Produktfeatures ohne Basis-Design — Neues entsteht durch Menschen
- Sensitive Daten — keine vertraulichen Inhalte in externe KI-Tools
Wo KI Mehrwert bringt
| Aufgabe | KI | Menschliche Rolle |
|---|---|---|
| User Flows strukturieren | ✅ Vordenken | Mensch entscheidet |
| UX Copy & Placeholder Content | ✅ Generieren | Mensch reviewed |
| Prototype-Linking (Figma AI) | ✅ Automatisieren | Mensch reviewt |
| Ticketerstellung | ✅ Struktur | Mensch reviewed |
| Testplan & Studiendesign | ✅ Ersten Entwurf | UX/UI verfeinert |
| Nutzerbedürfnisse verstehen | ❌ Nein | Mensch (PM + UX) |
| Kreative Richtungsentscheidungen | ❌ Nein | Mensch (UX/UI) |
| Kundenpräsentation | ❌ Nein | Mensch |
Figma als Single Source of Truth
Alles was gebaut werden soll, wird zuerst in Figma designed und freigegeben — nicht parallel, nicht vorher.
Untitled UI Pro (Basis — niemals editieren)
↓ Spherity UI Extensions (Spherity-spezifische Komponenten)
↓ Produkt-Files: CARO / VERA / EIDA / KYLE
(nur Screens, keine Komponentendefinitionen)
| Prefix | Bedeutung |
|---|---|
[BASE] | Referenz-Screens — niemals direkt präsentieren |
[FLOW] | Aktiver Prototype für Präsentation |
[WIP] | In Arbeit, noch nicht freigegeben |
[DONE] | Freigegeben für Meeting / Dev-Handoff |
Ethische Grundsätze
- Transparenz nach innen: Alle Teammitglieder wissen, welche KI-Tools eingesetzt werden.
- Transparenz nach außen: Kunden wissen, dass Demos KI-assistiert erstellt wurden.
- Ownership bleibt beim Menschen: Jeder KI-Output hat einen menschlichen Owner.
- Datenschutz: Keine Kundendaten oder vertraulichen Infos in externe KI-Tools.
- Kompetenzen erhalten: KI darf kein Ersatz für Kompetenzaufbau werden.
Default-Verhalten für Claude
Wenn nach Visuals, Layouts, Prompts oder UI-Ideen gefragt wird:
- Konzept vereinfachen
- Alle unnötigen Elemente entfernen
- Eine starke Idee fokussieren
Im Zweifel: Einfacher machen · 30 % der Elemente entfernen · Klarheit erhöhen
Querverweise: Guardrails · Prompts · design.md §3.6