Produktdesign utan Figma fungerar när en produkt redan har ett moget designsystem. Mitt AI-produktdesignarbetsflöde använder tre agentfärdigheter: ui-design utforskar nio riktningar, ui-implement omvandlar den valda riktningen till produkten och ui-walkthrough granskar varje tillstånd via den inbyggda Agent Browser. Jag fattar fortfarande besluten; agenten hanterar det repetitiva produktions- och kontrollarbetet.
De flesta produktfunktioner börjar inte från ett tomt blad. När en produkt har funnits ett tag finns dess grundläggande designbeslut redan i koden. Knappar, inmatningsfält, kort, navigation, avstånd, färger, texter, hovringstillstånd och mobilbeteende är redan definierade. Att återskapa dessa delar i Figma innebär ofta att dra samma komponenter till en annan arbetsyta innan de byggs om igen i produkten.
Designern fattar fortfarande produktbesluten. Agenten tar bort mycket av det repetitiva monterings- och kontrollarbetet. Detta fungerar eftersom Zero redan har ett relativt moget designsystem.
1. Starta produktdesign utan Figma med ett designsystem
Att arbeta utan Figma betyder inte att arbeta utan designregler. Det kräver tydligare regler.
För Zero kan agenten inspektera:
- Befintliga komponenter för knappar, inmatningsfält, dropdowns, kort, dialoger och navigation
- Etablerade avstånd, typografi, färger, ramar och hörnradier
- Befintliga tillstånd för hovring, markerad, inaktiverad, tom och mobil
- Textkonventioner som meningstor bokstav och korta användarvänliga etiketter
- Riktiga skärmar som visar hur dessa delar kombineras
Dessa referenser besvarar vanliga designfrågor. Ett nytt inmatningsfält ska se ut som de som redan finns. Ett nytt kort ska använda samma yta och radie som det närmaste befintliga kortet. En ikonknapp ska ha samma hovringsfeedback som andra ikonknappar.
Detta ger agenten en gräns. Den kan utforska strukturen för en funktion utan att uppfinna ett nytt visuellt språk för varje skärm.
Figma är fortfarande användbart när ett team skapar ett nytt varumärke, ett nytt komponentbibliotek eller en interaktion som saknar nära produktreferens. Men när systemet är moget kan den körande produkten bli den huvudsakliga designytan. Detta är funktionsnivåversionen av design-as-code-arbetsflödet vi använde för att bygga om Zero.
2. Använd ui-design för att utforska nio produktdesignriktningar
Varje funktion behöver fortfarande utforskas. Jag vill inte att en agent tar min första mening och omedelbart omvandlar den till kod.
Jag börjar med ui-design. Jag ger agenten den aktuella skärmen, användarproblemet, målet och de viktigaste begränsningarna. Agenten läser de befintliga produktmönstren och returnerar en rekommenderad riktning plus nio alternativ.
Med enkel beskrivning fångar färdigheten den aktuella skärmen, skapar en rekommenderad riktning, utforskar nio distinkta alternativ, presenterar avvägningarna och väntar på ett mänskligt val.
Designprocessen bakom denna instruktion
Denna instruktion är inte bara en lista med visuella regler. Den omvandlar en designers normala process till en upprepningsbar sekvens:
- Förstå innan du föreslår. Fånga den aktuella skärmen och läs av den omgivande produkten innan något skapas.
- Tänk i system. Behandla befintliga komponenter, mallar, interaktionsmönster och textregler som utgångsmaterial.
- Förhindra återuppfinning. AI tenderar att skapa ett nytt mönster när prompten är vag. Instruktionen säger att den ska hitta den närmaste levererade komponenten eller sidan och återanvända den istället för att approximera från minnet.
- Utforska innan du väljer. After-ankaret ger en rimlig riktning. De nio varianterna öppnar olika beslut om layout, hierarki, täthet, ingångspunkt och informationsavslöjande.
- Separera utforskning från åtagande. Agenten stannar efter att ha presenterat alternativen. En människa jämför avvägningarna och väljer innan kodningen börjar.
- Granska hela upplevelsen. Text, hovringsfeedback, tillstånd, mobilbeteende och visuell konsekvens är en del av designen, inte efterarbete efter implementation.
Det är det systemtänk jag vill ha från färdigheten: förstå den befintliga produkten, utforska inom den och gör sedan ett tydligt val.
Här är den kompletta ursprungliga instruktionen, återgiven ordagrant från det levande arbetsflödet:
Komplett ursprunglig 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 nio alternativen behöver inte vara nio färdiga designer. Deras syfte är att ge mig tillräckligt med variation för att se problemet ur olika vinklar och röra mig mot rätt riktning. Om ett koncept ligger utanför den nuvarande produkten kan en fristående React-prototyp ändå vara till hjälp. För denna funktion höll jag mig inom det verkliga produktsystemet.
Ett verkligt exempel: Zeros navigation
Zero hade ursprungligen en 300-pixels sidopanel som innehöll produktmål, fästa agenter och chattrådar. Den gjorde tre jobb samtidigt. Jag ville separera dessa jobb utan att ändra konversationsytan.
Produktbeskrivningen för utforskningen var:
/ui-designÅterskapa designfasen för Zeros tre-regionsnavigation från den verkliga historiska grunden. Separera produktmål, agenter och konversationer i tydligare regioner utan att ändra konversationsytan. Använd riktiga Zero-tokens, ikoner och komponenter. Skapa en källtro Before, en stark After och nio genuint olika varianter. Redigera inte produktkoden eller presentera en mockup som webbläsarbevis.
Den första utforskningen var för försiktig. Flera alternativ ändrade bredd och markeringsstilar, men de såg fortfarande ut som samma sidopanel. Jag avvisade det setet och bad agenten göra skillnaderna synliga på informationsarkitekturnivå.
Den andra körningen gav nio genuint olika riktningar. Jag grupperade dem i en 3 × 3-tabell så att de är lätta att jämföra utan att artikeln blir en lång bildremsa. Varje miniatyr öppnas i bloggens bildvisare.
| 1. Toppnavigation | 2. Fällbar låda | 3. Tråd först |
|---|---|---|
 |  |  |
