Quy trình Thiết kế Sản phẩm AI của tôi mà không cần Figma

Thiết kế sản phẩm mà không cần Figma vẫn hiệu quả khi sản phẩm đã có hệ thống thiết kế trưởng thành. Quy trình thiết kế sản phẩm AI của tôi sử dụng ba kỹ năng của agent: ui-design khám phá chín hướng, ui-implement biến hướng đã chọn thành sản phẩm, và ui-walkthrough kiểm tra mọi trạng thái qua Agent Browser tích hợp. Tôi vẫn là người ra quyết định; agent xử lý các công việc lặp lại và kiểm tra.

Hầu hết các tính năng sản phẩm không bắt đầu từ trang trắng. Khi sản phẩm đã tồn tại một thời gian, các quyết định thiết kế cơ bản đã có trong mã nguồn. Nút bấm, trường nhập, thẻ, điều hướng, khoảng cách, màu sắc, nội dung, trạng thái hover và hành vi trên di động đều đã được xác định. Việc dựng lại các thành phần này trong Figma thường chỉ là kéo các thành phần giống nhau lên một canvas khác rồi lại dựng lại trong sản phẩm.

Nhà thiết kế vẫn là người quyết định sản phẩm. Agent loại bỏ phần lớn công đoạn lắp ráp và kiểm tra lặp lại. Điều này hiệu quả vì Zero đã có hệ thống thiết kế khá trưởng thành.

1. Bắt đầu thiết kế sản phẩm không cần Figma với hệ thống thiết kế

Làm việc không có Figma không có nghĩa là không có quy tắc thiết kế. Ngược lại, cần quy tắc rõ ràng hơn.

Với Zero, agent có thể kiểm tra:

• Các thành phần hiện có như nút, trường nhập, dropdown, thẻ, hộp thoại và điều hướng
• Khoảng cách, kiểu chữ, màu sắc, viền và bán kính góc đã được thiết lập
• Các trạng thái hover, đã chọn, bị vô hiệu hóa, trống và trên di động
• Quy tắc nội dung như viết hoa đầu câu và nhãn ngắn hướng tới người dùng
• Màn hình thực tế thể hiện cách các thành phần này kết hợp với nhau

Những tham chiếu này trả lời các câu hỏi thiết kế thông thường. Một trường nhập mới nên giống các trường nhập đã có. Một thẻ mới nên dùng cùng bề mặt và bán kính với thẻ gần nhất. Nút icon nên có phản hồi hover giống các nút icon khác.

Điều này tạo ranh giới cho agent. Nó có thể khám phá cấu trúc tính năng mà không sáng tạo ra ngôn ngữ hình ảnh mới cho từng màn hình.

Figma vẫn hữu ích khi nhóm tạo thương hiệu mới, hệ thống thành phần mới hoặc một tương tác chưa có tham chiếu sản phẩm gần nhất. Nhưng khi hệ thống đã trưởng thành, sản phẩm đang chạy có thể trở thành bề mặt thiết kế chính. Đây là phiên bản ở quy mô tính năng của quy trình thiết kế như mã mà chúng tôi dùng để xây dựng lại Zero.

2. Dùng ui-design để khám phá chín hướng thiết kế sản phẩm

Mỗi tính năng vẫn cần được khám phá. Tôi không muốn agent lấy câu đầu tiên của tôi rồi lập tức biến nó thành mã.

Tôi bắt đầu với ui-design. Tôi cung cấp cho agent màn hình hiện tại, vấn đề người dùng, mục tiêu và các ràng buộc chính. Agent đọc các mẫu sản phẩm hiện có và trả về một hướng đề xuất cùng chín phương án thay thế.

Nói đơn giản, kỹ năng này chụp lại màn hình hiện tại, tạo một hướng đề xuất, khám phá chín phương án khác biệt, trình bày các điểm đánh đổi và chờ con người lựa chọn.

Tư duy thiết kế trong hướng dẫn này

Hướng dẫn này không chỉ là danh sách quy tắc hình ảnh. Nó biến quy trình thông thường của nhà thiết kế thành chuỗi lặp lại được:

