Design-to-Code Playbook

Implementing design and implementing architecture are different conversations. They need different context strategies.

Architecture conversations need the why.

When you're setting up a project; folder structure, design tokens, component patterns, build configuration. Front-load everything. Not just what you want, but why you want it. The reasoning matters because the model needs to generalize. You're establishing patterns that everything else builds on.

Withhold the reasoning and you'll spend tokens fixing symptoms instead of causes.

Design conversations need precision.

When you're implementing actual UI. The navigation, a card component, a form layout. All drip-feed, one section at a time, one component at a time. Start with structure, add detail incrementally.

The model doesn't need your company manifesto to build a button. It needs to know what the button looks like and how it should behave. Show it the design. Tell it what's interactive. That's it.

If you already have designs in Figma, prepare them first. Use variables for colors, spacing, typography. Add descriptions to components. Name your layers intentionally. All of this is machine-readable metadata that the model can use. This is how you sync design and code. Not through perfect prompts, but through structured source files.

Then follow this order:

1. Foundation first.

Design tokens. CSS custom properties or your styling system's primitives. Colors, spacing, typography scales. Get them right before you touch components.

This is where front-loading works. Tell the model your theming requirements, your accessibility constraints, your naming conventions and why. These decisions affect everything downstream.

2. Shell structure.

Basic page layout. Navigation skeleton. The chrome that stays constant while content changes. Don't fill it in, just establish where things go.

3. Components by need.

Build components as you need them, not as a library exercise. Need a card for the dashboard? Build the card. Need a form for settings? Build the form.

Each component conversation starts fresh with just what that component needs. Show the Figma frame, you can "Copy link to selection" to create a URL for frames or sections in Figma. Describe the interactions. Reference existing patterns: "Use the same hover state we have on the nav items."

4. Integration passes.

Connect the pieces. This is where you surface the issues. Components that don't compose well, spacing that breaks at certain breakpoints, states you forgot to handle.

Better to find these with one component than with twenty.

Prototypes can tolerate shortcuts. Inline styles, hardcoded data, component implementations that only work for one use case. Speed matters more than sustainability.

Production code needs different guidance: "This component will be reused across multiple screens. It needs to handle these states. The data shape will vary."

Be explicit about which conversation you're having. The model will optimize differently.

Early mistake: asking for "the foundation" without being clear about what comes next.

The model didn't know I had designs ready. It built comprehensive scaffolding—routing patterns for pages I hadn't shown it, state management for data I hadn't described, component hierarchies based on assumptions about my app structure.

Then I showed it the actual design.

The scaffolding didn't match. The component hierarchy it assumed didn't map to what I needed. I spent more time removing its decisions than implementing mine.

Now I'm explicit: "I have complete designs. Don't build extensive scaffolding. Create only what's needed for the current piece. More components coming."

The model stops guessing. I control the structure.

Tools like AI Studio, Lovable, or Figma Make generate code that runs in their environment. When you export to GitHub and open in VS Code, Cursor, or Antigravity you will probably face a blank page.

The code isn’t broken. It’s incomplete. These tools have pre-installed dependencies, configured paths, environment variables already set. When you download or push to a repo, a .gitignore excludes node_modules and build artifacts. Standard practice. But if you don't know to run npm install, or the tool used a different package manager, or paths assume their folder structure. You're stuck staring at errors.

The fix is straightforward if you know what’s happening: install dependencies, check the package.json, verify paths match your local setup. But most non-technical folks don't know what's happening. They see a wall.

Front-load the architecture conversation. Be generous with reasoning, explicit about trade-offs, clear about what's coming next.

Drip-feed the design conversation. One piece at a time, precise references, incremental complexity.

Match your tools to your actual requirements. Or match your requirements to your tools.

Test the export path before you commit.

That's it. Everything else is debugging.