Productontwerp zonder Figma werkt als een product al een volwassen designsysteem heeft. Mijn AI-productontwerpworkflow gebruikt drie agentvaardigheden: ui-design verkent negen richtingen, ui-implement zet de gekozen richting om in het product en ui-walkthrough beoordeelt elke staat via de ingebouwde Agent Browser. Ik neem nog steeds de beslissingen; de agent verzorgt het repetitieve werk en de controles.
De meeste productfuncties beginnen niet vanaf een leeg canvas. Zodra een product enige tijd bestaat, zijn de basisontwerpbeslissingen al in code vastgelegd. Knoppen, invoervelden, kaarten, navigatie, spatiëring, kleuren, teksten, hovertoestanden en mobiel gedrag zijn allemaal gedefinieerd. Die onderdelen opnieuw opbouwen in Figma betekent vaak dezelfde componenten naar een ander canvas slepen om ze daarna opnieuw in het product te bouwen.
De ontwerper neemt nog steeds de productbeslissingen. De agent haalt veel van het repetitieve samenstellen en controleren weg. Dit werkt omdat Zero al een redelijk volwassen designsysteem heeft.
1. Start productontwerp zonder Figma met een designsysteem
Werken zonder Figma betekent niet werken zonder ontwerprichtlijnen. Het vereist juist duidelijkere regels.
Voor Zero kan de agent het volgende inspecteren:
- Bestaande componenten voor knoppen, invoervelden, dropdowns, kaarten, dialogen en navigatie
- Vastgestelde spatiëring, typografie, kleuren, randen en hoekradii
- Bestaande hover-, geselecteerde, uitgeschakelde, lege en mobiele toestanden
- Tekstconventies zoals zinshoofdletters en korte gebruikerslabels
- Echte schermen die tonen hoe deze onderdelen gecombineerd worden
Deze referenties beantwoorden gewone ontwerpvragen. Een nieuw invoerveld moet eruitzien als de invoervelden die al bestaan. Een nieuwe kaart moet hetzelfde oppervlak en dezelfde radius gebruiken als de meest vergelijkbare bestaande kaart. Een icon-knop moet dezelfde hoverfeedback hebben als andere icon-knoppen.
Dit geeft de agent een afbakening. Het kan de structuur van een functie verkennen zonder voor elk scherm een nieuwe visuele taal te verzinnen.
Figma blijft nuttig als een team een nieuw merk, een nieuw componentensysteem of een interactie zonder duidelijke productreferentie ontwikkelt. Maar zodra het systeem volwassen is, kan het draaiende product het belangrijkste ontwerpoppervlak worden. Dit is de feature-schaalversie van de design-as-code workflow die we gebruikten om Zero opnieuw te bouwen.
2. Gebruik ui-design om negen productontwerprichtingen te verkennen
Elke functie vereist nog steeds verkenning. Ik wil niet dat een agent mijn eerste zin pakt en direct omzet in code.
Ik begin met ui-design. Ik geef de agent het huidige scherm, het gebruikersprobleem, het doel en de belangrijkste beperkingen. De agent leest de bestaande productpatronen en geeft één aanbevolen richting plus negen alternatieven terug.
In gewone taal legt de vaardigheid het huidige scherm vast, creëert één aanbevolen richting, verkent negen verschillende alternatieven, presenteert de afwegingen en wacht op een menselijke keuze.
Het ontwerpdenken in deze instructie
Deze instructie is niet alleen een lijst met visuele regels. Het maakt van het normale proces van een ontwerper een herhaalbare volgorde:
- Begrijp voordat je voorstelt. Leg het huidige scherm vast en lees het omliggende product voordat je iets maakt.
- Denk in systemen. Gebruik bestaande componenten, sjabloonpagina's, interactiepatronen en tekstregels als uitgangspunt.
- Voorkom heruitvinding. AI neigt naar het creëren van een nieuw patroon als de prompt vaag is. De instructie zegt dat het het dichtstbijzijnde bestaande component of pagina moet vinden en hergebruiken in plaats van uit het geheugen te benaderen.
- Verken voordat je kiest. De After-variant geeft één plausibele richting. De negen varianten openen verschillende keuzes over lay-out, hiërarchie, dichtheid, instappunt en onthulling.
- Scheid verkenning van keuze. De agent stopt na het presenteren van opties. Een mens vergelijkt de afwegingen en kiest voordat er code wordt geschreven.
- Beoordeel de hele ervaring. Tekst, hoverfeedback, toestanden, mobiel gedrag en visuele consistentie zijn onderdeel van het ontwerp, niet van de afronding na implementatie.
Dat is het systeemdenken dat ik van de vaardigheid verwacht: begrijp het bestaande product, verken binnen die grenzen en maak dan een expliciete keuze.
Hier volgt de volledige originele instructie, letterlijk overgenomen uit de live workflow:
Volledige originele ui-design-instructie
# 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 negen opties hoeven geen negen uitgewerkte ontwerpen te zijn. Hun doel is mij voldoende variatie te geven om het probleem anders te zien en richting de juiste oplossing te bewegen. Als een concept buiten het huidige product valt, kan een losstaand React-prototype alsnog helpen. Voor deze functie bleef ik binnen het echte productsysteem.
Een echt voorbeeld: Zero's navigatie
Zero had oorspronkelijk één 300-pixel zijbalk met productbestemmingen, vastgezette agents en chatthreads. Die deed drie dingen tegelijk. Ik wilde die taken scheiden zonder het gespreksgebied te veranderen.
De productopdracht voor de verkenning was:
/ui-designSpeel de ontwerpfase voor Zero's drie-regio navigatie na vanaf de echte historische basis. Scheid productbestemmingen, agents en gesprekken in duidelijkere regio's zonder het gespreksgebied te wijzigen. Gebruik echte Zero-tokens, iconen en componenten. Lever een brongetrouwe Before, één sterke After en negen echt verschillende varianten. Bewerk geen productcode en presenteer geen mockup als browserverificatie.
De eerste verkenning was te voorzichtig. Verschillende opties veranderden breedtes en selectiestijlen, maar leken nog steeds op dezelfde zijbalk. Ik wees die set af en vroeg de agent om de verschillen zichtbaar te maken op het niveau van informatiearchitectuur.
De tweede run leverde negen echt verschillende richtingen op. Ik groepeerde ze in een 3 × 3-tabel zodat ze makkelijk te vergelijken zijn zonder van het artikel een lange beeldstrook te maken. Elke miniatuur opent in de afbeeldingsviewer van de blog.
| 1. Topnavigatie | 2. Inklapbare lade | 3. Thread eerst |
|---|---|---|
 |  |  |