1. Hiểu trước khi đề xuất. Chụp màn hình hiện tại và đọc sản phẩm xung quanh trước khi làm gì đó.
2. Tư duy hệ thống. Xem các thành phần, trang mẫu, mẫu tương tác và quy tắc nội dung hiện có là vật liệu khởi đầu.
3. Ngăn tái phát minh. AI thường tạo mẫu mới khi prompt mơ hồ. Hướng dẫn yêu cầu tìm thành phần hoặc trang gần nhất đã phát hành và tái sử dụng thay vì đoán từ trí nhớ.
4. Khám phá trước khi chọn. Hướng After đưa ra một phương án hợp lý. Chín biến thể mở ra các quyết định khác về bố cục, thứ bậc, mật độ, điểm vào và cách hiển thị.
5. Tách biệt khám phá và cam kết. Agent dừng lại sau khi trình bày các lựa chọn. Con người so sánh các điểm đánh đổi và chọn trước khi bắt đầu mã hóa.
6. Kiểm tra toàn bộ trải nghiệm. Nội dung, phản hồi hover, trạng thái, hành vi di động và tính nhất quán hình ảnh là một phần của thiết kế, không phải dọn dẹp sau khi triển khai.

Đó là tư duy hệ thống tôi muốn từ kỹ năng này: hiểu sản phẩm hiện có, khám phá trong phạm vi đó, rồi đưa ra lựa chọn rõ ràng.

Đây là hướng dẫn gốc đầy đủ, trích nguyên văn từ quy trình đang chạy:

Hướng dẫn gốc đầy đủ của 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.

Chín phương án không cần là chín thiết kế hoàn chỉnh. Vai trò của chúng là giúp tôi nhìn vấn đề theo nhiều hướng và tiến gần hơn tới hướng đúng. Nếu một ý tưởng nằm ngoài sản phẩm hiện tại, một prototype React độc lập vẫn hữu ích. Với tính năng này, tôi ở lại trong hệ thống sản phẩm thực tế.

Ví dụ thực tế: điều hướng của Zero

Ban đầu Zero có một sidebar rộng 300 pixel chứa điểm đến sản phẩm, agent được ghim và các luồng chat. Nó đảm nhận ba vai trò cùng lúc. Tôi muốn tách các vai trò này mà không thay đổi khu vực hội thoại.

Bản tóm tắt sản phẩm cho giai đoạn khám phá là:

/ui-design

Phát lại giai đoạn thiết kế cho điều hướng ba vùng của Zero từ nền tảng lịch sử thực tế. Tách biệt điểm đến sản phẩm, agent và hội thoại thành các vùng rõ ràng hơn mà không thay đổi khu vực hội thoại. Sử dụng token, icon và thành phần thực của Zero. Tạo bản Before trung thực, một bản After mạnh và chín biến thể thực sự khác biệt. Không chỉnh sửa mã sản phẩm hoặc trình bày mockup như bằng chứng trình duyệt.

Lần khám phá đầu tiên quá thận trọng. Một số phương án thay đổi chiều rộng và kiểu chọn, nhưng vẫn giống sidebar cũ. Tôi loại bỏ bộ đó và yêu cầu agent làm cho sự khác biệt rõ ràng ở cấp độ kiến trúc thông tin.

Lần chạy thứ hai trả về chín hướng thực sự khác biệt. Tôi nhóm chúng thành bảng 3 × 3 để dễ so sánh mà không biến bài viết thành dải ảnh dài. Mỗi hình thu nhỏ mở trong trình xem ảnh của blog.

1. Điều hướng trên cùng	2. Ngăn kéo thu gọn	3. Ưu tiên luồng chat
Đưa điểm đến lên trên khu vực hội thoại	Ẩn điểm đến cho đến khi cần	Đặt hội thoại làm đối tượng điều hướng chính
4. Ưu tiên agent	5. Ưu tiên hội thoại	6. Bộ khởi chạy lệnh
Chọn agent trước khi vào luồng chat	Đặt agent được ghim lên trên hội thoại đang hoạt động	Mở điểm đến từ menu tìm kiếm
7. Thanh ray mở rộng	8. Vào từ dashboard	9. Dock dưới cùng
Chỉ mở rộng thanh ray hẹp khi cần	Bắt đầu từ công việc gần đây	Đưa điểm đến xuống dưới cùng

