Projektowanie produktu bez Figma działa, gdy produkt ma już dojrzały system projektowy. Mój workflow projektowania produktu AI wykorzystuje trzy umiejętności agenta: ui-design eksploruje dziewięć kierunków, ui-implement zamienia wybrany kierunek w produkt, a ui-walkthrough przegląda każdy stan przez wbudowaną przeglądarkę Agent Browser. Nadal podejmuję decyzje; agent zajmuje się powtarzalną produkcją i sprawdzaniem.
Większość funkcji produktu nie zaczyna się od pustej strony. Gdy produkt istnieje już jakiś czas, podstawowe decyzje projektowe są już zapisane w kodzie. Przycisk, pole, karta, nawigacja, odstępy, kolory, teksty, stany hover i zachowanie mobilne są już zdefiniowane. Odtwarzanie tych elementów w Figma często oznacza przeciąganie tych samych komponentów na kolejne płótno, zanim znów zostaną odbudowane w produkcie.
Projektant nadal podejmuje decyzje dotyczące produktu. Agent usuwa większość powtarzalnego składania i sprawdzania. To działa, ponieważ Zero ma już dość dojrzały system projektowy.
1. Zacznij projektowanie produktu bez Figma z systemem projektowym
Praca bez Figma nie oznacza pracy bez zasad projektowych. Wymaga jaśniejszych reguł.
Dla Zero agent może sprawdzić:
- Istniejące komponenty: przyciski, pola, rozwijane listy, karty, dialogi i nawigację
- Ustalone odstępy, typografię, kolory, obramowania i promienie narożników
- Istniejące stany: hover, wybrany, nieaktywny, pusty i mobilny
- Konwencje tekstowe, np. wielkość liter i krótkie etykiety dla użytkownika
- Prawdziwe ekrany pokazujące, jak te elementy są łączone
Te odniesienia odpowiadają na zwykłe pytania projektowe. Nowe pole powinno wyglądać jak te już dostępne. Nowa karta powinna używać tej samej powierzchni i promienia, co najbliższa istniejąca karta. Przycisk z ikoną powinien mieć taki sam efekt hover jak inne przyciski z ikoną.
To wyznacza agentowi granicę. Może eksplorować strukturę funkcji bez wymyślania nowego języka wizualnego dla każdego ekranu.
Figma nadal jest przydatna, gdy zespół tworzy nową markę, nowy system komponentów lub interakcję, która nie ma bliskiego odniesienia w produkcie. Ale gdy system jest dojrzały, działający produkt może stać się główną powierzchnią projektową. To wersja workflow design-as-code, którego użyliśmy do przebudowy Zero w skali funkcji.
2. Użyj ui-design do eksploracji dziewięciu kierunków projektowych
Każda funkcja nadal wymaga eksploracji. Nie chcę, by agent zamienił moje pierwsze zdanie od razu w kod.
Zaczynam od ui-design. Przekazuję agentowi aktualny ekran, problem użytkownika, cel i główne ograniczenia. Agent czyta istniejące wzorce produktu i zwraca jeden rekomendowany kierunek oraz dziewięć alternatyw.
W prostych słowach, umiejętność ta przechwytuje aktualny ekran, tworzy jeden rekomendowany kierunek, eksploruje dziewięć różnych alternatyw, przedstawia kompromisy i czeka na wybór człowieka.
Myślenie projektowe w tej instrukcji
Ta instrukcja to nie tylko lista zasad wizualnych. Zamienia normalny proces projektanta w powtarzalną sekwencję:
- Zrozum zanim zaproponujesz. Przechwyć aktualny ekran i przeczytaj otaczający produkt przed stworzeniem czegokolwiek.
- Myśl systemowo. Traktuj istniejące komponenty, strony szablonowe, wzorce interakcji i zasady tekstowe jako materiał wyjściowy.
- Zapobiegaj wymyślaniu na nowo. AI ma tendencję do tworzenia nowego wzorca, gdy prompt jest niejasny. Instrukcja nakazuje znaleźć najbliższy wdrożony komponent lub stronę i użyć go zamiast zgadywać z pamięci.
- Eksploruj przed wyborem. After anchor daje jeden wiarygodny kierunek. Dziewięć wariantów otwiera różne decyzje dotyczące układu, hierarchii, gęstości, punktu wejścia i ujawniania.
- Oddziel eksplorację od zobowiązania. Agent zatrzymuje się po przedstawieniu opcji. Człowiek porównuje kompromisy i wybiera, zanim zacznie się kodowanie.
- Przeglądaj całe doświadczenie. Teksty, efekty hover, stany, zachowanie mobilne i spójność wizualna są częścią projektu, a nie sprzątaniem po wdrożeniu.
To jest systemowe myślenie, jakiego oczekuję od tej umiejętności: zrozumieć istniejący produkt, eksplorować w jego ramach, a potem dokonać świadomego wyboru.
Oto pełna oryginalna instrukcja, przytoczona dosłownie z działającego workflow:
Pełna oryginalna instrukcja 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.
Dziewięć opcji nie musi być dziewięcioma gotowymi projektami. Ich zadaniem jest dać mi wystarczająco szeroki zakres, by spojrzeć na problem inaczej i zbliżyć się do właściwego kierunku. Jeśli koncepcja wykracza poza obecny produkt, samodzielny prototyp React nadal może pomóc. Dla tej funkcji pozostałem w ramach prawdziwego systemu produktu.
Prawdziwy przykład: nawigacja Zero
Zero pierwotnie miało jeden 300-pikselowy pasek boczny zawierający miejsca docelowe produktu, przypiętych agentów i wątki czatu. Robił trzy rzeczy naraz. Chciałem rozdzielić te zadania bez zmiany obszaru rozmowy.
Brief produktowy do eksploracji był następujący:
/ui-designOdtwórz fazę projektowania dla trójstrefowej nawigacji Zero na bazie prawdziwej historii. Rozdziel miejsca docelowe produktu, agentów i rozmowy na wyraźniejsze regiony bez zmiany obszaru rozmowy. Użyj prawdziwych tokenów, ikon i komponentów Zero. Przygotuj wierny oryginał Before, jeden mocny After i dziewięć naprawdę różnych wariantów. Nie edytuj kodu produktu ani nie prezentuj makiety jako dowodu w przeglądarce.
Pierwsza eksploracja była zbyt ostrożna. Kilka opcji zmieniało szerokości i style zaznaczenia, ale nadal wyglądały jak ten sam pasek boczny. Odrzuciłem ten zestaw i poprosiłem agenta, by różnice były widoczne na poziomie architektury informacji.
Drugi run zwrócił dziewięć naprawdę różnych kierunków. Pogrupowałem je w tabelę 3 × 3, by łatwo je porównać bez zamieniania artykułu w długi pasek obrazów. Każda miniatura otwiera się w przeglądarce obrazów bloga.
| 1. Nawigacja górna | 2. Składana szuflada | 3. Najpierw wątek |
|---|---|---|
 |  |  |
