The Pragmatic Engineer - Building Figma Slides with Noah Finer and Jonathan Kaufman

Episode Date: March 26, 2025

Supported by Our Partners• Graphite — The AI developer productivity platform. • Sonar —  Code quality and code security for ALL code. • Chronosphere — The observability platform built for control.—How do you take a new product idea, and turn it into a successful product? Figma Slides started as a hackathon project a year and a half ago – and today it’s a full-on product, with more than 4.5M slide decks created by users. I’m joined by two founding engineers on this project: Jonathan Kaufman and Noah Finer.In our chat, Jonathan and Noah pull back the curtain on what it took to build Figma Slides. They share engineering challenges faced, interesting engineering practices utilized, and what it's like working on a product used by millions of designers worldwide.We talk about:• An overview of Figma Slides• The tech stack behind Figma Slides• Why the engineering team built grid view before single slide view• How Figma ensures that all Figma files look the same across browsers• Figma’s "vibe testing" approach• How beta testing helped experiment more• The “all flags on”, “all flags off” testing approach• Engineering crits at Figma• And much more!—Timestamps(00:00) Intro(01:45) An overview of Figma Slides and the first steps in building it(06:41) Why Figma built grid view before single slide view(10:00) The next steps of building UI after grid view (12:10) The team structure and size of the Figma Slides team (14:14) The tech stack behind Figma Slides(15:31) How Figma uses C++ with bindings (17:43) The Chrome debugging extension used for C++ and WebAssembly (21:02) An example of how Noah used the debugging tool(22:18) Challenges in building Figma Slides (23:15) An explanation of multiplayer cursors (26:15) Figma’s philosophy of building interconnected products—and the code behind them(28:22) An example of a different mouse behavior in Figma (33:00) Technical challenges in developing single slide view (35:10) Challenges faced in single-slide view while maintaining multiplayer compatibility(40:00) The types of testing used on Figma Slides(43:42) Figma’s zero bug policy (45:30) The release process, and how engineering uses feature flags (48:40) How Figma tests Slides with feature flags enabled and then disabled(51:35) An explanation of eng crits at Figma (54:53) Rapid fire round—The Pragmatic Engineer deepdives relevant for this episode:• Inside Figma’s engineering culture• Quality Assurance across the tech industry• Shipping to production• Design-first software engineering—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

And how does it look like to push something out to production? Something that's interesting that I haven't seen at my past jobs that we started doing recently. For all of our unit tests and all of our interaction tests, we run the full suite with all the flags off and then with all the flags on. So the same tests are like running in both permutia. And like obviously like within the tests, you can specify a different permutation. Like if you're writing a test that only covers something that requires that flag, obviously you need that flag to be on. Before we were doing this, this was a source of regression. where it's like this flag caused this to break and I didn't know this until you know

someone went to delete the flag and then like that caused test to fail. So now that we're doing this, it's pretty awesome. Figma created a new product called Figma slides in less than a year from idea to launching an Mbita in April 2024. Since then, users have created more than 4.5 million slide decks and the product is quickly gaining momentum. But how was it built? I sat down with two engineers who worked on this project from the start, Jonathan Kaufman and Noah Finer. In today's conversation we cover how Figma slides is built using TypeScript React and a lot of C++ code. While building a seemingly simple UI, the single slide view, is a lot more complicated than it seems. Engineering approaches at Figma, including the NGrit process, using a feature flags, and running all unit tests twice, once with all the feature flags turned off, and then once with all turned on.

And a lot more. If you're interested in a behind-the-scenes look of how the engineering team at Figma does things differently, sometimes by choice, sometimes by necessity, then this episode is for you. If you enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube. John and Noah, it's great to have you on the podcast. Yeah, happy to be here.

Also excited to be here. So how do you start building? You know, like what kind of tech stack did you use back then? You know, like did you just have a few scratches? Like it sounds like a really exciting part of the project, right? And it actually,

you know, it can make or break a project. So everything about the slide grid and those things were built just sort of on a branch. And we kind of hack week style where we wouldn't have merged this to our main branch yet. Would you mind just sharing how Figma Slides looks and what the parts are that you're talking about,

for example, the slide deck and the grid? So this is Figma Slides. When you enter slides, you're presented with what we refer to as single slide view. And this is what people are very familiar with seeing in Google slides and PowerPoint and keynote, where you have this carousel on the left, and you can go through the slides.

But what we noticed is that when designers were building slides within Figma design, they would always lay everything out using our infinite canvas. So this is what we refer to as grid view. There were a bunch of annoyance building a deck like this in Figma design. And part of it is, you know, if you have all these top level frames on a canvas,

if you want to reorder them, they don't just like reorder, right? Yeah, yeah. So one of the first things that we built was like exploring how can we give better reorder behaviors for people who want to build slides and like see slides in this way. Right? So as you drag things around, they reorder.

You can reorder a whole row. And what was interesting is if you go back to single slide view, those rows correspond to the sections here. So each of these sections are the rows in grid view. And so it's this nice one-to-one relationship. And so what this allows is it allows. Hold on. Just a question.

