Hey friends, I'm Jake. I'm a developer

advocate here at Figma and we are so

excited that you're here. Before we

really dig in, I want to take a moment

to talk a little bit about design

systems and how we can think of them as

building blocks for efficient design

informed product development. So context

is everything and when we talk about

development workflows and dev mode, we

really want to be thinking about it as

how do you describe your design intent

to the people that you're collaborating

with as well as the tools that they're

using. Now, we're very familiar with

design systems in Figma. A lot of you

are very familiar with these concepts.

But here are some like named

abstractions that we have inside of

Figma. We have things like variables,

right? Which are like the design tokens

you have in your system. Those values

can change between themes, whether

they're colors or sizes or text values.

Then we also have components, right?

Which are kind of those reusable

elements that have component properties.

Uh those can exist inside of Figma and

code as well. And then we have styles.

Sometimes we talk about these like

they're composite tokens, right? Styles

are many tokens described by one idea,

something like a box shadow or a text

style. Those are all kind of the named

abstraction design patterns that we have

in Figma. But you also have a lot of

other ones that sit inside of your

codebase and are kind of implied in

Figma. So you also have abstractions

around layout. How do you think about

grid systems, responsiveness? Are you

using flexbox? are using absolute

position. A lot of teams have named

abstractions there. We also have like

how do you think about usage guidelines

and how do you describe your libraries

and like what sorts of naming

conventions are shared across

components. Uh there's all sorts of

things there that you build patterns

around. But then on the engineering

side, we also talk about like content

and state and how do we build patterns

around the way things work and the way

things are filled with data and the way

we store data in the back end and how we

refer to that data, the schema. And so

it's important to be thinking about all

of these things when we're talking about

implementing something that has been

designed inside of Figma. We're going to

be talking about dev mode today. And dev

mode is a dedicated space inside of

Figma with the developer perspective in

mind. And designers come into it to work

with developers to efficiently take

ideas from design to production. How you

do things inside of dev mode. And we're

going to get to some examples of this in

just a second. We have codebased context

inside of Figma. So Figma isn't just a

place to only think about design. It's

also a place to associate some of those

things that are in Figma with things

that are in code. And there's a couple

different ways we can talk about it. One

that you may have heard of is code

connect. And we'll show some examples of

this later, but this is a way to uh

document your components uh in Figma

with their component code uh that's

coming from the codebase. Um so code

connect snippets are these dynamic

snippets that show the production form

of the designed component inside of dev

mode. Now we also supply this over MCP

to agentic workflows which we'll talk

about and there's a lot of really cool

ways in which code connect snippets can

be utilized whether it's visually like

this or in kind of like a developer's

coding workflow. Now, we also have a new

way to do code connect that is a little

bit lower lift for a wider amount of

connections. It doesn't get in depth to

the same degree that code connect

snippets do, but it allows you inside of

Figma to quickly map your library to the

relevant files in the codebase. And this

little relationship between a component

in Figma and a file in the codebase can

actually be really important and helpful

in agentic coding workflows. And so we

have code connect UI that allows you to

do these sorts of mappings really

easily. And it's just another example of

the different ways we're bringing

connections to the codebase into Figma.

There's a lot more to come here with

features like this. Uh but I did want to

preview this uh for y'all. Um and I can

show what this looks like in a little

bit. Last but not least, I want to call

out variable code syntax. So for your

teams that are using variables, you can

actually supply the code form of those

variables inside of Figma. In this case,

we have, you know, a token that's called

background default secondary hover and

it has different values and different

modes. This kind of sentence case form

of it is really helpful inside of Figma

as well as the groups. But in the

codebase, you might actually like add a

prefix and like maybe have the word

color as a prefix in addition to like

the design system abbreviation or

something, right? You might have a very

specific form of this in your codebase

that might not be onetoone with how it's

kind of named inside of Figma. So what

we allow you to do with code syntax is

for web, iOS, and Android supply

different code syntaxes for your

variables so that your developers see

the exact representation of the variable

when they're inspecting it in Figma and

when we're providing this metadata to

LLMs through our MCP server. All right,

so let's take a peek at what this looks

like inside of Figma. All right, so here

we are. We have a design. We're using a

design system. This is a clone of our

