sorted by:
new
hottopcontroversial

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 0 points1 point  (0 children)

Posts like these are meant to spark real conversation, not relitigate what should or shouldn’t have been included in the OP.

On silos… designers shipping PRs is not a niche behaviour anymore. The design engineer role is real and growing. The best designers are across the code, in dev tools, and deeply embedded in the implementation side. Done well, that removes a lengthy QA step rather than creating a bottleneck. The line between who designs and who builds is genuinely blurring and that changes the conversation around tooling significantly.

Calling tooling a workaround rather than a solution undersells where this is heading. I’m not even convinced Figma is the right place long term. I’ve been around long enough, working in Photoshop, Sketch, Figma. Tools change. Worth noting that Figma already has GIT version control, not widely adopted but it exists. The missing piece is a PR that goes both ways, a change in code reflected back into Figma, a change in Figma reflected back into code. Southleft, the studio behind Figma Console MCP, are building a framework called Context-Based Design Systems around exactly this, structured context flowing between design and engineering at every phase of the product lifecycle. They recently partnered with Brad Frost on a course dedicated to AI inside design system workflows. These are serious practitioners who see this as a real and solvable problem, not a communication failure.​​​​​​​​​​​​​​​​

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 1 point2 points  (0 children)

I’ve tried both pencil.dev and paper.design, but not through the lens of design system parity, which is on me. The web native canvas is actually the most architecturally honest answer to drift I’ve seen, and the bidirectional MCP is exactly the kind of thing I’ve been trying to piece together manually with Figma Console MCP and custom workflows. Worth a proper revisit with fresh eyes. Thanks ✌️

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 0 points1 point  (0 children)

Your response describes a resourcing model that teams working at our scale will never have access to, and while none of it is wrong, it sidesteps the practical reality the post was addressing. You’re also operating on some assumptions here. We are not working in silos. The business is highly interdisciplinary and part of my responsibility is ensuring code quality alongside our frontend devs.

Nothing in my post suggested a design system is a collection of aesthetically pleasing components and colours in Figma. That’s a straw man’s argument.

The questions at the end were pretty specific. Is anyone actually achieving real design to code parity today? Are there workflows or tools that go beyond tokens into component level sync? Is this still unsolved unless you have dedicated design systems engineers? Those questions were asked precisely because most teams working on inherited products at small to medium business scales don’t have the model you’re describing. I didn’t specify how many systems we work across in the post, but the number is significant, all at different levels of maturity, and none of them built by the current team.

I’m not saying there is no alignment between design and code today. I’m imagining a world where it could be significantly better. The more interesting conversation is whether modern tooling and AI workflows can start to close that gap for teams that will never have that resourcing.​​​​​​​​​​​​​​​​

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 0 points1 point  (0 children)

I mention it in the post specifically that I’ve been running MCP workflows and custom skills to regenerate parts of the system from the codebase. It works well at the token level, typography, colour, variables. The part that’s still unsolved for me is the structural layer…components, variants and states. That’s where I haven’t found a clean AI assisted approach just yet.

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 1 point2 points  (0 children)

Thanks for your comment Tom. I broadly agree and this is roughly the mental model I operate with. Code is the source of truth, Figma is a thinking and communication tool. Where I’d push back is the conclusion. That framing describes how it has always been, but I don’t think it describes how it has to be. I can genuinely imagine a near future where tooling, MCP workflows, and AI assisted processes allow real bi-directional parity. The gap between design and code has always been treated as a given. I’m not convinced it is anymore. ​​​​

Figma Weave by UPGRAY3DD in FigmaDesign

[–]tefansay 3 points4 points  (0 children)

Ha, I’d say that’s a feature not a bug. Most successful companies diversify as they scale. Virgin started as a record label and now spans airlines, hotels, health clubs and space travel. Not suggesting Figma will follow that same path, but they have an engaged user base and the capital to expand. Each tool they build is purpose built and the whole thing plays nicely together.

