Produktdesign ohne Figma funktioniert, wenn ein Produkt bereits über ein ausgereiftes Designsystem verfügt. Mein KI-Produktdesign-Workflow nutzt drei Agentenfähigkeiten: ui-design erkundet neun Richtungen, ui-implement verwandelt die gewählte Richtung in das Produkt, und ui-walkthrough prüft jeden Zustand durch das eingebaute Agent Browser. Die Entscheidungen treffe ich weiterhin; der Agent übernimmt die wiederholte Produktion und Überprüfung.
Die meisten Produktfunktionen beginnen nicht auf einer leeren Seite. Wenn ein Produkt schon eine Weile existiert, sind seine grundlegenden Designentscheidungen bereits im Code vorhanden. Buttons, Eingabefelder, Karten, Navigation, Abstände, Farben, Texte, Hover-Zustände und das mobile Verhalten sind alle definiert. Diese Elemente in Figma neu aufzubauen bedeutet oft, dieselben Komponenten auf eine andere Leinwand zu ziehen, bevor sie im Produkt erneut aufgebaut werden.
Der Designer trifft immer noch die Produktentscheidungen. Der Agent übernimmt einen Großteil der wiederholenden Montage und Überprüfung. Das funktioniert, weil Zero bereits ein einigermaßen ausgereiftes Designsystem hat.
1. Starten Sie das Produktdesign ohne Figma mit einem Designsystem
Ohne Figma zu arbeiten bedeutet nicht, ohne Gestaltungsregeln zu arbeiten. Es erfordert klarere Regeln.
Für Zero kann der Agent prüfen:
- Vorhandene Komponenten für Schaltflächen, Eingaben, Dropdowns, Karten, Dialoge und Navigation
- Festgelegte Abstände, Typografie, Farben, Rahmen und Eckradien
- Bestehende Hover-, ausgewählte, deaktivierte, leere und mobile Zustände
- Kopierkonventionen wie Satzschreibung und kurze benutzerorientierte Bezeichnungen
- Echte Bildschirme, die zeigen, wie diese Teile kombiniert werden
Diese Referenzen beantworten gewöhnliche Designfragen. Eine neue Eingabe sollte wie die bereits gelieferten Eingaben aussehen. Eine neue Karte sollte die gleiche Oberfläche und den gleichen Radius wie die nächstgelegene bestehende Karte verwenden. Eine Symbolschaltfläche sollte das gleiche Hover-Verhalten wie andere Symbolschaltflächen haben.
Dies gibt dem Agenten eine Grenze. Er kann die Struktur eines Features erkunden, ohne für jeden Bildschirm eine neue visuelle Sprache zu erfinden.
Figma ist immer noch nützlich, wenn ein Team eine neue Marke, ein neues Komponentensystem oder eine Interaktion erstellt, die keinen engen Produktbezug hat. Sobald das System jedoch ausgereift ist, kann das laufende Produkt zur Hauptdesignoberfläche werden. Dies ist die Feature-Scale-Version von Design-as-Code-Workflow, mit dem wir Zero neu erstellt haben.
2. Verwenden Sie ui-design, um neun Produktdesign-Richtungen zu erkunden
Jedes Feature muss noch erkundet werden. Ich möchte nicht, dass ein Agent meinen ersten Satz nimmt und sofort in Code umwandelt.
Ich beginne mit ui-design. Ich gebe dem Agenten den aktuellen Bildschirm, das Benutzerproblem, das Ziel und die Hauptbeschränkungen. Der Agent liest die bestehenden Produktmuster und gibt eine empfohlene Richtung sowie neun Alternativen zurück.
In klarer Sprache erfasst die Fähigkeit den aktuellen Bildschirm, erstellt eine empfohlene Richtung, untersucht neun verschiedene Alternativen, stellt die Kompromisse dar und wartet auf eine menschliche Entscheidung.
Das Design Thinking innerhalb dieser Anweisung
Diese Anweisung ist nicht nur eine Liste visueller Regeln. Sie verwandelt den normalen Arbeitsprozess eines Designers in eine wiederholbare Abfolge:
- Verstehen, bevor Sie vorschlagen. Erfassen Sie den aktuellen Bildschirm und lesen Sie das umgebende Produkt, bevor Sie etwas erstellen.
- Denke in Systemen. Behandle bestehende Komponenten, Vorlagenseiten, Interaktionsmuster und Textregeln als Ausgangsmaterial.
- Vermeide Neuerfindungen. KI neigt dazu, ein neues Muster zu erstellen, wenn die Vorgabe vage ist. Die Anweisung sagt ihr, die am nächsten liegende bereitgestellte Komponente oder Seite zu finden und wiederzuverwenden, anstatt aus dem Gedächtnis abzuschätzen.
- Erkunden, bevor Sie wählen. Der After-Anker gibt eine plausible Richtung vor. Die neun Varianten eröffnen verschiedene Entscheidungen hinsichtlich Layout, Hierarchie, Dichte, Einstiegspunkt und Offenlegung.
- Trennung von Erkundung und Verpflichtung. Der Agent stoppt, nachdem er Optionen präsentiert hat. Ein Mensch vergleicht die Kompromisse und trifft die Entscheidung, bevor der Code beginnt.
- Überprüfen Sie die gesamte Erfahrung. Text, Hover-Rückmeldungen, Zustände, mobiles Verhalten und visuelle Konsistenz sind Teil des Designs, nicht die Nachbearbeitung nach der Implementierung.
Das ist das systemische Denken, das ich von der Fähigkeit erwarte: das bestehende Produkt verstehen, darin erkunden und dann eine bewusste Entscheidung treffen.
Hier ist die vollständige Originalanweisung, wortwörtlich aus dem Live-Workflow wiedergegeben:
Vollständige Originalanweisung für ui-design
# vm0 / Zero UI-Design-Richtlinien
## Workflow — zuerst Visuals, dann Code
**Nicht sofort zum Code springen.** Wenn diese Fähigkeit aktiviert wird, ist das erste Ergebnis immer eine Reihe von gerenderten Mockups, die Ming ansehen kann. Die Umsetzung erfolgt erst, nachdem eine Richtung gewählt wurde.
### Schritt 1 — Erfassen Sie das „Vorher“
- Wenn ein Bildschirm bereits existiert, rendern Sie seinen aktuellen Zustand als **vorher**-Bild (machen Sie einen Screenshot der laufenden App oder rendern Sie die bestehende Komponente als statische Vorschau).
- Wenn die Anfrage sich auf einen brandneuen Bildschirm bezieht, ist das „Davor“ entweder der nächstgelegene vorhandene Bildschirm oder ein leerer Zustand – mache dies in der Bildunterschrift deutlich.
### Schritt 2 — Erzeuge einen einzelnen "nach"-Anker
- Ein Mockup, das Ihre bestmögliche Interpretation der Anfrage darstellt und alle nachstehenden Regeln vollständig befolgt (Komponenten, Satzzeichen, Agent-Detail-Eingaben/Auswahlmenüs, Chat-Komponisten-Kartenradien, Schaltfläche Zeitplan hinzufügen, IconButton-Hover, grau-50-Oberflächen).
- Kombinieren Sie es mit der **vorher** Seite an Seite. Beschriften Sie sie deutlich: `Before` / `After`.
### Schritt 3 — Erzeuge 9 Varianten zur Erkundung
Nach dem Vorher/Nachher-Paar erstellen Sie **9 verschiedene Varianten-Mockups** für denselben Bildschirm. Jede Variante sollte eine bedeutend andere Designachse erkunden — nicht 9 Farbänderungen. Decken Sie eine Bandbreite ab wie:
1. Layout — einzelne Spalte vs. geteilter Bereich / Seitenleiste / Raster
2. Dichte — kompakt vs. geräumig
3. Hierarchie — welches Element führt visuell
4. Oberflächenbehandlung — flach vs. kartenweise gruppiert vs. geteilte Abschnitte
5. Einstiegspunkt — Inline-Aktion vs. dedizierte CTA vs. Empty-State-Held
6. Textrahmung — instruktiv vs. minimal vs. konversationell
7. Offenlegung — alles Sichtbare vs. schrittweise Enthüllung / Akkordeons
8. Komposition — inhaltsgesteuert vs. kontrollgesteuert
9. Eine bewusst unkonventionelle / „Joker“-Richtung, die es wert ist, einmal gesehen zu werden
Jede Variante muss weiterhin die unverhandelbaren Punkte respektieren (Satzzeichen, Wiederverwendung von Komponenten, Agent-Detail-Eingabe/Auswahlstil, Chat-Composer-Radien, Add-Schedule-Button, IconButton-Hover, Grau-50-Neutralfarben). Varianten erkunden *Layout und Betonung*, nicht „was wäre, wenn wir das Designsystem ignorieren würden.“
### Schritt 4 — Präsentieren, dann warten
- Zeige alle Bilder Ming in einer Nachricht: zuerst das `Before / After`-Paar, dann die 9 Varianten mit den Nummern 1–9, jeweils mit einer einzeiligen Bildunterschrift, die die untersuchte Achse beschreibt.
- Fragen, welche Richtung (oder welche Mischung) man verfolgen soll.
- Beginnen Sie nicht mit der Umsetzung, bis Ming eine Richtung wählt.
### Die Bilder rendern
- Bevorzugter Weg: statische HTML/React-Vorschauen erstellen, die echte Tailwind-Token von `turbo/apps/platform` verwenden, Screenshots davon machen und über `okou web upload-file` hochladen.
- Für die schnelle Erkundung: Die `v0`-Fähigkeit kann Varianten von Mockups aus einem Prompt erzeugen – aber der Prompt muss die untenstehenden Regeln ausdrücklich aufzählen (Satzzeichen, Agenten-Detail-Eingaben, Chat-Composer-Radius usw.), damit v0 keine generische SaaS-Benutzeroberfläche erzeugt.
- Wenn die Bilderstellung für die Sitzung nicht verfügbar ist, weiche auf klar gekennzeichnete ASCII- / textbasierte Drahtmodelle für alle 11 Frames aus (vorher, nachher, 9 Varianten) und weise darauf hin — überspringe den visuellen Schritt niemals stillschweigend.
---
# Designregeln
Dies sind die nicht verhandelbaren Designkonventionen für jede neue Benutzeroberfläche, die innerhalb der vm0-Plattform (`turbo/apps/platform`) bereitgestellt wird. Wenden Sie sie an, bevor Sie Komponenten schreiben, und prüfen Sie bestehende PRs während der Überprüfung darauf.
## Kernprinzipien
1. **Wiederverwenden, nicht neu erfinden.** Überprüfen Sie immer die vorhandenen Primitiven in `turbo/apps/platform/src/components/` und View-Level-Muster unter `src/views/`, bevor Sie eine neue Komponente einführen. Wenn eine ähnliche Interaktion bereits in Agentendetails, Zeitplan oder Chat-Komponist vorhanden ist, kopieren Sie dieses Muster, anstatt ein paralleles zu entwerfen.
2. **Passen Sie die Zero-Designsprache an.** Weiche Oberflächen, neutrale Grautöne, großzügige Radien, subtile Ränder, keine harten Schatten. Die visuelle Ausgangsbasis ist „ruhig, eigenwillig, leicht editorial“ — niemals SaaS-Standard.
3. **Sprich aus der Sicht des Benutzers.** Der Text sollte beschreiben, was *sie* gerade tun oder sehen werden, nicht, was das System tut. Halte ihn kurz — normalerweise ein Satz, höchstens zwei.
## Referenzmuster (diese direkt kopieren)
| Element | Referenzquelle | Warum |
|---------------------|---------------------------------------------------|-----|
| Text- / Textbereich-Eingabe | Agentendetailseite Eingabe (`src/views/agent-detail/`) | Festgelegtes Padding, Rahmen, Fokuszustand, Platzhalterbehandlung |
| Dropdown / Auswahl | Dropdown-Menü der Agentendetailseite | Etablierter Trigger-Stil, Menü-Radius, Element-Hover, Platzierung des Häkchens |
| Karten- / Plattenradius | Chat-Komponistenkarte (suche nach `composer` Komponenten) | Legt den kanonischen Kartenradius und den Oberflächenstil in der gesamten App fest |
| Primäre Seiten-Schaltfläche | „Zeitplan hinzufügen“-Button auf der Zeitplanseite | Das neutral-dunkle Primär, das überall *außerhalb* von Modalen verwendet wird |
| Primärer Schaltfläche im Modal | Die primäre Farbe der Marke (nur innerhalb von Dialogen/Popovers) | Modale behalten die Primärfarbe der Marke; Seiten tun dies nicht |
| Nur-Symbol-Schaltfläche | Bestehende IconButton mit Hover-Hintergrund | Jedes anklickbare Symbol muss einen sichtbaren Hover-Zustand haben |
Im Zweifelsfall öffnen Sie die Referenzkomponente im Codebestand, lesen ihre Props und Klassennamen und spiegeln sie. Nähern Sie sich nicht aus dem Gedächtnis an.
## Text-Richtlinien
- **Formulierung aus der Nutzerperspektive.** „Verbinden Sie Ihr Postfach“ ist besser als „Postfachverbindung erforderlich“. „Noch keine Agenten“ ist besser als „Agentenliste ist leer“.
- **Kürze vor Vollständigkeit.** Eine kurze Zeile ist einer vollständigen Satzstruktur überlegen. Streiche Füllwörter („einfach“, „bitte“, „um zu“).
- **Satzzeichen für alles.** Beschriftungen, Überschriften, Schaltflächen, Menüpunkte, Tabellenspalten — alles im Satzfall („Modellanbieter“, „API-Schlüssel“, „Zeitplan hinzufügen“). Niemals im Titelstil. Niemals `uppercase` über CSS auf Abschnittsüberschriften. Wenn Sie ein Label im Titelstil oder in Großbuchstaben finden, korrigieren Sie es.
- **Keine beschriftungsartigen „dekorativen“ Labels** über Feldern oder Abschnitten — sie wirken wie ein Formular und veraltet. Verwenden Sie ein normales Label oder verzichten Sie auf das Label, wenn das Feld selbsterklärend ist.
- **Kein abschließendes Satzzeichen** auf eigenständigen Beschriftungen oder Schaltflächen. Punkte sind für Fließtext und Hilfetexte vorgesehen.
- Beim Umbenennen eines Strings durchsuchen Sie den Code nach dem alten String und testen Sie ihn — Labels werden in Tests und Übersetzungen referenziert.
## Komponenten und Struktur
- Bauen Sie Seiten immer aus vorhandenen Komponenten (`Button`, `Input`, `Select`, `Card`, `IconButton`, Dialog-Primitiven usw.). Neue Komponenten sind das letzte Mittel und erfordern einen Grund.
- Suchen Sie nach einem vorhandenen Layout/Template (Einstellungsseite, Listen-Seite, Detailseite) und übernehmen Sie dessen Grundgerüst. Leiten Sie die Seitenstruktur nicht erneut ab.
- Beim Hinzufügen zu einer Einstellungsseite sollten Sie den Abschnittsabstand, die Trennlinienbehandlung und die Formularzeilenbreite an die benachbarten Abschnitte anpassen.
## Schaltflächen
- **Seiten-Primär** (die wichtigste CTA auf einer Seite) → entspricht dem „Zeitplan hinzufügen“-Button auf der Zeitplan-Seite. Dies ist der neutrale dunkle/solide Primärbutton, der app-weit außerhalb von Dialogen verwendet wird.
- **Modal primär** (die Bestätigungsschaltfläche innerhalb von Dialogen/Popovers) → verwendet die Marken-Primärfarbe. Seiten tun dies nicht.
- **Sekundäre / Ghost-Buttons** → Verwenden Sie die vorhandenen Varianten; erfinden Sie keine neuen.
- **Symbolschaltflächen** → müssen einen Hover-Hintergrund haben (typischerweise `hover:bg-gray-50` oder das etablierte IconButton-Hover-Token). Niemals ein nacktes, hoverloses Symbol als Klickziel ausliefern.
- Alle Tasten sollten die bestehenden Höhenwerte respektieren — keine einmaligen Größen einführen.
## Eingaben
- Spiegeln Sie die Eingabedetails des Agenten: gleiche Polsterung, gleicher Rand, gleicher Fokus-Ring (oder dessen Fehlen – prüfen Sie die Referenz, bevor Sie einen Fokus-Ring hinzufügen), gleiche Platzhalterfarbe.
- Mehrzeilig: Verwenden Sie das Agentendetail-Textarea-Muster (automatisches Wachsen oder feste Zeilen wie im Referenzbeispiel).
- Setzen Sie keinen Doppelpunkt am Ende von Feldbeschriftungen.
- Hilfetext unter dem Eingabefeld, in zurückhaltendem Grau, einzeilig.
## Dropdown-Menüs / Auswahlen
- Spiegeln Sie das Dropdown-Menü für Agentendetails: gleiche Auslöseranzeige, gleicher Menü-Radius, gleiche Elementabstände, gleiche Hover-/Auswahlzustände.
- Das Menü sollte nicht breiter als sein Auslöser sein, es sei denn, der Inhalt verlangt es.
- Vermeiden Sie verschachtelte Untermenüs, es sei denn, ein vorhandenes Dropdown-Menü verwendet sie bereits.
## Karten und Oberflächen
- Der Kartenradius und der Oberflächenstil stimmen mit der Chat-Komponistenkarte überein. Führen Sie keinen kleineren oder größeren Radius ohne Grund ein.
- Ränder sind subtil (ein einzelner Haarstrich im vorhandenen Rand-Token). Keine Schlagschatten, es sei denn, der Chat-Komponist verwendet einen.
- Neutrale Flächen auf Mobilgeräten / hellgraue Füllungen (aktive Pill-Hintergründe, Symbolbehälterfüllungen usw.) → `bg-gray-50`. `gray-100` und `gray-200` wurden wiederholt als zu dunkel bezeichnet — starten Sie bei `gray-50`.
## Fokus und Interaktion
- Fügen Sie keine benutzerdefinierten `:focus-visible`-Box-Schatten oder Umrandungen zu Navigations- oder Marketingelementen hinzu – verwenden Sie stattdessen die Hover-Farbänderung erneut. (Die gleiche Einschränkung gilt im Allgemeinen auch innerhalb der Plattform, es sei denn, eine Referenzkomponente hat einen expliziten Fokus-Ring.)
- Jedes interaktive Element (Button, Icon-Button, Zeile, Link) benötigt einen sichtbaren Hover-Zustand. Testen Sie, indem Sie jedes einzelne überfahren, bevor Sie das Design als abgeschlossen betrachten.
- Deaktivierte Zustände verwenden die vorhandenen deaktivierten Token; stellen Sie keine eigene verblasste Farbe her.
## Checkliste zur Überprüfung
Bevor Sie eine Benutzeroberfläche als bereit erklären, gehen Sie Folgendes durch:
1. Habe ich bestehende Komponenten wiederverwendet, anstatt neue zu bauen?
2. Habe ich eine vorhandene Seitenschablone / ein Layout verwendet?
3. Sind die Eingaben visuell identisch mit den Agentendetail-Eingaben?
4. Sind Dropdown-Menüs optisch identisch mit den Dropdown-Menüs für Agentendetails?
5. Passen die Karten zum Radius und zur Oberfläche des Chat-Erstellers?
6. Ist jedes Etikett in Satzschrift? Gibt es noch Titel-Schrift oder alles in Versalien?
7. Ist der Text kurz und aus Sicht des Nutzers geschrieben?
8. Ist die Seite hauptsächlich der Button im Stil „Zeitplan hinzufügen“? Wird die primäre Marke nur in Modalen verwendet?
9. Hat jede Symbolschaltfläche einen Hover-Hintergrund?
10. Habe ich über jedes interaktive Element gehovert, um das Feedback zu bestätigen?
Wenn eine Antwort „nein“ ist, beheben Sie es, bevor Sie den PR öffnen.
## Im Zweifel
- Öffne die Referenzkomponente, lies ihren Quelltext und kopiere die Struktur.
- Wenn zwei Referenzkomponenten nicht übereinstimmen, bevorzugen Sie die zuletzt ausgelieferte (git log prüfen).
- Wenn das Design wirklich ein neues Primitive benötigt, sprich es mit Ming ab, bevor du es baust — gebündelte Überarbeitungsarbeit gehört in einen PR, bei dem er der Prüfer ist.
Bei den neun Optionen muss es sich nicht unbedingt um neun fertige Designs handeln. Ihre Aufgabe ist es, mir genügend Spielraum zu geben, um das Problem anders zu sehen und mich in die richtige Richtung zu bewegen. Wenn ein Konzept außerhalb des aktuellen Produkts liegt, kann ein eigenständiger React-Prototyp dennoch hilfreich sein. Für diese Funktion blieb ich im realen Produktsystem.
Ein echtes Beispiel: die Navigation von Zero
Zero hatte ursprünglich eine 300-Pixel-Seitenleiste, die Produktziele, angeheftete Agenten und Chat-Threads enthielt. Sie erledigte drei Aufgaben gleichzeitig. Ich wollte diese Aufgaben trennen, ohne den Gesprächsbereich zu ändern.
Die Produktübersicht für die Erkundung war:
/ui-designWiederholen Sie die Designphase für die Drei-Regionen-Navigation von Zero basierend auf der realen historischen Grundlage. Trennen Sie Produktziele, Agenten und Konversationen in klarere Regionen, ohne den Konversationsbereich zu ändern. Verwenden Sie echte Zero-Token, Symbole und Komponenten. Erstellen Sie eine quellengetreue Vorher-Darstellung, eine starke Nachher-Darstellung und neun wirklich unterschiedliche Varianten. Bearbeiten Sie den Produktcode nicht und präsentieren Sie kein Mockup als Browsernachweis.
Die erste Erkundung war zu vorsichtig. Mehrere Optionen änderten Breiten und Auswahlstile, aber sie sahen immer noch wie die gleiche Seitenleiste aus. Ich lehnte dieses Set ab und bat den Agenten, die Unterschiede auf der Ebene der Informationsarchitektur sichtbar zu machen.
Der zweite Durchlauf ergab neun wirklich unterschiedliche Richtungen. Ich habe sie in einer 3 × 3-Tabelle gruppiert, damit sie leicht verglichen werden können, ohne den Artikel in einen langen Bilderstreifen zu verwandeln. Jede Miniaturansicht öffnet sich im Bildbetrachter des Blogs.
| 1. Obere Navigation | 2. Zusammenklappbare Schublade | 3. Zuerst den Faden einfädeln |
|---|---|---|
 |  |  |
