Produktdesign uden Figma fungerer, når et produkt allerede har et modent designsystem. Min AI-produktdesignworkflow bruger tre agentfærdigheder: ui-design udforsker ni retninger, ui-implement omsætter den valgte retning til produktet, og ui-walkthrough gennemgår alle tilstande via den indbyggede Agent Browser. Jeg træffer stadig beslutningerne; agenten håndterer det gentagne arbejde med produktion og kontrol.
De fleste produktegenskaber starter ikke fra bunden. Når et produkt har eksisteret et stykke tid, findes de grundlæggende designbeslutninger allerede i koden. Knapper, inputfelter, kort, navigation, afstande, farver, tekster, hover-tilstande og mobiladfærd er alt sammen defineret. At genopbygge disse elementer i Figma betyder ofte blot at trække de samme komponenter over på et andet lærred, før de igen bygges ind i produktet.
Designeren træffer stadig produktbeslutningerne. Agenten fjerner meget af det gentagne samlearbejde og kontrol. Det virker, fordi Zero allerede har et rimeligt modent designsystem.
1. Start produktdesign uden Figma med et designsystem
At arbejde uden Figma betyder ikke at arbejde uden designregler. Det kræver tydeligere regler.
For Zero kan agenten inspicere:
- Eksisterende komponenter til knapper, inputfelter, dropdowns, kort, dialoger og navigation
- Etablerede afstande, typografi, farver, kanter og hjørneradier
- Eksisterende hover-, valgt-, deaktiveret-, tom- og mobiltilstande
- Tekstkonventioner som sentence case og korte brugerrettede etiketter
- Rigtige skærmbilleder, der viser, hvordan disse elementer kombineres
Disse referencer besvarer almindelige designspørgsmål. Et nyt inputfelt skal ligne de inputfelter, der allerede findes. Et nyt kort skal bruge samme overflade og radius som det nærmeste eksisterende kort. En ikonknap skal have samme hover-feedback som andre ikonknapper.
Dette giver agenten en ramme. Den kan udforske strukturen af en funktion uden at opfinde et nyt visuelt sprog til hver skærm.
Figma er stadig nyttigt, når et team skaber et nyt brand, et nyt komponentbibliotek eller en interaktion uden tæt produktreference. Men når systemet er modent, kan det kørende produkt blive den primære designflade. Dette er funktionsniveau-versionen af design-as-code-workflowet, vi brugte til at genopbygge Zero.
2. Brug ui-design til at udforske ni produktdesignretninger
Hver funktion kræver stadig udforskning. Jeg ønsker ikke, at en agent tager min første sætning og straks omsætter den til kode.
Jeg starter med ui-design. Jeg giver agenten den aktuelle skærm, brugerproblemet, målet og de vigtigste begrænsninger. Agenten læser de eksisterende produktmønstre og returnerer én anbefalet retning plus ni alternativer.
Med almindeligt sprog indfanger færdigheden den aktuelle skærm, skaber én anbefalet retning, udforsker ni forskellige alternativer, præsenterer fordele og ulemper og afventer et menneskeligt valg.
Design-tænkningen bag denne instruktion
Denne instruktion er ikke bare en liste over visuelle regler. Den omsætter designerens normale proces til en gentagelig sekvens:
- Forstå før du foreslår. Indfang den aktuelle skærm og læs det omkringliggende produkt, før du laver noget.
- Tænk i systemer. Brug eksisterende komponenter, skabelonsider, interaktionsmønstre og tekstregler som udgangspunkt.
- Forebyg genopfindelse. AI har tendens til at skabe et nyt mønster, når prompten er vag. Instruktionen beder den finde den nærmeste eksisterende komponent eller side og genbruge den i stedet for at gætte fra hukommelsen.
- Udforsk før du vælger. After-ankeret giver én plausibel retning. De ni varianter åbner for forskellige beslutninger om layout, hierarki, tæthed, indgangspunkt og visning.
- Adskil udforskning fra valg. Agenten stopper efter at have præsenteret mulighederne. Et menneske sammenligner fordele og ulemper og vælger, før koden skrives.
- Gennemgå hele oplevelsen. Tekst, hover-feedback, tilstande, mobiladfærd og visuel konsistens er en del af designet, ikke oprydning efter implementering.
Det er den systemtænkning, jeg ønsker fra færdigheden: forstå det eksisterende produkt, udforsk inden for det, og træf derefter et eksplicit valg.
Her er den komplette originale instruktion, gengivet ordret fra den levende workflow:
Komplet original ui-design-instruktion
# vm0 / Zero UI Design Rules
## Workflow — visuals first, code later
**Do not jump to code.** When this skill is invoked, the first deliverable is always a set of rendered mockups for Ming to look at. Implementation happens only after a direction is chosen.
### Step 1 — Capture the "before"
- If a screen already exists, render its current state as the **before** image (screenshot the running app, or render the existing component as a static preview).
- If the request is for a brand-new screen, the "before" is either the closest existing screen or a blank state — make this explicit in the caption.
### Step 2 — Produce a single "after" anchor
- One mockup that represents your best-guess interpretation of the request, fully obeying every rule below (components, sentence case, agent-detail inputs/dropdowns, chat-composer card radii, add-schedule button, IconButton hovers, gray-50 surfaces).
- Pair it with the **before** side-by-side. Label them clearly: `Before` / `After`.
### Step 3 — Generate 9 variant explorations
After the before/after pair, produce **9 distinct variant mockups** for the same screen. Each variant should explore a meaningfully different design axis — not 9 color tweaks. Cover a spread such as:
1. Layout — single column vs. split / sidebar / grid
2. Density — compact vs. spacious
3. Hierarchy — which element leads visually
4. Surface treatment — flat vs. card-grouped vs. divided sections
5. Entry point — inline action vs. dedicated CTA vs. empty-state hero
6. Copy framing — instructive vs. minimal vs. conversational
7. Disclosure — everything visible vs. progressive reveal / accordions
8. Composition — content-led vs. control-led
9. A deliberately unconventional / "wild card" direction worth seeing once
Each variant must still respect the non-negotiables (sentence case, reuse components, agent-detail input/dropdown style, chat-composer radii, add-schedule button, IconButton hover, gray-50 neutrals). Variants explore *layout and emphasis*, not "what if we ignored the design system."
### Step 4 — Present, then wait
- Show all images to Ming in one message: the `Before / After` pair first, then the 9 variants numbered 1–9 with a one-line caption each describing the axis being explored.
- Ask which direction (or which mix) to pursue.
- Do not begin implementation until Ming picks a direction.
### Rendering the images
- Preferred path: build static HTML/React previews that use real Tailwind tokens from `turbo/apps/platform`, screenshot them, and upload via `okou web upload-file`.
- For quick exploration: the `v0` skill can generate variant mockups from a prompt — but the prompt must explicitly enumerate the rules below (sentence case, agent-detail inputs, chat-composer radius, etc.) so v0 doesn't produce generic SaaS UI.
- If image generation is unavailable for the session, fall back to clearly-labeled ASCII / textual wireframes for all 11 frames (before, after, 9 variants) and call this out — never silently skip the visuals step.
---
# Design Rules
These are the non-negotiable design conventions for any new UI shipped inside the vm0 platform (`turbo/apps/platform`). Apply them before writing components, and audit existing PRs against them during review.
## Core principles
1. **Reuse, don't reinvent.** Always check existing primitives in `turbo/apps/platform/src/components/` and view-level patterns under `src/views/` before introducing a new component. If a similar interaction already ships in agent detail, schedule, or chat composer, copy that pattern rather than designing a parallel one.
2. **Match the Zero design language.** Soft surfaces, neutral grays, generous radii, subtle borders, no harsh shadows. The visual baseline is "calm, opinionated, slightly editorial" — never SaaS-default.
3. **Speak from the user's seat.** Copy should describe what *they* are about to do or see, not what the system is doing. Keep it short — usually a single sentence, max two.
## Reference patterns (copy these directly)
| Element | Reference source | Why |
|---------------------|---------------------------------------------------|-----|
| Text / textarea input | Agent detail page input (`src/views/agent-detail/`) | Established padding, border, focus state, placeholder treatment |
| Dropdown / select | Agent detail page dropdown | Established trigger style, menu radius, item hover, check mark placement |
| Card / panel radius | Chat composer card (look for `composer` components) | Sets the canonical card radius and surface style across the app |
| Primary page button | "Add schedule" button on the schedule page | The neutral-dark primary used everywhere *outside* of modals |
| Modal primary button | The brand primary color (only inside dialogs/popovers) | Modals retain the brand-color primary; pages do not |
| Icon-only button | Existing IconButton with hover background | Every clickable icon must have a visible hover state |
When in doubt, open the reference component in the codebase, read its props and class names, and mirror them. Do not approximate from memory.
## Copy guidelines
- **User-perspective phrasing.** "Connect your inbox" beats "Inbox connection required". "No agents yet" beats "Agent list is empty".
- **Brevity over completeness.** A short line outperforms a complete sentence. Trim filler ("simply", "please", "in order to").
- **Sentence case for everything.** Labels, headings, buttons, menu items, table columns — all sentence case ("Model providers", "API keys", "Add schedule"). Never Title Case. Never `uppercase` via CSS on section headers. If you find a Title-Case or all-caps label, fix it.
- **No caption-case "decorative" labels** above fields or sections — they read as form-y and dated. Use a normal label or skip the label if the field is self-evident.
- **No trailing punctuation** on standalone labels or buttons. Periods are for body copy and helper text.
- When renaming a string, grep the codebase for the old string and tests for it — labels are referenced in tests and translations.
## Components and structure
- Always build pages out of existing components (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitives, etc.). New components are a last resort and require a reason.
- Look for an existing layout/template (settings page, list page, detail page) and inherit its scaffolding. Don't re-derive page structure.
- When adding to a settings-style page, match the section spacing, divider treatment, and form-row width used by neighboring sections.
## Buttons
- **Page primary** (the main CTA on a page) → match the "Add schedule" button on the schedule page. This is the neutral dark/solid primary used app-wide outside dialogs.
- **Modal primary** (the confirm button inside dialogs/popovers) → uses the brand primary color. Pages do not.
- **Secondary / ghost buttons** → reuse the existing variants; do not invent new ones.
- **Icon buttons** → must have a hover background (typically `hover:bg-gray-50` or the established IconButton hover token). Never ship a bare hoverless icon as a click target.
- All buttons should respect the existing height tokens — don't introduce one-off sizes.
## Inputs
- Mirror the agent detail input: same padding, same border, same focus ring (or lack thereof — check the reference before adding a focus ring), same placeholder color.
- Multi-line: use the agent detail textarea pattern (auto-grow or fixed rows as in reference).
- Don't put a colon at the end of field labels.
- Helper text below the input, in muted gray, single line.
## Dropdowns / selects
- Mirror the agent detail dropdown: same trigger appearance, same menu radius, same item padding, same hover/selected states.
- The menu should not be wider than its trigger unless the content demands it.
- Avoid nested submenus unless an existing dropdown already uses them.
## Cards and surfaces
- Card radius and surface style match the chat composer card. Do not introduce a smaller or larger radius without a reason.
- Borders are subtle (single hairline in the existing border token). No drop shadows unless the chat composer uses one.
- Neutral surfaces on mobile / light gray fills (active pill backgrounds, icon container fills, etc.) → `bg-gray-50`. `gray-100` and `gray-200` have repeatedly been called too dark — start at `gray-50`.
## Focus and interaction
- Don't add custom `:focus-visible` box-shadows or outlines to nav/marketing elements — reuse the hover color shift instead. (Same restraint generally applies inside the platform unless a reference component has an explicit focus ring.)
- Every interactive element (button, icon button, row, link) needs a visible hover state. Test by hovering each one before considering the design done.
- Disabled states use the existing disabled tokens; don't hand-roll a faded color.
## Review checklist
Before declaring a UI ready, walk through:
1. Did I reuse existing components instead of building new ones?
2. Did I match an existing page template / layout?
3. Are inputs visually identical to agent detail inputs?
4. Are dropdowns visually identical to agent detail dropdowns?
5. Do cards match the chat composer radius and surface?
6. Is every label sentence case? Any leftover Title Case or all-caps?
7. Is the copy short and written from the user's seat?
8. Is the page primary the "Add schedule"-style button? Is the brand primary used only inside modals?
9. Does every icon button have a hover background?
10. Did I hover every interactive element to confirm feedback?
If any answer is "no", fix it before opening the PR.
## When in doubt
- Open the reference component, read its source, and copy the structure.
- If two reference components disagree, prefer the more recently shipped one (check git log).
- If the design genuinely needs a new primitive, raise it with Ming before building it — bundled redesign work belongs in one PR with him as the reviewer.
De ni muligheder behøver ikke være ni færdige designs. Deres formål er at give mig nok variation til at se problemet fra nye vinkler og bevæge mig mod den rigtige retning. Hvis et koncept ligger uden for det nuværende produkt, kan en selvstændig React-prototype stadig hjælpe. For denne funktion blev jeg inden for det rigtige produktsystem.
Et rigtigt eksempel: Zeros navigation
Zero havde oprindeligt en 300-pixels sidebar med produktdestinationer, fastgjorte agenters og chattråde. Den udførte tre opgaver på én gang. Jeg ønskede at adskille disse opgaver uden at ændre samtaleområdet.
Produktbeskrivelsen for udforskningen var:
/ui-designGenskab designfasen for Zeros tre-regions navigation fra det reelle historiske udgangspunkt. Adskil produktdestinationer, agenter og samtaler i tydeligere områder uden at ændre samtaleområdet. Brug rigtige Zero-tokens, ikoner og komponenter. Lav en kilde-tro Before, én stærk After og ni reelt forskellige varianter. Rediger ikke produktkoden og præsenter ikke et mockup som browserbevis.
Den første udforskning var for forsigtig. Flere muligheder ændrede bredder og valgstile, men de lignede stadig den samme sidebar. Jeg afviste det sæt og bad agenten gøre forskellene synlige på informationsarkitektur-niveauet.
Anden kørsel returnerede ni reelt forskellige retninger. Jeg grupperede dem i en 3 × 3 tabel, så de er lette at sammenligne uden at gøre artiklen til en lang billedstribe. Hvert miniaturebillede åbner i bloggens billedfremviser.
| 1. Topnavigation | 2. Sammenklappelig skuffe | 3. Tråd først |
|---|---|---|
 |  |  |
