Building digital experiences is hard. It requires multiple disciplines that individually all have great depth. In my opinion, the single greatest challenge that teams must overcome to ship great software is communication related. We're all just trying to describe the shadows we see on the cave wall well enough to each other so that our users get as close a thing to what we actually wanted to build.

This is most evident in the design to dev handoff. Different orgs, different teams in the same org, heck, even different designers in the same team all approach this nexus point differently and with varying levels of success. Over time, (and with enough friction and trial) you will organically build patterns for your team but it's a challenging problem. On one side, you have little to no handoff and leave individual contributors to make assumptions about intent and hope they'd do the required legwork to get any overtly ambiguous questions sorted out quickly or risk substantial rework and frustration. On the other, you have a laborious and drawn out process that is overly rigid and ultimately resistant to improvement and agility.

There are some exciting trends that together could greatly reduce overhead while increasing handoff fidelity.

1. Organizations bought in to Design Systems as a default
2. Component-first development workflows
3. Proliferation of open source and accessible component libraries
4. Tokens getting feature level support in design tools like Figma

I'm not going to dive into each of these, there is a ton of info around the web about each. However, I do want to talk about the last point and how it stands to revolutionize how we build UIs.

Common ground

The underlying idea that each of these trends has is fundamentally about a shared language or common ground across disciplines. What it means to be some piece of discrete UI for that design system that everyone can understand.

What is a button? What different ways can it display itself? How does it change over time? What are the various properties that are used to define all the various buttons your system supports in all the various states it can possibly exist in?

Anyone that has built a design system with any amount of production use will tell you this is difficult and challenging work. Once that investment has been made though, the composable block is ready for all teams to use. Because of tool limitations, we've been forced into a process where each discipline essentially has to talk in great detail about the minutiae and then go and independently build their best attempt based on their understandings of those conversations.

Specifically regarding design tokens. The designers might define their tokens directly on the canvas or via a plugin. The developers might define some CSS classes or a JSON blob based on their understanding. Even though they are trying to describe the same fundamental concepts they were separate disjointed artifacts. This separation continued up the conceptual hierarchy of the design system, with each layer being less reliable than the previous. With great focus, patience, and determination teams could successfully create full systems.

The future

Last year Figma added a new feature called Figma Variables and exposed APIs to work with this features data that have the potential to unify this separation. At a high level, it lets you create variables of type string, color, number, or boolean and organize them into groups and collections. Then you can bind properties of nodes on the Figma canvas to those variables. If anyone ever changes the value of that variable, all the nodes with properties bound to it automatically update too.

What really makes this powerful for the purposes of design handoff is that you can get at this data via new APIs. There are two APIs that Figma provides:

1. One specifically for Plugins so they can access Figma data at their runtime
2. The other is a REST API that can work from any application or script

Note: There is a big caveat with the REST API. The variables endpoints are only available to enterprise level orgs, (highest $$$ tiered level). Which is a damn shame because it rules out some really interesting use cases for the vast majority of users and teams.

Since I don't have access to an enterprise level org, I don't have experience with the REST API. That being said, their plugin API exposes the same data to plugins during their execution lifecycle. Having that access is great but for the other artifacts of the design system to leverage those tokens directly, you'll need to build some method to export or expose them yourself.

Once they're available, you can integrate them into the other artifacts. These integrations can serve multiple purposes but here's a few top of mind ideas:

• integrate them into the documentation system you have so users always have up to date and reliable documentation
• automate their import into the components repo so that your dev teams never have to manually manage or doubt the references the components are using are trustworthy
• quickly roll token value updates out by baking it into your CI process by opening a PR to the relevant code repositories when tokens are published

Having built a few plugins that work with the Figma variable data in various ways, I haven't felt too limited without direct access to the REST APIs. Though I would love to get access and build some open source tooling, if you're also interested and want to collaborate please reach out!

All the plugins I've built that work with these APIs all export the Figma Variables they find in the current file into various formats so that application developers can use the values directly. This is the most simple and straightforward use case. Just the fact that multiple disciplines are building on top of primitives that are not just the same values each created and maintained independently but are fundamentally the same thing can't be understated. When one team changes one, the other team inherits the update. This is exciting, and it begins to paint a picture of a much more synchronized cross disciplinary workflow.

Instead of building things independently and hoping enough of the core essence of the thing makes it through to the production deployment we are working together on the same artifact. Variables & Tokens today, perhaps variants, components, and even pages tomorrow. There's no reason that layers that transform these concepts from Figma into application code couldn't also be introduced.

Going the other direction

Figma released Code Connect earlier this year too. Its current iteration is more focused on making the connection between the Figma component and the code for that component. It primarily acts as a documentation tool to show the source code for that variant of that component right in its panel. This is great to get a quick understanding of how to get specific piece of UI into an app.

It isn't hard to imagine a future version where Figma could tar this info and generate the code for a page or entire app given the design system is comprehensive enough and properly integrated. An even further view of this feature, likely supported by their recent AI push, could by something like importing the coded component directly into Figma, or generate the source of a component created in Figma.

Regardless of what the future looks like, all your teams having a shared understanding and language about the primitives that underpin everything your design system provides is the critical first step. Closing the gap at that foundational level empowers closing the gaps higher up the abstraction ladder.

Thanks for reading this far, and if you're interested in collaborating on tooling around bringing any of these ideas to life, please let me know!