RonanCodes/design-directions

Design Directions

The fastest way to pick a look: don't describe options, build them and let the user see them side by side. Generate N genuinely-different design directions for one view on a throwaway /designs route, each grounded in a real product's pattern (via Mobbin) and rendering the same data, then let the user point at the one they like and merge it in.

This is the "I really like how you showed the designs" pattern: real, clickable, comparable, grounded.

When to use

• A view works but you haven't committed to how it looks.
• Starting a new screen and want to choose a layout before building it for real.
• The user asks for "a few looks", "design options", "a design pass", or to "mobbin it".

The process

1. Pin the view + its data

Name the one view (e.g. the bid overview, the settings page, the dashboard). Define a small static sample dataset for it (3-ish rows with realistic values). All directions render THIS same data, so the comparison is fair.

2. Pull real references from Mobbin

Use the Mobbin MCP (mcp__mobbin__search_screens, search_flows) with 2-3 targeted queries describing the pattern (not the brand): e.g. "dashboard listing offers as ranked cards with status", "CRM pipeline board with deal cards in columns", "inbox master-detail with reply". Examine the returned images (don't go by metadata). Cite each screen you lean on by its mobbin_url. If the Mobbin MCP isn't connected, fall back to the Mobbin site or known patterns and say so.

3. Derive N distinct directions (default 5)

From the references, pick directions that are genuinely different shapes, not tweaks of one. A good spread for list/record views:

• Dense table (scannable, scales)
• Master-detail / inbox (list + detail panel)
• Pipeline board (cards in status columns)
• Labeled-field cards (calm record cards, uppercase labels)
• Hero + ranked list (spotlight the top item, rest compact)

Each direction names the app/pattern it's grounded in.

4. Build the /designs route

One page, N sections. Each section: Design N · <name>, a one-line note on when it shines, the Mobbin ref, then the component rendering the shared sample data using the app's real design tokens (not generic styling). Keep it static (no auth, no DB) so it's trivial to open and review. (In a guarded app, ensure the route isn't behind the auth redirect.)

5. Ship it for review

Deploy (or run locally) and give the user the /designs URL. Invite specific feedback: "tell me what you like/dislike about each."

6. Merge the winner

When the user picks one (or "blend 2 and 4"), merge that direction into the live view, keeping the real behaviour (actions, states, permissions). Then either delete /designs or keep it as a living style scratchpad.

Principles

• Same data everywhere — the only variable is the design.
• Grounded, not invented — every direction traces to a real reference; cite Mobbin links.
• Distinct, not variations — five shades of one card is not a design pass.
• Real tokens — use the app's colour/type/radius tokens so the winner drops straight in.
• Static + public — /designs should open with no friction.
• Show, don't tell — clickable beats described, every time.

Composes with

• Mobbin MCP (search_screens / search_flows) — the reference source.
• [/artifact-design] or [/ro:frontend-design] — apply real taste to each direction.
• The app's design tokens (extract them first if they aren't defined).