การออกแบบผลิตภัณฑ์โดยไม่ใช้ Figma สามารถทำได้เมื่อผลิตภัณฑ์มีระบบดีไซน์ที่สมบูรณ์แล้ว เวิร์กโฟลว์ออกแบบผลิตภัณฑ์ AI ของผมใช้ทักษะเอเจนต์ 3 อย่าง: ui-design สำรวจ 9 แนวทาง, ui-implement เปลี่ยนแนวทางที่เลือกเป็นผลิตภัณฑ์, และ ui-walkthrough ตรวจสอบทุกสถานะผ่าน Agent Browser ที่มีในตัว ผมยังคงเป็นผู้ตัดสินใจ ส่วนเอเจนต์จะจัดการงานผลิตซ้ำและตรวจสอบที่ซ้ำซาก
ฟีเจอร์ส่วนใหญ่ของผลิตภัณฑ์ไม่ได้เริ่มจากศูนย์ เมื่อผลิตภัณฑ์มีอายุสักระยะ การตัดสินใจด้านดีไซน์พื้นฐานจะถูกกำหนดไว้ในโค้ดแล้ว ไม่ว่าจะเป็นปุ่ม อินพุต การ์ด เมนูนำทาง ระยะห่าง สี ข้อความ สถานะ hover และพฤติกรรมบนมือถือ ทั้งหมดนี้ถูกนิยามไว้แล้ว การสร้างชิ้นส่วนเหล่านี้ใหม่ใน Figma มักหมายถึงการลากคอมโพเนนต์เดิมลงบนผืนผ้าใบอีกผืน ก่อนจะสร้างใหม่อีกครั้งในผลิตภัณฑ์
ผู้ออกแบบยังคงเป็นผู้ตัดสินใจในผลิตภัณฑ์ เอเจนต์ช่วยลดงานประกอบและตรวจสอบที่ซ้ำซาก วิธีนี้ใช้ได้เพราะ Zero มีระบบดีไซน์ที่สมบูรณ์ในระดับหนึ่งแล้ว
1. เริ่มออกแบบผลิตภัณฑ์โดยไม่ใช้ Figma ด้วยระบบดีไซน์
การทำงานโดยไม่ใช้ Figma ไม่ได้แปลว่าไม่มีหลักเกณฑ์ดีไซน์ แต่ต้องมีหลักเกณฑ์ที่ชัดเจนกว่าเดิม
สำหรับ Zero เอเจนต์สามารถตรวจสอบได้ว่า
- คอมโพเนนต์ที่มีอยู่ เช่น ปุ่ม อินพุต ดรอปดาวน์ การ์ด ไดอะล็อก และเมนูนำทาง
- ระยะห่าง ตัวอักษร สี เส้นขอบ และรัศมีมุมที่กำหนดไว้แล้ว
- สถานะ hover, เลือก, ปิดใช้งาน, ว่างเปล่า และสถานะบนมือถือที่มีอยู่
- แนวทางการเขียนข้อความ เช่น ตัวพิมพ์ประโยค และป้ายกำกับที่สั้นและเข้าใจง่าย
- หน้าจอจริงที่แสดงการประกอบชิ้นส่วนเหล่านี้
ข้อมูลอ้างอิงเหล่านี้ตอบคำถามดีไซน์ทั่วไป เช่น อินพุตใหม่ควรมีหน้าตาเหมือนอินพุตที่มีอยู่แล้ว การ์ดใหม่ควรใช้พื้นผิวและรัศมีเดียวกับการ์ดที่ใกล้เคียงที่สุด ปุ่มไอคอนควรมีฟีดแบ็ก hover เหมือนปุ่มไอคอนอื่น ๆ
สิ่งนี้กำหนดขอบเขตให้เอเจนต์ สามารถสำรวจโครงสร้างฟีเจอร์โดยไม่ต้องสร้างภาษาภาพใหม่ให้ทุกหน้าจอ
Figma ยังมีประโยชน์เมื่อทีมสร้างแบรนด์ใหม่ ระบบคอมโพเนนต์ใหม่ หรือปฏิสัมพันธ์ที่ไม่มีตัวอย่างในผลิตภัณฑ์ แต่เมื่อระบบสมบูรณ์แล้ว ผลิตภัณฑ์ที่ใช้งานจริงสามารถเป็นพื้นที่ออกแบบหลักได้ นี่คือเวอร์ชันระดับฟีเจอร์ของ เวิร์กโฟลว์ design-as-code ที่เราใช้สร้าง Zero ใหม่
2. ใช้ ui-design เพื่อสำรวจ 9 แนวทางออกแบบผลิตภัณฑ์
ทุกฟีเจอร์ยังต้องการการสำรวจ ผมไม่ต้องการให้เอเจนต์นำประโยคแรกของผมไปแปลงเป็นโค้ดทันที
ผมเริ่มด้วย ui-design ผมให้เอเจนต์ดูหน้าจอปัจจุบัน ปัญหาของผู้ใช้ เป้าหมาย และข้อจำกัดหลัก เอเจนต์จะอ่านรูปแบบผลิตภัณฑ์ที่มีอยู่และส่งคืนแนวทางแนะนำ 1 แนวทาง พร้อมทางเลือกอีก 9 แนวทาง
โดยสรุป ทักษะนี้จะจับภาพหน้าจอปัจจุบัน สร้างแนวทางแนะนำ 1 แนวทาง สำรวจทางเลือกที่แตกต่างกัน 9 แบบ นำเสนอข้อดีข้อเสีย และรอให้มนุษย์เลือก
กระบวนการคิดเชิงออกแบบในคำสั่งนี้
คำสั่งนี้ไม่ใช่แค่รายการกฎภาพลักษณ์ แต่เปลี่ยนกระบวนการปกติของนักออกแบบให้เป็นลำดับที่ทำซ้ำได้:
- เข้าใจก่อนเสนอ จับภาพหน้าจอปัจจุบันและอ่านบริบทผลิตภัณฑ์ก่อนสร้างสิ่งใด
- คิดเป็นระบบ ใช้คอมโพเนนต์ หน้าเทมเพลต รูปแบบปฏิสัมพันธ์ และกฎข้อความที่มีอยู่เป็นจุดเริ่มต้น
- ป้องกันการสร้างใหม่โดยไม่จำเป็น AI มักสร้างรูปแบบใหม่เมื่อคำสั่งคลุมเครือ คำสั่งนี้บอกให้หาองค์ประกอบหรือหน้าที่ใกล้เคียงที่สุดและนำมาใช้ซ้ำ แทนที่จะเดาจากความจำ
- สำรวจก่อนตัดสินใจ แนวทาง After ให้ทางเลือกที่เป็นไปได้ 1 แบบ ส่วน 9 ทางเลือกเปิดโอกาสให้ตัดสินใจเรื่องเลย์เอาต์ ลำดับชั้น ความหนาแน่น จุดเริ่มต้น และการเปิดเผยข้อมูลที่ต่างกัน
- แยกการสำรวจออกจากการตัดสินใจ เอเจนต์หยุดหลังนำเสนอทางเลือก มนุษย์เปรียบเทียบข้อดีข้อเสียและเลือกก่อนเริ่มโค้ด
- รีวิวประสบการณ์ทั้งหมด ข้อความ ฟีดแบ็ก hover สถานะ พฤติกรรมบนมือถือ และความสอดคล้องของภาพเป็นส่วนหนึ่งของดีไซน์ ไม่ใช่งานเก็บรายละเอียดหลังพัฒนา
นี่คือการคิดเชิงระบบที่ผมต้องการจากทักษะนี้: เข้าใจผลิตภัณฑ์ที่มีอยู่ สำรวจภายในขอบเขตนั้น แล้วเลือกอย่างชัดเจน
นี่คือคำสั่งต้นฉบับแบบเต็ม คัดลอกจากเวิร์กโฟลว์จริง:
คำสั่งต้นฉบับ 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.
9 ทางเลือกไม่จำเป็นต้องเป็นดีไซน์ที่เสร็จสมบูรณ์ จุดประสงค์คือให้ผมเห็นปัญหาในมุมที่ต่างกันและขยับไปสู่แนวทางที่ถูกต้อง หากแนวคิดใดอยู่นอกผลิตภัณฑ์ปัจจุบัน React prototype แบบแยกเดี่ยว ก็ยังช่วยได้ สำหรับฟีเจอร์นี้ ผมอยู่ในระบบผลิตภัณฑ์จริง
ตัวอย่างจริง: เมนูนำทางของ Zero
Zero เดิมมีแถบด้านข้างกว้าง 300 พิกเซล รวมปลายทางผลิตภัณฑ์ เอเจนต์ที่ปักหมุด และเธรดแชทไว้ด้วยกัน มันทำงาน 3 อย่างพร้อมกัน ผมต้องการแยกหน้าที่เหล่านั้นโดยไม่เปลี่ยนพื้นที่สนทนา
บรีฟผลิตภัณฑ์สำหรับการสำรวจนี้คือ:
/ui-designเล่นซ้ำขั้นตอนออกแบบเมนูนำทาง 3 ส่วนของ Zero จากฐานประวัติจริง แยกปลายทางผลิตภัณฑ์ เอเจนต์ และการสนทนาให้อยู่ในส่วนที่ชัดเจนขึ้นโดยไม่เปลี่ยนพื้นที่สนทนา ใช้โทเคน ไอคอน และคอมโพเนนต์ของ Zero จริง สร้าง Before ที่ตรงกับต้นฉบับ After ที่แข็งแรง 1 แบบ และทางเลือกที่แตกต่างกันจริง 9 แบบ ห้ามแก้ไขโค้ดผลิตภัณฑ์หรือแสดง mockup เป็นหลักฐานเบราว์เซอร์
การสำรวจครั้งแรกยังระมัดระวังเกินไป หลายทางเลือกเปลี่ยนความกว้างและสไตล์การเลือก แต่ยังดูเหมือนแถบด้านข้างเดิม ผมปฏิเสธชุดนั้นและขอให้เอเจนต์ทำให้ความแตกต่างชัดเจนในระดับโครงสร้างข้อมูล
การรันครั้งที่สองได้ 9 แนวทางที่แตกต่างกันจริง ผมจัดกลุ่มเป็นตาราง 3 × 3 เพื่อเปรียบเทียบง่ายโดยไม่ต้องแปลงบทความเป็นแถบภาพยาว ๆ ทุกภาพขนาดย่อสามารถเปิดดูในตัวดูภาพของบล็อก
| 1. เมนูนำทางด้านบน | 2. ลิ้นชักพับได้ | 3. เน้นเธรด |
|---|---|---|
 |  |  |