simple design system, which is a design

system that sits in Figma. and there's a

React code representation of it. That's

what we're going to be using today to

kind of do this demo. Now, we see that

in the design system, we have a bunch of

text styles. So, those are over here.

All these values are bound to variables.

If we want to take a peek at all the

variables, we can open up this little

control panel. This is the typography

collection, but we could also look at

color. We see a bunch of different demo

variables in here. I can click on this

and see that code syntax we were talking

about earlier and how that's been added

to these variables. And so, our system's

set up, ready to go. We also have a

bunch of components. But let's just talk

for a second about what we do before we

hand it off to developers. We've created

these comps. They're using the design

system. And we've also brought in

annotations, right? And so, for example,

I've created an annotation with a

content category that says, hey, this

content for this FAQ is stored in the

CMS. We can also just write arbitrary

annotations and map specific properties.

In this case, we're calling out the fill

color. We can also do things like call

out the direction of the auto layout. We

could do the gap. You know, if there's

any any specific properties we wanted to

reference, uh we can call that out. So

you could also call out, you know, the

the variant of the component. Now in

addition to that, these are rich text.

So we see some bold text here. Uh but we

could do this, right? And and italicize.

Um and so you have the ability to kind

of like write a headline.

we can end up doing a whole bunch of

rich text stuff here. Okay, there's a

lot of rich context inside of Figma and

sometimes you want to pull out specific

things. So, a good way to think about

annotations is to either call out

specific things that might get lost in

the context of the design or to provide

information that wouldn't otherwise be

provided. Right? So, in this case, we

have an image background. In this case,

I'm using an annotation to say, "Hey,

this asset is in our brand approved

drive, you know, and and reference a

specific image." Think of annotations as

a way to bring a bunch of different

context to what you're going to hand off

to your developers. Now that we're ready

to hand this off to developers, we can

actually select this section here and we

can mark this as ready for dev. One cool

feature about Figma AI is we actually

detect opportunities for you to improve

this design before handing it off. One

thing that we know is that metadata

about the design is really important

whether it's a developer looking at it

or the LLMs and the tools that they're

using. Um, and one of those pieces of

metadata is the name of layers, right?

And so we always talk about naming your

layers. And in this case, when we mark

this as ready for dev, Figma AI has

detected that there's a couple layers in

here that might be worth a name. And I'm

just going to go ahead and allow Figma

to name those for me. That's great.

Thank you so much. And so now we know

that everything in here is kind of like

passed a little bit of an audit. We know

that we've kind of tred this up and it's

ready to be consumed by our developer

counterparts and the tools they're

using. Before we switch into dev mode

here, I want to call out this ready for

dev view that's right here. When we

click on this view as a developer, we

look at this massive file with a ton of

pages in a different view. This view

only shows things that have been marked

as ready for dev in a timeline

orientation. This is a lot easier for

developers to consume. If you think

about it, like these design files that

we create can be massive and have a

whole bunch of context in them. And

sometimes it can be easy to get lost

what is and isn't important. This

timeline view allows developers to

consume it in in those terms. And when

they click on one of these, they're put

in the focus view, which is scoped to

just the the section in this case that

was marked as ready for dev. They could

do different things like, you know, take

a peek at it in dark mode, right? we get

all this nice little features around

this kind of dedicated environment.

Within here, we have the inspect panel

as well. I'm going to go back to dev

mode, but before I do, I'm going to call

out our plug-in ecosystem here. So, you

can run plugins in the inspect panel.

And one I want to call out is the Jira

plugin. So, for teams that use tools

like Jira, uh they can actually run

these things directly inside. We could

create an issue. Uh let me see what's

going on with this one here. Uh we can

load an issue. We can change the status

directly inside of the plugin. We can go

back and see what else is on that page.

So, I'm going to go ahead and select

this Tailwind one here and see how this

does. So, plugins like this actually

show code directly inside of the panel

itself. Codegen plugins can render code

directly inside of the inspect panel,

but then some other plugins like we were

just looking at with Jira can open up an

entire user interface inside of this

inspect panel. So, let's actually go

directly to this on the page and we'll

find ourselves back uh in the world of

our nice messy file, right? So, remember

the infinite canvas is your opportunity

to kind of explore and really figure out