| Zet bestemmingen boven het gesprek | Verberg bestemmingen tot ze nodig zijn | Maak gesprekken het hoofdonderdeel van de navigatie |
| 4. Agent eerst | 5. Gesprek eerst | 6. Command launcher |
 |  |  |
| Kies een agent vóór zijn threads | Zet vastgezette agents boven het actieve gesprek | Open bestemmingen via een doorzoekbaar menu |
| 7. Uitbreidbare rail | 8. Dashboard-entree | 9. Onderste dock |
 |  |  |
| Breid een smalle rail alleen uit als het nodig is | Start vanuit recent werk | Zet bestemmingen onderaan |
Ik koos geen van deze frames precies zoals getekend. Ik gebruikte ze om te bepalen wat moest blijven en wat moest veranderen. De uiteindelijke richting gebruikte een smalle bestemmingsrail, een aparte chatrail, vijf zichtbare vastgezette agents en het bestaande gespreksgebied.
Het belangrijkste resultaat van ui-design was niet alleen het beeld. Het was een kort beslissingsverslag:
- Behoud een 68-pixel bestemmingsrail en een 300-pixel chatrail
- Toon vijf vastgezette agent-slots
- Houd selectie rustig maar leesbaar
- Toon herordening alleen tijdens slepen
- Laat het gespreksgebied en de bestaande mobiele lade ongewijzigd
Dat was voldoende om met de implementatie te beginnen.
3. Gebruik ui-implement om het gekozen ontwerp om te zetten in code
Nadat ik een richting kies en de productcodebase verbind, werkt de agent direct in de code. Ik teken het gekozen frame niet eerst opnieuw in Figma.
In gewone taal slaat ui-implement de verkenning over omdat de richting al gekozen is. Het zoekt de meest vergelijkbare bestaande componenten en paginavorm, bouwt daarmee, controleert het resultaat en verifieert de functie in een browser.
Wat deze instructie beschermt
- De gekozen richting mag niet opnieuw ontworpen worden tijdens implementatie.
- De agent moet beginnen met het meest vergelijkbare bestaande component en sjabloonpagina.
- Hergebruik gaat boven een nieuw component, tenzij het product echt iets mist.
- De zelfcontrole en browsercheck vangen inconsistente tekst, toestanden en interacties.
- Als een productbeslissing nog niet is genomen, keert het werk terug naar
ui-design.
Zo blijft het designsysteem actief tijdens implementatie. Het is geen document dat de agent één keer leest. Het bepaalt welke componenten gekozen worden en hoe de ervaring wordt gecontroleerd.
Hier volgt de volledige originele instructie, letterlijk overgenomen uit de live workflow:
Volledige originele ui-implement-instructie
# 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.
Dit was de functie-specifieke implementatieprompt:
/ui-implementBegin vanaf revisie
04d642bb. Voeg een standaard-uit desktop-splitsing toe met een 68px bestemmingsrail, een 300px chatrail en het ongewijzigde gesprek. Behoud de oude 300px zijbalk als de schakelaar uit staat en op mobiel. Toon vijf vastgezette slots, behoud de door de gebruiker bepaalde volgorde en toon herordening alleen tijdens actief slepen. Inspecteer de historische functie of latere verfijningen niet tot de onafhankelijke patch, tests en browserverificatie zijn afgerond.
Voor de navigatiefunctie vroeg ik de agent om de oude zijbalk te behouden als de functie uit stond, de nieuwe driedelige lay-out te tonen als deze aan stond, de bestaande mobiele lade te behouden en gebruikers toe te staan vastgezette agents te herordenen.
Tijdens de implementatie ontdekte de agent een belangrijk punt. Het oude product onthield welke agents waren vastgezet, maar niet hun volgorde. Een sleepinteractie kon correct lijken, maar na een refresh weer resetten.
Dus de agent deed meer dan alleen de sleepstaat tekenen. Het liet de nieuwe volgorde bewaren, ververste de pagina en controleerde of de volgorde bleef. Ook werd bevestigd dat herordening alleen tijdens het slepen zichtbaar was en daarna verdween.
De implementatie leverde de twee desktoptoestanden die ik moest beoordelen. Ik toon ze op volledige breedte zodat de interface leesbaar blijft. Mobiel gedrag verschijnt later in de walkthrough als een compacte telefoonweergave.
Desktop rusttoestand
Actief herordenen
Op dit punt had ik een werkende functie, geen extra ontwerpbestand. Maar implementatie was nog niet het einde. Ik moest zien wat er daadwerkelijk draaide in de gedeployde preview.
4. Gebruik ui-walkthrough om het echte product te beoordelen
Productwalkthroughs waren vroeger tijdrovend. Ik opende een gedeployde preview, maakte het juiste account aan, schakelde functies aan en uit, klikte op elke controle, wijzigde de browsergrootte, maakte screenshots en probeerde te onthouden welke staat elk beeld toonde.
De agent heeft een ingebouwde Agent Browser, dus ik kan dat werk aan hem overlaten.
De workflow heeft twee hoofdonderdelen:
- Maak eerst de scenario's. De agent zet de ontwerp- en implementatieclaims om in een checklist.
- Voer de checklist uit en voeg bewijs toe. Het voert elk scenario uit in de gedeployde preview en geeft PASS, FAIL of BLOCKED terug met een screenshot van elke relevante staat.
Wat deze instructie verandert aan review
- De agent maakt de scenario's voordat hij begint te klikken.
- Het gebruikt het echte gedeployde component via de ingebouwde Agent Browser.
- Het legt één screenshot vast van elke relevante staat.
- Het markeert elk controlepunt als PASS, FAIL of BLOCKED.
- Het verbergt nooit een onbereikbare staat achter nep-bewijs.
Dit verandert handmatig klikken in een gestructureerd beoordelingspakket. Ik kan het bedoelde gedrag, het resultaat en het bewijs samen bekijken.
De volledige instructie staat hieronder. Ik heb de interne afhankelijkheidsnaam vertaald naar “ingebouwde Agent Browser” voor duidelijkheid; de workflowlogica is verder ongewijzigd.
Volledige originele ui-walkthrough-instructie
# 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.
Dit was de functie-specifieke walkthroughprompt:
/ui-walkthroughGebruik de gedeployde preview via de ingebouwde Agent Browser als enige browserwaarheid. Bewijs de functie-uit zijbalk, de 68px en 300px splitsing, bestemmingsvolgorde, hovertoestanden, vijf vastgezette slots, sleep-only handles, bewaarde herordening, threadselectie, scrollen en de volledige iPhone-lade. Geef PASS, FAIL of BLOCKED voor elk controlepunt. Vervang een onbereikbare staat niet door een replica.
Voor deze functie organiseerde de agent de walkthrough rond deze vragen:
- Werkt de oude zijbalk nog als de functie uit staat?
- Verschijnt de nieuwe desktopstructuur als deze aan staat?
- Zijn hover- en geselecteerde toestanden zichtbaar maar rustig?
- Zijn vijf vastgezette agents leesbaar?
- Blijven herordeningselementen verborgen tot een sleepactie start?
- Blijft de nieuwe volgorde behouden na een refresh?
- Kan ik echte threads selecteren en scrollen?
- Werkt de bestaande mobiele lade nog?
- Zijn alle navigatiebestemmingen aanwezig en in de juiste volgorde?
De agent opende vervolgens de gedeployde preview als nieuwe gebruiker, doorliep onboarding, schakelde de functie in en werkte de lijst af. Het testte de rusttoestand, hovertoestand, sleepstaat, refreshgedrag, threadselectie, scrollen en de telefoonlay-out.
Het resultaat was 11 PASS, 1 FAIL.
De mislukking was nuttig. De lay-out en interacties werkten, maar de gedeployde preview toonde slechts zes productbestemmingen. Activity en Insights ontbraken, en de volgorde kwam niet overeen met het gekozen ontwerp.
| Scenario | Resultaat |
|---|---|
| Oude zijbalk met de functie uit | PASS |
| Nieuwe driedelige desktoplay-out | PASS |
| Hover- en geselecteerde toestanden | PASS |
| Vijf vastgezette agents | PASS |
| Sleep-only herordening | PASS |
| Bewaarde volgorde na refresh | PASS |
| Threadselectie en scrollen | PASS |
| Bestaande mobiele lade | PASS |
| Bestemmingsinhoud en volgorde | FAIL |
De uiteindelijke oplevering was een georganiseerde screenshotset in plaats van een map met onbenoemde afbeeldingen. De desktopopnames zijn 1440 × 900 pixels en de telefoonopname is 1170 × 2532 pixels. Ze verschijnen één voor één hieronder zodat de interface leesbaar blijft; klik op een afbeelding om deze te vergroten zonder het artikel te verlaten.
Functie uitgeschakeld
Functie ingeschakeld
Desktoplay-out
Bestemming hover
Vastgezette-agent hover
Actief slepen
Bewaarde volgorde
Mobiele lade
Dit laat mij een functie gestructureerd beoordelen. Ik zie de bedoelde scenario's, het daadwerkelijke resultaat en het bewijs samen. Als iets faalt, weet ik precies waar het werk moet worden hervat.
Hoe een team deze AI-productontwerpworkflow adopteert
Het volledige proces is kort. Teamleden kunnen elke fase opslaan als een gedeelde Zero-workflow in plaats van het proces uit het hoofd te reconstrueren.
| Fase | Input | Output |
|---|---|---|
ui-design | Huidig scherm, probleem, doel en beperkingen | Eén aanbevolen richting, negen alternatieven en een gekozen ontwerpverslag |
ui-implement | Het gekozen ontwerpverslag | Een te beoordelen codewijziging en screenshots van de hoofdtoestanden |
ui-walkthrough | De gedeployde functie en het verwachte gedrag | Een georganiseerde scenariolijst met PASS-, FAIL- of BLOCKED-screenshots |
Een teamlid hoeft mijn ontwerpstijl niet te kopiëren. Ze moeten goede context geven, het gedeelde productsysteem gebruiken, na verkenning een expliciete keuze maken en het browserverificatiebewijs beoordelen. Dezelfde drie menselijke checkpoints—probleem, richting en acceptatie—bepalen ook hoe we AI-agents als een team beheren.
Deze workflow haalt ontwerppraktijk of -denken niet weg. Het verplaatst ze naar de onderdelen waar ze het meest van belang zijn: het probleem definiëren, beperkingen stellen, richtingen vergelijken, afwegingen maken en het draaiende product beoordelen.
Als het componentensysteem volwassen is, hoef ik niet langer elke functie als sleepbare blokken in Figma op te bouwen. Ik kan direct met de agent in het product werken, terwijl het designsysteem de output consistent houdt en de walkthrough het resultaat eerlijk houdt.
Veelgestelde vragen
Hoe bouw je een AI-productontwerpworkflow?
Begin met het bestaande productsysteem, niet met een leeg prompt. Splits het werk op in verkenning, implementatie en beoordeling. Laat de agent opties genereren en herhaalbare controles uitvoeren, maar houd de productontwerper verantwoordelijk voor het probleem, de gekozen richting en de uiteindelijke acceptatie.
Kunnen productontwerpers werken zonder Figma?
Ja, als het product al stabiele componenten, paginasjablonen en interactiepatronen heeft. Figma blijft nuttig voor een nieuwe visuele taal of een onbekende interactie. Het doel is niet om Figma te verbannen, maar om bekende productbeslissingen niet opnieuw op een tweede canvas te bouwen.
Vervangt AI productontwerpers?
Niet in deze workflow. De agent stelt opties samen, bewerkt code en controleert scenario's. De ontwerper kadert het probleem, stelt beperkingen, vergelijkt afwegingen, kiest de richting en beslist of het draaiende product goed genoeg is om te lanceren.
