Product design — UI/UX routing hub

Craft and product judgment first. This hub is for how product surfaces feel and behave — not marketing heroes, not backend, not “prove CI green.”

Route first → open one specialist → do the work. Load at most 1–3 specialists.

product-design (this hub)
    → design-system | product-ui-craft | mobile-product-ux | web-quality
    → ui-explore | mockup-implement | tufte
    → emil-design-eng | make-interfaces-feel-better | 12-principles-of-animation (motion/feel review)
    → flutter-pro-ux-review (Flutter app production polish audit)
    → quality-check / browser-verify (prove pixels)

When to use this hub

Primary ownership (vs frontend-design)

These specialists belong here first (product UX). frontend-design only pulls them in as steps inside a full implement pipeline:

frontend-design owns primarily: react-performance, SPA/feature structure, “build the page” orchestration.

Routing table

Multi-step craft pipeline

1. design-system — lock tokens / kit / bans
2. ui-explore if the look is still open (principle 9: live data, all shipped surfaces)
3. mockup-implement once signed off
4. product-ui-craft (+ mobile-product-ux if touch/sticky)
5. web-quality for forms/focus/targets
6. tufte if product charts
7. emil-design-eng / make-interfaces-feel-better / 12-principles-of-animation if motion/feel is the specific complaint (optional installs)
8. browser-verify or quality-check before claiming done

explore (ui-explore)
  → mockup-implement
  → product-ui-craft (+ mobile-product-ux)
  → web-quality
  → emil-design-eng / make-interfaces-feel-better / 12-principles-of-animation (motion/feel)
  → browser-verify / quality-check

product-design vs frontend-design vs quality-check

If the user says “build the page” → frontend-design.
If they say “make the trade HUD feel right on mobile” → this hub.
If they say “prove sticky doesn’t break” → quality-check / browser-verify.

Shared product UX principles

Each has a falsifiable Test:.

1. Project design system beats generic “pretty”

DESIGN.md, tokens, kit components win over neo-brutalism packs and random Inter/purple defaults.

Test: Would a design-system owner accept this without a rebrand fight?

2. Product surfaces optimize for scan, density, trust

Tables, chat, trade HUDs, filters ≠ marketing heroes. Prefer clear hierarchy and restrained motion.

Test: Can a user find the primary action and current state in under 2 seconds?

3. States are part of the design

Loading, empty, error, success, disabled, selected — not “polish later.”

Test: Is every async path designed, or only the happy path?

4. Mobile is a first viewport

Sticky, sheets, safe areas, and thumb reach are designed — not shrunk desktop.

Test: Does 390-class width need a special layout, or did we only check desktop?

5. Touch and focus are product quality

Targets, focus rings, form labels, motion prefs — web-quality. Automated axe alone is not craft.

Test: Keyboard-only and thumb-only paths both complete the primary job?

6. Charts carry product truth

Quantitative UI uses tufte (honest encoding) + design-system chart shells — not decorative sparklines that lie.

Test: Does the chart answer a product question without chartjunk?

7. Explore before freestyle production

Unsigned visuals → ui-explore. Signed → mockup-implement. Don’t invent production chrome mid-port.

Test: Is there a named source design, or are we improvising?

8. Prove the craft in a browser when pixels matter

Sticky, overflow, gesture, density → browser-verify (or quality-check for full QA).

Test: Have you opened the real viewport, or only reasoned about CSS?

9. Three surfaces, one contract, live data

If web, mobile-web, and native ship the same product surface, they share one data contract (same fields, same empty/error meaning). Explore on live backend data — or a recorded snapshot of it — not empty fixtures that hide density. ui-explore is throwaway; do not rewrite production chrome to “try a look.”

Test: would a reviewer see real row density and the same number on every shipped surface? If one surface is a fixture and another is live, the lab is lying.

Sources (attribution)

Full pack table: ATTRIBUTION.md.

Do not install competing aesthetic mega-skills (“UI/UX Pro Max” style) alongside this hub — they fight your design system. Prefer design-system + craft.

Anti-patterns

• Marketing landing maximalism on data/product chrome
• Inventing fonts/colors when a design system exists
• Desktop-only for mobile-critical product flows
• Happy-path-only UI (no empty/error)
• “Looks fine in my head” without viewport proof
• Rewriting production chrome during an explore pass
• Exploring a data surface on empty fixtures while prod is dense
• Using quality-check when you still need craft decisions
• Using this hub for pure React perf / code-split (frontend-design → react-performance)

When not to use this hub

Done criteria

• Routed to the right craft specialist(s)
• Design-system constraints respected
• Loading/empty/error considered for new async UI
• Mobile considered if the surface is touch-reachable
• Charts used tufte when quantitative
• Browser proof when sticky/gesture/density risk is non-trivial
• Multi-surface: same contract; explore used live (or recorded-live) data