Produktdesign uten Figma fungerer når et produkt allerede har et modent designsystem. Min AI-produktdesignarbeidsflyt bruker tre agentferdigheter: ui-design utforsker ni retninger, ui-implement gjør den valgte retningen om til produktet, og ui-walkthrough gjennomgår alle tilstander via den innebygde Agent Browser. Jeg tar fortsatt avgjørelsene; agenten håndterer det repeterende produksjons- og kontrollarbeidet.
De fleste produktegenskaper starter ikke fra blanke ark. Når et produkt har eksistert en stund, finnes de grunnleggende designbeslutningene allerede i koden. Knapper, inndatafelt, kort, navigasjon, avstand, farger, tekst, hover-tilstander og mobilatferd er allerede definert. Å bygge opp disse delene på nytt i Figma betyr ofte å dra de samme komponentene inn på et nytt lerret før de bygges opp igjen i produktet.
Designeren tar fortsatt produktbeslutningene. Agenten fjerner mye av det repeterende monterings- og kontrollarbeidet. Dette fungerer fordi Zero allerede har et rimelig modent designsystem.
1. Start produktdesign uten Figma med et designsystem
Å jobbe uten Figma betyr ikke å jobbe uten designregler. Det krever tydeligere regler.
For Zero kan agenten inspisere:
- Eksisterende komponenter for knapper, inndatafelt, nedtrekksmenyer, kort, dialoger og navigasjon
- Etablerte regler for avstand, typografi, farger, border og hjørneradius
- Eksisterende hover-, valgt-, deaktivert-, tom- og mobiltilstander
- Tekstkonvensjoner som setningsskrift og korte brukerrettede etiketter
- Faktiske skjermer som viser hvordan disse delene kombineres
Disse referansene besvarer vanlige designspørsmål. Et nytt inndatafelt bør se ut som de som allerede finnes. Et nytt kort bør bruke samme overflate og radius som det nærmeste eksisterende kortet. En ikonknapp bør ha samme hover-tilbakemelding som andre ikonknapper.
Dette gir agenten en ramme. Den kan utforske strukturen til en funksjon uten å finne opp et nytt visuelt språk for hver skjerm.
Figma er fortsatt nyttig når et team lager en ny merkevare, et nytt komponentbibliotek eller en interaksjon uten nær produktreferanse. Men når systemet er modent, kan det kjørende produktet bli hoveddesignoverflaten. Dette er funksjonsnivåversjonen av design-as-code-arbeidsflyten vi brukte for å bygge om Zero.
2. Bruk ui-design for å utforske ni produktdesignretninger
Hver funksjon trenger fortsatt utforskning. Jeg vil ikke at en agent skal ta min første setning og umiddelbart gjøre den om til kode.
Jeg starter med ui-design. Jeg gir agenten dagens skjerm, brukerproblemet, målet og hovedbegrensningene. Agenten leser eksisterende produktmønstre og returnerer én anbefalt retning pluss ni alternativer.
I klartekst fanger ferdigheten dagens skjerm, lager én anbefalt retning, utforsker ni distinkte alternativer, presenterer avveiningene og venter på et menneskelig valg.
Designtenkningen bak denne instruksjonen
Denne instruksjonen er ikke bare en liste med visuelle regler. Den gjør en designers normale prosess til en repeterbar sekvens:
- Forstå før du foreslår. Fang dagens skjerm og les det omkringliggende produktet før du lager noe.
- Tenk i systemer. Behandle eksisterende komponenter, mal-sider, interaksjonsmønstre og tekstregler som utgangspunkt.
- Forhindre nyoppfinnelse. AI har en tendens til å lage et nytt mønster når prompten er vag. Instruksjonen ber den finne nærmeste leverte komponent eller side og gjenbruke den i stedet for å gjette fra hukommelsen.
- Utforsk før du velger. After-ankeret gir én plausibel retning. De ni variantene åpner for ulike valg om layout, hierarki, tetthet, inngangspunkt og visning.
- Skille utforskning fra valg. Agenten stopper etter å ha presentert alternativer. Et menneske sammenligner avveiningene og velger før koding starter.
- Gjennomgå hele opplevelsen. Tekst, hover-tilbakemelding, tilstander, mobilatferd og visuell konsistens er del av designet, ikke opprydding etter implementering.
Dette er systemtenkningen jeg ønsker fra ferdigheten: forstå det eksisterende produktet, utforsk innenfor det, og ta deretter et eksplisitt valg.
Her er den komplette originale instruksjonen, gjengitt ordrett fra den levende arbeidsflyten:
Komplett original ui-design-instruksjon
# 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 alternativene trenger ikke være ni ferdige design. De skal gi meg nok spennvidde til å se problemet fra ulike vinkler og bevege meg mot riktig retning. Hvis et konsept ligger utenfor dagens produkt, kan en frittstående React-prototype fortsatt være nyttig. For denne funksjonen holdt jeg meg innenfor det faktiske produktsystemet.
Et ekte eksempel: Zeros navigasjon
Zero hadde opprinnelig én 300-piksel sidebar med produktmål, festede agenter og chat-tråder. Den gjorde tre jobber samtidig. Jeg ønsket å skille disse jobbene uten å endre samtaleområdet.
Produktbeskrivelsen for utforskningen var:
/ui-designGjenskap designfasen for Zeros tre-regioners navigasjon fra det faktiske historiske utgangspunktet. Skill produktmål, agenter og samtaler i tydeligere regioner uten å endre samtaleområdet. Bruk ekte Zero-tokens, ikoner og komponenter. Lag en kilde-tro Before, én sterk After og ni genuint ulike varianter. Ikke rediger produktkode eller presenter en mockup som nettleserbevis.
Den første utforskningen var for forsiktig. Flere alternativer endret bredder og valgstiler, men de så fortsatt ut som samme sidebar. Jeg avviste det settet og ba agenten gjøre forskjellene synlige på informasjonsarkitektur-nivå.
Andre kjøring returnerte ni genuint ulike retninger. Jeg grupperte dem i en 3 × 3-tabell slik at de er enkle å sammenligne uten å gjøre artikkelen til en lang bildestripe. Hvert miniatyrbilde åpnes i bloggens bildeviser.
| 1. Toppnavigasjon | 2. Sammenleggbar skuff | 3. Tråd først |
|---|---|---|
 |  |  |