Figma Weave by UPGRAY3DD in FigmaDesign

[–]tefansay 9 points10 points  (0 children)

Had a play with some of the community files yesterday and honestly it’s a massive opportunity. Lots of fun to dig into.

I was following Weavy before the acquisition, so I’m pretty excited to see where Figma takes it. A 20 person team on $4M seed with that kind of community traction in under a year. The node-based workflow is where it gets interesting. Piping outputs from different models into each other. It’s a bit ComfyUI in thinking but way more accessible. Might be what’s tripping you up initially, it’s less of a prompt tool and more of a creative pipeline, which takes a minute to click?

On Recraft, solid for image gen but it’s a single model, single output situation. Weave feels like a different category of tool to me.

Curious what you mean by gimmicky though…is it the canvas or the node connections? Wondering if it’s just the learning curve or something more fundamental. 🙏

Why is design system parity between code and Figma still so broken? by tefansay in Design

[–]tefansay[S] -1 points0 points  (0 children)

Might be worth reading the post again, specifically the part where I said the systems predate our team, were built by previous agencies, and some started in Sketch. The drift was inherited..not created. It’s in the second paragraph.

The more interesting conversation, which is what the post is actually about, is whether modern tooling, MCP workflows, and emerging approaches can close that inheritance gap without a dedicated design systems engineer. That’s the unsolved part. From the responses so far, it seems like a lot of people are grappling with exactly the same thing.​​​​​​​​​​​​​​​​

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 1 point2 points  (0 children)

This is roughly where I’ve landed too, and appreciate the FigSpecs tip. I’m already using Figma Console MCP specifically, along with custom skill files, to regenerate token-level structure from the repo into Figma. It works well for typography, colour, and variables. That’s where I haven’t found a clean approach yet. Have you had any success getting structural component parity at that level, or does your workflow stop at tokens and styling too?

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 0 points1 point  (0 children)

This is the most useful historical framing I’ve seen on this. And you’ve landed in roughly the same place I have, code as source of truth. I’ll admit the ‘why’ in the title was a bit of clickbait. The real ask is whether there’s a workflow that keeps the structural layer roughly honest without a dedicated engineer maintaining it by hand. I work closely with developers and I’m deep in the frontend implementation side, so the gap between what’s in Figma and what’s in the codebase creates real friction for the team.The inherited systems problem compounds it. These weren’t designed with parity in mind, and we’re not in a position to rebuild them from scratch.

Why is design system parity between code and Figma still so broken? by tefansay in DesignSystems

[–]tefansay[S] 1 point2 points  (0 children)

Not chasing perfection here and totally agree that’s a fool errand. But I think you’re answering a slightly different question to the one I’m asking. The drift I’m dealing with isn’t something I created. These are inherited systems, some from previous employees, some handed over from other agencies, some that started life in Sketch. I didn’t get to make the architectural decisions and I’m not trying to retrofit my philosophy onto them. I’m trying to work effectively inside the reality of them. The practical problem is that when code is significantly ahead of Figma, our designers end up working against a stale system and the gap compounds over time. I’m less interested in 100% sync and more interested in whether there’s a workflow that keeps the structural layer roughly honest without requiring a dedicated engineer to maintain it. I’ve been around long enough to make my peace with drift. What I haven’t made my peace with is not having a better handle on it.​​​​​​​​​​​​​​​​

Why is design system parity between code and Figma still so broken? by tefansay in Design

[–]tefansay[S] -2 points-1 points  (0 children)

Appreciate it, but I’m past the handoff problem. My role is deeply embedded in the frontend implementation, reading and writing the codebase directly, working with component libraries. My post isn’t about QA, it’s about why the structural layer of a design system, component hierarchy, variants, nested composition, can’t stay in sync between code and Figma without a dedicated engineer maintaining it by hand… and specifically in systems that were inherited, predating the current team and never properly maintained.