From Canvas to Merged PR: What Figma Make Changes for Designers Who Build

Figma just published a real workflow showing a designer connecting a live GitHub codebase to Figma Make, making accessibility fixes directly in production code, and opening a pull request — without filing a single ticket. If you've ever watched a small-but-important fix die in a backlog, this is worth understanding.

The old handoff tax is real, and it's quietly expensive

The traditional path from "I noticed something" to "it shipped" runs like this: designer spots a problem, writes a ticket, ticket lands in the backlog, backlog buries it under everything engineering already committed to. The fix is too small to prioritize and too important to drop, so it just... sits there.

There's a second cost that's easier to overlook. When you hand off a written description — "make the spacing a little tighter," "the screen reader announces this wrong" — the nuance bleeds out. The engineer becomes a translator of decisions you could have made directly. Every round of screenshots and clarifications is time neither of you gets back.

Figma Make is a direct answer to that specific problem.

What the workflow actually looks like

Figma's example centers on a fictional museum website (the Museum of Speculative Futures) that needs accessibility improvements while the engineering team is heads-down on a bigger architecture rewrite. The PM's suggestion: let the designer own the small, craft-level fixes end to end using Figma Make with the production codebase.

Here's the sequence, stripped to its essentials:

1. Pressure-test the current design with the Figma agent. The designer uses the agent inside Figma Design to generate synthetic personas — a first-time visitor, a returning member, someone navigating with a screen reader — and runs them through the site. The feedback that comes back is specific and small: a confusing navigation label, a low-contrast date picker, a call-to-action that's easy to miss, a search that dead-ends on a blank result.

2. Get a gut check from the team. Before touching code, the designer, engineer, and PM walk through the proposed changes together and align on what's in scope. This step matters: it's not "designer goes rogue in the codebase," it's "designer takes ownership of well-understood, agreed-upon fixes."

3. Connect the GitHub repo to Make. The engineer grants access, the designer connects the project's GitHub repository to Figma Make, and the production codebase is now live inside Figma. The designer creates a new branch off the current site and starts working.

4. Work in code, not just mocks. This is where it gets genuinely interesting. The designer starts with what looks like the simplest fix — the date picker. In a static mock, that's a five-minute change. But working against the actual code, Make surfaces something the canvas can't show: the date picker is a shared component, used on the exhibition page, the events calendar, and inside the membership sign-up flow. A ticket would have said "fix the date picker on the exhibition page." The code knows it's really a change that needs to happen in three places at once.

That last point is the clearest argument for this workflow. Designs lie, a little. They show one screen at a time. Code shows you the whole system.

What to pay attention to as you try this

You're not taking over engineering — you're handling the last mile. The workflow is explicit that the engineer stays focused on the bigger rewrite. The designer's scope is narrow: well-defined, low-lift, craft-level changes that are genuinely too small to prioritize in a normal sprint but too important to ignore. That boundary is what makes the collaboration work.

The handoff inverts at review. Instead of you writing a description for an engineer to build, you build it and the engineer reviews. Their judgment lands at review rather than implementation. For most teams, this will feel unfamiliar — but it's worth noting that the engineer's expertise still shapes the final result, just at a different point in the process.

Annotations help you work in context. The workflow mentions using annotations inside Make to flag intent and reasoning for reviewers — the design equivalent of a code comment. If you're shipping a PR, leaving breadcrumbs for whoever reviews it is good practice.

Synthetic personas are a starting point, not a finish line. The Figma agent's personas surfaced friction early, but Figma is careful to note they don't replace real user research. They're useful for catching obvious issues before you spend time on implementation.

The honest limits

This workflow assumes your team is already set up with a GitHub repository that can be connected to Make, and that your engineer is willing to grant access and review your PR. That's not a given everywhere — some codebases are locked down, some engineers will have reasonable concerns about a designer working directly in production code, and some teams simply aren't there yet in terms of trust and process.

It also requires you to get comfortable with the fact that working in code sometimes reveals that a "simple fix" is more complex than it looked on the canvas. That's not a bug — it's the point — but it does mean your time estimates need to stay flexible.

The bigger shift here isn't technical. It's organizational. Figma Make can give you the capability to own more of the implementation. Whether your team's workflow has room for that is a separate question worth having explicitly, not assuming.

What's clear is that the gap between design and shipped product just got a concrete tool for closing it — for the right kind of fix, on the right kind of team.