From brief to concept in under a day

How I use the Design screen gen Claude plugin to move from zero to a DS-compliant, multi-concept, interaction-ready flow — in 8.5 hours instead of 36. 

76%  Time saved overall  per project cycle

27.5 h  Hours recovered  ~3.5 working days

8.5 h  End-to-end workflow  was 36 h

4×  More concepts  same time budget

The hidden cost no one talks about

A product manager shares a requirements doc. Sometimes it’s sharp and strategic. More often it’s a brain dump of technical constraints, business rules, and edge cases wrapped around an implied solution. The designer’s job starts immediately: understand the system, map the user, find the real problem hiding inside the stated one. The intake work is irreplaceable — it’s where senior judgment matters most.

But everything after that? Building layout structures, diagramming flows, populating screens with dummy data, making enough to communicate an idea — that scaffolding work was eating more time than the actual thinking. I built the Design screen gen plugin to fix that ratio.

How the plugin changes each phase 

The plugin is a Claude-native tool that runs a four-phase pipeline: spec parsing, component mapping, React/JSX generation, and Figma export. What makes it different from a generic AI tool is that it works within your actual design system from the first prompt. Here is what that looks like across a real project cycle.

Step 1  —  Digest the brief  (2.5h → 0.5h)

The brief attaches directly to the /generate-screens command. Claude simultaneously parses it for screen requirements, target platform, required states (empty, loading, error, success), and interaction notes. What used to be two-plus hours of careful reading, annotation, and translation into design decisions becomes a 30-minute review of Claude’s interpretation. The designer’s job shifts from comprehension to confirmation — a fundamentally different cognitive task.

Step 2  —  Map user flows  (4h → 0.5h)

The component manifest that the plugin auto-generates is the user flow map. Every UI element is parsed from the spec, matched against your Figma DS library, and classified: confirmed DS component, new component needing flagging, or generic pattern. The plugin uses fuzzy matching logic to handle ambiguous elements — ‘top navigation’ maps to NavigationBar, ‘primary button’ to Button/Primary. The designer reviews and confirms a table, not draws a flow from scratch. Four hours becomes thirty minutes.

Step 3  —  Explore options and concepts  (12h → 1.5h)

This is where the plugin earns its keep most visibly. For multi-concept exploration, the traditional approach meant 10–12 hours building layout structures, sourcing realistic dummy data for enterprise scenarios, and producing enough fidelity for stakeholders to react to. The plugin generates a complete, DS-compliant, content-populated React/JSX concept per session in minutes. Running three or four sessions with different parameters produces three or four viable directions. Time shifts entirely from building to evaluating. The cognitive work is now: which direction is worth developing?

The shift that matters 

Generated screens are not precious. Designers stop defending early directions. Stakeholders stop reacting to aesthetics. The conversation moves to: does this flow solve the problem? That is a significantly more useful conversation at this stage. 

Step 4  —  Full flow with interactions  (9h → 3h)

States and interaction notes captured upfront in the spec prompt are carried through generation automatically. The REVISE loop in Phase 4 iterates without re-reading the DS — session state is persistent. You do not start over between iterations. The remaining three hours cover genuinely complex edge cases: permission-state branching, error recovery paths, accessibility requirements that need deliberate design judgment. That is the right use of a Staff designer’s time.

Step 5  —  Screens and variations  (5h → 1.5h)

Design system compliance is structural, not corrective. The plugin generates screens with the right tokens, component variants, and spacing from the first output. Realistic content is auto-populated — which matters significantly in enterprise UX, where a screen with actual data triggers different and more useful stakeholder reactions than a screen with placeholder text. The REVISE loop stays in session, so iterating on content distribution and layout hierarchy does not require a round-trip back to the DS.

Step 6  —  Refine and present  (3.5h → 1.5h)

Phase 4 of the plugin auto-generates a session summary: screens produced, DS components used, new components flagged. The new component queue offers one-click DS documentation through the figma-design-system skill. There is no token audit, no hunting for spacing drift, no manual annotation of component names. Refinement starts from a clean, compliant baseline. The time goes into sharpening the narrative and preparing for the questions coming in the room.