So what about the columns? Like, is that? Yeah, yeah. So if, see how this is, this, this Brendan slide is the second slide. If I make that third and then go back to grid, you'll see that this is now in this position. Got it, got it. If I reorder this whole row and then go back to single slide view, that whole row is now second, right? And so what this allows is people who are more familiar and comfortable with the infinite canvas, they can live in grid mode.

where they're happy, but people who may be less familiar or don't want that view, they can stay in this view on the same file. This episode is brought to you by Graphite, the developer productivity platform that helps developers create, review and merge smaller code changes, stay unblocked, and ship faster. Code review is a huge time sync for engineering teams. Most developers spend about a day per week or more reviewing code or blocked waiting for a review. It doesn't have to be this way.

Graphite brings stack pull requests, the workflow at the heart of the best in class internal code review tools at companies like Meta and Google, to every software company on GitHub. Graphite also leverages high signal code-based aware AI to give developers immediate actionable feedback on their poll requests, allowing teams to cut down on review cycles. Tens of thousands of developers at top companies like Asana, Ramp, Tecton, and Versel rely on graphite every day. Start stacking with graphite today for free and reduce your time to merge from 10. days to hours. Get started at gt.def slash pragmatic. That is G4 Graphite, T4technology.combe, pragmatic. This episode is brought to you by Sonar, the creators of Sonar Cube server, cloud, ID, and community build. Sonar will now offer SonarCube Advanced Security, delivering the first fully integrated solution for developers to find and fix code quality and code security issues in

the development phase of the software development lifecycle. Sonar Cube Advanced Security enhances Sonar's core security capabilities with software composition analysis and advanced static application security testing. This enables developers to identify vulnerability in third-party dependencies, ensure license compliance, and generate software bill of materials. Sonar analyzes all code, first-party, AI generated, and third-party open source, resulting in more secure, reliable, and maintainable software. Join the over several million developers from organizations like Microsoft, DOD, Barclays,

and T-Mobile who used Sonar. prioritize code security and code quality issues at the beginning of the software development lifecycle. Visit sonarsource.com slash pragmatic security to learn more about Sonar Cube. And then so when you started, it was just a very small team.

So one of the first things was coming up with this kind of two-way navigation that would make it unique, right? Because I haven't really seen this, you know, like going from an infinite grid view to this single, the single site we're familiar with. But was this one of the challenges to, you know, build a rough prototype of.

This became a later challenge. But what's interesting is we actually didn't build single slide view until like six or seven months into the project. For the first while slides was exclusively in the grid view. And what we built out was like how are you going to manipulate slides here? What are the what's the template system going to look like? You know, like when you add a slide, how can we pull from a, an existing deck.

What's the theme system going to be, you know, choosing colors within a theme and then like editing the whole theme of a deck. And then lastly, like, what is the presentation going to be like? Those are like the key areas of initial exploration, whereas a single slide view, we felt more confident that we could build. And because of that confidence, we didn't want to prototype it too early where like we just wanted to focus on the riskier bits. Yeah, actually I came on around the time that single slide view was being built.

And I remember the first draft of single slide view was like something that John cranked out in like, like, I think just a couple days. It was just like like boxes on the left side. And then if you like zoomed into a slide or something, it like teleported you into single slide view and just like showed the left side. And then if you zoomed out, it went away. And a lot of like when I first got on was like prototyping like, ooh, how like how will single slide? slide view work? Is it, are we going to try to make it, like, based on how zoomed in or zoomed out you are of the grid? Or, like, do we want to have, like, buttons and keyboard shortcuts and all this other stuff? And there's, like, a lot still to figure out about what is single slide view and how do we

make it work? And what we kind of landed on is secretly, like, in this view, in single slide view, we have, like, zoomed into the canvas. And, yeah, we've zoomed into the grid. We've hid everything except for just like the slide itself. Oh, really? Show some UI on the left and the right. So yeah, there's a lot of iteration back then to like figure out what are even doing with this. Yeah, it's one of the interesting parts about building on Figma's like infinite canvas, right, is because we wanted to preserve the grid view and allow people to still edit in grid view

and have their like cursors show up as they're editing if someone's in single slide view. what that means is that the slides are still represented in this two-dimensional space. And so all single slide view is, is as you toggle through the slides, we just snap the viewport for you. That is clever. And just taking a step back, just to understand how the project roughly went. So you had the early prototyping phase. You then had the, you know, like those like one or two months building a proof of concept. And then like what were the phases and what parts did you build until we get to a final, you know, general availability?

Yeah, I think. So when it was sort of John and just like one or two other engineers, before the team was fully staffed, there's a lot of focus on sort of like the grid view. And like how are we going to lay out slides in the grid? Then after the team started getting staffed a little bit more, then there were more explorations around like how do we lay out things on a slide? And we actually went through a lot of iterations there of like, do we want to do like constrained layouts where like users, everything is auto layout and users can like add something to the left, add some to the right and stuff like that. Or do you want to do something a little bit more freeform. We also did a lot of work on like single slide view, nailing like centering the slide and single slide view versus not that took like months of like working with designers and like sending over prototypes in order to like like, like, figure out. We also had a big group working on like presenting and presenter view.

Speaker notes took a, that was like one of the first things we wanted to add. And also like themes and working to like create a system of colors that both like come from the template you're using but also allow you to edit on top of it, which is like a whole new concept in Figma world. So those all sort of happened coming like up to data. I think like we had like like the only way to do like an end to end flow of like using a template and presenting it. I think that took until like I don't know if you remember John, but like maybe December, January or so. Yeah, it's not true. Yeah.

