Produktový design bez Figma funguje, když má produkt již vyspělý design systém. Můj workflow AI produktového designu využívá tři dovednosti agenta: ui-design prozkoumává devět směrů, ui-implement promění vybraný směr v produkt a ui-walkthrough kontroluje každý stav pomocí vestavěného Agent Browseru. Rozhodnutí stále dělám já; agent se stará o opakovanou produkci a kontrolu.
Většina produktových funkcí nezačíná na prázdné stránce. Jakmile produkt nějakou dobu existuje, jeho základní designová rozhodnutí už jsou v kódu. Tlačítka, vstupy, karty, navigace, mezery, barvy, texty, stavy najetí a mobilní chování jsou již definovány. Znovuvytváření těchto prvků ve Figma často znamená přetahování stejných komponent na další plátno, než je znovu sestavíte v produktu.
Designér stále činí produktová rozhodnutí. Agent odstraňuje většinu opakované montáže a kontroly. To funguje, protože Zero už má poměrně vyspělý design systém.
1. Začněte produktový design bez Figma s design systémem
Práce bez Figma neznamená práci bez designových pravidel. Vyžaduje jasnější pravidla.
Pro Zero může agent zkontrolovat:
- Stávající komponenty pro tlačítka, vstupy, rozbalovací nabídky, karty, dialogy a navigaci
- Zavedené mezery, typografii, barvy, okraje a poloměry rohů
- Stávající stavy najetí, vybrané, zakázané, prázdné a mobilní stavy
- Konvence textů jako větný tvar a krátké uživatelské popisky
- Skutečné obrazovky ukazující, jak jsou tyto prvky kombinovány
Tyto reference odpovídají na běžné designové otázky. Nový vstup by měl vypadat jako ty, které už jsou v produktu. Nová karta by měla použít stejný povrch a poloměr jako nejbližší existující karta. Ikonové tlačítko by mělo mít stejnou zpětnou vazbu na najetí jako ostatní ikonová tlačítka.
To dává agentovi hranice. Může prozkoumávat strukturu funkce, aniž by vymýšlel nový vizuální jazyk pro každou obrazovku.
Figma je stále užitečná, když tým vytváří novou značku, nový systém komponent nebo interakci, která nemá v produktu žádný blízký vzor. Jakmile je však systém vyspělý, běžící produkt se může stát hlavní designovou plochou. To je varianta workflow design-as-code, který jsme použili při přestavbě Zero v měřítku funkcí.
2. Použijte ui-design k prozkoumání devíti směrů produktového designu
Každá funkce stále potřebuje průzkum. Nechci, aby agent vzal mou první větu a hned ji proměnil v kód.
Začínám s ui-design. Dám agentovi aktuální obrazovku, uživatelský problém, cíl a hlavní omezení. Agent přečte stávající produktové vzory a vrátí jeden doporučený směr plus devět alternativ.
Jednoduše řečeno, tato dovednost zachytí aktuální obrazovku, vytvoří jeden doporučený směr, prozkoumá devět odlišných alternativ, představí kompromisy a čeká na lidský výběr.
Designové myšlení v tomto zadání
Toto zadání není jen seznam vizuálních pravidel. Převádí běžný proces designéra do opakovatelné sekvence:
- Nejdříve pochopit, pak navrhovat. Zachytit aktuální obrazovku a přečíst okolní produkt před tvorbou.
- Myslet v systémech. Brát existující komponenty, šablonové stránky, vzory interakcí a pravidla textů jako výchozí materiál.
- Zabránit zbytečnému vynalézání. AI má tendenci vytvářet nový vzor, když je zadání vágní. Instrukce jí říká najít nejbližší použitou komponentu nebo stránku a znovu ji použít místo přibližování z paměti.
- Prozkoumat před výběrem. After anchor dává jeden věrohodný směr. Devět variant otevírá různé možnosti rozvržení, hierarchie, hustoty, vstupního bodu a odhalení informací.
- Oddělit průzkum od závazku. Agent se zastaví po předložení možností. Člověk porovná kompromisy a vybere, než začne kódování.
- Zkontrolovat celý zážitek. Texty, zpětná vazba na najetí, stavy, mobilní chování a vizuální konzistence jsou součástí designu, ne jen úklid po implementaci.
To je systémové myšlení, které od této dovednosti chci: pochopit stávající produkt, prozkoumat v jeho rámci a pak učinit explicitní volbu.
Zde je kompletní původní zadání, doslovně převzaté z živého workflow:
Kompletní původní instrukce ui-design
# 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.
Těch devět možností nemusí být devět hotových návrhů. Jejich úkolem je dát mi dostatečný rozsah, abych na problém nahlédl jinak a posunul se ke správnému směru. Pokud koncept přesahuje stávající produkt, může pomoci i samostatný React prototyp. Pro tuto funkci jsem zůstal uvnitř skutečného produktového systému.
Skutečný příklad: navigace v Zero
Zero původně mělo jeden 300-pixelový postranní panel obsahující produktové destinace, připnuté agenty a chatovací vlákna. Dělal tři věci najednou. Chtěl jsem tyto úkoly oddělit, aniž bych měnil oblast konverzace.
Produktový brief pro průzkum byl:
/ui-designZopakujte fázi návrhu pro třízónovou navigaci Zero z reálného historického základu. Oddělte produktové destinace, agenty a konverzace do jasnějších oblastí bez změny konverzační části. Použijte skutečné Zero tokeny, ikony a komponenty. Vytvořte věrný Before, jeden silný After a devět opravdu odlišných variant. Neupravujte produktový kód ani nepředkládejte maketu jako důkaz v prohlížeči.
První průzkum byl příliš opatrný. Několik možností změnilo šířky a styly výběru, ale stále vypadaly jako stejný postranní panel. Tuto sadu jsem odmítl a požádal agenta, aby rozdíly zvýraznil na úrovni informační architektury.
Druhý běh vrátil devět opravdu odlišných směrů. Seřadil jsem je do tabulky 3 × 3, aby bylo snadné je porovnat, aniž by se článek změnil v dlouhý pás obrázků. Každý náhled se otevře v prohlížeči obrázků blogu.
| 1. Horní navigace | 2. Skládací zásuvka | 3. Nejprve vlákno |
|---|---|---|
 |  |  |