Tôi không chọn một khung nào đúng như bản vẽ. Tôi dùng chúng để quyết định phần nào giữ lại, phần nào thay đổi. Hướng cuối cùng dùng một thanh ray điểm đến hẹp, một thanh chat riêng, năm agent được ghim hiển thị và khu vực hội thoại giữ nguyên.

Kết quả quan trọng của ui-design không chỉ là hình ảnh. Đó là bản ghi quyết định ngắn:

• Giữ thanh ray điểm đến 68 pixel và thanh chat 300 pixel
• Hiển thị năm vị trí agent được ghim
• Giữ kiểu chọn yên tĩnh nhưng dễ đọc
• Chỉ hiển thị hướng dẫn sắp xếp lại khi đang kéo
• Giữ nguyên khu vực hội thoại và ngăn kéo di động hiện có

Như vậy là đủ để bắt đầu triển khai.

3. Dùng ui-implement để biến thiết kế đã chọn thành mã

Sau khi tôi chọn hướng và kết nối mã nguồn sản phẩm, agent làm việc trực tiếp trên mã. Tôi không vẽ lại khung đã chọn trong Figma trước.

Nói đơn giản, ui-implement bỏ qua bước khám phá vì hướng đã được chọn. Nó tìm thành phần và cấu trúc trang gần nhất, xây dựng với chúng, tự kiểm tra kết quả và xác nhận tính năng trong trình duyệt.

Điều hướng dẫn này bảo vệ

• Hướng đã chọn không được thiết kế lại trong quá trình triển khai.
• Agent phải bắt đầu từ thành phần và trang mẫu gần nhất.
• Tái sử dụng được ưu tiên hơn tạo thành phần mới trừ khi sản phẩm thực sự thiếu.
• Tự kiểm tra và kiểm tra trình duyệt phát hiện nội dung, trạng thái và tương tác không nhất quán.
• Nếu quyết định sản phẩm chưa rõ, công việc quay lại ui-design.

Đây là cách hệ thống thiết kế luôn hoạt động trong quá trình triển khai. Nó không phải tài liệu agent chỉ đọc một lần. Nó quyết định agent chọn thành phần nào và kiểm tra trải nghiệm hoàn thiện ra sao.

Đây là hướng dẫn gốc đầy đủ, trích nguyên văn từ quy trình đang chạy:

Hướng dẫn gốc đầy đủ của 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.

Đây là prompt triển khai dành riêng cho tính năng:

/ui-implement

Bắt đầu từ bản sửa đổi 04d642bb. Thêm chế độ chia desktop mặc định tắt với thanh ray điểm đến 68px, thanh chat 300px và khu vực hội thoại giữ nguyên. Giữ sidebar cũ 300px khi tắt chuyển đổi và trên di động. Hiển thị năm vị trí ghim, giữ thứ tự do người dùng xác định và chỉ hiển thị hướng dẫn sắp xếp lại khi đang kéo. Không kiểm tra tính năng lịch sử hoặc các cải tiến sau cho đến khi bản vá độc lập, kiểm thử và bằng chứng trình duyệt đã hoàn tất.

Với tính năng điều hướng, tôi yêu cầu agent giữ sidebar cũ khi tính năng tắt, hiển thị bố cục ba phần mới khi bật, giữ ngăn kéo di động hiện có và cho phép người dùng sắp xếp lại agent được ghim.

Trong quá trình triển khai, agent phát hiện một vấn đề quan trọng. Sản phẩm cũ nhớ agent nào được ghim nhưng không nhớ thứ tự. Tương tác kéo có thể trông đúng nhưng sẽ đặt lại sau khi làm mới.

Vì vậy, agent không chỉ vẽ trạng thái kéo. Nó làm cho thứ tự mới được lưu, làm mới trang và kiểm tra thứ tự vẫn giữ nguyên. Nó cũng xác nhận rằng tay cầm sắp xếp chỉ xuất hiện khi đang kéo và biến mất sau đó.

Bản bàn giao triển khai hiển thị hai trạng thái desktop tôi cần kiểm tra. Tôi trình bày chúng ở toàn bộ chiều rộng để giao diện dễ đọc. Hành vi di động xuất hiện sau trong walkthrough dưới dạng ảnh chụp màn hình điện thoại mật độ cao.

Trạng thái nghỉ desktop