And then. Is this 20203? Yes, because we launched in 2024. Yeah. Yeah. So 2024 January. Yeah, and then it was just a matter of like iterating. And it was just like we were cranking through bugs for like two months going up to config.

And that was that was wild. I remember we had like like 300 or so like P zeros and so many that we added a new like stage of P zeros of like a P zero do this now. And then how big was a team in terms of like engineers, designers roughly? I think at its biggest we had between 10 and 12 engineers. I want to say two designers and a dedicated person from research and a dedicated someone from UX writing. But you don't have any dedicated testers or QA folks, right? Like it's engineers doing the testing and like you know, you test your thing. Correct. Yeah.

You have the dedicated research person, though. Tell me about that. Yeah, it was pretty instrumental in finding the direction of slides. A lot of what we explored is very similar to Fig Jam, where it's like we're building for both a non-designer audience and a designer audience. So a lot of what we did was like building out prototypes and then putting it in front of both designers and non-designers and seeing what resonated and then using that to better form our POV on direction. Yeah, I think one of the coolest like tools that we have internally are these front end commit previews where if you like push up a branch, if you like push up or make a pull request, that's like, automatically deployed, and you can send a link to other people internally to test that out. So a really cool thing we were doing for these user research interviews was like making prototypes and then making prototypes internally with like non-production code and then like shooting those

over to research and then they were chatting with some folks internally. And we had them use like these like prototypes. So basically you just created a pull request with whatever data and then whatever was on your machine the researchers could show, right? Yeah. Nice. And what is the tech stack behind all of this, behind Figma Slides? Yeah, so Slides is the same stack as Figma Design and Fig Jam.

So everything that's in the canvas is rendered using what we refer to as full screen, which is RC++, code base and renderer. And then what that does is it writes to a literal canvas element in the DOM using either WebGL or WebGPU depending on browser support. So that's like a lot of our main stack that we work in when building out the UI is in C++. Everything that's on top of the canvas. So like this left panel, the properties panel, this tool belt, all the file menus, these are all in TypeScript and React. And then we have our own bindings layer that allows us to share state between what's in C++

and what's in Web. So, you know, like I think Reactions TypeScript is pretty straightforward. But do you also need to go into C++ to do some kind of UI changes or create new like four elements, those kind of things. All of the, all of the teams that work on our editors are either 50-50 or going to be more C++. That's not a conventional UI technology. Did you pick up C++ on the go after you joined Figma or did you do it before? There are some people who like come in as like C++ experts.

And then there's other people who like come in as more like web experts. And I'm one of the people who did not know C++ before starting here. I also did not know C++ before. Well, I worked with C++ a lot in college for like operating systems or like all these other like things. But how you'd use like C++ for like a college project or other things is very different from like how we use it at Figma. I feel like Figma is almost designed like a game. game engine almost, but the Figma codebase is just like, it takes a, it takes some time to like learn how to navigate it and how to find things around it and how to develop for it.

So I think there's a learning curve for everybody, but it's a very approachable learning curve. But a really cool thing like Figma's doing is they're trying to rewrite parts of like the full screen C++ like code base to actually be in TypeScript. So it's like TypeScript chatting with our C++. Is that like bindings, right? Yeah, with this bindings layer, which is really cool. So like one example of those is all the little like blue lines. Yeah, like if I'm like hanging out in Gridview, all of these like plus buttons and like these guys,

these guys are rendered on the canvas, but they're using, they're written in TypeScript. And then that TypeScript is like interacting with the canvas, which is, of course, being rendered by like TypeScript and React. And then one interesting thing that you previously mentioned is that Figma has this pretty cool tool, C++ WebAssembly editor to help debug TypeScript as you're building it. What is this tool? And this sounds very, very unique to Figma. It's sweet. We have this, there's this Chrome extension. called like dwarf wasm debugging that like we've installed.

And what's really crazy is like you you can debug like C++ inside of like Chrome itself inside of just like the inspector panel. And like sometimes if I have to like figure out a gnarly like a gnarly bug between like our carousel, which is written in TypeScript and like how that's chatting with the editor, which is written inside of C++, I can debug both our like web. assembly bundle as well as React at like the same time, which is really cool, like being able to set break points between the two. And this is like custom tooling, obviously, that you built, right?

No, no, no. This is, it's open. It's like a part of chromium. Oh, so chromium supports debugging like custom C++ web assembly libraries. Yeah, yeah. It's the like mental model is very similar to like if you're using compiled. or transpile JavaScript and source maps. It's the like analogous mental model.

You can make a special web assembly. It's maybe underwhelming to show, which is I think what makes it really cool. So here I just have like, you'll notice I have like a typescript file next to a C++ file. Oh. Okay. And obviously you need to have a debug build for this to work, right?

Yeah, yeah. So there's a special type of build that you, you can build that generates dwarf symbols. And then the Chrome extension can consume those symbols and map it to source files on your computer. That is so cool. Yeah. And things like breakpoints work.

