中文
Figma Config

A nine-person studio spent 12 months getting designers pushing production code — the method and the numbers both transfer

From handoffs to upstream ft. Frederick Andersen (EDL) | Config 2026 · Frederick Andersen

21 min
Design-to-CodeAI Coding

21 min total·Actually worth watching closely: ~5 min·2 must-watch clips

Orange = the 5 minutes worth watchingFor the rest, the guide is enough
Segment guide · 7 segments
  1. 0:12 2:40Listen

    Where design gets lost

    He opens straight with the diagnosis: quality doesn't leak because someone isn't invested, it leaks structurally — the people who care about the details are not the people implementing them. Every handoff in between dilutes the intent.

    Treat "what shipped isn't right" as a problem in how the collaboration is structured, not in how hard people tried.

    This stretch runs entirely on his spoken chain of reasoning; the screen is basically him and a title line, so watching adds nothing — fine to listen while doing something else.▶ Jump to 0:12
    Speaker · Frederick Andersen
  2. 2:40 5:20Listen

    The studio stopped handing off mockups for good

    His answer is that design has to own the code — the design system or the front-end implementation in its own hands — so the gap between the intent in Figma and what finally ships is as small as it can be made. To do that the studio stopped delivering design files and moved to building and shipping itself.

    "Owning the code" is a decision about the delivery model, not an extra skill bolted onto designers.

    A first-person account of a business decision — trade-offs and costs, with no artifact or interface demo to look at. You lose nothing by listening only.▶ Jump to 2:40
    Speaker · Frederick Andersen
  3. 5:20 7:15Listen

    AI compresses the timeline, not the bar

    Two years ago versus now: a designer able to ship a production-grade design system used to mean a full career change; today, with the right conditions, 2–4 months of focused training is enough. But he explicitly denies that the bar has dropped — architectural intuition, an understanding of the DOM, and being able to direct a coding tool rather than type prompts into a chat box are all still required.

    AI shortened the learning timeline; not one item came off the list of skills.

    The most easily misread claim in the talk, and its value lies in how carefully he words it. The visuals add nothing here — listening closely beats watching.▶ Jump to 5:20
    Speaker · Frederick Andersen
  4. 7:15 10:40Listen

    Validating one person with a one-week timebox

    Rather than assessing through interviews, he cleared the candidate's calendar for a week and handed over a B2B SaaS interface already finished in Figma but never shipped, asking for the components to be extracted and an initial component library stood up. A week later the code was rough and nothing was truly finished, but the four skills he was looking for had all surfaced — so he committed fully.

    What's being validated is whether the capability surfaces under pressure, not whether the artifact meets a bar.

    He narrates the setup, the constraints and the criteria; the screen never actually shows the interface or the component library that came out, so hearing "what is and isn't being tested" is enough.▶ Jump to 7:15
    Speaker · Frederick Andersen
  5. 10:40 14:17Listen

    Leaving guardrails for perfectionism and feeling like a fraud

    The biggest drag in the transition is perfectionism and impostor syndrome. His move is to say it out loud in advance: I expect mistakes, and in a few weeks we'll look back and feel embarrassed — and that is precisely what says it's working. Two low-cost mechanisms go with it: a fixed 15-minute design engineering sync every day so solo exploration doesn't get stuck in polishing, and dropping the person straight into engineering meetings with no runway, teaching only the line "we'll evaluate the options and come back to you."

    Naming the feeling before it hits works far better than consoling afterwards.

    This stretch is spoken management practice, and its value sits in the exact wording of a few lines — worth hearing clearly, even writing down. Nothing on screen illustrates it.▶ Jump to 10:40
    Speaker · Frederick Andersen
  6. 14:17 18:40Listen

    Let the peer say it, not the boss

    Spreading from one person to the whole team: he had the person bring their own code and component library into the studio-wide design reviews, and at the annual offsite had that designer, rather than the boss, announce that design engineering was becoming a core service. The reasoning: the same sentence from a boss is an instruction; from a credible peer it's a manifesto.

    The variable driving cultural spread is who says it, not what is said.

    The whole stretch is retrospective narration — the reviews and the offsite are described, never shown on screen. Take in the full logic and you're done; no need to watch.▶ Jump to 14:17
    Speaker · Frederick Andersen
  7. 18:40 20:48Skim

    84% and one honest closing line

    The results: one designer went from "just pixels in Figma" to a design system used by developers across three continents, three people push to client codebases, 84% of the production code on one client project is built by designers, and the mobile component library built in the first five months now backs several white label apps. The close is restrained — not every designer has to make this move; today half the team ships code and the other half does work that matters just as much. His advice to design leads: pick someone next Monday and hand them an interface that's already ready to implement.

    Behind the 84% is a line that has been removed, not designers writing a bit of code on the side.

    These results are a few parallel figures and facts, listed out on screen — one scan to take in the key ratio and scope is enough; the closing advice is a single sentence you can just hear out.▶ Jump to 18:40
    Speaker · Frederick Andersen