My AI Product Design Workflow Without Figma

Product design without Figma works when a product already has a mature design system. My AI product design workflow uses three agent skills: ui-design explores nine directions, ui-implement turns the selected direction into the product, and ui-walkthrough reviews every state through the built-in Agent Browser. I still make the decisions; the agent handles the repetitive production and checking.

Most product features do not start from a blank page. Once a product has been around for a while, its basic design decisions already exist in code. Buttons, inputs, cards, navigation, spacing, colors, copy, hover states, and mobile behavior have all been defined. Rebuilding those pieces in Figma often means dragging the same components onto another canvas before rebuilding them again in the product.

The designer still makes the product decisions. The agent removes much of the repetitive assembly and checking. This works because Zero already has a reasonably mature design system.

1. Start product design without Figma with a design system

Working without Figma does not mean working without design rules. It requires clearer rules.

For Zero, the agent can inspect:

• Existing components for buttons, inputs, dropdowns, cards, dialogs, and navigation
• Established spacing, typography, colors, borders, and corner radii
• Existing hover, selected, disabled, empty, and mobile states
• Copy conventions such as sentence case and short user-facing labels
• Real screens that show how these pieces are combined

These references answer ordinary design questions. A new input should look like the inputs that already ship. A new card should use the same surface and radius as the closest existing card. An icon button should have the same hover feedback as other icon buttons.

This gives the agent a boundary. It can explore the structure of a feature without inventing a new visual language for every screen.

Figma is still useful when a team is creating a new brand, a new component system, or an interaction that has no close product reference. But once the system is mature, the running product can become the main design surface. This is the feature-scale version of the design-as-code workflow we used to rebuild Zero.

2. Use ui-design to explore nine product design directions

Every feature still needs exploration. I do not want an agent to take my first sentence and immediately turn it into code.

I start with ui-design. I give the agent the current screen, the user problem, the goal, and the main constraints. The agent reads the existing product patterns and returns one recommended direction plus nine alternatives.

In plain language, the skill captures the current screen, creates one recommended direction, explores nine distinct alternatives, presents the tradeoffs, and waits for a human choice.

The design thinking inside this instruction

This instruction is not just a list of visual rules. It turns a designer's normal process into a repeatable sequence:

1. Understand before proposing. Capture the current screen and read the surrounding product before making anything.
2. Think in systems. Treat existing components, template pages, interaction patterns, and copy rules as the starting material.
3. Prevent reinvention. AI tends to create a new pattern when the prompt is vague. The instruction tells it to find the closest shipped component or page and reuse it instead of approximating from memory.
4. Explore before choosing. The After anchor gives one plausible direction. The nine variants open different decisions about layout, hierarchy, density, entry point, and disclosure.
5. Separate exploration from commitment. The agent stops after presenting options. A human compares the tradeoffs and chooses before code begins.
6. Review the whole experience. Copy, hover feedback, states, mobile behavior, and visual consistency are part of the design, not cleanup after implementation.

That is the system thinking I want from the skill: understand the existing product, explore within it, and then make an explicit choice.

Here is the complete original instruction, reproduced verbatim from the live workflow:

Complete original ui-design instruction

# 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.

The nine options do not need to be nine finished designs. Their job is to give me enough range to see the problem differently and move toward the right direction. If a concept sits outside the current product, a standalone React prototype can still help. For this feature, I stayed inside the real product system.

A real example: Zero's navigation

Zero originally had one 300-pixel sidebar containing product destinations, pinned agents, and chat threads. It was doing three jobs at once. I wanted to separate those jobs without changing the conversation area.

The product brief for the exploration was:

/ui-design

Replay the design phase for Zero's three-region navigation from the real historical base. Separate product destinations, agents, and conversations into clearer regions without changing the conversation area. Use real Zero tokens, icons, and components. Produce a source-faithful Before, one strong After, and nine genuinely different variants. Do not edit product code or present a mockup as browser evidence.

The first exploration was too cautious. Several options changed widths and selection styles, but they still looked like the same sidebar. I rejected that set and asked the agent to make the differences visible at the information-architecture level.