Not 100% of things work, but you can like inspect different objects and like read, read values of primitive things for sure. I mean, I worked with like back a very long time ago when I worked on Skype for Xbox One, we had an HTML and JavaScript for whatever reason and C++. There was a C++ bridge. And it was, you know, the only way we could debug the C++ code is send it over to JavaScript. Dude, debug logs. And like what I would have not given to have this tooling.

Yeah, it's super cool. Yeah. I think before this was supported, it was before I joined Figma. So this has been around for a few years, at least. People would build, we have a build that you can run within Xcode that like launches Figma. And then you can use X code to debug the C++. But now I think most engineers here are using this. Yeah, I think it's just come to show that even when you have a more unique tech stack,

it's pretty cool how some of these things are standards and they exist. You just need to find them because, as you said, I kind of assume that you must have built it yourself. But no, it's a universal Chrome plug-in. Yeah. Yeah, one really cool example of how I use the debugger was there was like one time where we had this variable that was getting set inside of our web code base. It was like a configuration variable between like, are you in UI2 or are you in Ui3? And we were seeing this really weird bug where you were both in like the carousel and the grid at the same time. And we were like, whoa, what's going on?

Why can't we repro this? And after like a good bit of investigation and using this debugger very specifically to see like when some initialization code that like set you in the editor to be in grid. view or single slide view. I put a breakpoint there. And then I put a break point on this code that was like, are you in UI2 or are you in Ui3, which is being set in web? As I was able to see, we were having like a crazy race condition going on. Wow. And the only way I could do that was with like this was and debugger. Yeah, because now you could debug like the two code bases running parallel pretty much. That's awesome. And so what were some unique challenges of building? slides, Figma slides, compared, you know, things that you don't really come across on other

projects. I'm assuming you built a bunch of web projects. You know, there's a bunch of kind of usual suspects from like UI layouts to like build, like how are we going to build or what linting are we going to use. But this didn't seem like, it sounds like it's not your typical project, this one. Yeah. I think one of the main challenges really was something that we've already touched upon, which was how we built single slide view to to be literally just moving the viewpoint, right? If you were to build a slides product from scratch, I don't think that's the way that you would approach it, right?

Where you're like, okay, well, what if we had an infinite canvas and slides had X, Y coordinates on the canvas? And then we can, like, zoom in, you know? So that was, like, a unique set of challenges. But what's really cool, not only that it works, but that it allows all of our existing tooling around like multiplayer cursors and things like that to kind of just work, right? And what is multiplayer cursor for those not familiar with, you know, Figma Lingo? Yeah, so multiplayer cursors are when someone else is editing the same thing.

You can see exactly what they are editing, right? So if Noah makes a selection, we can see that Noah has that node, selected. And this works regardless of if I'm in single slide view or if I'm in grid view, right? And then behind the scenes, like, how does multiplayer work? There must be some sort of TCP connection open and, you know, like, it must be talking to a server. Is it happening on a server or is it peer to peer? It is happening on a server. Yeah. This is how I get do my best to answer it. Our co-founder, Evan, wrote a great blog post on the Figma engineering blog about multiplayer and definitely much more of a subject matter expert than I am. But at a top level,

we have a Rust Service running that all edits propagate through and it handles conflict resolution and sends things back down. Each client maintains a WebSocket connection with it. And basically it's in this library, right? So as long as you use a C++ library, it's built in. So I guess was this one of reasons you decided? So like, all right, let's, you know, hack around it, like zoom in. Yeah, yeah. A lot of it's multiplayer, but I think more broadly,

a lot of it's just building on the Figma platform, right? Like you can copy anything from Figma design and paste it into slides and it'll just work. And same with going the other way, right? And that is really important to us as we're building these new products, right? Like copy paste works between fig jam and design. It works between design and slides. And so now there's this nice, it doesn't matter which editor you start in. You have access to the same things that you created in any of the other files.

And that's sort of like a second area of complication is like we call this interoperate. but what that means is that, you know, like fig jam has a bunch of no types that were made specific to fig jam like stickies for example. But because we want interop to feel so seamless, what this means is that if you add a new node type to a specific editor, it has to work everywhere, right? Like it would be a little bit of a bummer if you went to copy a sticky and it didn't, you know? And so this ability to bring things between products is really cool for our users, right? But it definitely adds complexity to the code. And as a dev, like what does this mean for you to support tickies? Like I'm assuming there must be some data type somewhere of like all the things supported.

And then you need to figure out like how to visualize it or how to draw it or how to like how it maps. Like how can we imagine? because I feel this is like inter-off is something that most of us don't need to worry about until you do. Yeah, there's something like there's like an irony. I feel like as other companies become multi-product companies, you like kind of do your best to like separate the products more, you know. But what we really lean into is the opposite, right? So like with each new product, we like really want things to be seamless, you know. as far as what the code looks like, a lot of what's in the full screen code base,

which is our C++ code base, is the same code running regardless of which editor that you're in. A lot of the differences are in the website, right? So we have a different react tree for each editor, and that's how things are very visually different. but the code running the what powers that main canvas is the same wasom bundle for each of the editors. Then, of course, you know, there are differences. And so differences are sometimes expressed in a concept that we call mouse behaviors. And so mouse behaviors are, you know, it's sometimes hard not to use the word in the definition. They're the behaviors that run for the mouse, right?