| Flytta mål ovanför konversationen | Dölj mål tills de behövs | Gör konversationer till huvudnavigationsobjekt |
| 4. Agent först | 5. Konversation först | 6. Kommandostartare |
 |  |  |
| Välj en agent före dess trådar | Placera fästa agenter ovanför aktiv konversation | Öppna mål från en sökbar meny |
| 7. Expanderbar räls | 8. Dashboard-ingång | 9. Nedre docka |
 |  |  |
| Expandera en smal räls endast vid behov | Starta från senaste arbete | Flytta mål till botten |
Jag valde inte exakt någon av dessa ramar som de var ritade. Jag använde dem för att avgöra vad som skulle vara kvar och vad som skulle ändras. Den slutliga riktningen använde en smal destinationsräls, en separat chatträls, fem synliga fästa agenter och den befintliga konversationsytan.
Den viktiga utgången från ui-design var inte bara bilden. Det var en kort beslutslogg:
- Behåll en 68-pixels destinationsräls och en 300-pixels chatträls
- Visa fem fästa agent-platser
- Behåll urvalet diskret men läsbart
- Visa omordningsvägledning endast vid dragning
- Behåll konversationen och den befintliga mobila lådan oförändrade
Det räckte för att börja implementeringen.
3. Använd ui-implement för att omvandla vald design till kod
När jag har valt en riktning och kopplat produktkodbasen arbetar agenten direkt i koden. Jag ritar inte om den valda ramen i Figma först.
Enkelt uttryckt hoppar ui-implement över utforskningen eftersom riktningen redan är vald. Den hittar de närmaste riktiga komponenterna och sidstrukturen, bygger med dem, granskar resultatet och verifierar funktionen i en webbläsare.
Vad denna instruktion skyddar
- Den valda riktningen ska inte omdesignas under implementationen.
- Agenten måste börja med den närmaste befintliga komponenten och mallsidan.
- Återanvändning går före ny komponent om inte produkten har en verklig lucka.
- Självgranskning och webbläsarkontroll fångar inkonsekvent text, tillstånd och interaktioner.
- Om ett produktbeslut fortfarande är olöst återgår arbetet till
ui-design.
Så här hålls designsystemet aktivt under implementationen. Det är inte ett dokument agenten läser en gång. Det styr vilka komponenter som väljs och hur den granskar den färdiga upplevelsen.
Här är den kompletta ursprungliga instruktionen, återgiven ordagrant från det levande arbetsflödet:
Komplett ursprunglig 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.
Detta var den funktionsspecifika implementeringsprompten:
/ui-implementBörja från revision
04d642bb. Lägg till en standard-av desktopdelning med en 68px destinationsräls, en 300px chatträls och den oförändrade konversationen. Behåll den gamla 300px sidopanelen när växeln är av och på mobil. Visa fem fästa platser, bevara användardefinierad ordning och visa omordningsmöjligheter endast under aktiv dragning. Inspektera inte den historiska funktionen eller senare förbättringar förrän den oberoende patchen, testerna och webbläsarbeviset är frusna.
För navigationsfunktionen bad jag agenten behålla den gamla sidopanelen när funktionen var av, visa den nya tre-delade layouten när den var på, behålla den befintliga mobila lådan och låta användare omordna fästa agenter.
Under implementationen hittade agenten ett viktigt problem. Den gamla produkten kom ihåg vilka agenter som var fästa, men inte deras ordning. En draginteraktion kunde se korrekt ut men återställas efter en uppdatering.
Så agenten gjorde mer än att rita dragläget. Den fick den nya ordningen att bestå, uppdaterade sidan och kontrollerade att ordningen kvarstod. Den bekräftade också att omordningshandtag bara visades under dragning och försvann efteråt.
Implementeringsleveransen visade de två desktoplägen jag behövde granska. Jag visar dem i full bredd så att gränssnittet förblir läsbart. Mobilbeteendet visas senare i genomgången som en tät telefonvy.
Desktop viloläge
Aktiv omordning
Vid denna punkt hade jag en fungerande funktion, inte ännu en designfil. Men implementationen var ändå inte slutet. Jag behövde se vad som faktiskt kördes i den distribuerade förhandsvisningen.
4. Använd ui-walkthrough för att granska den verkliga produkten
Produktgenomgångar brukade vara tidskrävande. Jag öppnade en distribuerad förhandsvisning, förberedde rätt konto, slog på och av funktioner, klickade på varje kontroll, ändrade webbläsarstorlek, tog skärmdumpar och försökte minnas vilket tillstånd varje bild representerade.
Agenten har en inbyggd Agent Browser, så jag kan överlåta det arbetet till den.
Arbetsflödet har två huvudsteg:
- Lista scenarierna först. Agenten omvandlar design- och implementationskrav till en checklista.
- Kör checklistan och bifoga bevis. Den utför varje scenario i den distribuerade förhandsvisningen och returnerar PASS, FAIL eller BLOCKED med en skärmdump för varje meningsfullt tillstånd.
Vad denna instruktion förändrar kring granskning
- Agenten listar scenarierna innan den börjar klicka.
- Den använder den verkliga distribuerade komponenten via sin inbyggda Agent Browser.
- Den fångar en skärmdump för varje meningsfullt tillstånd.
- Den markerar varje kontrollpunkt som PASS, FAIL eller BLOCKED.
- Den döljer aldrig ett otillgängligt tillstånd bakom falska bevis.
Detta omvandlar manuellt klickande till ett organiserat granskningspaket. Jag kan se avsett beteende, resultatet och bevisen tillsammans.
Den fullständiga instruktionen finns nedan. Jag har översatt det interna beroendenamnet till "inbyggd Agent Browser" för läsarens tydlighet; arbetsflödeslogiken är annars oförändrad.
Komplett ursprunglig 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.
Detta var den funktionsspecifika walkthrough-prompten:
/ui-walkthroughAnvänd den distribuerade förhandsvisningen via den inbyggda Agent Browser som enda webbläsarsanning. Bevisa sidopanelen när funktionen är av, 68px och 300px delning, destinationsordning, hovringstillstånd, fem fästa platser, dragbara handtag, bestående omordning, trådval, rullning och hela iPhone-lådan. Returnera PASS, FAIL eller BLOCKED för varje kontrollpunkt. Ersätt inte ett otillgängligt tillstånd med en kopia.
För denna funktion organiserade agenten genomgången kring dessa frågor:
- Fungerar den gamla sidopanelen när funktionen är av?
- Visas den nya desktopstrukturen när den är på?
- Är hovrings- och markerade tillstånd synliga men diskreta?
- Är fem fästa agenter läsbara?
- Hålls omordningskontroller dolda tills en dragning startar?
- Överlever den nya ordningen en uppdatering?
- Kan jag välja och rulla genom riktiga trådar?
- Fungerar den befintliga mobila lådan fortfarande?
- Finns alla navigationsmål och i rätt ordning?
Agenten öppnade sedan den distribuerade förhandsvisningen som en ny användare, slutförde onboarding, aktiverade funktionen och gick igenom listan. Den testade viloläge, hovring, dragläge, uppdateringsbeteende, trådval, rullning och telefonlayout.
Resultatet blev 11 PASS, 1 FAIL.
Felet var användbart. Layouten och interaktionerna fungerade, men den distribuerade förhandsvisningen visade bara sex produktmål. Activity och Insights saknades, och ordningen stämde inte med vald design.
| Scenario | Resultat |
|---|---|
| Gammal sidopanel med funktionen av | PASS |
| Ny tredelad desktoplayout | PASS |
| Hovrings- och markerade tillstånd | PASS |
| Fem fästa agenter | PASS |
| Endast dragbara omordningsvägledning | PASS |
| Sparad ordning efter uppdatering | PASS |
| Trådval och rullning | PASS |
| Befintlig mobil låda | PASS |
| Destinationsinnehåll och ordning | FAIL |
Den slutliga leveransen var ett organiserat skärmdumpspaket istället för en mapp med oetiketterade bilder. Desktopbilderna är 1440 × 900 pixlar och telefonbilden är 1170 × 2532 pixlar. De visas en i taget nedan så att gränssnittet förblir läsbart; klicka på en bild för att förstora den utan att lämna artikeln.
Funktion av
Funktion aktiverad
Desktoplayout
Destinationshovring
Fäst agent-hovring
Aktiv dragning
Sparad ordning
Mobil låda
Detta låter mig granska en funktion på ett strukturerat sätt. Jag kan se de avsedda scenarierna, det faktiska distribuerade resultatet och bevisen tillsammans. Om något misslyckas vet jag exakt var arbetet ska återupptas.
Hur ett team antar detta AI-produktdesignarbetsflöde
Hela processen är kort. Teammedlemmar kan spara varje steg som ett delat Zero-arbetsflöde istället för att återskapa processen ur minnet.
| Steg | Inmatning | Utmatning |
|---|---|---|
ui-design | Aktuell skärm, problem, mål och begränsningar | En rekommenderad riktning, nio alternativ och en vald designlogg |
ui-implement | Den valda designloggen | En granskbar kodändring och skärmdumpar av huvudtillstånden |
ui-walkthrough | Den distribuerade funktionen och dess förväntade beteende | En organiserad scenariolista med PASS-, FAIL- eller BLOCKED-skärmdumpar |
En teammedlem behöver inte återskapa min designsmak. De behöver ge bra kontext, använda det gemensamma produktsystemet, göra ett tydligt val efter utforskning och granska webbläsarbevisen. Samma tre mänskliga kontrollpunkter—problem, riktning och acceptans—formar också hur vi hanterar AI-agenter som ett team.
Detta arbetsflöde tar inte bort designpraxis eller designprocess. Det flyttar dem till de delar där de är viktigast: definiera problemet, sätta begränsningar, jämföra riktningar, välja avvägningar och bedöma den körande produkten.
När komponentbiblioteket är moget behöver jag inte längre bygga om varje funktion som dragbara block i Figma. Jag kan arbeta med agenten direkt i produkten, medan designsystemet håller resultatet konsekvent och genomgången håller resultatet ärligt.
Vanliga frågor
Hur bygger du ett AI-produktdesignarbetsflöde?
Börja med det befintliga produktsystemet, inte en tom prompt. Dela upp arbetet i utforskning, implementation och granskning. Låt agenten generera alternativ och utföra upprepningsbara kontroller, men låt produktdesignern ansvara för problemet, vald riktning och slutgiltigt godkännande.
Kan produktdesigners arbeta utan Figma?
Ja, när produkten redan har stabila komponenter, sidmallar och interaktionsmönster. Figma är fortfarande användbart för ett nytt visuellt språk eller en okänd interaktion. Poängen är inte att förbjuda Figma; det är att undvika att återskapa kända produktbeslut på en andra arbetsyta.
Ersätter AI produktdesigners?
Inte i detta arbetsflöde. Agenten sätter ihop alternativ, redigerar kod och kontrollerar scenarier. Designern ramar fortfarande in problemet, sätter begränsningar, jämför avvägningar, väljer riktning och avgör om den körande produkten är tillräckligt bra för att lanseras.