what it is you're making and and and it

prioritizes exploration. Uh but your

developers like to stay focused. So,

we're going to land back on the canvas

and I'm going to switch into dev mode.

Uh clicking this toggle down here, we'll

go back to the inspect panel. We see

that same inspect panel we were looking

at earlier. I'm actually going to switch

the language we're looking at to CSS for

a second. Uh and I'm going to click on

this section. Now, we get a whole bunch

of information in here. And I'm going to

start at the bottom. So, we see that we

can export this entire thing as a ping

image if we wanted to. We can change the

resolution of the export. Uh we also

have other export options down here from

SVG to PDF, JPEG, etc. depending on what

it is we're trying to export. We also

see that it's surfacing some icons and

some assets that we might want to export

as SVGs. We also see selection colors

categorized by what they're being

applied to. And then we also see CSS

here. We see code syntax that represents

the way it's defined in the codebase.

And that's pulled out right here. For

colors, I'll click on this one here. We

get to see kind of how it's inherited,

right? So this one, this color has been

aliased to another color. Um, and so we

can see how we arrived here based on the

mode. We could switch to dark mode and

see how that alias change changes. I'm

now going to select this component and

we'll get to see code connect in line.

Right? So if we select an individual

accordion item, we see the code connect

for that. We get a link uh to GitHub

where this component is described. And

then when I select the greater

accordion, we get to see all of those

rendered fully kind of recursively as a

React code snippet here. So code connect

is really cool because it allows you to

bring that codebase context you have

inside of Figma. So your developers are

actually getting really relevant

previews of the code representation of

the design. An example of like how this

can actually be pretty nuanced is this

is going to be a component we're going

to be using today in this demo, but this

is a pricing card. And often times like

this sort of a component is called like

a vanity component or a wrapping

component where we've basically said

even though there's a ton of instances

inside of here, we're creating a very

flat component structure for

representing this thing. But because all

of these components are documented with

code connect, I can actually come in

here and select like uh I'll select this

text list and the text list itself can

be looked at individually or this

button. we can see how to implement this

button if we ever wanted to implement a

button this way. But at a high level for

the pricing card, if we want to see

this, this is all we need to provide,

right? And so depending on what you're

doing as an engineer, maybe we're

looking at this navigation pill list.

There are different reasons why an

engineer might be interested in diving

in or zooming out when they're

inspecting with code connect. Now, to

make code connect work, we're going to

switch over to the codebase. And in here

we can see I'm in VS code right now.

This is what a code connect doc looks

like. So this code connect template sits

in the codebase alongside all of our

components. So in here I also have my UI

library. We could see that button

component is described right here. So

this is the React definition of our

button component in our codebase. Here's

the CSS. And then up here I've actually

put the Figma code connect template um

so that this gets published to Figma and

associated with Figma. And that's how it

ends up generating those relevant uh

code connect snippets. The one we were

just looking at was accordion. It's

pretty simple. Here's the one that does

the accordion and then here's the one

that does those accordion items. So it's

pretty straightforward. What it does is

it maps Figma information right here to

whatever we want it to turn into in code

and then we spit it out down here as a

template. We don't need to get into the

weeds here. I just wanted to show you

kind of how that ends up working. What

your engineer would do to kind of

publish this up to Figma is they would

end up saying npx figma connect publish.

And what that does is it'll look for all

the code connect in the codebase,

publish it up to the Figma library, and

that's how you end up getting this

result where these end up showing up

dynamically. Right? So this is going to

change based on which of these I have

selected and that's all described by

these dynamic code connect docs in the

codebase. In addition to those code

connect dynamic snippets that we were

just looking at, we have a new feature

that allows you to connect your codebase

to Figma at a shallower but wider level

and that's the code connect UI. I'm

going to give you a quick preview of

this. The way that it works is you can

come in here, you go to the library and

you can say connect components to code.

And this is going to look for all the

components that are described in the

current file. And we can see that I've

already connected a whole bunch of them.

But the way that it works is you select

one and you can actually authenticate

with GitHub or you can manually provide

these these references. This allows you

to search the codebase if you have

GitHub connected and you can map these

things to specific definitions in your

codebase and we pull in all that

definition code right here so that you