The second run returned nine genuinely different directions. I grouped them into a 3 × 3 table so they are easy to compare without turning the article into a long image strip. Every thumbnail opens in the blog's image viewer.

1. Top navigation	2. Collapsible drawer	3. Thread first
Move destinations above the conversation	Hide destinations until needed	Make conversations the main navigation object
4. Agent first	5. Conversation first	6. Command launcher
Choose an agent before its threads	Put pinned agents above the active conversation	Open destinations from a searchable menu
7. Expandable rail	8. Dashboard entry	9. Bottom dock
Expand a narrow rail only when needed	Start from recent work	Move destinations to the bottom

I did not choose one of these frames exactly as drawn. I used them to decide what should stay and what should change. The final direction used a narrow destination rail, a separate chat rail, five visible pinned agents, and the existing conversation area.

The important output of ui-design was not the image alone. It was a short decision record:

• Keep a 68-pixel destination rail and a 300-pixel chat rail
• Show five pinned-agent slots
• Keep selection quiet but readable
• Show reorder guidance only while dragging
• Keep the conversation and the existing mobile drawer unchanged

That was enough to begin implementation.

3. Use ui-implement to turn the selected design into code

After I choose a direction and connect the product codebase, the agent works directly in code. I do not redraw the selected frame in Figma first.

In plain language, ui-implement skips exploration because the direction has already been chosen. It finds the closest real components and page structure, builds with them, audits the result, and verifies the feature in a browser.

What this instruction protects

• The chosen direction should not be redesigned during implementation.
• The agent must begin with the closest existing component and template page.
• Reuse wins over a new component unless the product has a real gap.
• The self-audit and browser check catch inconsistent copy, states, and interactions.
• If a product decision is still unresolved, the work returns to ui-design.

This is how the design system stays active during implementation. It is not a document the agent reads once. It shapes which components it chooses and how it checks the finished experience.

Here is the complete original instruction, reproduced verbatim from the live workflow:

Complete original ui-implement instruction

# 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.

This was the feature-specific implementation prompt:

/ui-implement

Start from revision 04d642bb. Add a default-off desktop split with a 68px destination rail, a 300px chat rail, and the unchanged conversation. Keep the old 300px sidebar when the switch is off and on mobile. Render five pinned slots, preserve user-defined order, and show reorder affordances only during an active drag. Do not inspect the historical feature or later refinements until the independent patch, tests, and browser evidence are frozen.

For the navigation feature, I asked the agent to keep the old sidebar when the feature was off, show the new three-part layout when it was on, keep the existing mobile drawer, and allow people to reorder pinned agents.

During implementation, the agent found one important issue. The old product remembered which agents were pinned, but it did not remember their order. A drag interaction could look correct and then reset after a refresh.

So the agent did more than draw the drag state. It made the new order persist, refreshed the page, and checked that the order stayed. It also confirmed that reorder handles appeared only during the drag and disappeared afterward.

The implementation delivery showed the two desktop states I needed to review. I show them at full width so the interface remains readable. Mobile behavior appears later in the walkthrough as a high-density phone capture.

Desktop resting state

Active reordering

At this point I had a working feature, not another design file. But implementation was still not the end. I needed to see what was actually running in the deployed preview.

4. Use ui-walkthrough to review the real product

Product walkthroughs used to be tedious. I would open a deployed preview, prepare the right account, turn features on and off, click every control, resize the browser, take screenshots, and try to remember which state each image represented.

The agent has a built-in Agent Browser, so I can hand that work to it.

The workflow has two main steps:

1. List the scenarios first. The agent turns the design and implementation claims into a checklist.
2. Run the checklist and attach evidence. It performs every scenario in the deployed preview and returns PASS, FAIL, or BLOCKED with a screenshot for each meaningful state.

What this instruction changes about review

• The agent lists the scenarios before it starts clicking.
• It uses the real deployed component through its built-in Agent Browser.
• It captures one screenshot for each meaningful state.
• It marks every checkpoint PASS, FAIL, or BLOCKED.
• It never hides an unavailable state behind mock evidence.

This turns manual clicking into an organized review package. I can look at the intended behavior, the result, and the evidence together.

