| name | frontend-design-workflow |
| description | Workflow for frontend features, visual changes, and product design changes. Present mockup options before writing code, build against the project's design system, capture the right evidence type (screenshots vs video), and run a new-user usability review before finalizing. Use when building or changing UI, styling, layouts, animations, or any user-facing visual surface. |
| triggers | mockup, mockups, frontend, redesign, restyle, visual change, UI change, design change, landing page, new page, new component |
Frontend & Design Workflow
A disciplined workflow for frontend features, visual changes, and product
design changes. The core idea: design decisions happen in cheap mockups
before expensive code, and evidence matches the nature of the change.
Phase 1 — Mockups before code
Never jump straight to implementation when a change involves design
decisions, even when one design seems obvious.
Skip mockups only when there is nothing to design: the change is
mechanical and fully specified — fixing a typo, changing a value the user
prescribed exactly ("make this #FF0000", "bump the font to 14px"), or
deleting something. If the request leaves any visual choice open
(layout, spacing, color selection, interaction), mockups are required.
- Render 2–3 distinct design options as mockups for the user to choose
from. For small components, inline widgets work well when the chat
surface renders them; otherwise — and for full pages or complex
layouts — write a self-contained HTML file and share the path.
- Make each option genuinely different (layout, density, interaction
model) — not three shades of the same idea.
- Build mockups with the target project's real design tokens / theme
variables when they exist, so the options preview accurately.