can see it and reference it. But when we

go back, you can do this pretty quickly

with your entire library. It was able to

automatically connect a lot of my icon

library and we can see that that it's

been connected right here. That's how

you connect that. And what that ends up

giving you is the ability to look over

here at, you know, how many components

are in this current selection, how many

have been connected. We can click view

connections and see here are the

relevant components. We could dig in and

get more details here that are codebase

relevant. So that's the code connect UI.

That's a really cool addition to how

we're bringing some of this codebase

context inside of Figma, allowing you to

configure that relationship more easily

depending on your needs. All right,

before we talk about how engineers are

going to actually code this stuff now

that they have access to it, I want to

spend a second to talk about AI and code

generation and how Figma fits into those

workflows. All right, so we all know

that LLM are actually really good at

writing code. They've been trained on

massive corpuses of code bases. They can

write code any way you could ever want

them to. The problem is getting them to

write code the way you want them to. And

that's where there's a lot of

variability. And that's where agentic

coding tools come into play. Whether

this is something like claude, cursor,

copiloted, VS code, winds surf, there's

a bunch of different coding tools out

there. And what they do is they provide

the context in your codebase, which is

where you write your code to the LLMs.

So that when they write code, they write

code the way you do. The only way an LLM

is going to write code the way I write

code is if it knows how I write code,

right? And all of that information sits

in the codebase. Now when we talk about

creating code for a design a huge part

of that is understanding what sort of

code you should be writing right and

that's what are we trying to make and

that sits inside of Figma and that's

where Figma's MCP server comes in. So,

Figma's MCP server provides LLM's access

to what's been designed in Figma. And

inside of that is also that codebase

context like code connect variables code

syntax and Figma is in the position of

being able to say here's what we're

trying to make. Here are the pieces that

are going to be involved in doing that.

Here's the relevant codebase context.

And then the LLM can use that alongside

its understanding of the rest of the

codebase to write production grade UI

code. So that's how Figma fits into

these workflows. That's how the MCP

server kind of allows LLMs to get into

that. And we're going to do a demo of

this in a second, but the way that it

essentially works is your developer

clicks something in Figma that they want

to implement. Then they go into their

coding tool. In this case, I'm using VS

Code and Copilot. and I'm saying, "Hey,

get the current design in Figma and help

me implement it." And what the LLM ends

up doing is it ends up going out to

Figma, getting all of that relevant

context for the current selection, and

then it comes back and it uses that to

actually implement that correct

front-end code. So, that's what we're

going to demo right now, and I'm really

excited to show you. All right, so here

we have a design. We're using our design

system, and we want to go ahead and

implement this section. Now, before I go

too much further, I actually want to

make a quick shout out to make. So, if

we think about a section like this,

there's a lot of implied complexity. We

have a toggle for monthly and yearly.

Presumably, that's going to change these

cards. What happens if the user is

already on one of these plans? Does the

button content change? And this is all

an example, an oversimplified example of

like things a designer has to think

through. And traditionally, you do

something like this, right? you end up

pulling stuff out, connecting it with

noodles, uh describing all these

different states uh as a part of your

design. And this is still valid for a

lot of different use cases. [music] But

a really cool feature of Figma make is

the ability to actually paste in that

design and test it out and bring it to

life. So here I've actually brought this

to life inside of Figma make uh as a

designer and I can see what this

experience looks like when this is the

current plan. What does that look like

when you're in monthly, right? How does

this change the button text? Um, you can

also generate UI around your UI to kind

of like create some controls, right? And

this is just an example of how you can

use something like Figma make to kind of

work with your idea, really uncover what

this is that you're trying to design,

the experience you're trying to make.

And you can either hand this off to your

developer, they can access this with

MCP, but sometimes you want to actually

simplify how you're communicating this.

Uh, and that's actually a great

opportunity for annotation. So in this

example workflow, what we've done is

we've done a design, we've explored it

in make, and then we've come back and

we've actually just written two pretty

concise annotations to describe the

feature. That's also a perfectly valid

way to think about how you're going to

communicate this to your developer. So

we've selected this section. Inside of

it, we have a bunch of code connect on

all these components. We're using

variables. We can see right here,

variables are in context. we see these

variables on the canvas. That's another

