Figma olmadan ürün tasarımı, ürünün zaten olgun bir tasarım sistemine sahip olması durumunda işe yarar. Benim yapay zekâ ürün tasarım akışım üç ajan yeteneği kullanır: ui-design dokuz yönü keşfeder, ui-implement seçilen yönü ürüne dönüştürür ve ui-walkthrough yerleşik Agent Browser ile her durumu gözden geçirir. Kararları hâlâ ben veriyorum; ajan ise tekrarlayan üretim ve kontrol işlerini üstleniyor.
Çoğu ürün özelliği sıfırdan başlamaz. Bir ürün bir süre piyasada kaldıktan sonra, temel tasarım kararları zaten kodda yer alır. Butonlar, girişler, kartlar, gezinme, boşluklar, renkler, metinler, üzerine gelme durumları ve mobil davranışlar tanımlanmıştır. Bu parçaları Figma'da yeniden oluşturmak genellikle aynı bileşenleri başka bir tuvale sürükleyip üründe tekrar inşa etmek anlamına gelir.
Tasarımcı hâlâ ürün kararlarını verir. Ajan, tekrarlayan montaj ve kontrolün çoğunu ortadan kaldırır. Bu, Zero'nun zaten yeterince olgun bir tasarım sistemine sahip olması sayesinde mümkündür.
1. Figma olmadan ürün tasarımına bir tasarım sistemiyle başlayın
Figma olmadan çalışmak, tasarım kuralları olmadan çalışmak anlamına gelmez. Daha net kurallar gerektirir.
Zero için ajan şunları inceleyebilir:
- Butonlar, girişler, açılır menüler, kartlar, diyaloglar ve gezinme için mevcut bileşenler
- Belirlenmiş boşluklar, tipografi, renkler, kenarlıklar ve köşe yarıçapları
- Mevcut üzerine gelme, seçili, devre dışı, boş ve mobil durumlar
- Cümle başı büyük harf ve kısa kullanıcıya dönük etiketler gibi metin kuralları
- Bu parçaların nasıl birleştirildiğini gösteren gerçek ekranlar
Bu referanslar sıradan tasarım sorularını yanıtlar. Yeni bir giriş, zaten gönderilen girişler gibi görünmelidir. Yeni bir kart, en yakın mevcut kartla aynı yüzeyi ve yarıçapı kullanmalıdır. Bir simge butonu, diğer simge butonlarıyla aynı üzerine gelme geri bildirimi vermelidir.
Bu, ajana bir sınır çizer. Bir özelliğin yapısını keşfedebilir, ancak her ekran için yeni bir görsel dil icat etmez.
Figma, bir ekip yeni bir marka, yeni bir bileşen sistemi veya üründe yakın bir referansı olmayan bir etkileşim oluşturuyorsa hâlâ faydalıdır. Ancak sistem olgunlaştığında, çalışan ürün ana tasarım yüzeyi olabilir. Bu, Zero'yu yeniden inşa etmek için kullandığımız design-as-code akışının özellik ölçeğindeki hâlidir.
2. ui-design ile dokuz ürün tasarım yönü keşfedin
Her özellik hâlâ keşif gerektirir. Bir ajanın ilk cümlemi alıp hemen koda dökmesini istemem.
ui-design ile başlıyorum. Ajana mevcut ekranı, kullanıcı sorununu, hedefi ve ana kısıtları veriyorum. Ajan mevcut ürün kalıplarını okur ve bir önerilen yön ile dokuz alternatif döndürür.
Basitçe, bu yetenek mevcut ekranı yakalar, bir önerilen yön oluşturur, dokuz farklı alternatifi keşfeder, artılarını ve eksilerini sunar ve insan seçimini bekler.
Bu talimatın ardındaki tasarım düşüncesi
Bu talimat sadece görsel kurallar listesi değildir. Bir tasarımcının normal sürecini tekrarlanabilir bir sıraya dönüştürür:
- Önce anlamak, sonra önermek. Mevcut ekranı yakala ve bir şey yapmadan önce çevresindeki ürünü oku.
- Sistemlerle düşünmek. Mevcut bileşenleri, şablon sayfaları, etkileşim kalıplarını ve metin kurallarını başlangıç malzemesi olarak ele al.
- Yeniden icadı önle. Yapay zekâ, istem belirsizse yeni bir kalıp oluşturma eğilimindedir. Talimat, hafızadan yaklaşık yapmak yerine en yakın gönderilmiş bileşeni veya sayfayı bulup yeniden kullanmasını söyler.
- Seçmeden önce keşfet. After çapasından sonra bir makul yön gelir. Dokuz varyant, yerleşim, hiyerarşi, yoğunluk, giriş noktası ve açıklık hakkında farklı kararlar açar.
- Keşfi karardan ayır. Ajan seçenekleri sunduktan sonra durur. Bir insan artılarını ve eksilerini karşılaştırır ve kod başlamadan önce seçer.
- Tüm deneyimi gözden geçir. Metin, üzerine gelme geri bildirimi, durumlar, mobil davranış ve görsel tutarlılık tasarımın parçasıdır; uygulamadan sonra temizlik değildir.
Bu, yetenekten beklediğim sistem düşüncesidir: mevcut ürünü anlamak, içinde keşfetmek ve ardından açık bir seçim yapmak.
İşte canlı akıştan birebir alınmış tam orijinal talimat:
Tam orijinal ui-design talimatı
# 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.
Dokuz seçeneğin dokuzu da bitmiş tasarımlar olmak zorunda değildir. Amaçları, sorunu farklı görmemi ve doğru yöne ilerlememi sağlayacak kadar çeşit sunmaktır. Bir kavram mevcut ürünün dışında kalıyorsa, bağımsız bir React prototipi yine de yardımcı olabilir. Bu özellik için gerçek ürün sistemi içinde kaldım.
Gerçek bir örnek: Zero'nun navigasyonu
Zero'nun başlangıçta ürün hedeflerini, sabitlenmiş ajanları ve sohbet başlıklarını içeren bir 300 piksellik kenar çubuğu vardı. Aynı anda üç işi birden yapıyordu. Bu işleri sohbet alanını değiştirmeden ayırmak istedim.
Keşif için ürün özeti şuydu:
/ui-designZero'nun üç bölgeli navigasyonu için tasarım aşamasını gerçek tarihsel temelden tekrar oynat. Ürün hedeflerini, ajanları ve konuşmaları daha net bölgelere ayır; sohbet alanını değiştirme. Gerçek Zero jetonları, simgeleri ve bileşenleri kullan. Kaynağa sadık bir Before, güçlü bir After ve gerçekten farklı dokuz varyant üret. Ürün kodunu düzenleme veya bir maketi tarayıcı kanıtı olarak sunma.
İlk keşif fazla temkinliydi. Bazı seçenekler genişlikleri ve seçim stillerini değiştirdi, ancak hâlâ aynı kenar çubuğu gibi görünüyorlardı. O seti reddettim ve ajandan farkların bilgi mimarisi düzeyinde görünür olmasını istedim.
İkinci çalışmada dokuz gerçekten farklı yön döndü. Bunları 3 × 3'lik bir tabloya grupladım, böylece makaleyi uzun bir görsel şeride çevirmeden kolayca karşılaştırılabiliyorlar. Her küçük resim blogun görsel görüntüleyicisinde açılır.
| 1. Üst gezinme | 2. Katlanabilir çekmece | 3. Önce başlık |
|---|---|---|
 |  |  |
