| name | product-design |
| description | Design or revise visible product UI with reference-first judgment, real mode-specific controls, low-copy surfaces, and screenshot-based verification. |
| metadata | {"short-description":"Reference-first product UI without label/step slop"} |
Product Design
Use this before creating or revising visible UI.
The interface should do the job, not explain the job.
For public pages, blog/research surfaces, marketing pages, or broad design-system work, read the relevant docs/anti-patterns/ file before implementing.
Flow
- Identify the product type, user, primary workflow, and domain expectations.
- Inspect relevant references or existing design system before inventing a direction.
- Choose controls that match the task: icons, tabs, toggles, menus, sliders, upload/record, chat/intake, or direct commands.
- Remove obvious labels, raw inventory counts, procedural step cards, dead panels, repeated action words, fake readiness states, and decorative clutter.
- Implement in the app's existing component/style patterns.
- Verify rendered desktop and mobile screenshots; fix text overflow and visible polish issues.
Rules
- Mode changes must change the actual component, not just the label.
- Operational tools should be dense, calm, and scannable.
- Product/venue/person pages need real visual assets in the first viewport.
- Blog indexes should organize by reader path: series, topic, date, or argument.
- Research indexes should organize by claim and evidence standard, not by SEO category or product taxonomy.
- Do not market raw inventory counts unless the count is the reader's decision.
- Do not claim UI quality from a build alone.
Use references/full-reference.md for execution rules and docs/anti-patterns/ for durable writing/design doctrine.
Then consider
ui-test for adversarial browser QA.product-design-audit for a broader redesign pass.