example of codebase context coming into

our inspection flow. And when I scroll

up here, we're going to see this little

MCP server section. And this is going to

actually estimate how many tokens uh

which is almost think of it like how

many characters, how big is the message

going to be that gets sent over to LLMs.

Uh we get a little estimation of that

right here. And our MCP server is

enabled. We have a bunch of different

options for how it should think about

images when it sends images over. We

have we're going to have more settings

in here over time and things like that.

But we're selecting this and we're going

to hop on over to the codebase. I'm

going to open up the codebase here. And

here's our demo. And when I type hello

world in our demo and I save it and I

switch over to my browser, we see hello

world shows up here. Right? So, in this

example, we want to take this section

and have it use all of our codebase

components and put it inside of here.

This is an oversimplified example, I

know, but I think this is going to give

you a good sense uh for what this

workflow looks like for your engineers.

So, I'm going to hop into uh Copilot.

This is GitHub Copilot inside of VS

Code. Uh I'm currently using Cloud

Sonnet 4 and I'm in agent mode and I've

installed the Figma MCP server. Now,

this is all going to look a little bit

different whether or not your engineers

are using VS Code uh or whether or not

you're you're an engineer and you're

using, I don't know, cursor or whatever

it is. Uh but in inside of uh Copilot, I

can actually list my servers. I can see

that I've got a couple servers in here.

I can list the Figma server. I can see

uh I can restart it here. Often times,

that's helpful uh if if I'm looking to

update the server or do anything like

that. I've restarted my server. We're

ready to use it. There's a bunch of

tools on the server uh that we can

reference. If I click this tools icon in

in Copilot, I can actually see uh our

MCP server, our Figma MCP server. Here

are all the tools in their descriptions.

These are going to change over time.

We're going to look at a couple today.

Uh the names might change. We're still

in beta right now. Uh but uh we have a

whole bunch of tools that the LLM can

actually use to access Figma. So, I'm

going to close this and we're going to

say

implement my Figma selection in

demo.tsx.

And this is a way to refer to specific

files uh inside of Copilot. Uh that

changes based on your IDE. So, I'm going

to tell it to do that. Uh it's using

some references. It's using

instructions. These are like cursor

rules if you've heard of that concept

before. um to kind of like get a good

sense of what's going on. I've

specifically configured GitHub Copilot

to go through a specific sequence

whenever I wanted to implement Figma. So

the first thing it's going to do is it's

asking to get metadata from Figma. So it

got a bunch of highle metadata for our

current selection. This shows the frames

and instances that we have selected. And

now it's going to ask me to get a

screenshot. I'm going to say go right

ahead. We can see that it got this image

screenshot from Figma. That's fantastic.

So now it knows what this looks like

visually. Now it's going to get the code

connect map when I confirm here. And

that's going to return all of those code

connect snippets that are relevant for

uh this specific selection. We can see

those in here. We see the navigation. Uh

we're going to see those pricing cards

in here as well. Uh the text list, etc.,

etc. Now it's going to use the git

variable defs tool. Uh when I hit

continue here, that's going to show all

of the relevant variables in their code

syntax for the current selection. That's

important context. And last but not

least, it's going to get code. And get

code is going to return uh a React and

Tailwind representation of the design

that's also going to have variables in

it. It's also going to have the code

connect in it. Um so those are all the

tools that uh I've I've told Copilot to

use whenever we're going to access stuff

from Figma. Now, depending on your task

as an engineer, you might want some of

these, you might prioritize some over

others depending on what you're doing.

And we can see that it's doing a pretty

quick implementation here already to

implement these pricing cards. And we

can see it's using all the right

components. It's going to work through

some TypeScript errors here. I think

it's making sure that the APIs are

working. It's going to correct the

props. Great. So, it learned how to do

the right thing. It's going to go ahead

and convert some numbers to strings.

Make sure that all that it's working.

Okay. I'm going to hit keep as soon as

it's done telling us how good of a job

it did. All right. So, it's generated

this code. So, it's gone in and it's

implemented. It's connected to our data

layer. And when we come over here, we

can actually see how this feels uh and

what this behavior actually translates

to. From this point, we know it's using

the right things. It's pulled in the

right components. It's mapped to our

data layer. we can go ahead and take