So like I'm dragging what happens, right? And so a lot of what happens in Fig Jam, right, or we like to snap things to different pixel grid so that things like lock in more, where design is more free form, right? So for things like that, we can check which editor that you're in and like respond accordingly.

Yeah, one example of like a different mouse behavior that we have. Like inside of Figma design, If I were to try to drag some, like, things inside of an auto layout container, we have, like, this behavior over here where, like, they'll shuffle around in real time. But if I were to jump into a slides file, let me go share my slides tab, we have our own sort of unique behavior for handling, like, this drag. Like, we have our little, like, previews over here. We have, like, the ability to add new rows down here.

All of this is done via our own slide-specific mouse behaviors. Yeah. Okay. So each editor type can register a unique set of mouse behaviors is how a lot of differences are expressed. This is very interesting, and it sounds just very unique to Figma. But I guess, you know, like, if we're to peek in the internals of any company that has like, a big product that has evolved. We'll obviously see something, might see something similar,

but this is just fascinating on how things become really kind of unique for a good reason and homegrown. This goes back to like Noah mentioned that a lot of the Figma code looks like a game engine. I think that this like mass behavior concept is taken from how a lot of game engines run. So there's like a priority list of mass behaviors. if one of them accepts the event, it doesn't go to the next one, you know? So it's like our own sort of like delegation pattern that often the browser would handle for you, but because they're running in C++, plus, it's all written from scratch. Well, you do have a bit more freedom.

I was just recently talking with the, well, my brother, the founder of Craptocs, who decided to build their own UI not using the system. UI. I mean, it's a lot more work, but then you get a bunch of freedom to do whatever you whatever you want to do in terms of animation. What the system might not be able to do or the system elements might limit you. Yeah, yeah, yeah, for sure. It's one of those like with great power comes great responsibility thing. Because like something that we do, right, is like we render text ourselves, right? So we have code that like looks at the font and it like computes the geometry of the glyphs. and then based on that geometry renders out the pixels, you know.

And this is great because it guarantees that regardless of what browser you're using, what OS you're using, you know, if you're looking at a Figma file, we can guarantee that like it'll look the same, which is very important when you're making it a design tool, right? But that means that there's a lot that we don't get for free, right? So like we built and launched, I think last year, or the year before spell check, right? Just like the red squiggly that tells you that, you know,

something is misspelled. And that was like a huge undertaking, you know. Or like we added support for bidirectional fonts. And that was all like, like we had to add it, you know, because we couldn't lean on the browser. Hey, developers. We've all been there. It's 3 a.m. and your phone blares chelting you awake.

Another alert. You scramble to troubleshoot, but the complexity of your microservices environment makes it nearly impossible to pinpoint the problem quickly. That's why Chronosphere is on a mission to help you take back control with differential diagnosis, a newly distributed tracing feature that takes the guesswork out of troubleshooting. With just one click, DDX automatically analyzes all spans eye dimensions related to a service, pinpointing the most likely cause of the issue.

Don't let troubleshooting drag you in the early hours of the morning. Just DDX it and resolve issues faster. why Chronosphere was named a leader in the 2024 Quadmer Magic Quadron for observability platforms at Chronosphere. that I.O. slash pragmatic. That is chronosphere.io slash pragmatic.

It is interesting because now I remember just one everyday thing that people might come across is just a PDF file. When you open it, it's for editing with anything, really. And then you need to have your fonts. And those fonts need to be in so that they always level. And if they're not,

You know, you're out of luck and it'll look something weirdly different. Tradeoffs everywhere. Yeah, yeah, yeah, yeah, for sure. And what are type of things were tricky about this project? Yeah, I could chat a little bit about, like, how single slide you had some really interesting challenges. Oh, I love that. Because this is something I don't think most people would assume. Yeah.

Like, how hard could it be? And actually, you said earlier, right, that, oh, we knew this will be pretty simple. That's why we left it for later. Yeah, by simple, it's very relative. Yeah. But yeah, like single slide views in this really interesting spot where like collapse state, like collapsing slides and expanding them, we don't want to like save that to your file at all. Like we'd want to save stuff like the order of slides in the grid to the file,

but we don't want to save stuff like are these collapsed or not to the file. So in order to render like this carousel over here, we've got a bunch of state that like lives inside of web. And then a bunch of state that lives inside of the editor, inside of full screen. And we got to like have a bunch of complicated code to sort of like coalesce those in order to figure out like what to render here. On top of that, there's like a ton of crazy technical challenges to solve

in terms of like dragging slides around and like making sure that like if I were to drag these three slides, which like right now, they're their own row in the slide grid, if I want to like drag this title, this slide out and then like move it into this row, we got to make sure like this row is still preserved up there.

But if I were to drag this entire row and like make it sort of a child, we got to like delete that first row and then like combine this row together. So there's a lot of like really interesting. algorithm stuff to like coalesce like sort of changes from the carousel inside of web as well as like other users like dragging stuff around inside of full screen maybe across like multiple rows or something and like combine those two together in a way that's like that feels

