Skip to content

Handoff to Dev

In a traditional tool, design handoff means exporting frames, writing specs, and hoping the dev recreates them faithfully. In Doable, your design is the app; there is no export step. This guide covers how design intent becomes app code, how to keep the generated code clean, and how to iterate with a developer in the loop.

Comment-to-AI flow

The simplest handoff is to leave a design comment that captures intent in plain language. The AI reads pinned comments as feedback and can act on them directly.

  1. In Design View, click the Comment button at the top right of the preview.
  2. Click on the spot the change should target (a specific element, a section, or whitespace).
  3. Type the intent the way you would tell a colleague. For example, "this hero feels generic, can we use our brand purple and tighten the spacing?" or "this card grid should wrap to two columns on tablet."
  4. Press Comment.

Once a pin is placed, you have two ways to turn it into code:

  • Ask the AI to act on the comment: in the AI chat, write something like "apply Alex's feedback on the hero" and the AI will pull the pinned comment in as context.
  • Use the floating prompt with the element selected: click the element the pin sits on, then use "Ask Doable..." to apply the change scoped to that element.

Comments stay attached to the spot they were dropped, so they remain readable even after the underlying code has changed. Resolve them once the change is in (the green check) to keep the canvas tidy.

Saving design changes as code

When you finish a visual tweak in the Design Panel, you choose how the change is persisted. The choice matters for the developer who will read the resulting code later:

  • Save: writes the resulting CSS straight to source as raw style values. Use this for quick, isolated tweaks where pixel-accuracy is the priority and design-system fidelity is not. No tokens spent, instant.
  • AI Save: sends the diff to the AI, which translates it into something semantic: a design-system token, a Tailwind utility, a component prop, or a refactor of the parent component. Use this for changes you expect to live in the codebase long term, or anywhere the design system matters.

A useful rule of thumb:

Situation Save mode
One-off tweak you'll polish later Save
Change that should match the design system AI Save
Exploration you don't want to keep Discard
A change a developer will obviously read and refactor Save (let them refactor)
A change that should ship as-is AI Save

If you're unsure, AI Save is the safer default for handoff. The developer reads cleaner code, and the change is less likely to need follow-up.

Reviewing the generated code

After a save, the developer can review the change without leaving the project:

  • The Code tab in the editor shows the modified files. Every collaborator's edits (yours, the AI's, and the developer's) stream in via Yjs in real time. The developer sees the diff appear as you save.
  • The History view shows who made which change and when, including which commits came from AI Save versus direct Save.
  • The Activity feed shows ephemeral events ("Alex edited Hero.tsx via AI Save") so the developer can keep track without watching the file tree.

The developer typically does one of three things after a save:

  1. Approve as-is: most AI Save changes land clean enough to keep. The developer says so in Team chat.
  2. Refactor: tweak the code to use a slightly different token, extract a shared component, or simplify the markup. Refactors are a normal part of the loop and don't undo your visual change.
  3. Request a redo: if the AI Save produced something messy (e.g., inline styles where a token would have been better), the developer pings you to redo with a clearer prompt, or does it themselves in the code.

If the developer changes code while you're in Design View, you see the preview update live; the loop runs in both directions.

Iteration loop with the developer

A good design-dev loop in Doable looks like this:

  1. Designer drops a pin with the intent ("CTA needs more visual weight").
  2. Designer makes the change in the Design Panel and AI Saves.
  3. Developer sees the diff appear in the Code tab in real time. They glance at the result.
  4. Developer comments in Team chat: "Looks good, I'd pull that shadow into the design tokens; give me five minutes."
  5. Developer refactors the shadow into a token. You see the preview unchanged (the visual stays the same) but the underlying code is cleaner.
  6. Designer resolves the original pin.

Common patterns that make the loop smooth:

  • Pin first, change second. A pin captures the why in your words; the save captures the what in code. Together they give the developer everything they need to review.
  • Prefer AI Save for anything that touches shared tokens (colors, spacing scales, typography). The AI is good at picking the right token; raw Save bakes in a magic number.
  • Use Team chat for "I'm working on X" so the developer doesn't refactor a file you're about to touch.
  • Let the developer drive the code review. If they ask you to redo a save with a different prompt, that's faster than them rewriting the result.

The handoff stops being a handoff and starts being a shared loop. Design intent enters the project, the AI translates it into code, the developer keeps the code clean, and you see the result on the preview without ever leaving Doable.

For the design surface itself, see Visual Designer Overview. For the collaboration plumbing (presence, Yjs sync, Team chat), see Collaboration.