Hi, I'm Bersabel, a product manager at Figma.
And one of the things I focus on is our extensibility platform,
the APIs that let you build on top of Figma.
Now today, I'm going to talk to you
about how we built this platform, the lessons we
learned along the way and how we think about its future.
But first, I want to acknowledge that I
get to present on this work, but so many of my colleagues,
some of them pictured here, did a lot of the heavy lifting
and were instrumental to helping build the initial platform.
So I want to acknowledge them.
And I also want to acknowledge the editor platform
team at Figma, who work with me to maintain,
and expand this platform, in addition to a lot
of the back end of our editor.
Now, before we talk about how Figma built our platform,
I want to start with the why, and why
we decided to build a platform.
First, we knew if we created an API for users
to extend our product, it would allow us to support
infinitely more use cases.
Use cases such as, fitting together
a bunch of repetitive or rote steps that designers
do throughout the design process.
Or quickly generating placeholder content
to unblock further design exploration,
importing real data into designs to create higher fidelity
prototypes, facilitating developer handoff,
the list goes on and on.
But all of these use cases and all of the use cases,
we couldn't even imagine yet at the time,
required some form of extensibility.
Now, I believe extensibility platforms
are critical for all products, but especially
for creative tools.
Because they, one, help users unblock themselves and fill
any gaps in product functionality, usually
faster than you can.
And thus they expand the use cases you can support.
And two, they let users fully optimize
and customize their flows.
They let designers turn a task that
might take 10 steps into one that might take just two.
And we knew this would be especially powerful,
if we could create an ecosystem for people
to share what they build with each other,
as that could create real network
effects for our platform.
Now, the second reason we decided to build a platform
is that it become table stakes for good design.
We knew if we wanted to compete as a professional design tool,
we needed a platform.
Because efficient design doesn't happen in a silo in one tool,
it happens when your project management software and design
tool, and development ID and all the tools in between
can work in concert.
And so after we decided that we needed to build a platform--
and really it was just a matter of when and not if.
We then got to thinking about how
we might approach such a monumental and almost year long
endeavor.
And so we started with some principles.
Our principles really kept us grounded as we built.
They made it much easier to make trade offs around challenging
decisions and ultimately, build the right solutions
for our users.
Now, our first principle was that security
was a non-negotiable.
We wanted fine grained control of what data an extension
had access to at all times.
And we wanted users to always understand what information
they were exposing as well.
So to as large extent as possible,
we wanted to rely on browsers to enforce our security model,
since they have a very long history of protecting websites
from reading each other's data in unintentional ways.
Now, importantly, this principle is a reason
why plugins run in just one file at a time, as
opposed to across all of a user's files,
and also why they only run in a file
after an explicit user action.
Next, our API needed to be stable.
Generally, when people are building products
on top of your API, they should be
able to rely on their apps not breaking.
This is paramount.
But this was especially important
for a product like Figma, where our API and our editor
are closely tied together, because we especially
didn't want to run the risk of extensions breaking
every time we updated the Figma application, which happens
almost on a daily basis.
And from observing platforms from other design tools that
were unstable in this way, we knew we just
couldn't compromise on this.
And so this was a solvable problem,
but it required a lot of careful time
in designing the right API.
Now, good performance was another priority.
We wanted to make sure extensions could run really
fast.
An important nuance to this principle
here is that we wanted plugins that
did small and simple things to run really quickly,
while plugins that do more complex operations
might understandably take a bit longer.
We also wanted to make sure Figma's performance didn't
suffer when we introduced extensions.
Even if every plugin just reduced Figma's performance
by a tiny bit, once a user had installed and used it multiple,
that could really start adding up.
Now, upholding this principle actually
proved more challenging than expected.
And we actually ended up doing a huge rewrite of our plugin
platform halfway through our alpha,
because the initial architecture just wasn't performing enough.
In fact, we talked to our alpha users
about this decision we're weighing
of changing architectures and asked for their feedback.
Here are some screenshots of the discussion
we had in our slack with our alpha users.
Now, an important lesson here is in remaining
focused on upholding the principles you originally
defined, even if it means a considerable amount of work
or even redoing some work.
Now, it's important to note that this principle also
required making some important trade offs.
For example, this is why we currently
don't allow plugins that run constantly in the background
and also why only one plugin can run at a time in a file.
Now, last but definitely not least, ease of development
was critical.
We wanted to make it as approachable and as accessible
as possible for people to build on our platform.
And we strove to make the following true,
if you could build a simple website,
you should be able to build a Figma plugin.
And so we relied on common web technologies
as much as possible, So that all you needed to build
was vanilla JavaScript or the application logic,
and HTML and CSS for UI.
This way, developers who are already familiar with the web
can get up and running really quickly.
This also allowed us and our developers
to leverage all of the existing ecosystem of tools, libraries,
tutorials, documentation, et cetera, that already
exist for web technologies.
Now, if we had implemented our own API language
which we had evaluated, we couldn't
have benefited from the vast existing ecosystem JavaScript
adjacent frameworks.
And ultimately, our adoption, on-boarding and users,
would have suffered.
And to make sure the API worked well for plugin creators,
we had both an alpha and a multi-stage beta program to get
feedback on what worked well and what didn't.
We decided early on that we were committed
to really listening to our developers
throughout this process.
So we ended up talking to plugin creators
almost every day as they were building
and we iterated very quickly along the way.
And as we were putting the different pieces into place,
keeping our principles and the use
cases we wanted to support in mind,
we ultimately landed on releasing two APIs
for extending Figma.
First, REST API, for exporting data from Figma files
and connecting to third party applications.
We went with this first because, going back
to our principles of stability and performance,
an external API for pulling data out of Figma
was much easier to keep stable and performant than an API
built into the editor.
And thus this was much less risky to launch first.
We could launch with that first to unblock server side
integrations with third party applications,
we took our time building the right implementation
for a full extensibility solution.
And not to mention, REST API was a lot more differentiated
compared to other design tools at the time.
But after launching this API, we heard very quickly
from a lot of people that they also wanted the ability
to write to Figma files and create content
in Figma via an API.
And when looking at the use cases teams had,
overwhelmingly, they were for third party applications
running in the Figma editor.
And we knew this was a real user problem because there's
actually an unofficial Figma plugin
platform created to support these exact use cases.
So that's when we started thinking about and building
the plugin API in earnest to support these use cases
that automate design workflows and chain tedious operations
together to improve efficiency.
Now, all of this careful and principled thinking
didn't mean this launch didn't come without challenges.
The first was in finding the optimal developer experience
for those building plugins.
One of the earliest alpha versions of our plugin API
actually worked by developers copying and pasting
plugin code directly into the Figma editor, which you
can see a screenshot of here.
We very quickly learned that this just wouldn't work,
and also just how critical a good development
experience was to the overall success of the platform.
Not features or functionality, but really just ease of use.
So this is why we integrated plugin development
into our desktop app, because that way we could access
a user's file system directly where
the plugin code lives to speed up the iteration
process in development.
And this is why you can have a developer experience more
like this, with your plugin code running in an IDE,
with API suggestions provided via type definition
files, published on NPM, all of which
assists you directly while coding.
Now, this focus on a good developer experience
is also why we knew it was important to give developers
templates for creating plugins, directly available in product.
And also why we released source code for even more sample
plugins on GitHub, including for popular frameworks,
like React, Vue, and for using bundlers like Webpack.
We wanted to limit the amount of RAM time
and unnecessary work plugin developers
had to do before they could just start creating.
Now, another challenge was getting early alpha users.
Now, getting any early users of an API
is just challenging full stop.
In order to get meaningful feedback,
you need your testers to build something meaningful
themselves, which means they need
to put you on their roadmap or commit
to doing extra work to test out your product.
That coupled with having an alpha version of an API, that
is likely breaking almost every week,
and thus breaking whenever people build on top of it.
It all just compounds the amount of work
you're asking for your early users to do.
And so it's important to find early users who
have critical problems or API [INAUDIBLE]..
And to build our initial alpha, we got really scrappy
and first started with direct one on one outreach on Twitter,
reaching out to known and interested builders.
And then we talked to the design tooling
teams of some of our customers, because we
knew they needed more advanced functionality for extending
their design systems.
We use this method to get about 10 or so people,
initially testing the API.
We collaborated with them on slack
constantly throughout this process.
After we had a solid foundation for the API, an early developer
experience, we scaled up our efforts
and announced an open call for a closed beta.
We actually got a ton of interest from this open call,
but what's pretty normal with beta
is there's a ton of interest, but not
always a lot of follow through to building
and then giving feedback.
So we made sure to have a pre-screener, where
we asked interested folks to share what
they are planning to build.
And we prioritize access to those with concrete use cases.
We're able to get the next 100 or so folks
building through this process.
Now, it was also challenging to create a good plugin Sandbox
on the web, which we needed to do
to ensure that any third party plugin
code was truly self-contained and secure for our users.
We really weren't able to find any other websites that
had solved this problem in a way that was both secure
and also didn't make the development
experience cumbersome.
Now, a common solution here is to create
a custom coding language like, Excel, [INAUDIBLE]..
But we really wanted to enable vanilla JavaScript,
going back to our principle of ease of development.
So we ended up creating a custom JavaScript sandbox, which
was very complex and required a couple of iterations
to get exactly right.
Again, we committed to our principles
here, even though it was a considerable amount of work.
Because we ultimately felt this was the right solution
for developers and users.
And as some of you may know, a few weeks after initial launch,
we had to completely change our plugin API
[INAUDIBLE] hack because of a discovered security
vulnerability.
Another big challenge.
Now, the first choice sandboxing approach
you went with had a security vulnerability.
And so we ended up needing to swap it out
with our next choice solution.
This screenshot here shows an internal message
when we decided to pause the ability
to publish plugins and updates to plugins in our community,
while we address this issue.
Now, there are a few good lessons here.
First, because we spent a lot of time
up front carefully evaluating multiple solutions,
when this incident happened, we had a readily available backup
to implement.
Second, because we developed our plugin architecture
in such a way where the underlying sandboxing
solution could be quickly swapped out
without breaking or interfering with the existing plugins,
we were able to act very quickly.
Because security was a non-negotiable and important
principle, we knew all this extra work was justified,
and the optionality was important.
And last, because we were very transparent with our community
by releasing a blog post where we clearly
outlined all aspects of the incident and our decision
making process around it, users ultimately
felt secure with our product and our decision,
even in the face of a serious incident.
Now, if you can read what's on the screen,
it's a screen shot from the front page of Hacker News,
the day we released our blog post about this incident.
Thankfully, the security vulnerability
was never exploited.
Now, fast forward over a year and a half and we've grown
an incredible community of over 1.7K developers in our Figma
plugins slack, with even more actively building.
Over 2000 public and private plugins
that have been installed over 5 million times.
And plugins are run on average 300,000 times per day
by our users.
It's pretty incredible.
We've also seen some incredible plugins built. Plugins like,
content libraries for populating designs with premade content.
Photo editing plugins.
plugins for testing designs across various environments.
Plugins for linting designs for correctness.
And even some plugins we didn't expect at all, like, asteroids,
or a plugin that lets you draw by typing on your keyboard.
And even, a Gameboy emulator plugin
that draws every frame of scenes in a game as vectors
on the Canvas.
Lots of gaming use cases for plugins it seems.
We've also learned a lot about the creator's building plugins.
First, plugin creators are incredibly committed
to the community.
Across all types of plugin creators from design
tooling teams to indie developers,
even to startups building businesses on top
of Figma plugins, over 80% of all plugin creators
are primarily motivated by helping others improve
their efficiency with Figma.
And you really see this emulated in the Figma plugins
slack, which is such a special place for plugin creators
to share with each other, get help or feedback,
and also talk directly to the Figma team.
Not only do folks jump in eagerly to unblock each other
but they also proactively offer up tips and resources, as well.
By the way, feel free to reach out
to me for anything [INAUDIBLE],, if you want
an invite to the plugin slack.
You also see this commitment to the community from the fact
that 70% of plugin creators share their plugins publicly
to the Figma community, as opposed
to just keeping them internal.
We've also learned our original principles have paid off,
in particular, our focus on user development, because it's
really helped drive developer velocity on our platform.
We see this in the fact that 70% of creators
built their most recent plugins in just one week or less.
And 24% of creators built their most recent plugin
just one day.
And we found that the ease of development
hasn't just made it easy to build plugins,
it's also encouraged recurring developer activity
and repeat creation.
We found that 44% of plugin creators
have built multiple plugins.
On top of that 12% have created over six plugins.
Again, our focus on ease of development
has meant our community of developers
have high velocity, are active, which ultimately means
more plugins for users faster.
And that just means a more efficient Figma.
Now, these next stats are ones I'm particularly proud of.
Our focus on making our API approachable
has meant our community of developers
is diverse in terms of development experience,
to the point where 20% of Figma plugin creators
don't even identify as developers.
And 30% of plugin creators have just
up to five years of experience with web technologies,
and 12% have up to just one year of experience
with web technologies.
What an incredible testament to how approachable the API is.
And I know there's even more we can still do here.
Now, looking to the future, as we think about what we want,
the next 1 and 1/2 years to look like.
To me, it looks a lot like, doubling down
on our goal of making plugin development
accessible and approachable.
And providing an even better development
experience while continuing to expand
the capabilities and functionality of our platform.
That was a mouthful.
In short, we want to expand what you can do with our APIs,
while at the same time making it easier to use them.
Code and plugin development can be extremely powerful tools
for automating the creative process
and we want to work to ensure every Figma
user has the opportunity to use this tool, if they so wish.
We want to do this by providing more resources to plugin
creators as they create.
We were scrappy in the first year or so of our platform
and our community has been great in supporting each other,
and providing these resources.
We want to highlight and better connect
plugin creators with these existing resources
by the community.
But we also want to provide more resources directly
to developers and creators.
This might look like code examples
for very common actions, publish best practices,
boilerplate to make it even easier to get up and running.
And of course, we also want to do this
by releasing new platform functionality that
simplifies development and removes complexity
for plugin creators.
And finally, we want to double down
on the incredible developer community we've
started to build and make sure that plugin creators feel
recognized and rewarded for all the work they
do for other creators and for our users.
And I'm really looking forward to the continued partnership
there.
Thank you.