like safe for multiplayer so yeah I yeah yeah this is a good thing to like yeah yeah so like this like intersection of like editing and multiplayer is like a really interesting part of the figma stack. Everything is multiplayer first. For things to be local, you have to like opt out of it being sent. But what's interesting about, um, reordering stuff in single slide view is we do, um, there's a bunch of operations that you can do that can move like a lot of slides at once. Um, but because we wanted to be multiplayer friendly.

there's a lot of work under the scene or behind the scene under the hood that's happening to like perform the minimum number of mutations possible because the more mutations that you do the less multiplayer friendly something is right so like you can more likely it is like load yeah if you're picturing the slide grid right and if we move the bottom road to the top in a in a naive way When you do that mutation, you're changing every single slides x, y coordinate, right? Well, that's a most obvious thing to do, right? Yeah. And that's how slides worked for a while.

But then how we ended up solving this is our, like, ethos was to do the minimum number of mutations, right? Like, ideally the number of mutations are the number of slides that you drag. and the way that we achieve this under the hood is actually using the auto layout nodes within Figma Design. So what I mean by that is each row is in its own node, right? We call it the slide row node. And then each of those nodes is within a slide grid node. So each slide is now two levels deep.

We have an existing construct called parent index, which was made for reordering stuff within frames and reordering stuff within Autolayout. And what a parent index is is it's a structure that has a reference to the parent's ID, as well as an index represented as a float from zero to one. And so by doing it this way, if you reorder just one thing for example, you only only have one mutation, right? So I change something from the beginning to the end. Only that thing's parent index has to change. And then each client is responsible for rec computing the layout. No, and then just to like move things around. Just so I understand that the goal is that you send

the mutation to the server saying here's what changed and then that server sends it to all the clients and then all the clients execute it as well. Yeah. Okay. So, you know, there's like probably low risk that everyone's going to be mass reordering slides at the same time. Yeah. But there is a higher risk of like, you know, people lose internet connection. And so what we do is like if you're offline and you do a bunch of edits, then when you come back online, there's like a lot of resolution that needs to happen. So doing this minimum number of mutations is like is the goal. So everything's two levels deep. They're all using parent index.

And then we wrote code that I imagine looks kind of similar to the React Reconciler. We're like, okay, we have this. We have the beginning state of the drag. and we have the end state of the drag, what's the minimum number of mutations to get from A to B? And that's what we propagate. I remember before we had all these optimizations to figure out the minimum number of things to recompute,

it was like, it was pretty gnarly. Like we, I remember there was like a big like all hands that was happening internally. And then we just like got to report that like, hey, a bunch of slides, like, disappeared or something. And then we were like, oh, my goodness, chaos mode. So we had to do a lot of digging to sort of figure out theories as to how this might have happened because, like, it's really hard to reproduce, like, 10 people being in the

same file at once and then one of them losing connection while they did, like, a big, like, slide reorder. So, I mean, this sounds like a proper, you know, like hardcore engineering problem where it's like distributed systems, like state, reconciliation, playback, conflicts. How to the world conflicts? While we were working on this, we often jokes like, this would be a really mean interview question. Or a really good one.

If someone can bring something to use the table, it's like, all right, you need to join. And how do you test all this? So, like, I'm specifically curious of like, okay. You know, like in traditional, like, crud apps, you typically have, obviously you manually test that it doesn't work. You add your automated test, unit test later. You might add integration test. And then they're there to guard against regressions. And now, you know, like it's, you feel pretty happy.

And thumbs up, it'll kind of work, especially when it's like a back-and-heavy thing that doesn't have much UI. How does it work in your case? Yeah, we have all of those. For this space, for this case specifically, We do have, I think it's our most unit tested part of slides, this like grid reconciliation. And we have every case that has ever caused a bug report that we then assert the mutations that have happened. So we like reform the reorder and then we verify on like every single slide after the reorder. Like are you the same?

Has your index changed? I think another interesting part of slides is some of our test cases are like vibes in a way. To dig into this a little bit, especially when we were originally building the product. And still like today, we do a lot of like testing by like seeing how people feel about a subtle change. I remember one of the really interesting things I was iterating on was like, how does the viewport like feel inside of like single side view? And it's like, how far can you zoom out? How far can you zoom in? As you zoom out, when you can see that the slide gets centered, but like, when do you start

re-centering this slide? How far are like the margins here and here? And to do a lot of like this testing, and you can see like it also scales with like the viewport. But to do a lot of this testing, this was a lot of like sending two options over to designers or putting one option in our like internal like staging environment and then like seeing how people felt about it as they like naturally use slides like during their like day to day and figma. So there's a lot of like trying like things out, trying like one or two different options

and then like getting some feedback on those prototypes from designers or product people around the company and then going for just like whichever one. people either preferred or like whichever one people did not like less than the other one. Yeah, that is different, right, from your usual development. Yeah, for sure. Something that like I really love about working at Figma is just like how much we use the products that we make, right? Like we like really live in them.

And that really translates to a lot of the like deep power user. flows that end up in the product are because, like, people want them. And it also translates to an amount of care, I think, right? Like, people notice tiny bugs. And they fix them because, like, they're bothered by it. Or, like, people will notice, like, a string inconsistency and they'll, like, put up a change to resolve it. And so, like, all these, like, little minute things that may otherwise go unreported by users are, like, always reported internally in a, in a, really nice way. So I we did a deep dive with about Figma with actually Chris Rasmuson, uh, the CTO of about a year ago in the primatic engineer. And one thing that he told me there is