| Flytt mål over samtalen | Skjul mål til de trengs | Gjør samtaler til hovednavigasjonsobjekt |
| 4. Agent først | 5. Samtale først | 6. Kommandostarter |
 |  |  |
| Velg en agent før dens tråder | Plasser festede agenter over aktiv samtale | Åpne mål fra en søkbar meny |
| 7. Utvidbar skinne | 8. Dashbordinngang | 9. Bunn-dokk |
 |  |  |
| Utvid en smal skinne kun ved behov | Start fra nylig arbeid | Flytt mål til bunnen |
Jeg valgte ikke én av disse rammene nøyaktig slik de var tegnet. Jeg brukte dem til å avgjøre hva som skulle beholdes og hva som skulle endres. Den endelige retningen brukte en smal målsøyle, en egen chat-skinne, fem synlige festede agenter og det eksisterende samtaleområdet.
Det viktige resultatet fra ui-design var ikke bare bildet. Det var en kort beslutningslogg:
- Behold en 68-piksel målsøyle og en 300-piksel chat-skinne
- Vis fem plasser for festede agenter
- Hold utvalg diskret men lesbart
- Vis omorganiseringsveiledning kun under dra
- Behold samtalen og eksisterende mobilskuff uendret
Det var nok til å starte implementeringen.
3. Bruk ui-implement for å gjøre valgt design om til kode
Etter at jeg har valgt en retning og koblet til produktkoden, jobber agenten direkte i koden. Jeg tegner ikke opp valgt ramme i Figma først.
I klartekst hopper ui-implement over utforskning fordi retningen allerede er valgt. Den finner nærmeste faktiske komponenter og sidestruktur, bygger med dem, gjennomgår resultatet og verifiserer funksjonen i en nettleser.
Hva denne instruksjonen beskytter
- Den valgte retningen skal ikke redesignes under implementering.
- Agenten må starte med nærmeste eksisterende komponent og mal-side.
- Gjenbruk vinner over ny komponent med mindre produktet har et reelt hull.
- Egenkontroll og nettlesersjekk fanger opp inkonsekvent tekst, tilstander og interaksjoner.
- Hvis en produktbeslutning fortsatt er uløst, går arbeidet tilbake til
ui-design.
Slik forblir designsystemet aktivt under implementering. Det er ikke et dokument agenten leser én gang. Det former hvilke komponenter den velger og hvordan den kontrollerer den ferdige opplevelsen.
Her er den komplette originale instruksjonen, gjengitt ordrett fra den levende arbeidsflyten:
Komplett original ui-implement-instruksjon
# 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 funksjonsspesifikk implementeringsprompt:
/ui-implementStart fra revisjon
04d642bb. Legg til en standard-av desktop-deling med en 68px målsøyle, en 300px chat-skinne og uendret samtale. Behold den gamle 300px sidebaren når bryteren er av og på mobil. Vis fem festede plasser, bevar brukerdefinert rekkefølge og vis omorganiseringshåndtak kun under aktiv dra. Ikke inspiser den historiske funksjonen eller senere forbedringer før den uavhengige patchen, testene og nettleserbeviset er frosset.
For navigasjonsfunksjonen ba jeg agenten beholde den gamle sidebaren når funksjonen var av, vise det nye tre-delte oppsettet når den var på, beholde eksisterende mobilskuff og la brukere omorganisere festede agenter.
Under implementeringen fant agenten ett viktig problem. Det gamle produktet husket hvilke agenter som var festet, men ikke rekkefølgen deres. En dra-interaksjon kunne se riktig ut, men tilbakestilles etter oppdatering.
Så agenten gjorde mer enn å tegne dra-tilstanden. Den fikk den nye rekkefølgen til å lagres, oppdaterte siden og kontrollerte at rekkefølgen ble bevart. Den bekreftet også at omorganiseringshåndtak kun dukket opp under dra og forsvant etterpå.
Implementeringsleveransen viste de to desktop-tilstandene jeg trengte å gjennomgå. Jeg viser dem i full bredde slik at grensesnittet forblir lesbart. Mobilatferd vises senere i gjennomgangen som et tett telefonbilde.
Desktop hvilende tilstand
Aktiv omorganisering
På dette tidspunktet hadde jeg en fungerende funksjon, ikke enda en designfil. Men implementeringen var fortsatt ikke slutten. Jeg måtte se hva som faktisk kjørte i den utplasserte forhåndsvisningen.
4. Bruk ui-walkthrough for å gjennomgå det faktiske produktet
Produktgjennomganger pleide å være tidkrevende. Jeg åpnet en utplassert forhåndsvisning, forberedte riktig konto, slo funksjoner av og på, klikket på alle kontroller, endret nettleserstørrelse, tok skjermbilder og prøvde å huske hvilken tilstand hvert bilde viste.
Agenten har en innebygd Agent Browser, så jeg kan overlate det arbeidet til den.
Arbeidsflyten har to hovedtrinn:
- List opp scenarioene først. Agenten gjør design- og implementeringskrav om til en sjekkliste.
- Kjør sjekklisten og legg ved bevis. Den utfører hvert scenario i den utplasserte forhåndsvisningen og returnerer PASS, FAIL eller BLOCKED med skjermbilde for hver meningsfull tilstand.
Hva denne instruksjonen endrer ved gjennomgang
- Agenten lister scenarioene før den begynner å klikke.
- Den bruker den faktiske utplasserte komponenten via sin innebygde Agent Browser.
- Den tar ett skjermbilde for hver meningsfulle tilstand.
- Den markerer hvert sjekkpunkt med PASS, FAIL eller BLOCKED.
- Den skjuler aldri en utilgjengelig tilstand bak falske bevis.
Dette gjør manuell klikking om til en organisert gjennomgangspakke. Jeg kan se den tiltenkte atferden, resultatet og bevisene samlet.
Full instruksjon er under. Jeg har oversatt det interne avhengighetsnavnet til «innebygd Agent Browser» for leserens klarhet; arbeidsflytlogikken er ellers uendret.
Komplett original ui-walkthrough-instruksjon
# 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 funksjonsspesifikk walkthrough-prompt:
/ui-walkthroughBruk den utplasserte forhåndsvisningen via den innebygde Agent Browser som eneste nettlesersannhet. Bevis funksjon-av sidebar, 68px og 300px deling, målrekkefølge, hover-tilstander, fem festede plasser, kun dra-håndtak, lagret omorganisering, trådvalg, rulling og full iPhone-skuff. Returner PASS, FAIL eller BLOCKED for hvert sjekkpunkt. Ikke erstatt en utilgjengelig tilstand med en kopi.
For denne funksjonen organiserte agenten gjennomgangen rundt disse spørsmålene:
- Fungerer den gamle sidebaren fortsatt når funksjonen er av?
- Vises den nye desktop-strukturen når den er på?
- Er hover- og valgt-tilstander synlige men diskrete?
- Er fem festede agenter lesbare?
- Forblir omorganiseringskontroller skjult til dra starter?
- Overlever den nye rekkefølgen en oppdatering?
- Kan jeg velge og rulle gjennom ekte tråder?
- Fungerer eksisterende mobilskuff fortsatt?
- Er alle navigasjonsmål til stede og i riktig rekkefølge?
Agenten åpnet deretter den utplasserte forhåndsvisningen som ny bruker, fullførte onboarding, aktiverte funksjonen og gikk gjennom listen. Den testet hvilende tilstand, hover-tilstand, dra-tilstand, oppdateringsatferd, trådvalg, rulling og telefonoppsett.
Resultatet var 11 PASS, 1 FAIL.
Feilen var nyttig. Oppsett og interaksjoner fungerte, men den utplasserte forhåndsvisningen viste bare seks produktmål. Activity og Insights manglet, og rekkefølgen stemte ikke med valgt design.
| Scenario | Resultat |
|---|---|
| Gammel sidebar med funksjonen av | PASS |
| Nytt tre-delt desktop-oppsett | PASS |
| Hover- og valgt-tilstander | PASS |
| Fem festede agenter | PASS |
| Kun dra-veiledning | PASS |
| Lagret rekkefølge etter oppdatering | PASS |
| Trådvalg og rulling | PASS |
| Eksisterende mobilskuff | PASS |
| Målinnhold og rekkefølge | FAIL |
Den endelige leveransen var et organisert skjermbildesett i stedet for en mappe med umerkede bilder. Desktop-bildene er 1440 × 900 piksler og telefonbildet er 1170 × 2532 piksler. De vises én om gangen under slik at grensesnittet forblir lesbart; klikk på et bilde for å forstørre det uten å forlate artikkelen.
Funksjon av
Funksjon aktivert
Desktop-oppsett
Mål-hover
Festet agent-hover
Aktiv dra
Lagret rekkefølge
Mobilskuff
Dette lar meg gjennomgå en funksjon på en strukturert måte. Jeg kan se de tiltenkte scenarioene, det faktiske utplasserte resultatet og bevisene samlet. Hvis noe feiler, vet jeg nøyaktig hvor arbeidet skal tilbake.
Hvordan et team tar i bruk denne AI-produktdesignarbeidsflyten
Hele prosessen er kort. Teammedlemmer kan lagre hvert trinn som en delt Zero-arbeidsflyt i stedet for å bygge opp prosessen fra hukommelsen.
| Fase | Inndata | Utdata |
|---|---|---|
ui-design | Nåværende skjerm, problem, mål og begrensninger | Én anbefalt retning, ni alternativer og en valgt designlogg |
ui-implement | Den valgte designloggen | En gjennomgåelig kodeendring og skjermbilder av hovedtilstandene |
ui-walkthrough | Den utplasserte funksjonen og forventet atferd | En organisert scenarioliste med PASS-, FAIL- eller BLOCKED-skjermbilder |
En kollega trenger ikke å gjenskape min designsmak. De må gi god kontekst, bruke det delte produktsystemet, ta et eksplisitt valg etter utforskning og gjennomgå nettleserbeviset. De samme tre menneskelige sjekkpunktene—problem, retning og aksept—former også hvordan vi styrer AI-agenter som et team.
Denne arbeidsflyten fjerner ikke designpraksis eller designtenkning. Den flytter dem til de delene hvor de betyr mest: å definere problemet, sette begrensninger, sammenligne retninger, velge avveininger og vurdere det kjørende produktet.
Når komponentbiblioteket er modent, trenger jeg ikke lenger å bygge opp hver funksjon som dra-og-slipp-blokker i Figma. Jeg kan jobbe med agenten direkte i produktet, mens designsystemet holder resultatet konsistent og gjennomgangen holder resultatet ærlig.
Ofte stilte spørsmål
Hvordan bygger du en AI-produktdesignarbeidsflyt?
Start med det eksisterende produktsystemet, ikke en blank prompt. Del arbeidet i utforskning, implementering og gjennomgang. La agenten generere alternativer og utføre repeterbare kontroller, men la produktdesigneren være ansvarlig for problemet, valgt retning og endelig aksept.
Kan produktdesignere jobbe uten Figma?
Ja, når produktet allerede har stabile komponenter, sidemaler og interaksjonsmønstre. Figma er fortsatt nyttig for et nytt visuelt språk eller en ukjent interaksjon. Poenget er ikke å forby Figma; det er å unngå å bygge opp kjente produktbeslutninger på et nytt lerret.
Erstatter AI produktdesignere?
Ikke i denne arbeidsflyten. Agenten setter sammen alternativer, redigerer kode og sjekker scenarioer. Designeren rammer fortsatt inn problemet, setter begrensninger, sammenligner avveininger, velger retning og avgjør om det kjørende produktet er godt nok til å lanseres.