| Verschiebe Ziele über das Gespräch | Ziele verstecken, bis sie benötigt werden | Machen Sie Gespräche zum Hauptnavigationsobjekt |
| 4. Agent zuerst | 5. Zuerst das Gespräch | 6. Befehlsstarter |
 |  |  |
| Wähle einen Agenten vor seinen Threads | Platziere angeheftete Agenten über dem aktiven Gespräch | Öffnen Sie Ziele aus einem durchsuchbaren Menü |
| 7. Erweiterbare Schiene | 8. Dashboard-Eintrag | 9. Unteres Dock |
 |  |  |
| Erweitern Sie eine schmale Schiene nur bei Bedarf | Beginnen Sie mit der jüngsten Arbeit | Ziele nach unten verschieben |
Ich habe keinen dieser Rahmen genau so gewählt, wie sie gezeichnet waren. Ich habe sie verwendet, um zu entscheiden, was bleiben und was geändert werden sollte. Die endgültige Richtung nutzte eine schmale Zielschiene, eine separate Chatleiste, fünf sichtbare angepinnte Agenten und den bestehenden Gesprächsbereich.
Die wichtige Ausgabe von ui-design war nicht nur das Bild. Es war ein kurzer Entscheidungsbericht:
- Behalte eine 68-Pixel-Zielleiste und eine 300-Pixel-Chatleiste
- Zeige fünf angeheftete Agenten-Slots
- Halten Sie die Auswahl ruhig, aber lesbar
- Zeige die Neuordnungsanleitung nur beim Ziehen
- Lassen Sie das Gespräch und die bestehende mobile Schublade unverändert
Das war genug, um die Umsetzung zu beginnen.
3. Verwenden Sie ui-implement, um das ausgewählte Design in Code umzuwandeln
Nachdem ich eine Richtung gewählt und den Produkt-Codebase verbunden habe, arbeitet der Agent direkt im Code. Ich zeichne den ausgewählten Rahmen in Figma nicht zuerst neu.
In einfacher Sprache überspringt ui-implement die Exploration, weil die Richtung bereits gewählt wurde. Es findet die nächsten realen Komponenten und die Seitenstruktur, baut mit ihnen, prüft das Ergebnis und überprüft die Funktion in einem Browser.
Was diese Anweisung schützt
- Die gewählte Richtung sollte während der Umsetzung nicht neu gestaltet werden.
- Der Agent muss mit der nächstgelegenen vorhandenen Komponente und Vorlage-Seite beginnen.
- Wiederverwendung gewinnt gegenüber einer neuen Komponente, es sei denn, das Produkt hat eine echte Lücke.
- Die Selbstprüfung und Browserüberprüfung erkennen inkonsistente Texte, Zustände und Interaktionen.
- Wenn eine Produktentscheidung noch nicht getroffen wurde, kehrt die Arbeit zu
ui-designzurück.
So bleibt das Designsystem während der Umsetzung aktiv. Es ist kein Dokument, das der Agent einmal liest. Es bestimmt, welche Komponenten er auswählt und wie er das fertige Erlebnis überprüft.
Hier ist die vollständige Originalanweisung, wortwörtlich aus dem Live-Workflow wiedergegeben:
Vollständige Originalanweisung für ui-implement
# vm0 / Zero UI Implementierungsregeln
## Workflow — direkt implementieren
Wenn diese Fähigkeit aktiviert wird, **überspringen Sie die Phase der Mockups und Variantenexploration**. Beginnen Sie sofort mit der Implementierung in `turbo/apps/platform` und wenden Sie dabei jede der unten stehenden Designregeln an.
### Schritt 1 — Lokalisieren Sie die Referenzkomponenten
Bevor Sie eine Zeile schreiben, öffnen Sie die Referenzkomponenten, die Sie spiegeln werden:
- Eingabe / Textbereich → `src/views/agent-detail/` Eingabe
- Dropdown / Auswahl → `src/views/agent-detail/` Dropdown
- Karten-/Panelradius → Chat-Komponistenkarte
- Hauptseite-Schaltfläche → "Zeitplan hinzufügen"-Schaltfläche auf der Zeitplanseite
- Nur-Symbol-Schaltfläche → bestehend `IconButton` mit Hover-Hintergrund
Lies ihre Props und Klassennamen. Spiegele sie — schätze sie nicht aus dem Gedächtnis ab.
### Schritt 2 — Finde die nächstgelegene vorhandene Seitenvorlage
Öffnen Sie die nächstgelegene vorhandene Seite derselben Art (Einstellungen, Liste, Detail) und übernehmen Sie deren Gerüst: Abschnittsabstand, Trennlinienbehandlung, Formularreihenbreite. Leiten Sie die Seitenstruktur nicht erneut ab.
### Schritt 3 — Bauen, dann selbst prüfen
Implementieren Sie den Bildschirm mit vorhandenen Primitiven aus `turbo/apps/platform/src/components/`. Wenn Sie denken, dass er fertig ist, gehen Sie die **Überprüfungs-Checkliste** am Ende dieser Fertigkeit durch, bevor Sie Bericht erstatten. Beheben Sie jede „Nein“-Antwort, bevor Sie die Arbeit als abgeschlossen erklären.
### Schritt 4 — Im Browser überprüfen
Für jegliche UI-Arbeiten starte den Entwicklungsserver und teste die Funktion im Browser, bevor du die Aufgabe als erledigt meldest. Fahre mit der Maus über jedes interaktive Element, teste den normalen Ablauf und Randfälle und achte auf Rückschritte in benachbarten Bildschirmen. Type-Checks und Tests überprüfen den Code, nicht die Funktionskorrektheit — wenn du den Browser nicht öffnen kannst, sag das ausdrücklich.
### Wann auf ui-design zurückgegriffen werden sollte
Wenn die Anfrage offen ist („gestalte eine Einstellungsseite für X“) und keine festgelegte Richtung hat, stoppen Sie und führen Sie stattdessen die `ui-design`-Fähigkeit aus — das Vorher/Nachher + 9 Varianten existieren genau für diesen Fall. `ui-implement` ist dafür, wenn die Richtung bereits entschieden ist.
---
# Designregeln
Dies sind die unverhandelbaren Designkonventionen für jede neue Benutzeroberfläche, die innerhalb der vm0-Plattform (`turbo/apps/platform`) bereitgestellt wird. Wenden Sie sie beim Erstellen an und prüfen Sie Ihre eigenen Änderungen daran, bevor Sie die Pull-Anfrage öffnen.
## Kernprinzipien
1. **Wiederverwenden, nicht neu erfinden.** Überprüfen Sie immer die vorhandenen Primitiven in `turbo/apps/platform/src/components/` und die Muster auf Ebene der Ansicht unter `src/views/`, bevor Sie eine neue Komponente einführen. Wenn eine ähnliche Interaktion bereits im Agentendetail, im Zeitplan oder im Chat-Composer verfügbar ist, kopieren Sie dieses Muster, anstatt ein paralleles zu entwerfen.
2. **Passen Sie die Zero-Designsprache an.** Weiche Oberflächen, neutrale Grautöne, großzügige Radien, subtile Ränder, keine harten Schatten. Die visuelle Ausgangsbasis ist „ruhig, meinungsstark, leicht redaktionell“ — niemals SaaS-Standard.
3. **Sprich aus der Sicht des Benutzers.** Der Text sollte beschreiben, was *sie* gerade tun oder sehen werden, nicht, was das System tut. Halte ihn kurz — normalerweise ein Satz, höchstens zwei.
## Referenzmuster (diese direkt kopieren)
| Element | Referenzquelle | Warum |
|---------------------|---------------------------------------------------|-----|
| Text- / Textbereich-Eingabe | Agentendetailseite Eingabe (`src/views/agent-detail/`) | Festgelegtes Padding, Rahmen, Fokuszustand, Platzhalterbehandlung |
| Dropdown / Auswahl | Dropdown-Menü der Agentendetailseite | Etablierter Trigger-Stil, Menü-Radius, Element-Hover, Platzierung des Häkchens |
| Karten- / Plattenradius | Chat-Komponistenkarte (suche nach `composer` Komponenten) | Legt den kanonischen Kartenradius und den Oberflächenstil in der gesamten App fest |
| Primäre Seiten-Schaltfläche | „Zeitplan hinzufügen“-Button auf der Zeitplanseite | Das neutral-dunkle Primär, das überall *außerhalb* von Modalen verwendet wird |
| Primärer Schaltfläche im Modal | Die primäre Farbe der Marke (nur innerhalb von Dialogen/Popovers) | Modale behalten die Primärfarbe der Marke; Seiten tun dies nicht |
| Nur-Symbol-Schaltfläche | Bestehende IconButton mit Hover-Hintergrund | Jedes anklickbare Symbol muss einen sichtbaren Hover-Zustand haben |
Im Zweifelsfall öffnen Sie die Referenzkomponente im Codebestand, lesen ihre Props und Klassennamen und spiegeln sie. Nähern Sie sich nicht aus dem Gedächtnis an.
## Text-Richtlinien
- **Formulierung aus der Nutzerperspektive.** „Verbinden Sie Ihr Postfach“ ist besser als „Postfachverbindung erforderlich“. „Noch keine Agenten“ ist besser als „Agentenliste ist leer“.
- **Kürze vor Vollständigkeit.** Eine kurze Zeile ist einer vollständigen Satzstruktur überlegen. Streiche Füllwörter („einfach“, „bitte“, „um zu“).
- **Satzzeichen für alles.** Beschriftungen, Überschriften, Schaltflächen, Menüpunkte, Tabellenspalten — alles Satzzeichen („Modellanbieter“, „API-Schlüssel“, „Zeitplan hinzufügen“). Niemals Titelgroßschreibung. Niemals `uppercase` über CSS auf Abschnittsüberschriften. Wenn Sie ein Titelgroß- oder alles-in-Großbuchstaben-Label finden, korrigieren Sie es.
- **Keine beschriftungsartigen „dekorativen“ Labels** über Feldern oder Abschnitten — sie wirken wie ein Formular und veraltet. Verwenden Sie ein normales Label oder verzichten Sie auf das Label, wenn das Feld selbsterklärend ist.
- **Kein abschließendes Satzzeichen** auf eigenständigen Beschriftungen oder Schaltflächen. Punkte sind für Fließtext und Hilfetexte vorgesehen.
- Beim Umbenennen eines Strings durchsuchen Sie den Code nach dem alten String und testen Sie ihn — Labels werden in Tests und Übersetzungen referenziert.
## Komponenten und Struktur
- Bauen Sie Seiten immer aus vorhandenen Komponenten (`Button`, `Input`, `Select`, `Card`, `IconButton`, Dialog-Primitiven usw.). Neue Komponenten sind das letzte Mittel und erfordern einen Grund.
- Suchen Sie nach einem vorhandenen Layout/Template (Einstellungsseite, Listen-Seite, Detailseite) und übernehmen Sie dessen Grundgerüst. Leiten Sie die Seitenstruktur nicht erneut ab.
- Beim Hinzufügen zu einer Einstellungsseite sollten Sie den Abschnittsabstand, die Trennlinienbehandlung und die Formularzeilenbreite an die benachbarten Abschnitte anpassen.
## Schaltflächen
- **Seiten-Primär** (die wichtigste CTA auf einer Seite) → entspricht dem „Zeitplan hinzufügen“-Button auf der Zeitplan-Seite. Dies ist der neutrale dunkle/solide Primärbutton, der app-weit außerhalb von Dialogen verwendet wird.
- **Modal primär** (die Bestätigungsschaltfläche innerhalb von Dialogen/Popovers) → verwendet die Marken-Primärfarbe. Seiten tun dies nicht.
- **Sekundäre / Ghost-Buttons** → Verwenden Sie die vorhandenen Varianten; erfinden Sie keine neuen.
- **Symbolschaltflächen** → müssen einen Hover-Hintergrund haben (typischerweise `hover:bg-gray-50` oder das etablierte IconButton-Hover-Token). Niemals ein nacktes, hoverloses Symbol als Klickziel bereitstellen.
- Alle Tasten sollten die bestehenden Höhenwerte respektieren — keine einmaligen Größen einführen.
## Eingaben
- Spiegeln Sie die Eingabedetails des Agenten: gleiche Polsterung, gleicher Rand, gleicher Fokus-Ring (oder dessen Fehlen – prüfen Sie die Referenz, bevor Sie einen Fokus-Ring hinzufügen), gleiche Platzhalterfarbe.
- Mehrzeilig: Verwenden Sie das Agentendetail-Textarea-Muster (automatisches Wachsen oder feste Zeilen wie im Referenzbeispiel).
- Setzen Sie keinen Doppelpunkt am Ende von Feldbeschriftungen.
- Hilfetext unter dem Eingabefeld, in zurückhaltendem Grau, einzeilig.
## Dropdown-Menüs / Auswahlen
- Spiegeln Sie das Dropdown-Menü für Agentendetails: gleiche Auslöseranzeige, gleicher Menü-Radius, gleiche Elementabstände, gleiche Hover-/Auswahlzustände.
- Das Menü sollte nicht breiter als sein Auslöser sein, es sei denn, der Inhalt verlangt es.
- Vermeiden Sie verschachtelte Untermenüs, es sei denn, ein vorhandenes Dropdown-Menü verwendet sie bereits.
## Karten und Oberflächen
- Der Kartenradius und der Oberflächenstil stimmen mit der Chat-Komponistenkarte überein. Führen Sie keinen kleineren oder größeren Radius ohne Grund ein.
- Ränder sind subtil (ein einzelner Haarstrich im vorhandenen Rand-Token). Keine Schlagschatten, es sei denn, der Chat-Komponist verwendet einen.
- Neutrale Flächen auf Mobilgeräten / hellgraue Füllungen (aktive Pillen-Hintergründe, Symbol-Container-Füllungen usw.) → `bg-gray-50`. `gray-100` und `gray-200` wurden wiederholt als zu dunkel bezeichnet – beginnen Sie bei `gray-50`.
## Fokus und Interaktion
- Fügen Sie keine benutzerdefinierten `:focus-visible`-Box-Schatten oder Umrandungen zu Navigations- oder Marketingelementen hinzu – verwenden Sie stattdessen die Hover-Farbänderung erneut. (Die gleiche Einschränkung gilt im Allgemeinen innerhalb der Plattform, es sei denn, eine Referenzkomponente hat einen expliziten Fokus-Ring.)
- Jedes interaktive Element (Button, Icon-Button, Zeile, Link) benötigt einen sichtbaren Hover-Zustand. Testen Sie, indem Sie jedes einzelne überfahren, bevor Sie das Design als abgeschlossen betrachten.
- Deaktivierte Zustände verwenden die vorhandenen deaktivierten Token; stellen Sie keine eigene verblasste Farbe her.
## Checkliste zur Überprüfung
Bevor Sie eine Benutzeroberfläche als bereit erklären, gehen Sie Folgendes durch:
1. Habe ich bestehende Komponenten wiederverwendet, anstatt neue zu bauen?
2. Habe ich eine vorhandene Seitenschablone / ein Layout verwendet?
3. Sind die Eingaben visuell identisch mit den Agentendetail-Eingaben?
4. Sind Dropdown-Menüs optisch identisch mit den Dropdown-Menüs für Agentendetails?
5. Passen die Karten zum Radius und zur Oberfläche des Chat-Erstellers?
6. Ist jedes Etikett in Satzschrift? Gibt es noch Titel-Schrift oder alles in Versalien?
7. Ist der Text kurz und aus Sicht des Nutzers geschrieben?
8. Ist die Seite hauptsächlich der Button im Stil „Zeitplan hinzufügen“? Wird die primäre Marke nur in Modalen verwendet?
9. Hat jede Symbolschaltfläche einen Hover-Hintergrund?
10. Habe ich über jedes interaktive Element in einem Browser gehovert, um Feedback zu bestätigen?
Wenn eine Antwort „nein“ ist, beheben Sie es, bevor Sie den PR öffnen.
## Im Zweifel
- Öffne die Referenzkomponente, lies ihren Quelltext und kopiere die Struktur.
- Wenn zwei Referenzkomponenten nicht übereinstimmen, bevorzugen Sie die zuletzt ausgelieferte (git log prüfen).
- Wenn das Design wirklich ein neues Primitive benötigt, sprich es mit Ming ab, bevor du es baust — gebündelte Überarbeitungsarbeit gehört in einen PR, bei dem er der Prüfer ist.
Dies war die funktionsspezifische Implementierungsaufforderung:
/ui-implementBeginnen Sie mit der Revision
04d642bb. Fügen Sie eine standardmäßig deaktivierte Desktop-Aufteilung mit einem 68px Zielschiene, einer 300px Chat-Leiste und der unveränderten Konversation hinzu. Behalten Sie die alte 300px Seitenleiste bei, wenn der Schalter ausgeschaltet ist und auf Mobilgeräten. Rendern Sie fünf angeheftete Slots, bewahren Sie die vom Benutzer definierte Reihenfolge und zeigen Sie die Neuanordnungsoptionen nur während eines aktiven Ziehvorgangs an. Untersuchen Sie die historische Funktion oder spätere Verfeinerungen nicht, bis der unabhängige Patch, die Tests und die Browsernachweise eingefroren sind.
Für die Navigationsfunktion habe ich den Agenten gebeten, die alte Seitenleiste beizubehalten, wenn die Funktion ausgeschaltet war, das neue dreiteilige Layout anzuzeigen, wenn sie eingeschaltet war, die bestehende mobile Schublade beizubehalten und den Nutzern zu ermöglichen, angeheftete Agenten neu anzuordnen.
Während der Implementierung fand der Agent ein wichtiges Problem. Das alte Produkt erinnerte sich daran, welche Agenten angeheftet waren, aber es erinnerte sich nicht an deren Reihenfolge. Eine Ziehinteraktion konnte korrekt aussehen und sich dann nach einer Aktualisierung zurücksetzen.
Also tat der Agent mehr, als nur den Ziehzustand anzuzeigen. Er ließ die neue Reihenfolge bestehen, aktualisierte die Seite und überprüfte, dass die Reihenfolge erhalten blieb. Er bestätigte auch, dass die Ziehgriffe nur während des Ziehens erschienen und danach wieder verschwanden.
Die Implementierungslieferung zeigte die beiden Desktop-Zustände, die ich überprüfen musste. Ich zeige sie in voller Breite, damit die Schnittstelle lesbar bleibt. Das Verhalten auf Mobilgeräten erscheint später im Rundgang als hochauflösende Telefonaufnahme.
Desktop-Ruhemodus
Aktive Umordnung
An diesem Punkt hatte ich eine funktionierende Funktion, nicht eine weitere Design-Datei. Aber die Implementierung war immer noch nicht das Ende. Ich musste sehen, was tatsächlich in der bereitgestellten Vorschau lief.
4. Verwenden Sie ui-walkthrough, um das echte Produkt zu überprüfen
Produktdurchläufe waren früher mühsam. Ich musste eine bereitgestellte Vorschau öffnen, das richtige Konto vorbereiten, Funktionen ein- und ausschalten, jede Steuerung anklicken, den Browser skalieren, Screenshots machen und versuchen, mich daran zu erinnern, welchen Zustand jedes Bild darstellte.
Der Agent hat ein eingebautes Agent Browser, also kann ich diese Arbeit an ihn abgeben.
Der Arbeitsablauf hat zwei Hauptschritte:
- Liste zuerst die Szenarien auf. Der Agent verwandelt die Design- und Implementierungsansprüche in eine Checkliste.
- Führen Sie die Checkliste aus und fügen Sie Beweise bei. Es führt jedes Szenario in der bereitgestellten Vorschau aus und gibt PASS, FAIL oder BLOCKED mit einem Screenshot für jeden bedeutenden Zustand zurück.
Was diese Anweisung an der Überprüfung ändert
- Der Agent listet die Szenarien auf, bevor er anfängt zu klicken.
- Es verwendet die tatsächlich eingesetzte Komponente über sein integriertes Agent Browser.
- Es erstellt einen Screenshot für jeden sinnvollen Zustand.
- Es markiert jeden Kontrollpunkt PASS, FAIL oder BLOCKED.
- Es verbirgt niemals einen nicht verfügbaren Zustand hinter vorgetäuschten Beweisen.
Dies verwandelt manuelles Klicken in ein organisiertes Überprüfungspaket. Ich kann das beabsichtigte Verhalten, das Ergebnis und die Beweise zusammen betrachten.
Die vollständige Anweisung ist unten. Ich habe den internen Abhängigkeitsnamen zur Klarheit für den Leser in „eingebautes Agent Browser“ übersetzt; die Workflow-Logik ist sonst unverändert.
Vollständige Originalanweisung für ui-walkthrough
# UI-Durchgang
End-to-End-Visual-QA eines vm0/Zero-Front-End-Features in seiner realen Vorschau pro PR. Dieser Workflow legt fest, was überprüft werden soll und wie das Ergebnis berichtet wird; er definiert nicht die UI-Bedienwerkzeuge.
## Erforderliche Abhängigkeit: integrierter Agent Browser
Verwenden Sie das integrierte Agent Browser als einzige verlässliche Quelle für jede UI-Interaktion, einschließlich:
- Entdecken und Öffnen der Vorschau pro PR.
- Vorschau-Schutzbehandlung und Sitzungsaufbau.
- Anmeldung, OTP, Onboarding, Stripe Test-Checkout und das Erreichen der Live-App.
- Aktivieren von Funktionsschaltern.
- Navigieren, Interagieren mit Steuerelementen, Bereitstellen von Test- oder Mock-Daten, Erfassen von Screenshots, Hochladen von Artefakten, Fehlerbehebung und Aufräumen.
Lesen Sie die aktuellen integrierten Agent Browser-Anweisungen und befolgen Sie diese, bevor Sie eine beliebige Benutzeroberflächenaktion ausführen. Duplizieren Sie keine laufzeitspezifischen Befehle, Engine-Einstellungen, Selektormechanismen, Seitenkontext-Skripte, Sitzungsverwaltung oder Methoden zur Prozessbereinigung in diesem Workflow. Wenn sich das integrierte Agent Browser ändert, haben dessen aktuelle Anweisungen Vorrang.
## Wann verwenden
- Gehen Sie die Benutzeroberfläche einer vm0-Pull-Anfrage in ihrer bereitgestellten Vorschau durch.
- Überprüfen Sie eine In-App-Funktion, die Authentifizierung, Onboarding, Abrechnung, Funktionsumschalter oder einen echten Chatverlauf erfordert.
- Erfassen Sie getreue Screenshots oder ein kurzes Durchlaufvideo der Funktion, wie sie in der Live-Anwendung arbeitet.
## Schritt-für-Schritt-Arbeitsablauf
### 1. Ziel und Umfang festlegen
- Identifizieren Sie den PR, den Haupt-Commit, das geänderte benutzer sichtbare Verhalten und die erwartete Vorschau.
- Bestätigen Sie, dass die bereitgestellte Vorschau dem PR-Head entspricht, bevor Sie testen.
- Lies den PR-Diff und die Beschreibung, um den kritischen Pfad und die Zustände abzuleiten, die die Änderung zeigen.
- Beheben Sie während einer Durchsicht keinen Code, lösen Sie keine Konflikte und ändern Sie das Produktverhalten nicht, es sei denn, der Benutzer fordert die Umsetzung gesondert an.
### 2. Erreichen Sie die Funktion
Verwenden Sie den integrierten Agent Browser, um die Vorschau zu betreten und den Live-Funktionszustand zu erreichen. Befolgen Sie dessen aktuelle Regeln für Authentifizierung, Onboarding, Abrechnung, Funktionsumschaltungen und Vorschau-only-Umgehungen.
Wenn ein Umgehungsweg verwendet wird, geben Sie dies im Abschlussbericht an. Verwenden Sie niemals einen Onboarding-Umgehungsweg, wenn das Onboarding selbst getestet wird.
### 3. Definieren Sie die visuelle Zustandsmatrix
Bevor Sie interagieren, listen Sie die kleinste Menge von Zuständen auf, die beweist, dass die Funktion funktioniert. Fügen Sie die zutreffenden Elemente ein:
- Anfangs-/Standardzustand.
- Offener, schwebender, fokussierter, ausgewählter, erweiterter oder aktiver Zustand.
- Leere und gefüllte Zustände.
- Aktivierte und deaktivierte Zustände.
- Erfolgs-, Validierungs-, Lade- und Fehlerzustände.
- Platzierung, Kollision, Spiegelung, Zuschneiden und reaktionsschnelles Verhalten.
- Einreichung oder nachgelagerte Aktion, wenn die Funktion interaktiv ist.
Bevorzugen Sie es, das tatsächlich geänderte Verhalten zu üben, anstatt einen generischen Smoke-Test durchzuführen.
### 4. Führe die stromführende Komponente
Verwenden Sie das integrierte Agent Browser für alle Interaktions- und Testdatentechniken.
Gefälschte oder injizierte Inhalte dürfen nur verwendet werden, um eine echte Anwendungskomponente in einen deterministischen visuellen Zustand zu versetzen. Die zu bewertende Komponente, das Styling und die Interaktion müssen weiterhin die tatsächliche Implementierung aus der PR-Vorschau sein.
Für jeden gemockten Zustand:
- Notieren Sie, welcher Inhalt oder welches Voraussetzung verspottet wurde.
- Unterscheiden Sie gemockte Inhalte vom tatsächlichen Anwendungsverhalten.
- Impliziere niemals, dass gespotteter Text oder Daten von einem Modell oder einer Produktionsquelle stammen.
- Betätigen Sie die echten Steuerungen und die nachgelagerte Verkabelung, wo immer es die Umgebung zulässt.
### 5. Beweise erfassen
Verwenden Sie das integrierte Agent Browser, um Beweise für die wichtigsten Kontrollpunkte zu erfassen und hochzuladen. Jedes Bild sollte einen bedeutenden Zustand nachweisen, anstatt denselben Blick zu wiederholen.
Wenn der Benutzer um ein Video bittet, erstelle einen kurzen, untertitelten Rundgang aus den überprüften Kontrollpunkten. Die Untertitel sollten die Benutzeraktion und das erwartete Ergebnis angeben, ohne die Benutzeroberfläche zu verdecken.
### 6. Liefern und berichten
Bericht:
- PR-Link, genaue Vorschau-URL und getesteter Commit, wenn verfügbar.
- Genau ausgeführter Benutzerfluss.
- Testkonto, wann eines erstellt wurde.
- `PASS`, `FAIL` oder `BLOCKED` für jeden Kontrollpunkt.
- Screenshot-Links und ein optionaler Video-Link mit kurzen Beschreibungen.
- Feature-Schalter, Umgehungen, Schein-Daten und andere nur für Tests verwendete Setups.
- Fehlgeschlagene Prüfungen, Umgebungsblocker oder Überprüfungslücken.
Behaupten Sie nicht, dass die Funktion überprüft ist, es sei denn, der Live-Preview-Ablauf wurde durchgeführt und Beweise wurden erfasst. Wenn die Vorschau nicht verfügbar ist, melden Sie `BLOCKED` mit den Bereitstellungsnachweisen, anstatt eine lokale oder statische Kopie zu verwenden.
Dies war die funktionsspezifische Schritt-für-Schritt-Anleitung:
/ui-walkthroughVerwenden Sie die bereitgestellte Vorschau über den integrierten Agent Browser als die einzige Browser-Quelle. Überprüfen Sie die Feature-off-Seitenleiste, die 68px- und 300px-Aufteilung, die Zielreihenfolge, Hover-Zustände, fünf angeheftete Slots, Drag-only-Griffe, dauerhaftes Umordnen, Thread-Auswahl, Scrollen und die vollständige iPhone-Schublade. Geben Sie für jeden Kontrollpunkt PASS, FAIL oder BLOCKED zurück. Ersetzen Sie keinen unerreichbaren Zustand durch ein Duplikat.
Für diese Funktion organisierte der Agent die Durchsicht rund um diese Fragen:
- Funktioniert die alte Seitenleiste noch, wenn die Funktion deaktiviert ist?
- Erscheint die neue Desktop-Struktur, wenn sie eingeschaltet ist?
- Sind Hover- und Auswahlzustände sichtbar, aber dezent?
- Sind fünf angeheftete Agenten lesbar?
- Bleiben die Umordnungssteuerungen ausgeblendet, bis ein Ziehen gestartet wird?
- Überlebt die neue Bestellung eine Aktualisierung?
- Kann ich echte Threads auswählen und durchblättern?
- Funktioniert die vorhandene mobile Schublade noch?
- Sind alle Navigationsziele vorhanden und in der richtigen Reihenfolge?
Der Agent öffnete dann die bereitgestellte Vorschau als neuer Benutzer, absolvierte das Onboarding, aktivierte die Funktion und arbeitete die Liste durch. Er testete den Ruhezustand, den Hover-Zustand, den Ziehzustand, das Aktualisierungsverhalten, die Thread-Auswahl, das Scrollen und das Telefonlayout.
Das Ergebnis war 11 PASS, 1 FAIL.
Das Scheitern war nützlich. Das Layout und die Interaktionen funktionierten, aber die bereitgestellte Vorschau zeigte nur sechs Produktziele. Activity und Insights fehlten, und die Reihenfolge stimmte nicht mit dem ausgewählten Design überein.
| Szenario | Ergebnis |
|---|---|
| Alte Seitenleiste mit deaktivierter Funktion | PASS |
| Neues dreiteiliges Desktop-Layout | PASS |
| Hover- und ausgewählte Zustände | PASS |
| Fünf angeheftete Agenten | PASS |
| Nur-Ziehen-Neuanordnen-Anleitung | PASS |
| Bestellung nach Aktualisierung gespeichert | PASS |
| Thread-Auswahl und Scrollen | PASS |
| Bestehende mobile Schublade | PASS |
| Zielinhalt und Reihenfolge | FAIL |
Die endgültige Lieferung war ein organisiertes Screenshot-Set und kein Ordner mit unbeschrifteten Bildern. Die Desktop-Aufnahmen haben 1440 × 900 Pixel und die Handy-Aufnahme 1170 × 2532 Pixel. Sie erscheinen nacheinander unten, sodass die Benutzeroberfläche lesbar bleibt; klicken Sie auf ein beliebiges Bild, um es zu vergrößern, ohne den Artikel zu verlassen.
Funktion aus
Funktion aktiviert
Desktop-Layout
Ziel schwebend
Gepinnter Agent schwebend
Aktives Ziehen
Gespeicherte Bestellung
Mobiles Regal
Dies ermöglicht mir, eine Funktion auf strukturierte Weise zu überprüfen. Ich kann die vorgesehenen Szenarien, das tatsächlich eingesetzte Ergebnis und die Beweise zusammen sehen. Wenn etwas fehlschlägt, weiß ich genau, wohin die Arbeit zurückgehen sollte.
Wie ein Team diesen KI-Produktdesign-Workflow übernimmt
Der gesamte Vorgang ist kurz. Teamkollegen können jede Phase als Gemeinsamer Zero-Workflow speichern, anstatt den Prozess aus dem Speicher neu zu erstellen.
| Bühne | Eingabe | Ausgabe |
|---|---|---|
ui-design | Aktueller Bildschirm, Problem, Ziel und Einschränkungen | Eine empfohlene Richtung, neun Alternativen und ein ausgewähltes Designprotokoll |
ui-implement | Der ausgewählte Designdatensatz | Eine überprüfbare Codeänderung und Screenshots der Hauptzustände |
ui-walkthrough | Die bereitgestellte Funktion und ihr erwartetes Verhalten | Eine organisierte Szenarienliste mit PASS-, FAIL- oder BLOCKED-Screenshots |
Ein Teamkollege muss meinen Designgeschmack nicht reproduzieren. Sie müssen einen guten Kontext bereitstellen, das gemeinsame Produktsystem nutzen, nach der Erkundung eine explizite Entscheidung treffen und die Browserbeweise überprüfen. Die gleichen drei menschlichen Kontrollpunkte – Problem, Richtung und Akzeptanz – prägen auch, wie wir Verwalten Sie KI-Agenten wie ein Team.
Dieser Arbeitsablauf entfernt Praxis im Design oder Design Thinking nicht. Er verschiebt sie zu den Teilen, in denen sie am wichtigsten sind: das Problem definieren, Einschränkungen festlegen, Richtungen vergleichen, Kompromisse wählen und das laufende Produkt beurteilen.
Wenn das Komponentensystem ausgereift ist, muss ich nicht mehr jede Funktion als ziehbare Blöcke in Figma neu erstellen. Ich kann direkt mit dem Agenten im Produkt arbeiten, während das Designsystem die Ausgabe konsistent hält und der Durchgang das Ergebnis ehrlich hält.
Häufige Fragen
Wie baut man einen Workflow für die Gestaltung von KI-Produkten auf?
Beginnen Sie mit dem bestehenden Produktsystem, nicht mit einer leeren Eingabe. Teilen Sie die Arbeit in Erkundung, Umsetzung und Überprüfung auf. Lassen Sie den Agenten Optionen generieren und wiederholbare Prüfungen durchführen, aber behalten Sie den Produktdesigner für das Problem, die gewählte Richtung und die endgültige Abnahme verantwortlich.
Können Produktdesigner ohne Figma arbeiten?
Ja, wenn das Produkt bereits stabile Komponenten, Seitenschablonen und Interaktionsmuster hat. Figma bleibt für eine neue visuelle Sprache oder eine unbekannte Interaktion nützlich. Es geht nicht darum, Figma zu verbieten; es geht darum, bekannte Produktentscheidungen auf einer zweiten Leinwand nicht neu zu erstellen.
Ersetzt KI Produktdesigner?
Nicht in diesem Arbeitsablauf. Der Agent stellt Optionen zusammen, bearbeitet Code und überprüft Szenarien. Der Designer hingegen definiert weiterhin das Problem, legt Einschränkungen fest, vergleicht Kompromisse, wählt die Richtung und entscheidet, ob das laufende Produkt gut genug ist, um es zu veröffentlichen.