this and actually properly implement the

feature without having to get lost in

the details of making sure we're using

all of the right UI components and that

sort of a thing. One thing I want to

call out is the importance of also

documenting in the codebase how to use

the design system. So I have co-pilot

instructions in here that give an

overview of my library, you know, some

implementation guidelines. This is also

important in addition to the context

that Figma is providing about what

pieces are required for the current

task. All right, before we go, let's

talk about some best practices for using

Figma uh and and using our MCP server

and dev mode. This is ultimately where

you get to supply your expertise to get

better outcomes. So from the top, most

importantly, design consideration is

important. Uh design consideration is

where you want to spend your time. You

want to spend your time thinking about

better experiences uh going further, not

just faster. And once you do that, you

want to make sure that those decisions

make their way into production. But in

order to get good outputs on the other

end, you need precise and potent inputs.

Uh and Figma can provide those inputs to

LLMs for better code generation. So what

that looks like for you also requires a

little bit of uh curiosity about

pursuing the different things uh that

would be most beneficial for LLMs to

understand to do the right thing. Now

here are some practical uh best

practices. [music] So just remember that

design patterns are very machine

readable. So document and adopt design

patterns. Uh think about them with

modern developer tools in mind. uh the

more you stick to the system, the better

outcomes you're going to get. Uh both

from an efficiency perspective and

quality. Leverage the MCP server for

more than UI generation. Design context

can be used to do tons of things, right?

You could get the metadata about a bunch

of screens and say, "Help me project

plan how I'm going to go about

implementing this." You could select a

big thing and say, "How many of these

things are using components the right

way based on what we have in the

codebase and how many aren't?" uh you

can do all sorts of things whether it's

auditing your design tokens or whatever

using the MCP server. Don't just think

of the MCP server as a way to make

whatever's in Figma. You can also think

about it as from an engineering

perspective about how to better plan uh

and and and kind of like do the

engineering work around uh the the idea

of UI development. Also instruct your

agents. So provide agentic coding tools

with context about your specific

implementation details at a workspace

level. This is the best place to apply

your expertise. Uh don't just set it and

forget it. Uh make sure that you're

providing uh specific context. You're

telling the agents how to think about

these problems, how to interpret what

Figma is going to give it. Uh all of

those things are critical if you want to

get good outcomes with with AI tools.

Last but not least, uh annotate design

intent. If you're a designer and you're

like, "How can I help uh developers like

understand this or their tools do a

better job?" Use annotations as a

machine readable format to kind of like

really uh describe the idea of what it

is you're making. Not everything you're

making is just visual, right? It's a

sequence. It's it's thinking about the

user's experience. How can you describe

that in a way so that an LLM is going to

get a good understanding of what you're

trying to convey? Some resources if

you're interested. The simple design

system that we were demonstrating here

uh is up on GitHub at Figma SDS. Simple

design system is a React and Figma

library that has code connect on it. Um

you can use it uh to kind of like be a

starter design system if you want to or

you could just use it for good

references for how to bring some of

these ideas to your design system. Um

there's also storybook in there. There's

also some integrations that show how to

use the REST API for variables to like

sync design tokens. All sorts of little

examples like that that might help

unblock you uh in whatever situation

you're in. Simple design system also has

a stencil representation thanks to our

friends over at Oneorth which is an

agency. They created a

system that documents web components

view angular forms of the library as

well. So if you use one of those other

web frameworks that might be helpful.

There's code connect in there to kind of

show you how that would look uh if

you're interested in those APIs. Last

but not least, check out

figma.com/developers.

That's going to be the best place to

visit if you're a developer and you want

to learn more about our APIs uh or the

best uh thing to share with your team uh

internally when they're investigating

the different features that Figma has uh

and the different APIs that they can

use. So, you can learn more about the

MCP server there. You can learn more

about uh code connect, how to set that

stuff up, plugin APIs, rest APIs. We've

got a whole bunch of resources out

there. So, check them out. Thank you so

much. Again, I'm Jake. I work on the

advocacy team at Figma. Advocates are

always here to hear from you uh about

what you need uh and how we can uh take

that feedback, bring it internally uh so

that we can make sure that Figma is

offering as much value uh for your

workflows as we can.