Đang sắp xếp lại

Lúc này tôi đã có tính năng hoạt động, không phải một file thiết kế khác. Nhưng triển khai vẫn chưa phải là kết thúc. Tôi cần xem thực tế đang chạy trong bản preview đã triển khai.

4. Dùng ui-walkthrough để kiểm tra sản phẩm thực tế

Walkthrough sản phẩm từng rất tốn công. Tôi phải mở bản preview đã triển khai, chuẩn bị tài khoản phù hợp, bật tắt tính năng, bấm từng nút, thay đổi kích thước trình duyệt, chụp màn hình và cố nhớ mỗi ảnh là trạng thái nào.

Agent có Agent Browser tích hợp, nên tôi giao việc này cho nó.

Quy trình gồm hai bước chính:

1. Liệt kê kịch bản trước. Agent biến các cam kết thiết kế và triển khai thành checklist.
2. Chạy checklist và đính kèm bằng chứng. Nó thực hiện từng kịch bản trong bản preview đã triển khai và trả về PASS, FAIL hoặc BLOCKED kèm ảnh chụp cho mỗi trạng thái quan trọng.

Điều hướng dẫn này thay đổi về kiểm tra

• Agent liệt kê kịch bản trước khi bắt đầu bấm thử.
• Nó dùng thành phần đã triển khai thực tế qua Agent Browser tích hợp.
• Nó chụp một ảnh cho mỗi trạng thái quan trọng.
• Nó đánh dấu từng checkpoint PASS, FAIL hoặc BLOCKED.
• Nó không bao giờ che giấu trạng thái không có bằng bằng chứng giả.

Việc bấm thử thủ công trở thành gói kiểm tra có tổ chức. Tôi có thể xem hành vi dự kiến, kết quả thực tế và bằng chứng cùng lúc.

Hướng dẫn đầy đủ bên dưới. Tôi đã dịch tên phụ thuộc nội bộ thành “Agent Browser tích hợp” cho rõ ràng với người đọc; logic quy trình không thay đổi.

Hướng dẫn gốc đầy đủ của 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.

Đây là prompt walkthrough dành riêng cho tính năng:

/ui-walkthrough

Sử dụng bản preview đã triển khai qua Agent Browser tích hợp làm nguồn sự thật duy nhất. Chứng minh sidebar khi tắt tính năng, chia 68px và 300px, thứ tự điểm đến, trạng thái hover, năm vị trí ghim, tay cầm chỉ khi kéo, sắp xếp lại được lưu, chọn luồng chat, cuộn và ngăn kéo iPhone đầy đủ. Trả về PASS, FAIL hoặc BLOCKED cho từng checkpoint. Không thay thế trạng thái không thể truy cập bằng bản sao.

Với tính năng này, agent tổ chức walkthrough quanh các câu hỏi:

• Sidebar cũ còn hoạt động khi tắt tính năng không?
• Cấu trúc desktop mới xuất hiện khi bật không?
• Trạng thái hover và đã chọn có rõ ràng nhưng yên tĩnh không?
• Năm agent được ghim có dễ đọc không?
• Điều khiển sắp xếp lại có ẩn cho đến khi kéo không?
• Thứ tự mới có giữ sau khi làm mới không?
• Tôi có thể chọn và cuộn qua các luồng chat thật không?
• Ngăn kéo di động hiện có còn hoạt động không?
• Tất cả điểm đến điều hướng có đủ và đúng thứ tự không?

Agent sau đó mở bản preview đã triển khai như người dùng mới, hoàn thành onboarding, bật tính năng và thực hiện checklist. Nó kiểm tra trạng thái nghỉ, trạng thái hover, trạng thái kéo, hành vi làm mới, chọn luồng chat, cuộn và bố cục điện thoại.

Kết quả là 11 PASS, 1 FAIL.

Lỗi này hữu ích. Bố cục và tương tác hoạt động, nhưng bản preview chỉ hiển thị sáu điểm đến sản phẩm. Activity và Insights bị thiếu, và thứ tự không khớp thiết kế đã chọn.