there's this concept of Figma of fixing, you know, like a lot of companies, like they're having a zero buck policy, especially for new development. So when something is launched for certain amount of time, if it's a bug, you fix it. Uh, as opposed to what a lot of companies do as well, you know, there's a report, you kind of put it in the backlog, eventually you might or might not fix it. How, do you still do this? And if so, you know, how are you doing this with slides, which is a new product that's still not ready or well, it's, you know, like just ready. Yeah, I definitely resonate with that. We have like, are like on-call shifts work differently than in my past jobs. We're like, when you're on-call,

it's a lot of what you do is you triage that main feedback channel. Um, if something, like a quick fix that someone reported, you can just put the fix up right away. But if not, like, you go through the act of them prioritizing those things. So we do make sure that everything that's reported internally is either than like fixed or planned to be fixed. Nice. Yeah, I will say being in beta did allow like a little bit of leeway with with bugs to like make sure that we had a really solid set of like an end-to-end flow ahead of like the config launch. So we definitely, one thing I really did like respect about Figma is like when it came to crunch time, we were really good about like prioritization instead of like adding more hours onto everyone's

workflow. So I think we were, um, Figma was really good about like making sure that we had like, we were able to figure out the true blockers. Um, that would make beta like less successful versus stuff that we could happen in beta that we would want to fix ahead of like our bigger launch. And how does it look like to push something out to production? You know, like you fix a bug or are you out of new feature? Do you literally just like push it out and it goes out to every single customer? Do you have feature? Well, obviously, you know, I'm assuming you'll have code review, CI.

You're just nodding, but, you know, not every place has it. But I'm going to assume, you know, correct me if I'm wrong. And then when it goes out, do you have a concept of feature flags? I assume you must have it. But for the most part, does it just go out to everyone? And then, like, boom, it's there? Or is there a little bit more kind of careful release process? I think the answer depends on, like, what the bug is.

And then, like, the risk of the bug or even just the area, right? I think it's like anything that's going to be touching the core experience of the core editor, if that's like a risky bug fix always gets a flag. And we tend to roll those out slowly and like watch for reports. Or like any like bug fixes in our renderer too, right? Just like these like really core areas always always get a flag. And part of that is like, you know, we're making this thing that people live in for eight hours a day. You know, like people do their full time jobs in Figma.

And so we tend to, you know, prioritize not. being risky. Yeah. Yeah. In terms of like feature flags, yep, we got we have feature flags. Yeah, last I checked we have over 2,000 I think over two. Okay, okay. You must have an internal panel right for for devs to be able to trigger it on your local thing, right? Yeah, yeah. But yeah, but yeah, but in terms of feature flags, since we have our like staging environment where we have people like dog fooding stuff all the time. We have a lot of like feature flags of like the bigger features we're working on, such as like some of the ones we're launching for GA, such as like slide numbers or components or like object animations. We have those on internally in our like staging

environment. And we get a lot of really good like feedback on bugs and just general like usability by just having those on within staging. And I think that really helps, like, make us feel a lot more confident of, like, when we eventually flip that in prod, just making sure that it, like, that it feels good. And then is staging internal or is it also for a subset of customers who might opt in to, you know, like, get feedback or be on the bleeding edge? Staging is, yeah, staging is only internal. I think for slides at least, we had a point where slides was staging only, like internal.

only. And then I think it was like March, 24 or so, where we had our first like alpha launch, where we like had a select few customers that we like decided to open the feature flags up to inside of prod who we like worked really heavily with user researchers to like figure out. So we had a, we had an alpha period. Something that's interesting that I haven't seen at my past jobs that we started doing recently is for all of our unit tests and all of our interaction tests, we run the full suite with all the flags off and then with all the flags on. So the same tests are like running in both permutia. And like obviously like within the tests,

you can specify a different permutation. Like if you're writing a test that only covers something that like has, that like requires that flag, obviously you need that flag to be on, you know. But this has been like a huge, because like, you know, before we were doing this, this was a source of regressions, right?

Where it's like, hey, you know, like this flag caused this to break. And I didn't know this until, you know, someone went to delete the flag and then like that caused test to fail, right? So now that we're doing this, it's really, I don't know, it's pretty awesome. I feel like everyone should do this is my takeaway. Like one really good example is I was debugging like a really deep like copy paste test. and then like a really deep copy paste bug, and then I wrote some tests for it,

and I was like, okay, let's make sure, like, slide one is the first slide, and then slide two is the second slide. At the same time, like, John is working on slide numbers, and I don't have the slide numbers, like, feature flag on internally, like on my local environment, but it's on, like, in our staging environment. So one thing I didn't catch is that, like, the slide numbers change, like,

renames slides internally from the word slide space one to just like one or two. And that like, and like, yeah, if I just merge that test, it would break under John's feature flag. But because we have this system where all flags are off and all flags are on, I was able to catch that test before I like merged it in.

I haven't heard this, but I'm going to make a note because it's just like sounds like, Yeah, yeah. You know, like a good, good practice at a lot of places because so many places do have feature flags, but this is smart. I was going to say getting from where we were to like having this, having this setup did take a bit, right? So like each of our flags have their own configuration to be like, am I enabled always? Am I enabled just for we call them rollout tests? So it's like off in the non-rollout test and then on in the rollout test.