| Przenieś miejsca docelowe nad rozmowę | Ukryj miejsca docelowe do czasu potrzeby | Uczyń rozmowy głównym obiektem nawigacji |
| 4. Najpierw agent | 5. Najpierw rozmowa | 6. Launcher poleceń |
 |  |  |
| Wybierz agenta przed jego wątkami | Przypięci agenci nad aktywną rozmową | Otwieraj miejsca docelowe z wyszukiwalnego menu |
| 7. Rozszerzalna szyna | 8. Wejście z dashboardu | 9. Dolny dok |
 |  |  |
| Rozszerzaj wąską szynę tylko w razie potrzeby | Zaczynaj od ostatniej pracy | Przenieś miejsca docelowe na dół |
Nie wybrałem żadnej z tych ram dokładnie tak, jak zostały narysowane. Użyłem ich, by zdecydować, co powinno zostać, a co się zmienić. Ostateczny kierunek wykorzystał wąską szynę miejsc docelowych, osobną szynę czatu, pięciu widocznych przypiętych agentów i istniejący obszar rozmowy.
Najważniejszym wynikiem ui-design nie był sam obraz. To był krótki zapis decyzji:
- Pozostaw szynę miejsc docelowych o szerokości 68 pikseli i szynę czatu o szerokości 300 pikseli
- Pokaż pięć slotów przypiętych agentów
- Zachowaj spokojny, ale czytelny wybór
- Pokaż wskazówki zmiany kolejności tylko podczas przeciągania
- Pozostaw rozmowę i istniejącą szufladę mobilną bez zmian
To wystarczyło, by rozpocząć wdrożenie.
3. Użyj ui-implement, by zamienić wybrany projekt w kod
Po wyborze kierunku i podłączeniu bazy kodu produktu agent pracuje bezpośrednio w kodzie. Nie rysuję wybranej ramki najpierw w Figma.
W prostych słowach, ui-implement pomija eksplorację, bo kierunek został już wybrany. Znajduje najbliższe prawdziwe komponenty i strukturę strony, buduje z nich, audytuje wynik i weryfikuje funkcję w przeglądarce.
Co chroni ta instrukcja
- Wybrany kierunek nie powinien być przeprojektowywany podczas wdrożenia.
- Agent musi zacząć od najbliższego istniejącego komponentu i strony szablonowej.
- Ponowne użycie wygrywa z nowym komponentem, chyba że produkt ma realną lukę.
- Samo-audyt i sprawdzenie w przeglądarce wychwytują niespójne teksty, stany i interakcje.
- Jeśli decyzja produktowa nadal nie jest rozstrzygnięta, praca wraca do
ui-design.
Tak system projektowy pozostaje aktywny podczas wdrożenia. To nie jest dokument, który agent czyta raz. To kształtuje, które komponenty wybiera i jak sprawdza gotowe doświadczenie.
Oto pełna oryginalna instrukcja, przytoczona dosłownie z działającego workflow:
Pełna oryginalna instrukcja 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.
To był prompt wdrożeniowy dla tej funkcji:
/ui-implementZacznij od rewizji
04d642bb. Dodaj domyślnie wyłączony desktopowy podział z 68px szyną miejsc docelowych, 300px szyną czatu i niezmienioną rozmową. Zachowaj stary 300px pasek boczny, gdy przełącznik jest wyłączony i na urządzeniach mobilnych. Wyświetl pięć przypiętych slotów, zachowaj kolejność ustaloną przez użytkownika i pokazuj uchwyty zmiany kolejności tylko podczas aktywnego przeciągania. Nie sprawdzaj historycznej funkcji ani późniejszych poprawek, dopóki niezależna poprawka, testy i dowód w przeglądarce nie zostaną zamrożone.
Dla funkcji nawigacji poprosiłem agenta, by zachował stary pasek boczny, gdy funkcja jest wyłączona, pokazał nowy trójdzielny układ, gdy jest włączona, zachował istniejącą szufladę mobilną i pozwolił użytkownikom zmieniać kolejność przypiętych agentów.
Podczas wdrożenia agent znalazł jeden ważny problem. Stary produkt pamiętał, którzy agenci byli przypięci, ale nie pamiętał ich kolejności. Interakcja przeciągania mogła wyglądać poprawnie, ale po odświeżeniu kolejność wracała do poprzedniej.
Agent zrobił więc więcej niż tylko narysował stan przeciągania. Sprawił, że nowa kolejność była zapisywana, odświeżył stronę i sprawdził, czy kolejność się utrzymała. Potwierdził też, że uchwyty zmiany kolejności pojawiają się tylko podczas przeciągania i znikają po jego zakończeniu.
Wdrożenie pokazało dwa stany desktopowe, które musiałem przejrzeć. Pokazuję je w pełnej szerokości, by interfejs pozostał czytelny. Zachowanie mobilne pojawia się później w walkthrough jako zrzut ekranu z telefonu o wysokiej gęstości pikseli.
Stan spoczynkowy desktopu
Aktywna zmiana kolejności
Na tym etapie miałem działającą funkcję, a nie kolejny plik projektowy. Ale wdrożenie to nie był koniec. Musiałem zobaczyć, co faktycznie działa w wdrożonym podglądzie.
4. Użyj ui-walkthrough do przeglądu prawdziwego produktu
Walkthrough produktu kiedyś były żmudne. Otwierałem wdrożony podgląd, przygotowywałem odpowiednie konto, włączałem i wyłączałem funkcje, klikałem każdy kontroler, zmieniałem rozmiar przeglądarki, robiłem zrzuty ekranu i próbowałem zapamiętać, który stan reprezentuje który obraz.
Agent ma wbudowaną przeglądarkę Agent Browser, więc mogę przekazać mu tę pracę.
Workflow ma dwa główne kroki:
- Najpierw lista scenariuszy. Agent zamienia założenia projektowe i wdrożeniowe w checklistę.
- Wykonaj checklistę i dołącz dowody. Realizuje każdy scenariusz w wdrożonym podglądzie i zwraca PASS, FAIL lub BLOCKED ze zrzutem ekranu dla każdego istotnego stanu.
Co ta instrukcja zmienia w przeglądzie
- Agent tworzy listę scenariuszy przed rozpoczęciem klikania.
- Używa prawdziwego wdrożonego komponentu przez wbudowaną przeglądarkę Agent Browser.
- Przechwytuje jeden zrzut ekranu dla każdego istotnego stanu.
- Oznacza każdy punkt kontrolny jako PASS, FAIL lub BLOCKED.
- Nigdy nie ukrywa niedostępnego stanu za fałszywym dowodem.
To zamienia ręczne klikanie w uporządkowany pakiet przeglądowy. Mogę zobaczyć zamierzone zachowanie, wynik i dowód razem.
Pełna instrukcja poniżej. Nazwę wewnętrznej zależności przetłumaczyłem na „wbudowana przeglądarka Agent Browser” dla jasności czytelnika; logika workflow pozostaje bez zmian.
Pełna oryginalna instrukcja 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.
To był prompt walkthrough dla tej funkcji:
/ui-walkthroughUżyj wdrożonego podglądu przez wbudowaną przeglądarkę Agent Browser jako jedynego źródła prawdy. Udowodnij pasek boczny przy wyłączonej funkcji, podział 68px i 300px, kolejność miejsc docelowych, stany hover, pięć przypiętych slotów, uchwyty tylko podczas przeciągania, trwałą zmianę kolejności, wybór wątku, przewijanie i pełną szufladę iPhone. Zwróć PASS, FAIL lub BLOCKED dla każdego punktu kontrolnego. Nie zastępuj nieosiągalnego stanu repliką.
Dla tej funkcji agent zorganizował walkthrough wokół tych pytań:
- Czy stary pasek boczny nadal działa, gdy funkcja jest wyłączona?
- Czy nowa struktura desktopowa pojawia się, gdy jest włączona?
- Czy stany hover i wybrany są widoczne, ale spokojne?
- Czy pięciu przypiętych agentów jest czytelnych?
- Czy kontrolki zmiany kolejności są ukryte do czasu rozpoczęcia przeciągania?
- Czy nowa kolejność przetrwa odświeżenie?
- Czy mogę wybierać i przewijać prawdziwe wątki?
- Czy istniejąca szuflada mobilna nadal działa?
- Czy wszystkie miejsca docelowe nawigacji są obecne i w odpowiedniej kolejności?
Agent otworzył następnie wdrożony podgląd jako nowy użytkownik, przeszedł onboarding, włączył funkcję i przeszedł przez listę. Przetestował stan spoczynkowy, stan hover, stan przeciągania, zachowanie po odświeżeniu, wybór wątku, przewijanie i układ telefonu.
Wynik to 11 PASS, 1 FAIL.
Porażka była przydatna. Układ i interakcje działały, ale wdrożony podgląd pokazywał tylko sześć miejsc docelowych produktu. Brakowało Activity i Insights, a kolejność nie zgadzała się z wybranym projektem.
| Scenariusz | Wynik |
|---|---|
| Stary pasek boczny przy wyłączonej funkcji | PASS |
| Nowy trójdzielny układ desktopowy | PASS |
| Stany hover i wybrany | PASS |
| Pięciu przypiętych agentów | PASS |
| Wskazówki zmiany kolejności tylko podczas przeciągania | PASS |
| Zapisana kolejność po odświeżeniu | PASS |
| Wybór wątku i przewijanie | PASS |
| Istniejąca szuflada mobilna | PASS |
| Zawartość i kolejność miejsc docelowych | FAIL |
Ostateczna dostawa to uporządkowany zestaw zrzutów ekranu zamiast folderu nieopisanych obrazów. Zrzuty desktopowe mają 1440 × 900 pikseli, a telefoniczne 1170 × 2532 pikseli. Pojawiają się pojedynczo poniżej, by interfejs pozostał czytelny; kliknij dowolny obraz, by powiększyć go bez opuszczania artykułu.
Funkcja wyłączona
Funkcja włączona
Układ desktopowy
Hover miejsca docelowego
Hover przypiętego agenta
Aktywne przeciąganie
Zapisana kolejność
Szuflada mobilna
To pozwala mi przeglądać funkcję w uporządkowany sposób. Widzę zamierzone scenariusze, faktyczny wdrożony wynik i dowody razem. Jeśli coś zawiedzie, wiem dokładnie, gdzie praca powinna wrócić.
Jak zespół wdraża ten workflow projektowania produktu AI
Cały proces jest krótki. Współpracownicy mogą zapisać każdy etap jako współdzielony workflow Zero zamiast odtwarzać proces z pamięci.
| Etap | Wejście | Wyjście |
|---|---|---|
ui-design | Aktualny ekran, problem, cel i ograniczenia | Jeden rekomendowany kierunek, dziewięć alternatyw i zapis wybranego projektu |
ui-implement | Zapis wybranego projektu | Przeglądana zmiana w kodzie i zrzuty głównych stanów |
ui-walkthrough | Wdrożona funkcja i jej oczekiwane zachowanie | Uporządkowana lista scenariuszy ze zrzutami PASS, FAIL lub BLOCKED |
Współpracownik nie musi powielać mojego gustu projektowego. Musi zapewnić dobry kontekst, korzystać ze wspólnego systemu produktu, dokonać świadomego wyboru po eksploracji i przejrzeć dowody z przeglądarki. Te same trzy ludzkie punkty kontrolne—problem, kierunek i akceptacja—kształtują też sposób, w jaki zarządzamy agentami AI jak zespołem.
Ten workflow nie usuwa praktyki ani myślenia projektowego. Przenosi je tam, gdzie mają największe znaczenie: definiowanie problemu, ustalanie ograniczeń, porównywanie kierunków, wybór kompromisów i ocena działającego produktu.
Gdy system komponentów jest dojrzały, nie muszę już odbudowywać każdej funkcji jako przeciąganych bloków w Figma. Mogę pracować z agentem bezpośrednio w produkcie, a system projektowy dba o spójność wyniku, a walkthrough zapewnia uczciwość rezultatu.
Najczęściej zadawane pytania
Jak zbudować workflow projektowania produktu AI?
Zacznij od istniejącego systemu produktu, nie od pustego promptu. Podziel pracę na eksplorację, wdrożenie i przegląd. Pozwól agentowi generować opcje i wykonywać powtarzalne kontrole, ale pozostaw projektantowi odpowiedzialność za problem, wybrany kierunek i końcową akceptację.
Czy projektanci produktów mogą pracować bez Figma?
Tak, gdy produkt ma już stabilne komponenty, szablony stron i wzorce interakcji. Figma pozostaje przydatna dla nowego języka wizualnego lub nieznanej interakcji. Nie chodzi o zakazanie Figma; chodzi o unikanie odtwarzania znanych decyzji produktowych na drugim płótnie.
Czy AI zastępuje projektantów produktów?
Nie w tym workflow. Agent składa opcje, edytuje kod i sprawdza scenariusze. Projektant nadal określa problem, ustala ograniczenia, porównuje kompromisy, wybiera kierunek i decyduje, czy działający produkt jest wystarczająco dobry do wdrożenia.