| Hedefleri sohbetin üstüne taşı | Hedefleri gerekene kadar gizle | Konuşmaları ana gezinme nesnesi yap |
| 4. Önce ajan | 5. Önce konuşma | 6. Komut başlatıcı |
 |  |  |
| Başlıklarından önce bir ajan seç | Sabitlenmiş ajanları aktif konuşmanın üstüne koy | Hedefleri aranabilir bir menüden aç |
| 7. Genişletilebilir ray | 8. Gösterge paneli girişi | 9. Alt kenar çubuğu |
 |  |  |
| Dar bir rayı yalnızca gerektiğinde genişlet | Son çalışmadan başla | Hedefleri alta taşı |
Bu çerçevelerden hiçbirini aynen çizildiği gibi seçmedim. Onları neyin kalacağına ve neyin değişeceğine karar vermek için kullandım. Son yön, dar bir hedef rayı, ayrı bir sohbet rayı, beş görünür sabitlenmiş ajan ve mevcut sohbet alanını kullandı.
ui-design'ın önemli çıktısı yalnızca görsel değildi. Kısa bir karar kaydıydı:
- 68 piksellik bir hedef rayı ve 300 piksellik bir sohbet rayı tut
- Beş sabitlenmiş ajan yuvası göster
- Seçimi sade ama okunabilir tut
- Yeniden sıralama rehberini yalnızca sürüklerken göster
- Sohbet ve mevcut mobil çekmeceyi değiştirme
Bu, uygulamaya başlamak için yeterliydi.
3. Seçilen tasarımı koda dökmek için ui-implement kullanın
Bir yön seçip ürün kod tabanını bağladıktan sonra ajan doğrudan kodda çalışır. Seçilen çerçeveyi önce Figma'da yeniden çizmem.
Basitçe, ui-implement keşfi atlar çünkü yön zaten seçilmiştir. En yakın gerçek bileşenleri ve sayfa yapısını bulur, bunlarla inşa eder, sonucu denetler ve özelliği bir tarayıcıda doğrular.
Bu talimatın korudukları
- Seçilen yön uygulama sırasında yeniden tasarlanmamalıdır.
- Ajan, en yakın mevcut bileşen ve şablon sayfa ile başlamalıdır.
- Gerçek bir ürün eksikliği yoksa yeniden kullanım yeni bileşene tercih edilir.
- Kendi kendine denetim ve tarayıcı kontrolü, tutarsız metin, durum ve etkileşimleri yakalar.
- Bir ürün kararı hâlâ çözülmemişse, iş
ui-design'ya geri döner.
Bu, tasarım sisteminin uygulama sırasında aktif kalmasını sağlar. Ajanın bir kez okuduğu bir belge değildir. Hangi bileşenleri seçeceğini ve bitmiş deneyimi nasıl kontrol edeceğini şekillendirir.
İşte canlı akıştan birebir alınmış tam orijinal talimat:
Tam orijinal ui-implement talimatı
# 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.
Bu, özellikle özellik için verilen uygulama istemiydi:
/ui-implementRevizyon
04d642bb'dan başla. Varsayılan kapalı masaüstü bölmesi ekle: 68px hedef rayı, 300px sohbet rayı ve değişmeyen sohbet. Anahtar kapalıyken ve mobilde eski 300px kenar çubuğunu koru. Beş sabitlenmiş yuva göster, kullanıcı tanımlı sıralamayı koru ve yeniden sıralama göstergelerini yalnızca aktif sürüklemede göster. Bağımsız yama, testler ve tarayıcı kanıtı donana kadar tarihsel özelliği veya sonraki iyileştirmeleri inceleme.
Navigasyon özelliği için ajandan, özellik kapalıyken eski kenar çubuğunu korumasını, açıkken yeni üç parçalı düzeni göstermesini, mevcut mobil çekmeceyi tutmasını ve kullanıcıların sabitlenmiş ajanları yeniden sıralamasına izin vermesini istedim.
Uygulama sırasında ajan önemli bir sorun buldu. Eski ürün hangi ajanların sabitlendiğini hatırlıyordu, ancak sıralarını hatırlamıyordu. Bir sürükleme etkileşimi doğru görünebilir, ancak yenilendikten sonra sıfırlanabilirdi.
Yani ajan sadece sürükleme durumunu çizmekle kalmadı. Yeni sıralamayı kalıcı hale getirdi, sayfayı yeniledi ve sıralamanın korunduğunu kontrol etti. Ayrıca yeniden sıralama tutamaçlarının yalnızca sürükleme sırasında görünüp sonrasında kaybolduğunu doğruladı.
Uygulama teslimatı, gözden geçirmem gereken iki masaüstü durumu gösterdi. Arayüz okunaklı kalsın diye tam genişlikte gösteriyorum. Mobil davranış daha sonra walkthrough'da yüksek yoğunluklu telefon görüntüsü olarak yer alıyor.
Masaüstü bekleme durumu
Aktif yeniden sıralama
Bu noktada elimde çalışan bir özellik vardı, başka bir tasarım dosyası değil. Ancak uygulama yine de son değildi. Dağıtılmış önizlemede gerçekten neyin çalıştığını görmem gerekiyordu.
4. Gerçek ürünü gözden geçirmek için ui-walkthrough kullanın
Ürün walkthrough'ları eskiden zahmetliydi. Dağıtılmış önizlemeyi açar, doğru hesabı hazırlar, özellikleri açıp kapatır, her kontrolü tıklar, tarayıcıyı yeniden boyutlandırır, ekran görüntüleri alır ve her görselin hangi durumu temsil ettiğini hatırlamaya çalışırdım.
Ajanın yerleşik Agent Browser'ı var, bu yüzden bu işi ona devredebiliyorum.
Akışın iki ana adımı var:
- Önce senaryoları listele. Ajan, tasarım ve uygulama iddialarını bir kontrol listesine dönüştürür.
- Kontrol listesini çalıştır ve kanıt ekle. Dağıtılmış önizlemede her senaryoyu uygular ve her anlamlı durum için PASS, FAIL veya BLOCKED ile ekran görüntüsü döndürür.
Bu talimat incelemede neyi değiştiriyor
- Ajan, tıklamaya başlamadan önce senaryoları listeler.
- Yerleşik Agent Browser ile gerçek dağıtılmış bileşeni kullanır.
- Her anlamlı durum için bir ekran görüntüsü yakalar.
- Her kontrol noktasını PASS, FAIL veya BLOCKED olarak işaretler.
- Ulaşılamayan bir durumu sahte kanıtla gizlemez.
Bu, manuel tıklamayı düzenli bir inceleme paketine dönüştürür. Amaçlanan davranışı, sonucu ve kanıtı birlikte görebilirim.
Tam talimat aşağıdadır. Okuyucuya açıklık için iç bağımlılık adını “yerleşik Agent Browser” olarak çevirdim; akış mantığı aynen korunmuştur.
Tam orijinal ui-walkthrough talimatı
# 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.
Bu, özellikle walkthrough için verilen istemdi:
/ui-walkthroughDağıtılmış önizlemeyi yalnızca yerleşik Agent Browser ile gerçek tarayıcı olarak kullan. Özellik kapalı kenar çubuğu, 68px ve 300px bölme, hedef sırası, üzerine gelme durumları, beş sabitlenmiş yuva, yalnızca sürüklemede tutamaçlar, kalıcı yeniden sıralama, başlık seçimi, kaydırma ve tam iPhone çekmecesini kanıtla. Her kontrol noktası için PASS, FAIL veya BLOCKED döndür. Ulaşılamayan bir durumu kopya ile değiştirme.
Bu özellik için ajan walkthrough'u şu sorular etrafında organize etti:
- Özellik kapalıyken eski kenar çubuğu hâlâ çalışıyor mu?
- Özellik açıkken yeni masaüstü yapısı görünüyor mu?
- Üzerine gelme ve seçili durumlar görünür ama sade mi?
- Beş sabitlenmiş ajan okunabiliyor mu?
- Yeniden sıralama kontrolleri sürükleme başlayana kadar gizli mi kalıyor?
- Yeni sıra yenilemeden sonra korunuyor mu?
- Gerçek başlıklar seçilip kaydırılabiliyor mu?
- Mevcut mobil çekmece hâlâ çalışıyor mu?
- Tüm gezinme hedefleri mevcut ve doğru sırada mı?
Ajan ardından dağıtılmış önizlemeyi yeni bir kullanıcı olarak açtı, onboarding'i tamamladı, özelliği etkinleştirdi ve listeyi uyguladı. Bekleme durumu, üzerine gelme durumu, sürükleme durumu, yenileme davranışı, başlık seçimi, kaydırma ve telefon düzenini test etti.
Sonuç 11 PASS, 1 FAIL oldu.
Başarısızlık faydalıydı. Düzen ve etkileşimler çalıştı, ancak dağıtılmış önizleme yalnızca altı ürün hedefi gösterdi. Activity ve Insights eksikti ve sıra seçilen tasarımla eşleşmiyordu.
| Senaryo | Sonuç |
|---|---|
| Özellik kapalı eski kenar çubuğu | PASS |
| Yeni üç parçalı masaüstü düzeni | PASS |
| Üzerine gelme ve seçili durumlar | PASS |
| Beş sabitlenmiş ajan | PASS |
| Yalnızca sürüklemede yeniden sıralama rehberi | PASS |
| Yenilemeden sonra kaydedilen sıra | PASS |
| Başlık seçimi ve kaydırma | PASS |
| Mevcut mobil çekmece | PASS |
| Hedef içeriği ve sırası | FAIL |
Son teslimat, etiketlenmemiş görseller klasörü yerine düzenli bir ekran görüntüsü setiydi. Masaüstü görüntüleri 1440 × 900 piksel, telefon görüntüsü ise 1170 × 2532 piksel. Arayüz okunaklı kalsın diye aşağıda tek tek gösteriliyor; herhangi bir görsele tıklayarak makaleden çıkmadan büyütebilirsiniz.
Özellik kapalı
Özellik etkin
Masaüstü düzeni
Hedef üzerine gelme
Sabitlenmiş ajan üzerine gelme
Aktif sürükleme
Kaydedilen sıra
Mobil çekmece
Bu, bir özelliği yapılandırılmış şekilde gözden geçirmemi sağlar. Amaçlanan senaryoları, gerçek dağıtılmış sonucu ve kanıtı birlikte görebilirim. Bir şey başarısız olursa, işin nereye döneceğini tam olarak bilirim.
Bir ekip bu yapay zekâ ürün tasarım akışını nasıl benimser?
Tüm süreç kısadır. Ekip arkadaşları her aşamayı paylaşılan bir Zero akışı olarak kaydedebilir, böylece süreci hafızadan yeniden inşa etmeye gerek kalmaz.
| Aşama | Girdi | Çıktı |
|---|---|---|
ui-design | Mevcut ekran, sorun, hedef ve kısıtlar | Bir önerilen yön, dokuz alternatif ve seçilen tasarım kaydı |
ui-implement | Seçilen tasarım kaydı | Gözden geçirilebilir kod değişikliği ve ana durumların ekran görüntüleri |
ui-walkthrough | Dağıtılmış özellik ve beklenen davranışı | PASS, FAIL veya BLOCKED ekran görüntüleriyle düzenli senaryo listesi |
Bir ekip arkadaşının benim tasarım zevkimi kopyalaması gerekmez. İyi bağlam sağlamalı, paylaşılan ürün sistemini kullanmalı, keşiften sonra açık bir seçim yapmalı ve tarayıcı kanıtını gözden geçirmelidir. Aynı üç insan kontrol noktası—sorun, yön ve kabul—AI ajanlarını bir ekip gibi yönetmemizi de şekillendirir.
Bu akış tasarım pratiğini veya tasarım düşüncesini ortadan kaldırmaz. Onları en önemli yerlere taşır: sorunu tanımlamak, kısıtları belirlemek, yönleri karşılaştırmak, artı-eksi seçmek ve çalışan ürünü değerlendirmek.
Bileşen sistemi olgunlaştığında, artık her özelliği Figma'da sürüklenebilir bloklar olarak yeniden inşa etmeme gerek kalmaz. Ajana doğrudan üründe çalışabilirim; tasarım sistemi çıktıyı tutarlı tutar, walkthrough ise sonucu dürüst kılar.
Sıkça sorulan sorular
Yapay zekâ ürün tasarım akışı nasıl kurulur?
Mevcut ürün sistemiyle başlayın, boş bir istemle değil. Çalışmayı keşif, uygulama ve inceleme olarak ayırın. Ajana seçenekler ürettirin ve tekrarlanabilir kontroller yaptırın, ancak ürün tasarımcısı sorundan, seçilen yönden ve son kabulden sorumlu kalmalı.
Ürün tasarımcıları Figma olmadan çalışabilir mi?
Evet, ürünün zaten stabil bileşenleri, sayfa şablonları ve etkileşim kalıpları varsa. Figma, yeni bir görsel dil veya alışılmadık bir etkileşim için hâlâ faydalıdır. Amaç Figma'yı yasaklamak değil; bilinen ürün kararlarını ikinci bir tuvalde yeniden inşa etmekten kaçınmaktır.
Yapay zekâ ürün tasarımcılarının yerini alıyor mu?
Bu akışta hayır. Ajan seçenekleri birleştirir, kodu düzenler ve senaryoları kontrol eder. Tasarımcı hâlâ sorunu çerçeveler, kısıtları belirler, artı-eksileri karşılaştırır, yönü seçer ve çalışan ürünün gönderilmeye değer olup olmadığına karar verir.