And so just getting to the point where we could even get a green build in the rollout test was like a huge effort. And then one last area that I was curious about is this concept called inch crit. Now, this is something I've not heard before. I think the practice is somewhat familiar. But can you tell me about it? What is inch crit? And what is even a crit? inside of Figma.

Yeah, Eng-crites are pretty sweet. We actually run them internally using fig jam, which is yet another one of our products. But yeah, instead of someone sending over a long, like, dock, and then people, like, leaving comments in those, we sometimes do these, like, 30-minute Eng-Critz where someone makes a fig-jam file.

And then for 20 minutes, like, a ton of other engineers around the company, like, jump in and, like, leave sticky notes. and then leave sticky note threads and have all these, like, acin conversations. And then at the end, we have, like, sometimes 10 minutes or so to, like, talk about some of the spiciest, like, sticky threads. I think we have, like, a good, like, engineering blog post about this concept. But, like, for instance, when I was, like, trying to add components into slides, I had a really good EngCrit with our design systems team where I made a fig jam. I showed him a prototype that I made. I, like, showed some of the code changes that we'd have to do.

And then 20 minutes, just tons of sticky notes and, like, spicy feedback and, like, sticky note threads. And then afterwards, we had, like, 10 minutes of just chatting about, like, some of the biggest decisions or not. So, yeah. So it's basically like a design review, but very figma kind of flavored, right? Yeah. I like it because it does lower the... the stakes a little bit. Like sending out a doc can be like a little bit scary. Yeah, yeah. I, I remember, you know, you want it to be good, well-formatted, nice wording, that kind of stuff. Actually,

one thing that might be cool to talk about is we have this really cool, like, bisect system internally. We call it web bisect and using sort of our front and commit previews where like any commit that's, or any pull request that's like merged into our master branch. We have an image of that, like deployed. So we have this sweet tool that someone actually made during a maker week where if you see like a bug or something and you don't know where it came from, you can actually use this tool to bisect where which commit actually introduced that bug.

So you could be like, okay, I saw this bug for the first time like last. week and then this internal tool lets you pick chooses some like commit preview right in the middle of that and then you can like test that preview and you'd be like oh the bug is here or it's not here and then depending on that it like bisects a little bit more and then it could be like you could test that again and it's like okay the bugs here the bug's not here and then if you do that 10 times you can nail down like which commit in the last week or so out of thousands of commits cause this regression and that's like extremely useful. So we'll close up with some rapid questions, if that's all right with you guys.

And I'll just ask and you just like shoot whatever comes. So what is your favorite language or framework that you really like using? I've got to go with the classic type script. It's becoming too popular. It is a very good language. I've become a big next JS fan as far as frameworks go. Oh, nice. What made you convert?

I built my personal site using it just to like test it out. And I just thought it was really fun. And so since then, like all my side projects that I do, I've been using Next. Who knows if you're going to introduce it to work as well now? Our stack's too complicated. Oh, yeah. What's a design resource or a tool that you use in line? like.

Honestly, the first thing that came to mind is I'm an avid hacker news reader. I don't know if that's like 100% what you meant by like resource, but I just love going through like the like top voted blog post there. Yeah, I think for me, just like flexing my design muscle a little bit, refactoring UI was really cool just to get like rapid fire quick tips of like how can I make some like engineering mock or like some like weird website that I'm making on mind and just look like slightly better like making sure that like my pixels are in like factors of four or eight pixels or like adding a little bit more white space or like keeping a limited set of font size.

So refactoring UI is this the book or is this a tool? Yeah, there's a book. It's like a PDF book that's pretty useful. And there's also like there's like a Twitter thread that I think the this is from the creators of Tailwind. right? I think so. I think so. Yeah, I just found it. It's from Adam Weth and Steve Schroger. Mm-hmm. Awesome. And what is a book? What is one or two books, fiction or nonfiction that you read in would recommend? I recently read Piranesi, which is, it's like, it's pretty short. It's a really

captivating story and it's one of those books where after you read it you really do think about it every day, you know. Yeah, this one isn't software really, but I'm reading Kurtzgesat's immune book, which is this really cool like book about the immune system being written by like a very good science communicator. I think it's just cool to sort of like visualize like my immune system and my body in like a whole different way of like this whole collaboration of cells working together. Nice. Well, John and Anna, thanks a lot for being here and for giving us a behind the scenes view of how slides is built and how some of the simple user interfaces have a lot of complexity

behind them. This was really, really eye-opening for me. Yeah, thanks for having us. Yeah, thanks so much for having us. Isn't it interesting how seemingly simple product or UI can be so complex behind the scenes like the single slide view and figma slide? Thanks a lot to John and Noah for all these details that they shared with us. You can find both of them on social media as linked in the show notes below.

For a more detailed deep dive about the engineering culture at Figma, check out a longer article in the pragmatic engineer titled Inside Figma's Engineering Culture, also linked in the show notes. If you enjoy this podcast, please do subscribe on your favorite podcast platform and on YouTube. This helps more people discover the podcast. A special thanks if you leave a rating. Thanks, and see you in the next one.