| Přesunout destinace nad konverzaci | Skrýt destinace, dokud nejsou potřeba | Udělat z konverzací hlavní navigační objekt |
| 4. Nejprve agent | 5. Nejprve konverzace | 6. Spouštěč příkazů |
 |  |  |
| Vybrat agenta před jeho vlákny | Umístit připnuté agenty nad aktivní konverzaci | Otevírat destinace z vyhledávací nabídky |
| 7. Rozšiřitelná lišta | 8. Vstup přes dashboard | 9. Spodní dok |
 |  |  |
| Rozšířit úzkou lištu jen při potřebě | Začít z nedávné práce | Přesunout destinace dolů |
Nevybral jsem přesně jeden z těchto návrhů. Použil jsem je k rozhodnutí, co má zůstat a co změnit. Konečný směr použil úzkou lištu pro destinace, samostatnou lištu pro chat, pět viditelných připnutých agentů a stávající oblast konverzace.
Důležitým výstupem ui-design nebyl jen obrázek. Bylo to krátké rozhodovací shrnutí:
- Zachovat 68-pixelovou lištu pro destinace a 300-pixelovou lištu pro chat
- Zobrazit pět slotů pro připnuté agenty
- Zachovat výběr decentní, ale čitelný
- Zobrazit vodítko pro přesun pouze při přetahování
- Zachovat konverzaci a stávající mobilní zásuvku beze změny
To stačilo k zahájení implementace.
3. Použijte ui-implement k proměně vybraného návrhu v kód
Po výběru směru a připojení produktového kódu pracuje agent přímo v kódu. Vybraný návrh znovu nekreslím nejprve ve Figma.
Jednoduše řečeno, ui-implement přeskočí průzkum, protože směr už byl zvolen. Najde nejbližší skutečné komponenty a strukturu stránky, sestaví je, zkontroluje výsledek a ověří funkci v prohlížeči.
Co tato instrukce chrání
- Vybraný směr by neměl být během implementace přepracován.
- Agent musí začít s nejbližší existující komponentou a šablonou stránky.
- Přednost má znovupoužití před novou komponentou, pokud v produktu není skutečná mezera.
- Samokontrola a kontrola v prohlížeči zachytí nekonzistentní texty, stavy a interakce.
- Pokud je produktové rozhodnutí stále nevyřešené, práce se vrací k
ui-design.
Takto zůstává design systém aktivní během implementace. Není to dokument, který agent přečte jednou. Ovlivňuje, které komponenty vybírá a jak kontroluje výsledný zážitek.
Zde je kompletní původní zadání, doslovně převzaté z živého workflow:
Kompletní původní instrukce ui-implement
# 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.
Toto bylo zadání pro konkrétní implementaci funkce:
/ui-implementZačněte z revize
04d642bb. Přidejte výchozí vypnuté rozdělení desktopu se 68px lištou pro destinace, 300px lištou pro chat a nezměněnou konverzací. Zachovejte starý 300px postranní panel, když je přepínač vypnutý a na mobilu. Zobrazte pět připnutých slotů, zachovejte uživatelské pořadí a zobrazte vodítka pro přesun pouze během aktivního přetahování. Nekontrolujte historickou funkci ani pozdější úpravy, dokud nejsou nezávislý patch, testy a důkaz v prohlížeči hotové.
U navigační funkce jsem požádal agenta, aby zachoval starý postranní panel, když je funkce vypnutá, zobrazil nové třízónové rozvržení, když je zapnutá, zachoval stávající mobilní zásuvku a umožnil uživatelům měnit pořadí připnutých agentů.
Během implementace agent našel jeden důležitý problém. Starý produkt si pamatoval, kteří agenti byli připnutí, ale ne jejich pořadí. Přetahování mohlo vypadat správně, ale po obnovení stránky se pořadí resetovalo.
Agent tedy udělal víc než jen nakreslit stav přetahování. Zajistil, že nové pořadí přetrvá, obnovil stránku a ověřil, že pořadí zůstalo. Také potvrdil, že úchyty pro přesun se zobrazují pouze během přetahování a po něm mizí.
Výstup implementace ukázal dvě desktopové stavy, které jsem potřeboval zkontrolovat. Zobrazuji je v plné šířce, aby rozhraní zůstalo čitelné. Mobilní chování se objeví později v průchodu jako hustý záznam z telefonu.
Klidový stav na desktopu
Aktivní přesun
V tuto chvíli jsem měl funkční funkci, ne další designový soubor. Implementace však nebyla konec. Potřeboval jsem vidět, co skutečně běží v nasazeném náhledu.
4. Použijte ui-walkthrough k revizi skutečného produktu
Průchody produktem bývaly zdlouhavé. Otevřel jsem nasazený náhled, připravil správný účet, zapínal a vypínal funkce, klikal na každé ovládání, měnil velikost prohlížeče, pořizoval snímky obrazovky a snažil se zapamatovat, který stav každý obrázek představuje.
Agent má vestavěný Agent Browser, takže tuto práci mohu předat jemu.
Workflow má dva hlavní kroky:
- Nejprve vypsat scénáře. Agent převede designová a implementační tvrzení na kontrolní seznam.
- Proveďte kontrolní seznam a přiložte důkazy. Provede každý scénář v nasazeném náhledu a vrátí PASS, FAIL nebo BLOCKED s obrázkem pro každý smysluplný stav.
Co tato instrukce mění na revizi
- Agent vypíše scénáře před tím, než začne klikat.
- Používá skutečnou nasazenou komponentu přes vestavěný Agent Browser.
- Zachytí jeden snímek obrazovky pro každý smysluplný stav.
- Označí každý kontrolní bod jako PASS, FAIL nebo BLOCKED.
- Nikdy neschovává nedostupný stav za falešný důkaz.
To promění ruční klikání v organizovaný balíček revize. Mohu vidět zamýšlené chování, výsledek i důkaz najednou.
Celé zadání je níže. Interní název závislosti jsem pro čtenářskou srozumitelnost přeložil jako „vestavěný Agent Browser“; logika workflow zůstává nezměněna.
Kompletní původní instrukce ui-walkthrough
# 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.
Toto bylo zadání pro konkrétní walkthrough funkce:
/ui-walkthroughPoužijte nasazený náhled přes vestavěný Agent Browser jako jediný zdroj pravdy v prohlížeči. Prokažte postranní panel při vypnuté funkci, rozdělení 68px a 300px, pořadí destinací, stavy najetí, pět připnutých slotů, úchyty pouze při přetahování, trvalé pořadí, výběr vlákna, posouvání a plnou iPhone zásuvku. Vraťte PASS, FAIL nebo BLOCKED pro každý kontrolní bod. Nenahrazujte nedosažitelný stav replikou.
Pro tuto funkci agent uspořádal walkthrough kolem těchto otázek:
- Funguje starý postranní panel, když je funkce vypnutá?
- Objeví se nové desktopové rozvržení, když je zapnuté?
- Jsou stavy najetí a výběru viditelné, ale decentní?
- Je pět připnutých agentů čitelných?
- Zůstávají ovládací prvky pro přesun skryté, dokud nezačne přetahování?
- Přetrvá nové pořadí po obnovení?
- Mohu vybírat a posouvat skutečná vlákna?
- Funguje stále stávající mobilní zásuvka?
- Jsou všechny navigační destinace přítomné a ve správném pořadí?
Agent pak otevřel nasazený náhled jako nový uživatel, dokončil onboarding, povolil funkci a prošel seznam. Otestoval klidový stav, stav najetí, stav přetahování, chování po obnovení, výběr vlákna, posouvání i rozvržení na telefonu.
Výsledek byl 11 PASS, 1 FAIL.
Selhání bylo užitečné. Rozvržení a interakce fungovaly, ale nasazený náhled ukazoval jen šest produktových destinací. Activity a Insights chyběly a pořadí neodpovídalo vybranému návrhu.
| Scénář | Výsledek |
|---|---|
| Starý postranní panel s vypnutou funkcí | PASS |
| Nové třízónové desktopové rozvržení | PASS |
| Stavy najetí a výběru | PASS |
| Pět připnutých agentů | PASS |
| Vodítka pro přesun pouze při přetahování | PASS |
| Uložené pořadí po obnovení | PASS |
| Výběr vlákna a posouvání | PASS |
| Stávající mobilní zásuvka | PASS |
| Obsah a pořadí destinací | FAIL |
Konečné předání bylo organizovanou sadou snímků obrazovky místo složky neoznačených obrázků. Desktopové snímky mají 1440 × 900 pixelů a snímek z telefonu má 1170 × 2532 pixelů. Zobrazují se postupně níže, aby rozhraní zůstalo čitelné; kliknutím na obrázek jej zvětšíte bez opuštění článku.
Funkce vypnutá
Funkce zapnutá
Desktopové rozvržení
Najetí na destinaci
Najetí na připnutého agenta
Aktivní přetahování
Uložené pořadí
Mobilní zásuvka
To mi umožňuje zkontrolovat funkci strukturovaně. Vidím zamýšlené scénáře, skutečný nasazený výsledek i důkaz najednou. Pokud něco selže, vím přesně, kam se má práce vrátit.
Jak tým přijme tento workflow AI produktového designu
Celý proces je krátký. Kolegové si mohou každou fázi uložit jako sdílený Zero workflow místo znovuvytváření procesu z paměti.
| Fáze | Vstup | Výstup |
|---|---|---|
ui-design | Aktuální obrazovka, problém, cíl a omezení | Jeden doporučený směr, devět alternativ a záznam o vybraném návrhu |
ui-implement | Záznam o vybraném návrhu | Revizní změna kódu a snímky hlavních stavů |
ui-walkthrough | Nasazená funkce a očekávané chování | Organizovaný seznam scénářů se snímky PASS, FAIL nebo BLOCKED |
Kolega nemusí reprodukovat můj designový vkus. Potřebuje poskytnout dobrý kontext, použít sdílený produktový systém, učinit explicitní volbu po průzkumu a zkontrolovat důkaz v prohlížeči. Stejné tři lidské kontrolní body—problém, směr a přijetí—také ovlivňují, jak řídíme AI agenty jako tým.
Tento workflow neodstraňuje designérskou praxi ani myšlení. Přesouvá je do částí, kde jsou nejdůležitější: definování problému, nastavení omezení, porovnání směrů, volba kompromisů a posouzení běžícího produktu.
Když je systém komponent vyspělý, nemusím už každou funkci znovu sestavovat jako přetahovatelné bloky ve Figma. Mohu pracovat s agentem přímo v produktu, zatímco design systém udržuje výstup konzistentní a walkthrough zajišťuje poctivost výsledku.
Často kladené otázky
Jak vytvořit workflow AI produktového designu?
Začněte se stávajícím produktovým systémem, ne prázdným zadáním. Rozdělte práci na průzkum, implementaci a revizi. Nechte agenta generovat možnosti a provádět opakovatelné kontroly, ale ponechte produktovému designérovi odpovědnost za problém, zvolený směr a konečné přijetí.
Mohou produktoví designéři pracovat bez Figma?
Ano, když má produkt stabilní komponenty, šablony stránek a vzory interakcí. Figma zůstává užitečná pro nový vizuální jazyk nebo neznámou interakci. Cílem není zakázat Figma, ale vyhnout se znovuvytváření známých produktových rozhodnutí na druhém plátně.
Nahrazuje AI produktové designéry?
Ne v tomto workflow. Agent sestavuje možnosti, upravuje kód a kontroluje scénáře. Designér stále formuluje problém, nastavuje omezení, porovnává kompromisy, volí směr a rozhoduje, zda je běžící produkt dostatečně dobrý k vydání.
