Building Figma Slides with Noah Finer and Jonathan Kaufman
Scores
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 per and like obviously like within the test 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 right 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 sliding less than a year from idea to launching it Ina in April 20124 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 slide is built using typescript Rea 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 in crit process using a feature flags and running all unit test twice once with all the feature of flags turned off and then once with all turned on and a lot more if you're interested in the 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 did you start building you know like what kind of what kind of text tag did you use back then um you know like did you just have a few scratches like it sounds like a really exciting part of the of the project right and it actually you know it can make or break a project so everything about the slide grade and um and those things were were built just sort of on a branch and we kind of hack we style where like we wouldn't have merge this to uh our main branch yet would you mind just sharing like how figma slice looks and and what the parts are that you're talking about the for example the slide deck and the grid um so this is figma slides when you enter uh slides you're presented with what we refer to as single slide View and this is what people are very familiar uh with seeing in Google slides and PowerPoint and keynote where you have um this carousel on the left and you can go through the slides yeah um but what we noticed um is that when designers were building slides within figma design they would always lay everything out uh using our Infinite Canvas um so this is what we refer to as as grid view um there were a bunch of annoyances uh 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 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 how can we give better um reorder behaviors for people who want to build slides and like see slides in this way right so you know as you drag things around they they re you can reorder a whole row um and what uh 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 in in in Grid View and so it's this nice Ono one relationship and so what this allows is it allow just a question like so what about the columns like is that uh yeah yeah so if uh see how this is this this Brendan slide is 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 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 Al allows is um people who are more familiar and comfortable with the infinite canvas they can live in Grid mode where they're where they're happy but people who may be less familiar here or or or don't want that view they can stay in this view on the same file this episode was 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 inuring 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 Port requests the workflow at the part 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 cbase 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 versell rely on graphite every day start stacking with graphite today for free and reduce your time to merge from days to hours get started at gt. the/ pragmatic that is g for graphite tfor technology. def pragmatic this episode is brought to you by sonar the creators of sonar Cube server cloud ID and Community build sonar will now offer sonar Cube 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 life cycle sonar Cube Advanced security enhances sonar's core security capabilities with software composition analysis and advanced static application security testing in this enables developers to identify vulnerability in third party dependencies insur license compliance and generate software bill of materials sonar analyzes all code first-party AI generated and thirdparty open source resulting in more secure reliable and maintainable software joined over 7 million developers from organizations like Microsoft DOD Barkley and T-Mobile who use sonar prioritize code security and code quality issues at the beginning of the software development life cycle visit son source.com pragmatic security to learn more about sonar Cube and then so when you started you know it was just a very small team so the one of the first things was coming up with this kind of two-way navigation that would make it unique right cuz I I haven't really seen this you know like going from an infinite grid view to this s single the single s we we we familiar with but what was this one of the challenges to you know build the rough prototype of uh this this became a later challenge um 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 in the grid View and what we built out was like how how are you going to manipulate slides here what are the um what's the template system going to look like you know like like when you add a slide how how can we pull from an existing deck um what's the theme system going to be um 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 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 too early where like we just wanted to focus on the riskier bits yeah actually I came on around the time that uh single slide view was being built and um 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 um and a lot of like when I first got on was like prototyping like ooh how like how will single 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 button and keyboard shortcuts and all this other stuff and there's like a lot still to figure out about what is single side view and how do we make it work um and what we kind of landed on is um secretly like in this view in single slide view we have like zoomed into the canvas um 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 um yeah there's a lot of iter back then to like figure out what are we even doing with this yeah it's one of the interesting Parts about building on figas like Infinite Canvas right is because we wanted to preserve the grid view um and allow people to still edit in Grid View and have their like cursor 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 slide we just snap the viewport for you that that that is clever and just taking a a step back just to understand like how the project roughly went uh so you you had the early prototyping phase you then had the the you know like those like one or two months building a proof of concept and then like what were the phases and and what parts did you build until we we get to final you know General availability yeah I think um so when it was sort of JN and just like one or two other Engineers um before the team was fully staffed there's a lot of focus on sort of like the grid view um and like how are we going to lay out slides in the grid um then after the team started getting staffed a little bit more then there were more explo 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 free form um we also did a lot of work on like single slide view nailing like centering the slide in single slide view versus not that took like months of like working with designers and like sending over prototypes in order to like like figure out um we also had a big group working on like um like um presenting and presenter viiew um 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 um those all sort of happened um coming like up to Beta I think like we had like like the only way to do like an endtoend flow of like using a template and presenting it um I think that took until like I don't know if you remember John but like maybe December January or so um and then yeah and then is it 2023 yes because we launched in 2024 yeah yeah yeah so 2024 January um 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 three 300 or so like pz and so many that we added a new like stage of pz of like a P0 do this now and then how big was the team in terms of like Engineers designers roughly I think at its biggest we had between 10 and 12 Engineers um I want to say two designers and uh a dedicated person from research and a dedicated um someone from ux writing but you you don't have any dedicated testers or QA folks right like it's Engineers doing the testing and and like you know test oh so so you have a dedicated research person though tell me about that yeah uh it was pretty instrumental in finding the direction of slides um a lot of what we explored is very similar to to Fig Jam where it's like we're building for um 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 um what what resonated and then using that to to better form our uh POV on on Direction yeah I think one of the coolest like tools that we have internally are these frontend commit previews where um if you like push up a branch um uh if you like push up or make a PO request um 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 nonproduction code and then like um shooting those over to uh research and then they were chatting with some folks internally and we had them use like these like prototypes basically just created a poll request with the whatever data and then whatever was on your machine the researchers could show right yeah nice and what is the text tag 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 uh using what we refer to as full screen which is R C++ code base and and and renderer and then um what that does is it writes to a literal canvas element um in the Dom uh using either webg or web GPU depending on browser support so that's like a lot of the our main stack that that we work in when when building out the UI is in C++ everything that's on top of uh the can Bas so like this left panel the properties panel this tool belt um all the file menus these are all in typescript and react and then we uh have our own bindings layer that allows us to share State between what's in C++ and what's in web so uh you know like I think react and C is pretty straightforward but do you also need to go into C++ to do some kind of UI changes or create new like core elements those kind of things I feel like all all of the like teams that work on our our editors are um either 50/50 or or going to be more uh C++ that's that's that's you know not a conventional uh UI technology did you pick up C++ on on on the go after you join figar did or did you do it before I there are some people who like come in as like C+ plus experts and then there's other people who like come in as more like web uh experts um I 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 um for like operating systems or like all these other like things but how you'd use like C+ Plus for like a college project or other things is very different from like how we use it at figma um I feel like figma's almost designed like like a game engine almost but the figma code base 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 um but a really cool thing like figma's doing is they're trying to rewrite parts of like the full screen C++ um like codebase to actually be in typescript so it's like typescript chatting with um R C++ code that like bindings right yeah with this bindings layer which is really cool So like um one example of those is um all the little like blue lines yeah like if I'm like hanging out in Grid view um all of these like plus buttons and Like These Guys these guys are rendered on the canvas but um they're using they're written in typescript um and then that typescript is like um interacting with the canvas which is of course being rendered by um like typescript and react and then one interesting thing that you previously mentioned is that figma has this pretty cool Tool uh C++ web assembly Editor to help debug typescript as as you're building it what is this tool and this sounds very very unique to figma it'swe we have this um there's this Crim extension called like dwarf wasm debugging um that like we've installed and um what's really crazy is like you you can debug like C++ inside of like Chrome itself um inside of just like the um 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 and this is like custom tooling obviously that that you built from cuz no no this is um it's open it's like a part of chromium oh so chromium supports debugging like custom C++ uh web assembly libraries yeah yeah it's the like mental model is very similar to like if you're using compiled or transpiled 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 um so here I just have like you'll notice I have like a typescript file next to a C++ file oh okay and then obviously you need to have a debug build for this to to work right yeah yeah so there's a special type of build that you can build that generates dwarf symbols and then the Chrome extension can consume those symbols and and map it to source files on your computer that is so cool yeah and things like like breakpoints work um not 100% of things work um but you can like inspect different objects and like read read values of primitive things for sure like I mean I I I worked with like back a very long time ago when I worked on Skype for Xbox one we had it 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 do debug logs and like I what I would have not given to have this tooling it's yeah it's super cool yeah I think before this was supported uh it was before I joined figma so this has been around for a few years at least um people would build uh we have a build that you can run within xcode that like launches figma and then you can use xcode to to debug the C++ but now I think most most uh Engineers here are are using this yeah I think it just comes to show that even when you have like a more unique text stack it's pretty cool how like some of these things are are standards and they exist you just need to find them because as you said like I I kind of assume that you must have built it yourself but no it's uh it's a universal uh Chrome plugin yeah yeah yeah one really cool example of like how I use the debugger um was there was like one time where we had this variable that was getting set inside of um inside of our web code base it was like a configuration variable between like are you in ui2 or are you in ui3 um and um 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 um and after like a good bit of Investigation um 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 um I put a breakpoint there and then I put a breakpoint on this code that was like are you in UI 2 or are you in ui3 which is being set in web as able to see we were having like a crazy race condition going on um wow and the only way I could have did that was with like this was and debugger yeah cuz 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 uh slides figma slides compared you know things that you you don't really come across on other projects you know I'm assuming you 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 it sounds like it's not not your typical project this one yeah I think one of the main challenges really was um something that we've already touched upon which was how we built single slide view to to be literally just moving the viewport 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 XY coordinates on the canvas and then we can like zoom in you know um so that was like a unique set of challenges uh but what's really cool not only that it works but that it allows um all of our existing uh tooling around like multiplayer cursors and things like that to to to kind of just work right and and what what is multiplayer cursor for those not familiar with you know fig Mingo yeah so multiplayer cursors are when someone else is editing the same thing you can see exact ly what they are editing right so if Noah makes a selection uh uh we can see that Noah has has that node selected um 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 how does multiplayer work there must be some sort of TCP connection open and you know like this must be talking to a server is is it happening on a server or is it is it peer-to-peer uh it is happening on a on a server yeah this is some I could do my best to answer it our uh 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 at a at a top level we have um a rust service running that like um um all edits propagate through and it it it handles conflict resolution and sends things back down each each client maintains a websocket connection with it and and basically it's in this library right so as long as you use a C++ Library it's built in so so I guess was this was this one of the reasons you decided to like all right let's you know hack around it like zoom in keep using it a a lot of it's multiplayer but um I think more more broadly a 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 will just work and same with going the other way right and uh uh 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 um uh it doesn't matter which editor you start in you have access to the same things that you created in in any of the other files uh and that's sort of like a second area of complication is is so like we call this interop right um uh but what that means is that you know like fig Jam has a bunch of not types that were made specific to Fig Jam like stickies for example uh but because we want interupt to feel so seamless what this means is that if you add a new note type to a specific editor um uh 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 um and so this ability to like bring things between products um is really cool for our users right uh but you know definitely adds complexity to the code and and as a Dev like what what does this mean for for you to support stickies 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 how it Maps like how how can we imag cuz I I feel this is like interop is is something that most of don't need to worry about until you do yeah there there's something like um there's like an irony I feel like as 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 with each new product we like really want things to be seamless you know um as as far as what the code looks like a lot of what's in the full screen code base which is our our our C++ code base is the same uh code running regardless of which editor that you're in um a lot of the differences are are in the website right so like we have a different root react tree for for each editor and that's how things are very visually different um but the code running the what powers that main canvas is the same wasm bundle for 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 um and so Mouse behaviors are you know it's sometimes hard not to use the word in a definition they're the behaviors that run for the mouse right uh so like I'm dragging what happens right and so a lot of what happens in fig Jam right or or we like to snap things to different uh um pixel grid so that things like lock in more vers design is more free form right so for things like that we can check which editor that you're in and like uh uh respond accordingly yeah one example of like a different mouse behavior that we have like inside of figma design if I were to like try to drag some like things inside of an auto layout container um we have like this Behavior over here where like um they'll Shuffle around in real time but if I were to jump into a slides file um let me go share my slides tab um we have our own sort of uh unique behavior um for handling like this drag like we have our little like previews over here um we have like the ability to add new rows down here um all of this is done via like our own like slide specific Mouse behaviors um yeah okay so so each editor type can like register a unique set of mouse behaviors is how a lot of differences are expressed this this is pretty interesting and it sound just very very unique to to to figma I I but I I guess you know like if if we're to peek in the internals of like any company that has like a big product that that has evolved we'll probably see something might see something similar but this is just fascinating how you know things become really kind of unique for a good reason and homegrown this goes back to like Noah mentioned that um uh a lot of the figma code looks like a game engine I think that this like mass behavior concept is is like taken from how uh a lot of game engines run right so there's like a a priority list of mass behaviors if one of them accepts the event it doesn't go to to the next one you know um so it's like our own sort of like delegation pattern that often uh the browser would handle for you but because we're running in C++ it's all written from scratch well and you do have a bit more freedom I just had a I was just recently talking with uh the well my brother the founder of craft docs who decided to build their own UI not using the system UI and then I mean it's a lot more work but then you get a bunch of freedom to do 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 things cuz like something that we do um 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 uh what OS you're using you know if you're looking at a a figma file we can guarantee that like it'll look the same which is very important when you're making a 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 um 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 we we added support for by directional fonts and that was all like like we had to add it you know cuz we couldn't lean on the browser hey developers we've all been there it's 3:00 a.m. and your phone blares jolting you awake another alert you scramble to troubleshoot but the complexity of your microservice 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 guess work out of troubleshooting with just one click DDX automatically analyzes all spans side Dimensions related to a service pinpointing the most likely cause of the issue don't let troubleshooting drag you into the early hours of the morning just DD exit and resolve issues faster see why chronosphere was named a leader in the 2024 gner magic quadron for observability platforms at chronosphere doio pragmatic that is chronosphere doio pragmatic it it is interesting cuz now I remember you know like just one everyday thing that people might come across is just a PDF file is when you when you open it uh it's for editing with uh with anything really and then you need to have your fonts and those fonts need to be installed at the OS level and if they're not you know you're out of luck and it'll look something weirdly different yeah tradeoffs everywhere yeah yeah yeah yeah for sure and what are type of things we tricky about this project yeah um um I could chat a little bit about like how single slide view had some really interesting challenges oh love that because this is something I I I don't think most people would assume yeah like it's how hard could it be it's it's this and actually you you said earlier right that oh we knew this would be pretty simple that's why we left it for later Yeah by simple it's very relative yeah um but yeah like single slide views in this really interesting spot where um like collapse State um like collapsing slides and expanding them we don't want to like save that to your file at all um like we'd want to save stuff like the the order of slides in the grid to the file but we don't want to save stuff like are these collaps or not to the file so in order to render um like this 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 licated code to um sort of like coales those in order to figure out like what to render here um on top of that there's like a ton of crazy technical challenges to solve in terms of like dragging slides around um and like making sure that like if I were to drag um 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 this slide out and then like move it into this row um um we got to make sure like this row is still preserved up there um 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 um coales like sort of changes from the carousel um 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 yeah so like this like intersection of like editing and multiplayer is like a really interesting part of the figma stack um 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 want it to be multiplayer friendly there's a lot of work under the scene or under un behind the scene under the hood that's happening to like perform the the minimum number of mutations possible because the more mutations that you do the less multiplayer friendly something is right so you can 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 um when you do that mutation you're changing every single slides XY coordinate right well that's the most obvious thing to do right yeah and that's how slides worked for a a a while um but then how we ended up solving this is our like ethos was was to do the minimum number of mutations right like ideally the number of mutations or the number of slides that you drag um and the way that we achieve this under the hood is actually using um 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 and then each of those nodes is within uh a slide grid node right so each each slide is now two levels deep um we have an existing construct called parent index which was made for reordering Stuff within frames and reordering stuff within Auto layout um and what a parent index is is it's a struct that has a a reference to the parents ID as well as uh a an index represented as a float from 0 to one and so by doing it this way if you reorder just one thing for ex example you 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 recomputing the layout right just to like move things around just so I understand the goal is that you send the mutations to the server saying here's what changed and then that server sends it to all the client and then all the clients execute it as well yeah and 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 where 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 like that's what we propagate I remember like um when before we had all these optimizations to figure out the minimum number of things to recompute um it was like it was pretty gnarly um like we I remember there was like a like a big like all hands that was happening internally and then we just like got a report that like hey a bunch of slides like disappeared or something and then we were like oh my goodness chaos mode um so we had to do a lot of digging to sort of figure out theories as to how this might have happened cuz 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 uh reconciliation playback conflicts how how to deal with conflict were while we were working on this we often joked like this would be a really mean interview question or or a really good one if someone can bring something use at the table it's like all right you need to join and how do you test all this so like I'm I'm specifically curious of like okay you know like in traditional like crud apps you typically have obviously you manually test that does it work you add your automated tests unit test later you might add integration test and then they're there to to guard against regressions and now you know like it's and you're you feel pretty happy and thumbs up it it'll kind of work especially when it's like a backend heavy thing that doesn't have much UI how does it work in your case yeah we have all of those um 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 um and we have every case that has ever caused a bug report um that we then assert the mutations that have happened so we like perform the reorder and then we verify on like every single slide after the order 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 um to to dig into this a little bit um 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 um um I remember one of the really interesting things I was um iterating on was like um how does the viewport like feel inside of um like single side view and um it's like how far can you zoom out how far can you zoom in um as you zoom out when you can see that the slide gets centered but like when do you start reentering the slide how far are like the margins here and here and to do a lot of like this testing um and you can see like it also scales with like the viewport but um to do a lot of this testing um this was a lot of like sending two options over to designers or um putting one option in our like internal um like staging environment and then like seeing how people felt about it as they like naturally use slides like um during their like day-to-day inigma um so it's a lot of like um 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 um people either preferred or like whichever one people um did not like like less than the other one yeah that that is different right from from from your usual development yeah 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 um 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 um 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 user are like always reported internally in a in a really nice way so I we we did a deep dive with about figma with actually Chris rasmason uh the CTO about a year ago and the pragmatic engineer and one thing that he told me there is there's this concept of figma of fixing you know like a a lot of like they're having this 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 is well you know there's a report you kind of put it in the backlog eventually you might or might now fix it how do you still do this and and if so you know H how are you doing this with with Sid which is a new product it's still not ready or well it's you know like just ready yeah uh I definitely resonate with that we have like are like on call shifts work differently than in my past jobs where like when you're on call it's uh a a lot of what you do is you triage that main feedback Channel um if something's 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 um being in beta did allow like a little bit of leeway um with with bugs um to like make sure that we had a really solid set of like an endtoend flow um ahead of like the config launch so um we definitely one thing I really did like respect about figma is like when it came to crunch time um 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 like could happen beta that we would want to fix ahead of like our bigger launch yeah and how how does it look like to push something out to to production you know like you you're you you fix a bug um or or you add a 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 um you're just nodding but you know like not not every place has it but I'm 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 flly I 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 the 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 um uh so like anything that's going to be touching the the core experience of of 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 any like bug fixes in our render two right just like these like really core areas always always get a flag and part of that is like you know we're we're making this thing that people live in for8 hours a day you know like people do their full-time jobs in figma and so uh we tend to you know prioritize not being risky yeah yeah in terms of like feature Flags yep we got we have feature Flags um yeah last I checked we have over 2,000 I think over Okay okay then you must have an internal panel right for for for devs to to be able to trigger on your local thing right yeah yeah yeah um but yeah but in terms of um feature Flags um since we have our like staging environment where we have people like dog fooding stuff all the time uh we have a lot of like feature flags of like the bigger features we're working on um such as like some of the ones we're launching for GA such as like slide numbers or components or like um object animations we have those on internally in our like staging environment um and we get a lot of really good like feedback on bugs and um just general like usability um by just having those on uh within staging and I think that really helps like make us feel a lot more confident of like when we eventually flip that in PR 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 who might opt in to you know like get get feedback or be on be on the bleeding edge yeah staging is only internal um I think for slides at least we had a point where slides was staging only like internal only yeah and then um I think it was like March 2024 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 um 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 um 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 oh the same tests are like running uh uh in both PR 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 um but this has been like a huge cuz 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 like that caused test to fail right so now that we're doing this it's it's really I don't know it's it's pretty awesome I feel like everyone should do this is my takeaway like one really good example is um I was debugging like a really deep like copy paste test and then uh 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 um on the 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 um one thing I didn't catch is that like um 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 um it would break under John's feature flag but because we have this um 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 I haven't heard this but I'm going to make a note cuz it it just like sounds like just like you know like a good good practice at a lot of places cuz so many places do have feature Flags but this is smart I was going to say say getting from where we were to like having this having this setup did take a bit right so like uh each of our flags have their own configuration to be like am I enabled always am I enabled just for uh we call them roll out tests um so it's like off in the non rollout test and then on in the roll out test and so just just getting to the point where we could even get a green build in the roll out test was like a huge effort and then one last area that I was curious about is uh this concept called ench crit now this is something I've not heard before I think the practice uh is somewhat familiar but can can you tell me about it what is ench crit and what is even a crit inside of figma yeah en crits are pretty sweet uh we actually run them internally using fig Jam uh which is yet another one of our products but yeah have instead of someone sending over like a long like Dock and then people like leaving comments in those um we sometimes do um these like 30 minute crits 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 um and then like leave sticky note threads and have all these like um asent 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 um 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 um I had a really good enge crit with um our Design Systems team where I made a fig Jam I like showed him a prototype that I made um I like showed some of the code changes that we'd have to do and then 20 minutes just tons of uh 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 it's it's basically like a design review but a but very figma kind of flavored right yeah I like it cuz it it does lower the stakes a little bit like sending out a dock is can be like a little bit scary but like yeah yeah I I I I remember you know you want it to be be be look 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 bisc system internally um we call it web bisect and um 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 um 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 buy disect where which commit actually introduced that bug um so you could be like okay I saw this bug for the first time like last week um and then this internal tool lets you pick um chooses some like commit preview right in the middle of that um and then you can like test that preview and you 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 bug's 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 like cause this regression and that's like extremely useful so we'll we'll we'll close up with some rabbit questions if that's start with you guys and I'll just ask and you just like shoot whatever comes so what is your favorite language or or framework that you really like using I've got to go with the classic typescript h it's becoming too popular it is a very good language yeah I become a big nextjs fan as far as Frameworks go oh nice what what what made you convert um 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 uh all my side projects that I do I've been using njs who who knows if you're going to introduce it to work as well now our Stacks too complicated yeah oh yeah what's a design resource or tool that you use un 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 I love going through like the like top voted blog post there yeah I think um for me um just like flexing my design muscle a little bit uh 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 like weird website that I'm making on my end just look like slightly better like making sure that like um 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 f refracturing UI is this the the book or or is this a tool yeah there's a book um it it's it's like a PDF book that's pretty useful and there's also like um there's like a Twitter thread that I think the this from the creators of Tailwind right I think so I think so yeah I just found it it's from Adam weth and and and Steve Sher awesome and what what is a book what is one or two books fiction or non-fiction that you read and would recommend uh I recently read panesi 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 for every day you know yeah this one isn't software related but I'm reading um kurts skazat um immune book which is this really cool like book about the immune system being written by like a very good science communicator and 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 and Noah thanks a lot for for being here and for giving us a a behind the scenes view of how slides is built and how some some of the simple user interfaces have a lot of complexity behind them this was really really eye openening for me yeah thanks for having us yeah thanks so much for having us isn't it interesting how a seemingly simple product or UI can be so complex behind the scenes like the single side view and figma SL sides 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 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
Summary
This podcast episode provides a behind-the-scenes look at how Figma built Figma Slides, highlighting the engineering challenges of creating a simple UI that integrates with Figma's complex underlying architecture, including C++ rendering, feature flags, and multiplayer collaboration.
Key Points
- Figma Slides was built in less than a year, launching in April 2024 with over 4.5 million decks created.
- The core challenge was building a simple single-slide view that integrates seamlessly with Figma's infinite canvas and grid view.
- The team used a two-way navigation system between grid view and single-slide view, with the single-slide view being a viewport zoom into the grid.
- Figma Slides uses a complex tech stack: C++ for rendering (full screen), TypeScript/React for UI components, and a custom bindings layer to connect them.
- A unique debugging tool allows engineers to debug both C++ and TypeScript simultaneously in Chrome using WebAssembly and DWARF symbols.
- The team uses feature flags extensively, running all unit tests with flags both on and off to prevent regressions.
- They employ a 'zero bug' policy for new features, prioritizing fixes for bugs reported internally.
- The team uses 'ench crits' (design reviews in FigJam) and internal prototypes to gather feedback before launching features.
- The engineering approach prioritizes minimizing mutations for multiplayer operations to ensure consistency.
Key Takeaways
- Even simple-looking UIs can have complex engineering under the hood, especially when integrating with a powerful platform like Figma.
- Use a robust testing strategy that includes running tests with all feature flags both on and off to catch regressions early.
- Consider using a hybrid tech stack where core performance-critical components are in a low-level language (like C++), while the UI is built with modern frameworks (like React).
- Leverage unique tooling, such as WebAssembly debugging in Chrome, to solve complex debugging challenges across different codebases.
- Prioritize user experience and feel in design decisions, using internal user research and feedback to refine subtle interactions.