Kịch bản	Kết quả
Sidebar cũ khi tắt tính năng	PASS
Bố cục desktop ba phần mới	PASS
Trạng thái hover và đã chọn	PASS
Năm agent được ghim	PASS
Hướng dẫn sắp xếp lại chỉ khi kéo	PASS
Thứ tự lưu sau khi làm mới	PASS
Chọn luồng chat và cuộn	PASS
Ngăn kéo di động hiện có	PASS
Nội dung và thứ tự điểm đến	FAIL

Bàn giao cuối cùng là bộ ảnh chụp có tổ chức thay vì thư mục ảnh không nhãn. Ảnh desktop là 1440 × 900 pixel và ảnh điện thoại là 1170 × 2532 pixel. Chúng hiển thị từng cái một bên dưới để giao diện dễ đọc; bấm vào ảnh để phóng to mà không rời bài viết.

Tính năng tắt

Tính năng bật

Bố cục desktop

Hover điểm đến

Hover agent được ghim

Đang kéo

Thứ tự đã lưu

Ngăn kéo di động

Điều này giúp tôi kiểm tra tính năng một cách có cấu trúc. Tôi thấy được kịch bản dự kiến, kết quả thực tế và bằng chứng cùng lúc. Nếu có lỗi, tôi biết chính xác nên quay lại bước nào.

Cách nhóm áp dụng quy trình thiết kế sản phẩm AI này

Toàn bộ quy trình rất ngắn. Thành viên có thể lưu từng giai đoạn thành một quy trình Zero chia sẻ thay vì phải nhớ lại từng bước.

Giai đoạn	Đầu vào	Đầu ra
ui-design	Màn hình hiện tại, vấn đề, mục tiêu và ràng buộc	Một hướng đề xuất, chín phương án thay thế và bản ghi thiết kế đã chọn
ui-implement	Bản ghi thiết kế đã chọn	Thay đổi mã có thể kiểm tra và ảnh chụp các trạng thái chính
ui-walkthrough	Tính năng đã triển khai và hành vi mong đợi	Danh sách kịch bản có ảnh PASS, FAIL hoặc BLOCKED

Thành viên không cần giống gu thiết kế của tôi. Họ chỉ cần cung cấp ngữ cảnh tốt, dùng hệ thống sản phẩm chung, lựa chọn rõ ràng sau khi khám phá và kiểm tra bằng chứng trình duyệt. Ba điểm kiểm tra của con người—vấn đề, hướng đi và chấp nhận—cũng định hình cách chúng tôi quản lý AI agent như một nhóm.

Quy trình này không loại bỏ thực hành hay tư duy thiết kế. Nó chuyển chúng tới các phần quan trọng nhất: xác định vấn đề, đặt ràng buộc, so sánh hướng đi, chọn đánh đổi và đánh giá sản phẩm đang chạy.

Khi hệ thống thành phần đã trưởng thành, tôi không còn phải dựng lại từng tính năng bằng các khối kéo thả trong Figma. Tôi có thể làm việc với agent trực tiếp trong sản phẩm, trong khi hệ thống thiết kế giữ cho đầu ra nhất quán và walkthrough đảm bảo kết quả trung thực.

Câu hỏi thường gặp

Làm thế nào để xây dựng quy trình thiết kế sản phẩm AI?

Bắt đầu từ hệ thống sản phẩm hiện có, không phải prompt trắng. Tách công việc thành khám phá, triển khai và kiểm tra. Để agent tạo phương án và kiểm tra lặp lại, nhưng nhà thiết kế vẫn chịu trách nhiệm về vấn đề, hướng đi và chấp nhận cuối cùng.

Nhà thiết kế sản phẩm có thể làm việc không cần Figma không?

Có, khi sản phẩm đã có thành phần ổn định, trang mẫu và mẫu tương tác. Figma vẫn hữu ích cho ngôn ngữ hình ảnh mới hoặc tương tác lạ. Mục đích không phải cấm Figma; mà là tránh dựng lại quyết định sản phẩm đã biết trên một canvas thứ hai.

AI có thay thế nhà thiết kế sản phẩm không?

Không trong quy trình này. Agent lắp ráp phương án, chỉnh sửa mã và kiểm tra kịch bản. Nhà thiết kế vẫn xác định vấn đề, đặt ràng buộc, so sánh đánh đổi, chọn hướng đi và quyết định sản phẩm chạy đã đủ tốt để phát hành chưa.