| ย้ายปลายทางไว้เหนือพื้นที่สนทนา | ซ่อนปลายทางจนกว่าจะต้องใช้ | ทำให้การสนทนาเป็นวัตถุหลักของเมนูนำทาง |
| 4. เน้นเอเจนต์ | 5. เน้นการสนทนา | 6. ตัวเรียกคำสั่ง |
 |  |  |
| เลือกเอเจนต์ก่อนเลือกเธรด | วางเอเจนต์ที่ปักหมุดไว้เหนือการสนทนาที่ใช้งาน | เปิดปลายทางจากเมนูค้นหาได้ |
| 7. รางขยายได้ | 8. เข้าผ่านแดชบอร์ด | 9. ท่าเรือด้านล่าง |
 |  |  |
| ขยายรางแคบเมื่อจำเป็น | เริ่มจากงานล่าสุด | ย้ายปลายทางไปไว้ด้านล่าง |
ผมไม่ได้เลือกกรอบใดกรอบหนึ่งตามภาพเป๊ะ ๆ แต่ใช้เพื่อช่วยตัดสินใจว่าอะไรควรอยู่ อะไรควรเปลี่ยน ทิศทางสุดท้ายใช้รางปลายทางแคบ รางแชทแยก 5 ช่องเอเจนต์ที่ปักหมุด และพื้นที่สนทนาเดิม
ผลลัพธ์สำคัญของ ui-design ไม่ใช่แค่ภาพ แต่เป็นบันทึกการตัดสินใจสั้น ๆ:
- คงรางปลายทางกว้าง 68 พิกเซล และรางแชทกว้าง 300 พิกเซล
- แสดงช่องเอเจนต์ที่ปักหมุด 5 ช่อง
- การเลือกต้องเงียบแต่ชัดเจน
- แสดงคำแนะนำการจัดเรียงใหม่เฉพาะขณะลาก
- คงพื้นที่สนทนาและลิ้นชักมือถือเดิมไว้
เท่านี้ก็เริ่มพัฒนาได้แล้ว
3. ใช้ ui-implement เพื่อเปลี่ยนดีไซน์ที่เลือกเป็นโค้ด
หลังจากเลือกแนวทางและเชื่อมต่อโค้ดเบสของผลิตภัณฑ์แล้ว เอเจนต์จะทำงานในโค้ดโดยตรง ผมไม่ต้องวาดเฟรมที่เลือกใหม่ใน Figma ก่อน
โดยสรุป ui-implement ข้ามขั้นตอนสำรวจเพราะเลือกแนวทางแล้ว มันจะหาคอมโพเนนต์จริงและโครงสร้างหน้าที่ใกล้เคียงที่สุด สร้างด้วยสิ่งเหล่านั้น ตรวจสอบผลลัพธ์ และยืนยันฟีเจอร์ในเบราว์เซอร์
สิ่งที่คำสั่งนี้ปกป้อง
- แนวทางที่เลือกไม่ควรถูกออกแบบใหม่ระหว่างพัฒนา
- เอเจนต์ต้องเริ่มจากคอมโพเนนต์และหน้าเทมเพลตที่ใกล้เคียงที่สุด
- การนำกลับมาใช้ซ้ำสำคัญกว่าการสร้างคอมโพเนนต์ใหม่ เว้นแต่ผลิตภัณฑ์จะขาดจริง ๆ
- การตรวจสอบตัวเองและเช็คในเบราว์เซอร์จะจับข้อความ สถานะ และปฏิสัมพันธ์ที่ไม่สอดคล้อง
- หากการตัดสินใจยังไม่จบ งานจะย้อนกลับไปที่
ui-design
นี่คือวิธีที่ระบบดีไซน์ยังคงมีบทบาทระหว่างพัฒนา มันไม่ใช่เอกสารที่เอเจนต์อ่านครั้งเดียว แต่กำหนดว่าคอมโพเนนต์ไหนจะถูกเลือกและตรวจสอบประสบการณ์ที่เสร็จแล้วอย่างไร
นี่คือคำสั่งต้นฉบับแบบเต็ม คัดลอกจากเวิร์กโฟลว์จริง:
คำสั่งต้นฉบับ 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.
นี่คือพรอมต์สำหรับการพัฒนาเฉพาะฟีเจอร์นี้:
/ui-implementเริ่มจากรีวิชัน
04d642bbเพิ่มการแยกหน้าจอเดสก์ท็อปแบบปิดค่าเริ่มต้น โดยมีรางปลายทาง 68px รางแชท 300px และพื้นที่สนทนาเดิม คงแถบด้านข้าง 300px เดิมเมื่อปิดสวิตช์และบนมือถือ แสดงช่องปักหมุด 5 ช่อง รักษาลำดับที่ผู้ใช้กำหนด และแสดงตัวช่วยจัดเรียงใหม่เฉพาะขณะลาก ห้ามตรวจสอบฟีเจอร์เก่าหรือการปรับปรุงภายหลังจนกว่าจะแพตช์อิสระ ทดสอบ และมีหลักฐานเบราว์เซอร์ครบ
สำหรับฟีเจอร์เมนูนำทางนี้ ผมขอให้เอเจนต์คงแถบด้านข้างเดิมเมื่อปิดฟีเจอร์ แสดงเลย์เอาต์ 3 ส่วนใหม่เมื่อเปิด คงลิ้นชักมือถือเดิม และให้ผู้ใช้จัดเรียงเอเจนต์ที่ปักหมุดใหม่ได้
ระหว่างพัฒนา เอเจนต์พบปัญหาสำคัญอย่างหนึ่ง ผลิตภัณฑ์เดิมจำได้ว่าเอเจนต์ไหนถูกปักหมุด แต่ไม่จำลำดับการปักหมุด การลากอาจดูถูกต้องแต่รีเซ็ตหลังรีเฟรช
ดังนั้นเอเจนต์จึงทำมากกว่าการวาดสถานะลาก มันทำให้ลำดับใหม่คงอยู่ รีเฟรชหน้า และตรวจสอบว่าลำดับยังคงอยู่ นอกจากนี้ยังยืนยันว่าตัวจับจัดเรียงใหม่จะปรากฏเฉพาะขณะลากและหายไปหลังจากนั้น
การส่งมอบงานแสดงสถานะเดสก์ท็อป 2 แบบที่ผมต้องรีวิว ผมแสดงแบบเต็มความกว้างเพื่อให้ส่วนติดต่ออ่านง่าย พฤติกรรมบนมือถือจะปรากฏใน walkthrough เป็นภาพจับหน้าจอมือถือความหนาแน่นสูง
สถานะพักเดสก์ท็อป
กำลังจัดเรียงใหม่
ถึงจุดนี้ผมมีฟีเจอร์ที่ใช้งานได้จริง ไม่ใช่แค่ไฟล์ดีไซน์อีกไฟล์ แต่การพัฒนายังไม่จบ ผมต้องดูว่าฟีเจอร์ทำงานจริงใน deployed preview หรือไม่
4. ใช้ ui-walkthrough เพื่อตรวจสอบผลิตภัณฑ์จริง
การ walkthrough ผลิตภัณฑ์เคยเป็นงานน่าเบื่อ ผมต้องเปิด deployed preview เตรียมบัญชี เปิด-ปิดฟีเจอร์ คลิกทุกปุ่ม ปรับขนาดเบราว์เซอร์ ถ่ายภาพหน้าจอ และพยายามจำว่าสถานะไหนเป็นภาพไหน
เอเจนต์มี Agent Browser ในตัว ผมจึงมอบงานนี้ให้มันได้
เวิร์กโฟลว์นี้มี 2 ขั้นตอนหลัก:
- ลิสต์สถานการณ์ก่อน เอเจนต์จะแปลงข้ออ้างอิงดีไซน์และการพัฒนาเป็นเช็กลิสต์
- รันเช็กลิสต์และแนบหลักฐาน มันจะดำเนินการแต่ละสถานการณ์ใน deployed preview และส่งคืน PASS, FAIL หรือ BLOCKED พร้อมภาพหน้าจอของแต่ละสถานะสำคัญ
สิ่งที่คำสั่งนี้เปลี่ยนในการรีวิว
- เอเจนต์ลิสต์สถานการณ์ก่อนเริ่มคลิก
- ใช้คอมโพเนนต์ที่ deploy จริงผ่าน Agent Browser ในตัว
- จับภาพหน้าจอ 1 ภาพต่อสถานะสำคัญ
- ทำเครื่องหมายแต่ละจุดตรวจเป็น PASS, FAIL หรือ BLOCKED
- ไม่เคยซ่อนสถานะที่ไม่มีอยู่จริงด้วยหลักฐานจำลอง
สิ่งนี้เปลี่ยนการคลิกด้วยมือเป็นชุดรีวิวที่เป็นระบบ ผมดูพฤติกรรมที่ตั้งใจ ผลลัพธ์จริง และหลักฐานได้พร้อมกัน
คำสั่งเต็มอยู่ด้านล่าง ผมแปลชื่อ internal dependency เป็น “Agent Browser ในตัว” เพื่อความชัดเจนสำหรับผู้อ่าน; ตรรกะเวิร์กโฟลว์ไม่เปลี่ยนแปลง
คำสั่งต้นฉบับ 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.
นี่คือพรอมต์ walkthrough เฉพาะฟีเจอร์นี้:
/ui-walkthroughใช้ deployed preview ผ่าน Agent Browser ในตัวเป็นความจริงเดียวของเบราว์เซอร์ พิสูจน์แถบด้านข้างเมื่อปิดฟีเจอร์ การแยก 68px และ 300px ลำดับปลายทาง สถานะ hover ช่องปักหมุด 5 ช่อง ตัวจับจัดเรียงเฉพาะขณะลาก การจัดเรียงใหม่ที่คงอยู่ การเลือกเธรด การเลื่อน และลิ้นชัก iPhone แบบเต็ม ส่งคืน PASS, FAIL หรือ BLOCKED สำหรับแต่ละจุดตรวจ ห้ามแทนสถานะที่เข้าถึงไม่ได้ด้วยสำเนา
สำหรับฟีเจอร์นี้ เอเจนต์จัด walkthrough รอบคำถามเหล่านี้:
- แถบด้านข้างเดิมยังทำงานเมื่อปิดฟีเจอร์หรือไม่
- โครงสร้างเดสก์ท็อปใหม่ปรากฏเมื่อเปิดหรือไม่
- สถานะ hover และเลือกมองเห็นได้แต่ไม่รบกวนหรือไม่
- เอเจนต์ที่ปักหมุด 5 ตัวอ่านง่ายหรือไม่
- ตัวควบคุมจัดเรียงใหม่ซ่อนจนกว่าจะเริ่มลากหรือไม่
- ลำดับใหม่คงอยู่หลังรีเฟรชหรือไม่
- เลือกและเลื่อนดูเธรดจริงได้หรือไม่
- ลิ้นชักมือถือเดิมยังทำงานหรือไม่
- ปลายทางเมนูนำทางครบและเรียงถูกต้องหรือไม่
เอเจนต์เปิด deployed preview ในฐานะผู้ใช้ใหม่ ดำเนิน onboarding เปิดฟีเจอร์ และทำตามลิสต์ ทดสอบสถานะพัก สถานะ hover สถานะลาก พฤติกรรมหลังรีเฟรช การเลือกเธรด การเลื่อน และเลย์เอาต์มือถือ
ผลลัพธ์คือ 11 PASS, 1 FAIL
ความล้มเหลวนี้มีประโยชน์ เลย์เอาต์และปฏิสัมพันธ์ทำงาน แต่ deployed preview แสดงปลายทางผลิตภัณฑ์แค่ 6 รายการ Activity และ Insights หายไป และลำดับไม่ตรงกับดีไซน์ที่เลือก
| สถานการณ์ | ผลลัพธ์ |
|---|---|
| แถบด้านข้างเดิมเมื่อปิดฟีเจอร์ | PASS |
| เลย์เอาต์เดสก์ท็อป 3 ส่วนใหม่ | PASS |
| สถานะ hover และเลือก | PASS |
| เอเจนต์ที่ปักหมุด 5 ตัว | PASS |
| ตัวช่วยจัดเรียงใหม่เฉพาะขณะลาก | PASS |
| ลำดับที่บันทึกหลังรีเฟรช | PASS |
| การเลือกเธรดและการเลื่อน | PASS |
| ลิ้นชักมือถือเดิม | PASS |
| เนื้อหาและลำดับปลายทาง | FAIL |
การส่งมอบสุดท้ายคือชุดภาพหน้าจอที่จัดระเบียบ ไม่ใช่โฟลเดอร์ภาพที่ไม่มีป้ายกำกับ ภาพเดสก์ท็อปขนาด 1440 × 900 พิกเซล และภาพมือถือ 1170 × 2532 พิกเซล แสดงทีละภาพด้านล่างเพื่อให้อินเทอร์เฟซอ่านง่าย คลิกภาพเพื่อขยายโดยไม่ออกจากบทความ
ปิดฟีเจอร์
เปิดฟีเจอร์
เลย์เอาต์เดสก์ท็อป
Hover ปลายทาง
Hover เอเจนต์ที่ปักหมุด
กำลังลาก
ลำดับที่บันทึกไว้
ลิ้นชักมือถือ
สิ่งนี้ช่วยให้ผมรีวิวฟีเจอร์อย่างเป็นระบบ เห็นสถานการณ์ที่ตั้งใจ ผลลัพธ์จริง และหลักฐานพร้อมกัน หากมีข้อผิดพลาด ผมรู้ทันทีว่างานควรย้อนกลับไปที่จุดใด
วิธีที่ทีมจะนำเวิร์กโฟลว์ออกแบบผลิตภัณฑ์ AI นี้ไปใช้
กระบวนการเต็มสั้นมาก เพื่อนร่วมทีมสามารถบันทึกแต่ละขั้นเป็น Zero workflow ที่แชร์ แทนที่จะสร้างใหม่จากความจำ
| ขั้นตอน | อินพุต | เอาต์พุต |
|---|---|---|
ui-design | หน้าจอปัจจุบัน ปัญหา เป้าหมาย และข้อจำกัด | แนวทางแนะนำ 1 แบบ ทางเลือก 9 แบบ และบันทึกดีไซน์ที่เลือก |
ui-implement | บันทึกดีไซน์ที่เลือก | โค้ดที่รีวิวได้และภาพหน้าจอสถานะหลัก |
ui-walkthrough | ฟีเจอร์ที่ deploy แล้วและพฤติกรรมที่คาดหวัง | รายการสถานการณ์พร้อมภาพ PASS, FAIL หรือ BLOCKED |
เพื่อนร่วมทีมไม่จำเป็นต้องมีรสนิยมดีไซน์เหมือนผม แค่ให้บริบทที่ดี ใช้ระบบผลิตภัณฑ์ร่วมกัน เลือกอย่างชัดเจนหลังสำรวจ และรีวิวหลักฐานเบราว์เซอร์ จุดตรวจมนุษย์ 3 จุด—ปัญหา ทิศทาง และการยอมรับ—ยังคงกำหนดวิธีที่เรา บริหาร AI agent เหมือนทีม
เวิร์กโฟลว์นี้ไม่ได้ตัดทิ้งการปฏิบัติหรือความคิดเชิงออกแบบ แต่นำไปไว้ในส่วนที่สำคัญที่สุด: นิยามปัญหา กำหนดข้อจำกัด เปรียบเทียบแนวทาง เลือกข้อแลกเปลี่ยน และตัดสินผลิตภัณฑ์ที่ใช้งานจริง
เมื่อระบบคอมโพเนนต์สมบูรณ์ ผมไม่ต้องสร้างฟีเจอร์ใหม่ทุกครั้งเป็นบล็อกลากใน Figma อีกต่อไป ผมทำงานกับเอเจนต์ในผลิตภัณฑ์โดยตรง ขณะที่ระบบดีไซน์ช่วยให้ผลลัพธ์สอดคล้อง และ walkthrough ช่วยให้ผลลัพธ์ตรงไปตรงมา
คำถามที่พบบ่อย
สร้างเวิร์กโฟลว์ออกแบบผลิตภัณฑ์ AI อย่างไร?
เริ่มจากระบบผลิตภัณฑ์ที่มีอยู่ ไม่ใช่พรอมต์เปล่า แยกงานเป็นการสำรวจ การพัฒนา และการรีวิว ให้เอเจนต์สร้างทางเลือกและตรวจสอบซ้ำได้ แต่ผู้ออกแบบผลิตภัณฑ์ต้องรับผิดชอบปัญหา ทิศทางที่เลือก และการยอมรับสุดท้าย
นักออกแบบผลิตภัณฑ์ทำงานโดยไม่ใช้ Figma ได้หรือไม่?
ได้ เมื่อผลิตภัณฑ์มีคอมโพเนนต์ เทมเพลตหน้า และรูปแบบปฏิสัมพันธ์ที่เสถียร Figma ยังมีประโยชน์สำหรับภาษาภาพใหม่หรือปฏิสัมพันธ์ที่ไม่คุ้นเคย จุดประสงค์ไม่ใช่ห้ามใช้ Figma แต่เพื่อหลีกเลี่ยงการสร้างการตัดสินใจที่รู้แล้วซ้ำบนผืนผ้าใบที่สอง
AI กำลังแทนที่นักออกแบบผลิตภัณฑ์หรือไม่?
ไม่ใช่ในเวิร์กโฟลว์นี้ เอเจนต์ช่วยประกอบทางเลือก แก้ไขโค้ด และตรวจสอบสถานการณ์ ผู้ออกแบบยังคงนิยามปัญหา กำหนดข้อจำกัด เปรียบเทียบข้อแลกเปลี่ยน เลือกทิศทาง และตัดสินว่าผลิตภัณฑ์ที่ใช้งานจริงดีพอจะปล่อยหรือไม่