| Flyt destinationer over samtalen | Skjul destinationer indtil de er nødvendige | Gør samtaler til hovednavigationsobjektet |
| 4. Agent først | 5. Samtale først | 6. Kommandostarter |
 |  |  |
| Vælg en agent før dens tråde | Placer fastgjorte agenter over den aktive samtale | Åbn destinationer fra en søgbar menu |
| 7. Udvidelig skinne | 8. Dashboard-indgang | 9. Bunddock |
 |  |  |
| Udvid en smal skinne kun når det er nødvendigt | Start fra nyligt arbejde | Flyt destinationer til bunden |
Jeg valgte ikke én af disse rammer præcis som tegnet. Jeg brugte dem til at beslutte, hvad der skulle bevares, og hvad der skulle ændres. Den endelige retning brugte en smal destinationsskinne, en separat chatskinne, fem synlige fastgjorte agenter og det eksisterende samtaleområde.
Det vigtige output fra ui-design var ikke kun billedet. Det var en kort beslutningslog:
- Behold en 68-pixels destinationsskinne og en 300-pixels chatskinne
- Vis fem fastgjorte agent-pladser
- Behold markering diskret men læsbar
- Vis omplaceringsvejledning kun under træk
- Behold samtalen og den eksisterende mobildrawer uændret
Det var nok til at begynde implementeringen.
3. Brug ui-implement til at omsætte det valgte design til kode
Når jeg har valgt en retning og forbundet produktets kodebase, arbejder agenten direkte i koden. Jeg tegner ikke den valgte ramme op i Figma først.
Med almindeligt sprog springer ui-implement udforskningen over, fordi retningen allerede er valgt. Den finder de nærmeste rigtige komponenter og sidestruktur, bygger med dem, gennemgår resultatet og verificerer funktionen i en browser.
Hvad denne instruktion beskytter
- Den valgte retning må ikke redesignes under implementeringen.
- Agenten skal starte med den nærmeste eksisterende komponent og skabelonside.
- Genbrug vinder over en ny komponent, medmindre produktet har et reelt hul.
- Selvkontrol og browsercheck fanger inkonsekvent tekst, tilstande og interaktioner.
- Hvis en produktbeslutning stadig er uafklaret, vender arbejdet tilbage til
ui-design.
Sådan forbliver designsystemet aktivt under implementeringen. Det er ikke et dokument, agenten læser én gang. Det former, hvilke komponenter den vælger, og hvordan den kontrollerer den færdige oplevelse.
Her er den komplette originale instruktion, gengivet ordret fra den levende workflow:
Komplet original ui-implement-instruktion
# vm0 / Zero UI Implementation Rules
## Workflow — implement directly
When this skill is invoked, **skip the mockup and variant exploration phase**. Start implementing in `turbo/apps/platform` immediately, applying every design rule below.
### Step 1 — Locate the reference components
Before writing a line, open the reference components you'll mirror:
- Input / textarea → `src/views/agent-detail/` input
- Dropdown / select → `src/views/agent-detail/` dropdown
- Card / panel radius → chat composer card
- Page primary button → "Add schedule" button on the schedule page
- Icon-only button → existing `IconButton` with hover background
Read their props and class names. Mirror them — do not approximate from memory.
### Step 2 — Find the closest existing page template
Open the nearest existing page of the same shape (settings, list, detail) and inherit its scaffolding: section spacing, divider treatment, form-row width. Don't re-derive page structure.
### Step 3 — Build, then self-audit
Implement the screen with existing primitives from `turbo/apps/platform/src/components/`. When you think it's done, walk the **Review checklist** at the bottom of this skill before reporting back. Fix every "no" answer before declaring the work complete.
### Step 4 — Verify in the browser
For any UI work, start the dev server and exercise the feature in a browser before reporting the task as done. Hover every interactive element, test the golden path and edge cases, and watch for regressions in neighboring screens. Type-check and tests verify code, not feature correctness — if you can't open the browser, say so explicitly.
### When to fall back to ui-design
If the request is open-ended ("design a settings page for X") with no chosen direction, stop and run the `ui-design` skill instead — the before/after + 9 variants exist for exactly that case. `ui-implement` is for when the direction is already decided.
---
# Design Rules
These are the non-negotiable design conventions for any new UI shipped inside the vm0 platform (`turbo/apps/platform`). Apply them while building, and audit your own diff against them before opening the PR.
## Core principles
1. **Reuse, don't reinvent.** Always check existing primitives in `turbo/apps/platform/src/components/` and view-level patterns under `src/views/` before introducing a new component. If a similar interaction already ships in agent detail, schedule, or chat composer, copy that pattern rather than designing a parallel one.
2. **Match the Zero design language.** Soft surfaces, neutral grays, generous radii, subtle borders, no harsh shadows. The visual baseline is "calm, opinionated, slightly editorial" — never SaaS-default.
3. **Speak from the user's seat.** Copy should describe what *they* are about to do or see, not what the system is doing. Keep it short — usually a single sentence, max two.
## Reference patterns (copy these directly)
| Element | Reference source | Why |
|---------------------|---------------------------------------------------|-----|
| Text / textarea input | Agent detail page input (`src/views/agent-detail/`) | Established padding, border, focus state, placeholder treatment |
| Dropdown / select | Agent detail page dropdown | Established trigger style, menu radius, item hover, check mark placement |
| Card / panel radius | Chat composer card (look for `composer` components) | Sets the canonical card radius and surface style across the app |
| Primary page button | "Add schedule" button on the schedule page | The neutral-dark primary used everywhere *outside* of modals |
| Modal primary button | The brand primary color (only inside dialogs/popovers) | Modals retain the brand-color primary; pages do not |
| Icon-only button | Existing IconButton with hover background | Every clickable icon must have a visible hover state |
When in doubt, open the reference component in the codebase, read its props and class names, and mirror them. Do not approximate from memory.
## Copy guidelines
- **User-perspective phrasing.** "Connect your inbox" beats "Inbox connection required". "No agents yet" beats "Agent list is empty".
- **Brevity over completeness.** A short line outperforms a complete sentence. Trim filler ("simply", "please", "in order to").
- **Sentence case for everything.** Labels, headings, buttons, menu items, table columns — all sentence case ("Model providers", "API keys", "Add schedule"). Never Title Case. Never `uppercase` via CSS on section headers. If you find a Title-Case or all-caps label, fix it.
- **No caption-case "decorative" labels** above fields or sections — they read as form-y and dated. Use a normal label or skip the label if the field is self-evident.
- **No trailing punctuation** on standalone labels or buttons. Periods are for body copy and helper text.
- When renaming a string, grep the codebase for the old string and tests for it — labels are referenced in tests and translations.
## Components and structure
- Always build pages out of existing components (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitives, etc.). New components are a last resort and require a reason.
- Look for an existing layout/template (settings page, list page, detail page) and inherit its scaffolding. Don't re-derive page structure.
- When adding to a settings-style page, match the section spacing, divider treatment, and form-row width used by neighboring sections.
## Buttons
- **Page primary** (the main CTA on a page) → match the "Add schedule" button on the schedule page. This is the neutral dark/solid primary used app-wide outside dialogs.
- **Modal primary** (the confirm button inside dialogs/popovers) → uses the brand primary color. Pages do not.
- **Secondary / ghost buttons** → reuse the existing variants; do not invent new ones.
- **Icon buttons** → must have a hover background (typically `hover:bg-gray-50` or the established IconButton hover token). Never ship a bare hoverless icon as a click target.
- All buttons should respect the existing height tokens — don't introduce one-off sizes.
## Inputs
- Mirror the agent detail input: same padding, same border, same focus ring (or lack thereof — check the reference before adding a focus ring), same placeholder color.
- Multi-line: use the agent detail textarea pattern (auto-grow or fixed rows as in reference).
- Don't put a colon at the end of field labels.
- Helper text below the input, in muted gray, single line.
## Dropdowns / selects
- Mirror the agent detail dropdown: same trigger appearance, same menu radius, same item padding, same hover/selected states.
- The menu should not be wider than its trigger unless the content demands it.
- Avoid nested submenus unless an existing dropdown already uses them.
## Cards and surfaces
- Card radius and surface style match the chat composer card. Do not introduce a smaller or larger radius without a reason.
- Borders are subtle (single hairline in the existing border token). No drop shadows unless the chat composer uses one.
- Neutral surfaces on mobile / light gray fills (active pill backgrounds, icon container fills, etc.) → `bg-gray-50`. `gray-100` and `gray-200` have repeatedly been called too dark — start at `gray-50`.
## Focus and interaction
- Don't add custom `:focus-visible` box-shadows or outlines to nav/marketing elements — reuse the hover color shift instead. (Same restraint generally applies inside the platform unless a reference component has an explicit focus ring.)
- Every interactive element (button, icon button, row, link) needs a visible hover state. Test by hovering each one before considering the design done.
- Disabled states use the existing disabled tokens; don't hand-roll a faded color.
## Review checklist
Before declaring a UI ready, walk through:
1. Did I reuse existing components instead of building new ones?
2. Did I match an existing page template / layout?
3. Are inputs visually identical to agent detail inputs?
4. Are dropdowns visually identical to agent detail dropdowns?
5. Do cards match the chat composer radius and surface?
6. Is every label sentence case? Any leftover Title Case or all-caps?
7. Is the copy short and written from the user's seat?
8. Is the page primary the "Add schedule"-style button? Is the brand primary used only inside modals?
9. Does every icon button have a hover background?
10. Did I hover every interactive element in a browser to confirm feedback?
If any answer is "no", fix it before opening the PR.
## When in doubt
- Open the reference component, read its source, and copy the structure.
- If two reference components disagree, prefer the more recently shipped one (check git log).
- If the design genuinely needs a new primitive, raise it with Ming before building it — bundled redesign work belongs in one PR with him as the reviewer.
Dette var den funktionsspecifikke implementeringsprompt:
/ui-implementStart fra revision
04d642bb. Tilføj et standard-slukket desktop-split med en 68px destinationsskinne, en 300px chatskinne og den uændrede samtale. Behold den gamle 300px sidebar, når skiftet er slukket og på mobil. Vis fem fastgjorte pladser, bevar brugerdefineret rækkefølge og vis omplaceringshåndtag kun under aktiv træk. Inspicer ikke den historiske funktion eller senere forbedringer, før den uafhængige patch, tests og browserbevis er fastfrosset.
For navigationsfunktionen bad jeg agenten om at beholde den gamle sidebar, når funktionen var slukket, vise det nye tre-delte layout, når det var tændt, beholde den eksisterende mobildrawer og lade brugerne omplacere fastgjorte agenter.
Under implementeringen fandt agenten et vigtigt problem. Det gamle produkt huskede, hvilke agenter der var fastgjort, men ikke deres rækkefølge. En træk-interaktion kunne se korrekt ud og så nulstille efter en opdatering.
Så agenten gjorde mere end at tegne træktilstanden. Den fik den nye rækkefølge til at blive gemt, opdaterede siden og kontrollerede, at rækkefølgen blev bevaret. Den bekræftede også, at omplaceringshåndtag kun dukkede op under træk og forsvandt bagefter.
Implementeringsleverancen viste de to desktop-tilstande, jeg skulle gennemgå. Jeg viser dem i fuld bredde, så grænsefladen forbliver læsbar. Mobiladfærd vises senere i gennemgangen som et tæt telefonskærmbillede.
Desktop hvilende tilstand
Aktiv omplacering
På dette tidspunkt havde jeg en fungerende funktion, ikke endnu en designfil. Men implementeringen var stadig ikke slutningen. Jeg havde brug for at se, hvad der faktisk kørte i den udrullede forhåndsvisning.
4. Brug ui-walkthrough til at gennemgå det rigtige produkt
Produktgennemgange plejede at være tidskrævende. Jeg åbnede en udrullet forhåndsvisning, forberedte den rigtige konto, tændte og slukkede funktioner, klikkede på alle kontroller, ændrede browserstørrelse, tog skærmbilleder og prøvede at huske, hvilken tilstand hvert billede viste.
Agenten har en indbygget Agent Browser, så jeg kan overlade det arbejde til den.
Workflowen har to hovedtrin:
- List scenarierne først. Agenten omsætter design- og implementeringskrav til en tjekliste.
- Gennemfør tjeklisten og vedlæg bevis. Den udfører hvert scenarie i den udrullede forhåndsvisning og returnerer PASS, FAIL eller BLOCKED med et skærmbillede for hver meningsfuld tilstand.
Hvad denne instruktion ændrer ved gennemgang
- Agenten lister scenarierne, før den begynder at klikke.
- Den bruger den rigtige udrullede komponent via sin indbyggede Agent Browser.
- Den tager ét skærmbillede for hver meningsfuld tilstand.
- Den markerer hvert checkpoint som PASS, FAIL eller BLOCKED.
- Den skjuler aldrig en utilgængelig tilstand bag falske beviser.
Dette forvandler manuel klikning til en organiseret gennemgangspakke. Jeg kan se den tilsigtede adfærd, resultatet og beviserne samlet.
Den fulde instruktion er nedenfor. Jeg har oversat det interne afhængighedsnavn til “indbygget Agent Browser” for læserens klarhed; workflow-logikken er ellers uændret.
Komplet original ui-walkthrough-instruktion
# UI Walkthrough
End-to-end visual QA of a vm0/Zero front-end feature in its real per-PR preview. This workflow defines what to verify and how to report the result; it does not define UI-operation tooling.
## Required dependency: built-in Agent Browser
Use the built-in Agent Browser as the single source of truth for every UI interaction, including:
- Discovering and opening the per-PR preview.
- Preview-protection handling and session setup.
- Sign-up, OTP, onboarding, Stripe test checkout, and reaching the live app.
- Enabling feature switches.
- Navigating, interacting with controls, supplying test or mock data, capturing screenshots, uploading artifacts, troubleshooting, and cleanup.
Read and follow the current built-in Agent Browser instructions before taking any UI action. Do not duplicate runtime-specific commands, engine setup, selector mechanics, page-context scripts, session management, or process-cleanup methods in this workflow. If the built-in Agent Browser changes, its current instructions take precedence.
## When to use
- Walk through the UI of a vm0 pull request in its deployed preview.
- Verify an in-app feature that requires authentication, onboarding, billing, feature switches, or a real chat thread.
- Capture faithful screenshots or a short walkthrough video of the feature working in the live application.
## Walkthrough workflow
### 1. Establish the target and scope
- Identify the PR, head commit, changed user-visible behavior, and expected preview.
- Confirm that the deployed preview corresponds to the PR head before testing.
- Read the PR diff and description to derive the critical path and the states that demonstrate the change.
- Do not fix code, resolve conflicts, or change product behavior during a walkthrough unless the user separately requests implementation.
### 2. Reach the feature
Use the built-in Agent Browser to enter the preview and reach the live feature state. Follow its current rules for authentication, onboarding, billing, feature switches, and preview-only bypasses.
If a bypass is used, disclose it in the final report. Never use an onboarding bypass when onboarding itself is under test.
### 3. Define the visual state matrix
Before interacting, list the smallest set of states that proves the feature works. Include the applicable items:
- Initial/default state.
- Open, hover, focus, selected, expanded, or active state.
- Empty and populated states.
- Enabled and disabled states.
- Success, validation, loading, and error states.
- Placement, collision, flip, clipping, and responsive behavior.
- Submission or downstream action when the feature is interactive.
Prefer exercising the actual changed behavior over a generic smoke test.
### 4. Drive the live component
Use the built-in Agent Browser for all interaction and test-data techniques.
Mock or injected content may be used only to place a real application component into a deterministic visual state. The component, styling, and interaction being assessed must remain the live implementation from the PR preview.
For every mocked state:
- Record which content or prerequisite was mocked.
- Distinguish mocked content from real application behavior.
- Never imply that mocked text or data came from a model or production source.
- Exercise the real controls and downstream wiring wherever the environment permits.
### 5. Capture evidence
Use the built-in Agent Browser to capture and upload evidence for the key checkpoints. Each image should prove one meaningful state rather than repeat the same view.
If the user asks for a video, assemble a short captioned walkthrough from the verified checkpoints. Captions should identify the user action and expected result without obscuring the UI.
### 6. Deliver and report
Report:
- PR link, exact preview URL, and tested commit when available.
- Exact user flow exercised.
- Test account when one was created.
- `PASS`, `FAIL`, or `BLOCKED` for each checkpoint.
- Screenshot links and an optional video link with short descriptions.
- Feature switches, bypasses, mock data, and other test-only setup used.
- Failed checks, environment blockers, or verification gaps.
Do not claim the feature is verified unless the live preview flow was exercised and evidence was captured. If the preview is unavailable, report `BLOCKED` with the deployment evidence rather than substituting a local or static replica.
Dette var den funktionsspecifikke walkthrough-prompt:
/ui-walkthroughBrug den udrullede forhåndsvisning via den indbyggede Agent Browser som eneste browser-sandhed. Bevis sidebar med funktionen slukket, 68px og 300px split, destinationsrækkefølge, hover-tilstande, fem fastgjorte pladser, kun træk-håndtag, gemt omplacering, trådvalg, scrolling og fuld iPhone-drawer. Returner PASS, FAIL eller BLOCKED for hvert checkpoint. Erstat ikke en utilgængelig tilstand med en kopi.
For denne funktion organiserede agenten gennemgangen omkring disse spørgsmål:
- Fungerer den gamle sidebar stadig, når funktionen er slukket?
- Vises den nye desktop-struktur, når den er tændt?
- Er hover- og valgt-tilstande synlige men diskrete?
- Er fem fastgjorte agenter læsbare?
- Forbliver omplaceringskontroller skjult, indtil et træk starter?
- Overlever den nye rækkefølge en opdatering?
- Kan jeg vælge og scrolle gennem rigtige tråde?
- Fungerer den eksisterende mobildrawer stadig?
- Er alle navigationsdestinationer til stede og i den rigtige rækkefølge?
Agenten åbnede derefter den udrullede forhåndsvisning som ny bruger, gennemførte onboarding, aktiverede funktionen og gennemgik listen. Den testede hvilende tilstand, hover-tilstand, træk-tilstand, opdateringsadfærd, trådvalg, scrolling og telefonlayoutet.
Resultatet var 11 PASS, 1 FAIL.
Fejlen var nyttig. Layoutet og interaktionerne virkede, men den udrullede forhåndsvisning viste kun seks produktdestinationer. Activity og Insights manglede, og rækkefølgen matchede ikke det valgte design.
| Scenarie | Resultat |
|---|---|
| Gammel sidebar med funktionen slukket | PASS |
| Nyt tredelt desktop-layout | PASS |
| Hover- og valgt-tilstande | PASS |
| Fem fastgjorte agenter | PASS |
| Kun træk-omplaceringsvejledning | PASS |
| Gemt rækkefølge efter opdatering | PASS |
| Trådvalg og scrolling | PASS |
| Eksisterende mobildrawer | PASS |
| Destinationsindhold og rækkefølge | FAIL |
Den endelige levering var et organiseret sæt skærmbilleder i stedet for en mappe med ubenævnte billeder. Desktop-billederne er 1440 × 900 pixels og telefonbilledet er 1170 × 2532 pixels. De vises én ad gangen nedenfor, så grænsefladen forbliver læsbar; klik på et billede for at forstørre det uden at forlade artiklen.
Funktion slukket
Funktion aktiveret
Desktop-layout
Destination hover
Fastgjort agent hover
Aktivt træk
Gemt rækkefølge
Mobildrawer
Dette lader mig gennemgå en funktion på en struktureret måde. Jeg kan se de tilsigtede scenarier, det faktiske udrullede resultat og beviserne samlet. Hvis noget fejler, ved jeg præcis, hvor arbejdet skal tilbage.
Sådan tager et team denne AI-produktdesignworkflow i brug
Hele processen er kort. Teammedlemmer kan gemme hvert trin som en delt Zero-workflow i stedet for at genopbygge processen fra hukommelsen.
| Trin | Input | Output |
|---|---|---|
ui-design | Aktuel skærm, problem, mål og begrænsninger | Én anbefalet retning, ni alternativer og en valgt designlog |
ui-implement | Den valgte designlog | En gennemgåelig kodeændring og skærmbilleder af hovedtilstandene |
ui-walkthrough | Den udrullede funktion og dens forventede adfærd | En organiseret scenarieliste med PASS, FAIL eller BLOCKED skærmbilleder |
En kollega behøver ikke at gengive min designstil. De skal give god kontekst, bruge det delte produktsystem, træffe et eksplicit valg efter udforskning og gennemgå browserbeviset. De samme tre menneskelige checkpoints—problem, retning og accept—former også, hvordan vi styrer AI-agenter som et team.
Denne workflow fjerner ikke designpraksis eller design-tænkning. Den flytter dem til de dele, hvor de betyder mest: at definere problemet, sætte begrænsninger, sammenligne retninger, vælge kompromiser og vurdere det kørende produkt.
Når komponentbiblioteket er modent, behøver jeg ikke længere genopbygge hver funktion som trækbare blokke i Figma. Jeg kan arbejde med agenten direkte i produktet, mens designsystemet holder output konsistent og gennemgangen holder resultatet ærligt.
Ofte stillede spørgsmål
Hvordan bygger du en AI-produktdesignworkflow?
Start med det eksisterende produktsystem, ikke en tom prompt. Opdel arbejdet i udforskning, implementering og gennemgang. Lad agenten generere muligheder og udføre gentagelige kontroller, men lad produktdesigneren være ansvarlig for problemet, den valgte retning og endelig accept.
Kan produktdesignere arbejde uden Figma?
Ja, når produktet allerede har stabile komponenter, sideskabeloner og interaktionsmønstre. Figma er stadig nyttigt til et nyt visuelt sprog eller en ukendt interaktion. Pointen er ikke at forbyde Figma; det er at undgå at genopbygge kendte produktbeslutninger på et andet lærred.
Erstatter AI produktdesignere?
Ikke i denne workflow. Agenten samler muligheder, redigerer kode og kontrollerer scenarier. Designeren definerer stadig problemet, sætter begrænsninger, sammenligner kompromiser, vælger retningen og beslutter, om det kørende produkt er godt nok til at blive lanceret.
