Handoff Is a PR

For years my job ended at a Figma file. Redlines, a Dev Mode link, a ticket, and weeks later a build that was close but not quite. Now it ends at a merged pull request. I make the change in the codebase with GitHub Copilot in VS Code, push a branch, and open the PR myself. QA meets the change on SIT once it's in develop.

The first draft of this page leaned on industry research and made Figma look more central than it is. This version is the process I actually run: the branches I touch, the commands, how QA picks it up, and what happens when a developer and I end up in the same code. The industry context is still at the end, because it's useful to know this isn't only my team.

One screen, from idea to release.

What disappeared is everything that existed only to translate a file into code: redlines, spec notes, "the build doesn't match the mock" tickets, the wait between rounds. Polishing every state in Figma went too. The states now get polished once, in code.

We use a Git Flow shape. It's not fashionable. Vincent Driessen, who wrote git-flow, said in 2020 that teams doing continuous delivery should use something simpler, and Atlassian now calls it a legacy workflow. It still fits a product with SIT and UAT stages, because each long-lived branch maps to an environment.

The map

I only ever create feature/* branches. Release branches and the merge into main belong to the developers, and we merge with merge commits, so the history keeps every branch visible.

How QA knows what is on SIT

No build hash in a footer. A deploy notification and the team channel. When something merges into develop and goes out, QA hears about it there. Fixes found during testing go up separately as their own branches. Per Git Flow, once a release branch exists, bug fixes for that release are made on the release branch and merged back into develop; before that, they go into develop like any other change. Which of the two a fix takes depends on where the release is.

What a typical change looks like, with the commands I actually type. Copilot does most of the editing; Git is still mine.

Two habits matter more than any command. Sync with develop before opening the PR, not after the reviewer finds the conflict. And keep the PR to one screen or one fix, because a reviewer can actually read that.

For syncing I merge develop into my branch (git merge origin/develop). Rebasing rewrites history and needs a force push, so I only do it on a branch nobody else has pulled. One trap worth knowing: during a rebase, "ours" and "theirs" in the conflict editor are the reverse of what you'd expect.

Copilot doesn't know our design system unless the repo tells it. That's what .github/copilot-instructions.md is for, along with path-specific .instructions.md files that apply only to matching folders. Agent mode reads them on every request, and since August 2025 Copilot code review reads the same file, so the rules that guide the change are also the rules it's reviewed against.

The rules that matter most for UI work are boring and literal: use the existing component before writing a new one, use tokens instead of hex values or pixel spacing, cover loading, empty and error states, don't touch shared business logic without saying so in the PR, and warn me before editing code that someone is already changing on another branch.

Figma has a small job now

Ideation, and sometimes pulling an existing, detailed component into the conversation through Figma MCP so Copilot builds against the real spec instead of guessing. The setup is one entry in VS Code's MCP config pointing at Figma's remote server. As of October 2026 Figma still lists that server as beta, and in an enterprise org an admin has to allow MCP servers in Copilot first.

This is the part nobody writes about, and the part that actually goes wrong.

The case

During payment work, the payment history page and the payout approval flow shared the same logic. I was fixing something on one screen. A developer was fixing something in the same logic for the other. Neither change was wrong on its own. Together they collided, and because the code was shared, a fix on one screen could quietly change behavior on the other.

There are three kinds of conflict, and only one of them is loud:

The payment case started as the third kind and could easily have shipped as the second.

What I do instead

Prevention, not resolution. One of the instruction files tells the Copilot agent to warn me when the code I'm about to change is already being worked on in another branch, before it writes anything. When that warning comes up, we decide who takes that part. If it's the developer, I don't touch it. They finish and merge into develop, I pull, and only then do I start the work that connects to it. The conflict editor never opens because the two changes never overlap in time.

We don't use CODEOWNERS, so these boundaries aren't enforced by the repo. The warning and the quick conversation after it do that job, and every PR still needs two approvals before it merges.

QA used to spend a lot of their time comparing builds to Figma. Spacing that was a few pixels off, the wrong grey, a missing hover state. Those bugs existed because the same screen was built twice, once in Figma and once in code. When the designer writes the UI, that whole category mostly disappears.

So their process got shorter, and their scope got wider. They pick up the change on SIT once it's in develop and spend the time on what I and the agent are bad at: functional edge cases, real data and integrations on SIT, regressions on other screens that share the same logic, accessibility, and devices. The payment case above is exactly the kind of bug they're now positioned to catch.

The loop

Nobody has published numbers on how QA changes when designers write the UI. The World Quality Report 2025-26 describes tester time moving from writing test scripts toward risk analysis and test strategy, which matches what I see, but this part is observation, not measurement.

Things I don't do: create release or hotfix branches, merge into main, or change shared business logic without a developer agreeing to it first. New components go through a developer. Copilot's review is a first pass, never the approval.

I'm not alone in working this way. Buzzvil, a Korean ad-tech company, published six months of designer PRs in September 2026: 432 of them, participation from 17% of the design team to 100%, and Figma Dev Mode seats from 23 down to three or four because there was no handoff left to inspect. Figma's 2026 AI report says designers doing development work doubled in a year, from 21% to 41%. But almost every public case is a startup testing on per-PR previews, mostly with Claude-based tools. A Copilot workflow running through a shared SIT and a UAT stage, with QA in the loop, is barely documented anywhere.

What I would tell another designer

Git isn't the hard part. The hard part is three judgments. Can I rebase this branch, or has someone else pulled it? Is this conflict mine to resolve, or is it logic? And is the thing on SIT actually my change? The design file used to carry the design decisions. Now the pull request does, and so does the code it merges into.