In this discussion, the speakers examine whether design systems should originate in Figma and flow to code, or be generated from code back into Figma. They note that in large enterprises, the standard practice is to start with a design schema, naming conventions, and guidelines in Figma, then hand off to engineering to build a UI kit. Once a UI kit exists, there is interest in a two‑way sync that lets designers import code‑level semantics (e.g., component definitions, props) back into Figma, but this is still exploratory. They highlight failure modes when trying to extract semantics from Figma that never existed (hard‑coded hex values, missing props). For small teams (one or two people), the need for Figma diminishes; a code‑first approach may be sufficient, especially when design and engineering roles overlap. The conversation references the Shipwright design system as a greenfield example that still starts in Figma, and they speculate on how the workflow might evolve over the next year, questioning whether Figma will remain a required approval and strategy layer.
We had a, a question come in here from Justin and I'll upload it here, but have you looked at the reverse direction generating Figma from code instead of code from Figma? It seems like a lot of these failure modes, invented props, hardcoded hex, wrong component, come from trying to extract semantics Figma never had in the first place, rather than pushing semantics you already have in code outward.
Yeah, that's a really good question. I would say that typically your design system is going to start with— there's a schema, there's naming, there's guidelines, there's documentation, generally speaking, that exists before the UI kit. And so at, at the new birth of a design system, you're typically starting from design and I'll just use Figma as the tool for that. You're starting from Figma and you're flowing into engineering, into the development. Of components and a UI kit. That typically, that's what happens. But once you have that UI kit established, Billy and I and Andrew and others have been exploring what then, to your question, like, what does it mean then if I want to improve this component definition that doesn't yet have representation in Figma? We've been exploring ways to empower designers to help bring some of that concept from code back into Figma. But in the end, that creates a, that creates a two-way street. It creates the second of a two-way street. We haven't started. And to be honest, I think we'd have a hard time imagining starting from code and then establishing the design system and all the definition with that design system in Figma. We just typically start again from design and flow into engineering, if, if that helps.
Yeah. And for, for context, Justin, these approaches really hold true inside of larger enterprise teams, product teams of 20, 30, 50, right? We also have greenfield projects that, that Tim mentioned where we still will start with the Figma design system. That we've created called Shipwright. But we'll start there and define it out to kit for designers to use and then push into code. But really is that foundational layer. But I would say if you're a small team of one or you have two people and one of them's design engineer or front end, I mean, you may not have to be in Figma. I think that's the discussion that's up, up for grabs is, hey, what does the future look like, you know, a year from now, even for small teams now, do you need Figma? Well, you Not really, no. So it kind of depends on where Figma sits in your workflow of approvals, of decision-making, and of product strategy. And that's kind of the core of, do we need Figma or not? Or can we go, can we create something in code and push backward? And in that case, you're probably using it a little bit different than how we're seeing teams use it in these larger contexts across multiple products or platforms or things like that. Hopefully that's helpful.