The full instruction is below. I have translated the internal dependency name to “built-in Agent Browser” for reader-facing clarity; the workflow logic is otherwise unchanged.

Complete original ui-walkthrough instruction

# 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.

This was the feature-specific walkthrough prompt:

/ui-walkthrough

Use the deployed preview through the built-in Agent Browser as the only browser truth. Prove the feature-off sidebar, the 68px and 300px split, destination order, hover states, five pinned slots, drag-only handles, persisted reorder, thread selection, scrolling, and the full iPhone drawer. Return PASS, FAIL, or BLOCKED for every checkpoint. Do not replace an unreachable state with a replica.

For this feature, the agent organized the walkthrough around these questions:

• Does the old sidebar still work when the feature is off?
• Does the new desktop structure appear when it is on?
• Are hover and selected states visible but quiet?
• Are five pinned agents readable?
• Do reorder controls stay hidden until a drag starts?
• Does the new order survive a refresh?
• Can I select and scroll through real threads?
• Does the existing mobile drawer still work?
• Are all navigation destinations present and in the right order?

The agent then opened the deployed preview as a new user, completed onboarding, enabled the feature, and worked through the list. It tested the resting state, hover state, drag state, refresh behavior, thread selection, scrolling, and the phone layout.

The result was 11 PASS, 1 FAIL.

The failure was useful. The layout and interactions worked, but the deployed preview showed only six product destinations. Activity and Insights were missing, and the order did not match the selected design.

Scenario	Result
Old sidebar with the feature off	PASS
New three-part desktop layout	PASS
Hover and selected states	PASS
Five pinned agents	PASS
Drag-only reorder guidance	PASS
Saved order after refresh	PASS
Thread selection and scrolling	PASS
Existing mobile drawer	PASS
Destination content and order	FAIL

The final delivery was an organized screenshot set rather than a folder of unlabeled images. The desktop captures are 1440 × 900 pixels and the phone capture is 1170 × 2532 pixels. They appear one at a time below so the interface stays readable; click any image to enlarge it without leaving the article.

Feature off

Feature enabled

Desktop layout

Destination hover

Pinned-agent hover

Active drag

Saved order

Mobile drawer

This lets me review a feature in a structured way. I can see the intended scenarios, the actual deployed result, and the evidence together. If something fails, I know exactly where the work should return.

How a team adopts this AI product design workflow

The full process is short. Teammates can save each stage as a shared Zero workflow instead of rebuilding the process from memory.

Stage	Input	Output
ui-design	Current screen, problem, goal, and constraints	One recommended direction, nine alternatives, and a selected design record
ui-implement	The selected design record	A reviewable code change and screenshots of the main states
ui-walkthrough	The deployed feature and its expected behavior	An organized scenario list with PASS, FAIL, or BLOCKED screenshots

A teammate does not need to reproduce my design taste. They need to provide good context, use the shared product system, make an explicit choice after exploration, and review the browser evidence. The same three human checkpoints—problem, direction, and acceptance—also shape how we manage AI agents like a team.

This workflow does not remove design practice or design thinking. It moves them to the parts where they matter most: defining the problem, setting constraints, comparing directions, choosing tradeoffs, and judging the running product.

When the component system is mature, I no longer need to rebuild every feature as draggable blocks in Figma. I can work with the agent directly in the product, while the design system keeps the output consistent and the walkthrough keeps the result honest.

Frequently asked questions

How do you build an AI product design workflow?

Start with the existing product system, not a blank prompt. Separate the work into exploration, implementation, and review. Let the agent generate options and perform repeatable checks, but keep the product designer responsible for the problem, the chosen direction, and final acceptance.

Can product designers work without Figma?

Yes, when the product already has stable components, page templates, and interaction patterns. Figma remains useful for a new visual language or an unfamiliar interaction. The point is not to ban Figma; it is to avoid rebuilding known product decisions on a second canvas.

Is AI replacing product designers?

Not in this workflow. The agent assembles options, edits code, and checks scenarios. The designer still frames the problem, sets constraints, compares tradeoffs, chooses the direction, and decides whether the running product is good enough to ship.