Season 3
|
Episode 9
Figma prototyping masterclass
Nikolas Klein + Garrett Miller
Figma prototyping team
Dec 7, 2023
Dec 7, 2023
|
49 min
49 min
music by Dennis
About this Episode
This Deep Dive is a special one because we get to hear from Nikolas Klein and Garrett Miller from the prototyping team at Figma.
We get a behind-the-scenes look at everything that led up to the advanced prototyping release at Config 2023 as well as:
How Niko collaborates with engineering
The prototyping feature they didn’t think they would release
How they balanced power and simplicity while designing the expression builder
Traits of a prototyping culture
Strategies for prototype fidelity
The future of prototyping in Figma
Show Notes
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
Deep Dives
Get our weekly breakdowns
Free lessons from 👇
Lauren LoPrete
Lead designer @ Netflix
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
Transcript chapters
Backstory to Config 2023
I think in June 6th, 2022, which was pretty much exactly a year before the, , 2023 config, we actually had an internal presentation at our, like all hands, our Fignation, where we shared out, here's our plan for prototyping of what we're going to ship next year at config.
And we talked about the story of, of, of aiming to reduce the. Noodle messes, the pasta pictures that we've seen so many people have, imagining what it does look like.
Once you get away from the entire canvas being filled with noodles to a prototype, being something manageable, something you can like. See and read and so we knew it a year ago and that story started, I would say, around six months earlier, where basically we were being asked from show.
And our leadership team on how we can like make a bigger jump in prototyping over the years before this, we've [00:01:00] always worked on improving it step by step, right? We've, we've, we've made things like interactive components and smart animate, but it felt like there was this looming thing of like, okay, we need to find a way to reduce the number of noodles for slightly more complex prototypes.
But getting started on this and understanding that that is the right direction to focus on over so many of the other things we could do that, I would say the whole research and design process took about six months and ended with this June presentation.
Can you talk a little bit more about the research component? How did you go about structuring that research and what are some of the key takeaways that informed the higher level vision for what prototyping could become?
The great thing for us essentially was basically that the ask from leadership was very open ended. It was like. Where could prototyping go, right? How can we make bigger steps within the prototyping space? And so the research was ultimately that we interviewed, I think up to 20 people, , [00:02:00] from all kinds of like, like skill levels.
We've interviewed like novice users and try to look at how they are using prototyping for the first time. We'd try to understand why do people not prototype today? And we try to essentially. See what people do, , when they prototype in Figma successfully and what their problems are and understand what other tools they're using.
, if Figma can't fulfill their prototyping needs. And so the interesting thing really was that there are. Like broad, broad ways for using prototyping. , for one side being you want to demo something, you want to show something, you want to kind of like convince something that this is a good idea or communicate a specific animation detail to your developers, or you want to validate.
A product direction, does your idea fulfill the needs of your customers, and those two are relatively separate prototypes. And we've seen them, people are using, , amazing tools for these, like more one off high [00:03:00] fidelity micro interaction prototypes, but. We've seen that the pain that people have for building these more realistic prototypes is so much bigger in Figma because you can kind of do it if you put enough work in it, right? Like you can create a checkout flow if you create 400 screen combinations that are all just tiny different. And some people did, and that was the wild part for us because we realized that They are doing this in Figma, but it is incredibly painful for them. And that I think is a perfect opportunity for a big feature break. Because you're essentially solving this, this true pain that people experience within your product. You don't need to convince them to come in. They're already there. They're getting to that level of fidelity and we are providing them a better way to do so now.
Backstory to Config 2023
I think in June 6th, 2022, which was pretty much exactly a year before the, , 2023 config, we actually had an internal presentation at our, like all hands, our Fignation, where we shared out, here's our plan for prototyping of what we're going to ship next year at config.
And we talked about the story of, of, of aiming to reduce the. Noodle messes, the pasta pictures that we've seen so many people have, imagining what it does look like.
Once you get away from the entire canvas being filled with noodles to a prototype, being something manageable, something you can like. See and read and so we knew it a year ago and that story started, I would say, around six months earlier, where basically we were being asked from show.
And our leadership team on how we can like make a bigger jump in prototyping over the years before this, we've [00:01:00] always worked on improving it step by step, right? We've, we've, we've made things like interactive components and smart animate, but it felt like there was this looming thing of like, okay, we need to find a way to reduce the number of noodles for slightly more complex prototypes.
But getting started on this and understanding that that is the right direction to focus on over so many of the other things we could do that, I would say the whole research and design process took about six months and ended with this June presentation.
Can you talk a little bit more about the research component? How did you go about structuring that research and what are some of the key takeaways that informed the higher level vision for what prototyping could become?
The great thing for us essentially was basically that the ask from leadership was very open ended. It was like. Where could prototyping go, right? How can we make bigger steps within the prototyping space? And so the research was ultimately that we interviewed, I think up to 20 people, , [00:02:00] from all kinds of like, like skill levels.
We've interviewed like novice users and try to look at how they are using prototyping for the first time. We'd try to understand why do people not prototype today? And we try to essentially. See what people do, , when they prototype in Figma successfully and what their problems are and understand what other tools they're using.
, if Figma can't fulfill their prototyping needs. And so the interesting thing really was that there are. Like broad, broad ways for using prototyping. , for one side being you want to demo something, you want to show something, you want to kind of like convince something that this is a good idea or communicate a specific animation detail to your developers, or you want to validate.
A product direction, does your idea fulfill the needs of your customers, and those two are relatively separate prototypes. And we've seen them, people are using, , amazing tools for these, like more one off high [00:03:00] fidelity micro interaction prototypes, but. We've seen that the pain that people have for building these more realistic prototypes is so much bigger in Figma because you can kind of do it if you put enough work in it, right? Like you can create a checkout flow if you create 400 screen combinations that are all just tiny different. And some people did, and that was the wild part for us because we realized that They are doing this in Figma, but it is incredibly painful for them. And that I think is a perfect opportunity for a big feature break. Because you're essentially solving this, this true pain that people experience within your product. You don't need to convince them to come in. They're already there. They're getting to that level of fidelity and we are providing them a better way to do so now.
Building on top of variables work
It's cool to hear how green pasture it was at the beginning stages of the project. And I'd love to get a little bit more clarity around [00:04:00] when did variables come into the picture? Like when you were first thinking about what this could become were variables. As they more or less exist today, always part of that vision.
Were they an unlock that came later down the road? How did you get alignment on that being the high level way to execute against this vision?
Variables came into play as we understood the different use cases that I talked about, right. And we started sketching out what kind of features we would need to have to solve these problems.
Yeah. Yeah. Yeah. And variables is an obvious, solution in this space, because if you look at these hundreds of screens, the differences in between those screens are tiny. And it is about the relation between the global state in a program or in a, in a prototype essentially, and how that relates to which exact variants of a button are shown, that that was the thing that once we would find a way to abstract that particular [00:05:00] aspect of these prototypes into variables, we would be able to remove the need for all of those redundant screens.
Building on top of variables work
It's cool to hear how green pasture it was at the beginning stages of the project. And I'd love to get a little bit more clarity around [00:04:00] when did variables come into the picture? Like when you were first thinking about what this could become were variables. As they more or less exist today, always part of that vision.
Were they an unlock that came later down the road? How did you get alignment on that being the high level way to execute against this vision?
Variables came into play as we understood the different use cases that I talked about, right. And we started sketching out what kind of features we would need to have to solve these problems.
Yeah. Yeah. Yeah. And variables is an obvious, solution in this space, because if you look at these hundreds of screens, the differences in between those screens are tiny. And it is about the relation between the global state in a program or in a, in a prototype essentially, and how that relates to which exact variants of a button are shown, that that was the thing that once we would find a way to abstract that particular [00:05:00] aspect of these prototypes into variables, we would be able to remove the need for all of those redundant screens.
How the design team collaborated
so, say you've just kind of gotten buy in on the fact that, okay, we're going to, we're going to do this. We're going to make a real move in advanced prototyping. We're going to build on top of variables. Can you talk to me a little bit about what collaboration looked like at a team level? Because me it feels a little bit complex, right?
Like as the prototyping team, you're building on this foundation that my assumption is a whole other team is working on for design systems and variables as tokens. So how did you stay aligned? Throughout the project, especially in the early days. And what did that collaboration look like?
It was ultimately relatively clear to us from the beginning that those are similar concepts. Tokens hold individual pieces of value, right? And, and, and variables hold and hold individual pieces of value. So ultimately , there was a question, which is.[00:06:00] Can we do this together? So it was a lucky.
lucky moment in the end for us that like the design systems team wasn't super far along. We weren't super far along and we just realized, Hey, we need to work together on this. We should work together on this. , of course there's struggles , because design systems, variables, design system, tokens need to be able to capture users that have thousands of tokens and for prototyping, often a couple, of variables are enough. So of course there are some differences in how they, are viewed and edited, but ultimately for, for us as Figma, we knew that we needed to build one underlying system.
We wouldn't maintain technically two different systems that are kind of the same and kind of different. And if you try to explain this to users that are not super well versed in all of those terms, how are they supposed to understand this? If we are already arguing about,
How the design team collaborated
so, say you've just kind of gotten buy in on the fact that, okay, we're going to, we're going to do this. We're going to make a real move in advanced prototyping. We're going to build on top of variables. Can you talk to me a little bit about what collaboration looked like at a team level? Because me it feels a little bit complex, right?
Like as the prototyping team, you're building on this foundation that my assumption is a whole other team is working on for design systems and variables as tokens. So how did you stay aligned? Throughout the project, especially in the early days. And what did that collaboration look like?
It was ultimately relatively clear to us from the beginning that those are similar concepts. Tokens hold individual pieces of value, right? And, and, and variables hold and hold individual pieces of value. So ultimately , there was a question, which is.[00:06:00] Can we do this together? So it was a lucky.
lucky moment in the end for us that like the design systems team wasn't super far along. We weren't super far along and we just realized, Hey, we need to work together on this. We should work together on this. , of course there's struggles , because design systems, variables, design system, tokens need to be able to capture users that have thousands of tokens and for prototyping, often a couple, of variables are enough. So of course there are some differences in how they, are viewed and edited, but ultimately for, for us as Figma, we knew that we needed to build one underlying system.
We wouldn't maintain technically two different systems that are kind of the same and kind of different. And if you try to explain this to users that are not super well versed in all of those terms, how are they supposed to understand this? If we are already arguing about,
Garrett joining Figma
this is around the time I think I came in. So this is roughly the end of summer of, , [00:07:00] 2022. , I had actually been talking to Figma previously about some product manager roles. , but at the time I was, I was really focused on, on doing my own thing. , I had been an engineer at Slack for a number of years.
And I left Slack because I was, I was really focused on kind of the space between design and engineering is something that was, that was really important to me, having been an engineer, having been a designer, I knew that there was a lot of nuance, , in the space between when you're coming up with an idea and when you're trying to hand it off.
And I always had this idea that, Wouldn't it be nice if the rectangles that were being created by designers were also the rectangles that were being poked by the users? I've been working on design systems as well at Slack and, , was really deeply invested in like, we could just solve some of these, , Central collaborative points and come up with better abstractions that make sense to both sides to designers to engineers, then we could all be moving a lot faster.
, so I've been working on a startup, , focused on some of those pieces, , and over time, I think what I realized is that's a huge, vast, , more than industry wide problem to solve and maybe a startup isn't the best way to solve some of that. , [00:08:00] and I think the timing was really fortunate because, , this is roughly when I started talking to Nico and to show cool motto or VP of product at Figma again, , where they're like, well, you know.
We're doing some things with prototyping. We can't say what yet, but, you know, we'll talk to you in a couple weeks about it. it was, it was then that I learned more about these plans for advanced prototyping and I was like, oh, wow. So there's like, there's this Venn diagram between what I was really trying to solve and trying to focus on and what Figma now is saying that it wants to focus on.
And I think prototyping is an interesting, , kind of Trojan horse for a lot of these problems because the inherent nature and definition of a prototype means you're allowed to be a little bit mushier, you're allowed to be a little, like, take, you know, cut corners in order to achieve something that you want to achieve sooner.
, and I think , there's a benefit to that because it means that you're not exactly trying to build a production fidelity experience. You're trying to build something that's, that's close enough. and I think that's some of the nuance that, that Nico's kind of capturing with variables here, which is that.
, in a design systems world, a variable is almost, it's, it's a source of truth. [00:09:00] There's a token of truth that has to be consistent across all of these different services, across all of these different people, it holds an intrinsic value that can change. But the benefit of it is that it doesn't need to change.
It can be shared across all these things. And you take that same core object and you put into prototyping and it's like, it's almost the opposite. It's like, yes, I have this little thing that can store data, but I want to do all sorts of things to it. I want to mush it into here. I want to modify it. I want to run expressions on it.
I want to try to use it to hold the state. of this frame. , but yeah, I came in, to, , Fill the product manager role and help with some of this coordination. , and I think like very like on the ground week by week, process for this was us meeting with design systems. So our engineers were going to their weeklies. , they would often attend ours where, when we're all touching variables.
We actually are still continuing to have like weekly meetings in which we talk to design systems, , using variables as kind of the bridge core topic, but there's a lot of, of shared real estate there between. components, variables, handoff, , and everything in between. And I think a lot of the trickiest conversations have been us figuring out how we can [00:10:00] use them in the different ways that we want to use them, , while still, making them make sense to our users.
Garrett joining Figma
this is around the time I think I came in. So this is roughly the end of summer of, , [00:07:00] 2022. , I had actually been talking to Figma previously about some product manager roles. , but at the time I was, I was really focused on, on doing my own thing. , I had been an engineer at Slack for a number of years.
And I left Slack because I was, I was really focused on kind of the space between design and engineering is something that was, that was really important to me, having been an engineer, having been a designer, I knew that there was a lot of nuance, , in the space between when you're coming up with an idea and when you're trying to hand it off.
And I always had this idea that, Wouldn't it be nice if the rectangles that were being created by designers were also the rectangles that were being poked by the users? I've been working on design systems as well at Slack and, , was really deeply invested in like, we could just solve some of these, , Central collaborative points and come up with better abstractions that make sense to both sides to designers to engineers, then we could all be moving a lot faster.
, so I've been working on a startup, , focused on some of those pieces, , and over time, I think what I realized is that's a huge, vast, , more than industry wide problem to solve and maybe a startup isn't the best way to solve some of that. , [00:08:00] and I think the timing was really fortunate because, , this is roughly when I started talking to Nico and to show cool motto or VP of product at Figma again, , where they're like, well, you know.
We're doing some things with prototyping. We can't say what yet, but, you know, we'll talk to you in a couple weeks about it. it was, it was then that I learned more about these plans for advanced prototyping and I was like, oh, wow. So there's like, there's this Venn diagram between what I was really trying to solve and trying to focus on and what Figma now is saying that it wants to focus on.
And I think prototyping is an interesting, , kind of Trojan horse for a lot of these problems because the inherent nature and definition of a prototype means you're allowed to be a little bit mushier, you're allowed to be a little, like, take, you know, cut corners in order to achieve something that you want to achieve sooner.
, and I think , there's a benefit to that because it means that you're not exactly trying to build a production fidelity experience. You're trying to build something that's, that's close enough. and I think that's some of the nuance that, that Nico's kind of capturing with variables here, which is that.
, in a design systems world, a variable is almost, it's, it's a source of truth. [00:09:00] There's a token of truth that has to be consistent across all of these different services, across all of these different people, it holds an intrinsic value that can change. But the benefit of it is that it doesn't need to change.
It can be shared across all these things. And you take that same core object and you put into prototyping and it's like, it's almost the opposite. It's like, yes, I have this little thing that can store data, but I want to do all sorts of things to it. I want to mush it into here. I want to modify it. I want to run expressions on it.
I want to try to use it to hold the state. of this frame. , but yeah, I came in, to, , Fill the product manager role and help with some of this coordination. , and I think like very like on the ground week by week, process for this was us meeting with design systems. So our engineers were going to their weeklies. , they would often attend ours where, when we're all touching variables.
We actually are still continuing to have like weekly meetings in which we talk to design systems, , using variables as kind of the bridge core topic, but there's a lot of, of shared real estate there between. components, variables, handoff, , and everything in between. And I think a lot of the trickiest conversations have been us figuring out how we can [00:10:00] use them in the different ways that we want to use them, , while still, making them make sense to our users.
The design process for text variables in prototypes
I want to drill into that last point as a way to kind of learn more about what does the prototyping design and product team look like at Figma. And how are you exploring ideas and reaching decisions because. One of the components of this project that I think is really fascinating and a huge unlock, but probably wasn't super obvious is this idea of using text strings to manipulate a component state.
I think it's my favorite part of the entire. release. And yet surely that wasn't like super obvious in the beginning. So how do you take something like that and work together to arrive at like, yes, this is the way to do it. And now we can get people bought in on this idea.
That one was funny. I think primarily because it points a little bit to what Garrett had said, where it's like, It doesn't need to be perfect. iT needs [00:11:00] to be something that enables designers to be more creative in a, in a faster way, in a more approachable way, and it doesn't need to necessarily make perfect, technically scalable sense that variant binding, as we call it also works in both directions, like you can change it from the outside and if the interactive component changes, it also changes the applied variant. That might not be the perfect production way to build an application, but it is a directly understandable way of how to use it. And that's the same thing with these text strings, right? It's like, Oh yeah. But if you use a text string, then what happens if you change it to something that doesn't has a variant state underneath it?
And it's like, yeah, then it just doesn't work. Right. It's like, Oh, but like, it would be nice if you could make it work in such a way that the users never run into that particular kind of problem. That's true. But then I think that comes back with a different kind of cost. Right? Because now you have that state that you want to control on that [00:12:00] component, and now you need to create a different kind of variable. And if you all set this up correctly, you'll never run into the issue that it's the wrong, like variable name and the wrong state, and it comes at such a complexity cost that.
We ultimately realized, Hey, this is a super powerful functionality. It is an easy way to define not micro, but like slightly bigger changes inside of an application where it's like, Oh, the state changes from this to this. If I click on this, like those kinds of same screen interactions are relatively easily achievable with us. And we just realized once we tried it out, it's like, yeah, this is, this is good enough, interestingly, designers that. Did not came from a coding background, had no problem to adopt this in our beta, user testing flows. I'm just like, Oh yeah, of course this is how it works. Designers with much more of a development background were a little bit like.
I don't think this [00:13:00] should work. Like, why is this working? And, and I think that actually shows some of this like difference where it really isn't about the technical perfectness of these models that we have in prototyping. It is about intuitive abstractions that, that make creating of interactive ideas easier and faster and the technical perfection can come in later.
The design process for text variables in prototypes
I want to drill into that last point as a way to kind of learn more about what does the prototyping design and product team look like at Figma. And how are you exploring ideas and reaching decisions because. One of the components of this project that I think is really fascinating and a huge unlock, but probably wasn't super obvious is this idea of using text strings to manipulate a component state.
I think it's my favorite part of the entire. release. And yet surely that wasn't like super obvious in the beginning. So how do you take something like that and work together to arrive at like, yes, this is the way to do it. And now we can get people bought in on this idea.
That one was funny. I think primarily because it points a little bit to what Garrett had said, where it's like, It doesn't need to be perfect. iT needs [00:11:00] to be something that enables designers to be more creative in a, in a faster way, in a more approachable way, and it doesn't need to necessarily make perfect, technically scalable sense that variant binding, as we call it also works in both directions, like you can change it from the outside and if the interactive component changes, it also changes the applied variant. That might not be the perfect production way to build an application, but it is a directly understandable way of how to use it. And that's the same thing with these text strings, right? It's like, Oh yeah. But if you use a text string, then what happens if you change it to something that doesn't has a variant state underneath it?
And it's like, yeah, then it just doesn't work. Right. It's like, Oh, but like, it would be nice if you could make it work in such a way that the users never run into that particular kind of problem. That's true. But then I think that comes back with a different kind of cost. Right? Because now you have that state that you want to control on that [00:12:00] component, and now you need to create a different kind of variable. And if you all set this up correctly, you'll never run into the issue that it's the wrong, like variable name and the wrong state, and it comes at such a complexity cost that.
We ultimately realized, Hey, this is a super powerful functionality. It is an easy way to define not micro, but like slightly bigger changes inside of an application where it's like, Oh, the state changes from this to this. If I click on this, like those kinds of same screen interactions are relatively easily achievable with us. And we just realized once we tried it out, it's like, yeah, this is, this is good enough, interestingly, designers that. Did not came from a coding background, had no problem to adopt this in our beta, user testing flows. I'm just like, Oh yeah, of course this is how it works. Designers with much more of a development background were a little bit like.
I don't think this [00:13:00] should work. Like, why is this working? And, and I think that actually shows some of this like difference where it really isn't about the technical perfectness of these models that we have in prototyping. It is about intuitive abstractions that, that make creating of interactive ideas easier and faster and the technical perfection can come in later.
How Figma beta tests new features
Can you talk a little bit more about that beta program? At what point did you start to loop users in and. How are you learning and figuring out whether or not what you're doing is working.
So I think generally at Figma, when working on editor features, it can be like, It's either incredibly easy to run a beta program because it's a feature that changes maybe some of the editing behaviors, right? And then in those cases, you can just turn on a feature flag for a couple of users. You contact them and you gather some feedback from them with something like this.
It's very different because if you think about this, it's a new kind of like behavior and data that users [00:14:00] can create. And since Figma is just so entirely multiplayer, if I'm on the feature flag and you're not. I'm adding things to the document that you have no, not the capability to read,
so we have to be careful and essentially I think add all like an entire organization at once. and so we started with earlier just like usability testing behaviors where we basically just had a set of uh, example cases that we wanted to run users through, but we did end up, kind of like inviting entire organizations, right, Garrett?
Yeah, so we worked, we were closely with product marketing on this one. And I think, as Nico said, each beta for us is a different flavor, depending on the feature set, the scope of it, with one where you're kind of changing some of the underlying foundations or functionality of Figma in such a way like variables, you know, variables go across all files in all states.
And so, , you can't just. Turn that on in a, in a more bespoke way, like in a way that you may have around the layout, a layout, like feature or something that is, that is contained [00:15:00] within a certain sandbox within the editor itself. , so that was something that we struggled with because we had that epiphany of like, oh, okay.
Dang, we can't actually go and like, just turn this on for these three people within this much larger team. And that inherently means that like, okay, we can't, we can't beta test this with really large customers right now. Cause we don't want to bring 400 people in and potentially like disrupt things, especially early stage with some of the, the earlier months where were fairly sure that the features wouldn't corrupt files, but we weren't positive, right?
So we, it really limited us to smaller teams. Which we had, like, we, Figma had, had good working relationships with, or past histories with that we know could recognize the benefits, but also recognize that, like, there are some, some risks to using these things, , or, , Very specific individuals and teams of 1, essentially people who you wouldn't need to be collaborating within their own Figma team.
And I think There's the use cases that Nico talks about where we see people building hundreds of frames across these massive files and, you know, just to drag the canvas, it stutters
But then there's also , the people who, [00:16:00] I use this metaphor of like, a goldfish and you put it in any aquarium, the goldfish will always grow to the size of its aquarium. And you put it in a bigger aquarium, the goldfish will then grow bigger.
And we definitely have users that, that see Figma as a challenge to that effect, right? They'll like figure out ways to use that same functionality to do things that even we hadn't considered. and so we pulled in a few of those users too because no better stress test for a system than someone who's trying to find an escape, they'll push this to whatever limit that we don't know about.
I think there were two people who rebuilt an entire CPU and were able to like compile machine code. I don't, I don't even know how this works. You end up at a point where you build a system and people build stuff on top of this. And we're just sitting in Slack and we're like, how,
It had to be fun watching it all come out because it was almost like a
it's amazing.
Twitter too. Cause like everyone wanted to be the first one to create some kind of a novel pattern. And I remember like thinking, wow, I think someone just built a full keyboard within like 45 minutes of the feature, even being [00:17:00] released.
And it's like, well, what is happening here?
It's the most rewarding thing, to me every time, like people ask is like, how is it designing Figma and Figma? And it's like, it can be really boring because you have to think about so many edge cases and so many functionalities and so many other things that also happen. And then the engineers DM you and it's like, Oh, what, what happens if this case is copied out of version history and paste it into a file that isn't in the same org?
I don't know. That's a constructed use case, but like stuff like this. Happens a lot. And so you focus on all of these tiny, tiny details of what this building block and all the edges of this building blocks looks like, that you don't necessarily see what people can do if they just put those building blocks together.
And then you, take a step back and you're like, oh, wow, you built like an entire. Like life sized Lego sculptures of our building blocks. I know every single building block here. I would have never guessed you would build a life sized Lego figure out of those things. And that is incredibly rewarding [00:18:00] because it feels like you've helped more creativity come to life. And that's cool.
How Figma beta tests new features
Can you talk a little bit more about that beta program? At what point did you start to loop users in and. How are you learning and figuring out whether or not what you're doing is working.
So I think generally at Figma, when working on editor features, it can be like, It's either incredibly easy to run a beta program because it's a feature that changes maybe some of the editing behaviors, right? And then in those cases, you can just turn on a feature flag for a couple of users. You contact them and you gather some feedback from them with something like this.
It's very different because if you think about this, it's a new kind of like behavior and data that users [00:14:00] can create. And since Figma is just so entirely multiplayer, if I'm on the feature flag and you're not. I'm adding things to the document that you have no, not the capability to read,
so we have to be careful and essentially I think add all like an entire organization at once. and so we started with earlier just like usability testing behaviors where we basically just had a set of uh, example cases that we wanted to run users through, but we did end up, kind of like inviting entire organizations, right, Garrett?
Yeah, so we worked, we were closely with product marketing on this one. And I think, as Nico said, each beta for us is a different flavor, depending on the feature set, the scope of it, with one where you're kind of changing some of the underlying foundations or functionality of Figma in such a way like variables, you know, variables go across all files in all states.
And so, , you can't just. Turn that on in a, in a more bespoke way, like in a way that you may have around the layout, a layout, like feature or something that is, that is contained [00:15:00] within a certain sandbox within the editor itself. , so that was something that we struggled with because we had that epiphany of like, oh, okay.
Dang, we can't actually go and like, just turn this on for these three people within this much larger team. And that inherently means that like, okay, we can't, we can't beta test this with really large customers right now. Cause we don't want to bring 400 people in and potentially like disrupt things, especially early stage with some of the, the earlier months where were fairly sure that the features wouldn't corrupt files, but we weren't positive, right?
So we, it really limited us to smaller teams. Which we had, like, we, Figma had, had good working relationships with, or past histories with that we know could recognize the benefits, but also recognize that, like, there are some, some risks to using these things, , or, , Very specific individuals and teams of 1, essentially people who you wouldn't need to be collaborating within their own Figma team.
And I think There's the use cases that Nico talks about where we see people building hundreds of frames across these massive files and, you know, just to drag the canvas, it stutters
But then there's also , the people who, [00:16:00] I use this metaphor of like, a goldfish and you put it in any aquarium, the goldfish will always grow to the size of its aquarium. And you put it in a bigger aquarium, the goldfish will then grow bigger.
And we definitely have users that, that see Figma as a challenge to that effect, right? They'll like figure out ways to use that same functionality to do things that even we hadn't considered. and so we pulled in a few of those users too because no better stress test for a system than someone who's trying to find an escape, they'll push this to whatever limit that we don't know about.
I think there were two people who rebuilt an entire CPU and were able to like compile machine code. I don't, I don't even know how this works. You end up at a point where you build a system and people build stuff on top of this. And we're just sitting in Slack and we're like, how,
It had to be fun watching it all come out because it was almost like a
it's amazing.
Twitter too. Cause like everyone wanted to be the first one to create some kind of a novel pattern. And I remember like thinking, wow, I think someone just built a full keyboard within like 45 minutes of the feature, even being [00:17:00] released.
And it's like, well, what is happening here?
It's the most rewarding thing, to me every time, like people ask is like, how is it designing Figma and Figma? And it's like, it can be really boring because you have to think about so many edge cases and so many functionalities and so many other things that also happen. And then the engineers DM you and it's like, Oh, what, what happens if this case is copied out of version history and paste it into a file that isn't in the same org?
I don't know. That's a constructed use case, but like stuff like this. Happens a lot. And so you focus on all of these tiny, tiny details of what this building block and all the edges of this building blocks looks like, that you don't necessarily see what people can do if they just put those building blocks together.
And then you, take a step back and you're like, oh, wow, you built like an entire. Like life sized Lego sculptures of our building blocks. I know every single building block here. I would have never guessed you would build a life sized Lego figure out of those things. And that is incredibly rewarding [00:18:00] because it feels like you've helped more creativity come to life. And that's cool.
How Figma keeps track of edge cases
Let's talk a little bit more about that actually, because I'm always fascinated to hear from. Product teams, how they keep track of of the edge cases and points of contention between the different features and how they play together. And to me, this is a behemoth of, you know, bucket of edge cases.
There's a million different States that you'd have to keep track of. How do you tackle something like that as a product team?
Garrett, do you know,
Yeah, right. Yeah, we've joked in the past, actually, that we have created a machine that creates nothing but edge cases, right? But we do have good processes. I think both within Figma and within the prototyping team that help with this. And 1 of the things that's honestly most useful , is probably the most simplistic to, which is just bug bashes that we do when we get our features to a certain point, especially these features where, you know, Figma, we, we prototype, but we don't [00:19:00] prototype nearly at the level of some of our customers.
And we can't reliably say, like. To the folks who are prototyping inside Figma. Hey, we've also done this other feature. So stop what you're doing today to go like test this out and find any bugs for us. So, um, our engineering culture and engineering teams are really good about, , essentially putting together files of test cases and problems and user stories and challenges and saying, go and try to do all of these things using this functionality.
And honestly, that's kind of our, you know, one of our main insurance policies, because we always find bugs. We always find weird, idiosyncrasies. Sometimes we discover bugs in other parts of Figma at the same time. But those have been one of our most reliable ways, especially in these tricky times when beta testing is either hard to do or a bad idea or not, you know, not quite right.
How Figma keeps track of edge cases
Let's talk a little bit more about that actually, because I'm always fascinated to hear from. Product teams, how they keep track of of the edge cases and points of contention between the different features and how they play together. And to me, this is a behemoth of, you know, bucket of edge cases.
There's a million different States that you'd have to keep track of. How do you tackle something like that as a product team?
Garrett, do you know,
Yeah, right. Yeah, we've joked in the past, actually, that we have created a machine that creates nothing but edge cases, right? But we do have good processes. I think both within Figma and within the prototyping team that help with this. And 1 of the things that's honestly most useful , is probably the most simplistic to, which is just bug bashes that we do when we get our features to a certain point, especially these features where, you know, Figma, we, we prototype, but we don't [00:19:00] prototype nearly at the level of some of our customers.
And we can't reliably say, like. To the folks who are prototyping inside Figma. Hey, we've also done this other feature. So stop what you're doing today to go like test this out and find any bugs for us. So, um, our engineering culture and engineering teams are really good about, , essentially putting together files of test cases and problems and user stories and challenges and saying, go and try to do all of these things using this functionality.
And honestly, that's kind of our, you know, one of our main insurance policies, because we always find bugs. We always find weird, idiosyncrasies. Sometimes we discover bugs in other parts of Figma at the same time. But those have been one of our most reliable ways, especially in these tricky times when beta testing is either hard to do or a bad idea or not, you know, not quite right.
How Niko collaborates with engineers
And from a designer's perspective, it really is the case where it's like. I do not know all of the edge cases. I do not design all of the edge cases. It's not even a question that like, I'm going to do this. We work so closely with our engineering [00:20:00] partners that, for example, in the way we built the expression builder, I'm designing a couple of states.
I'm designing a little overview, maybe a mini prototype here for a simple flow, but. I think the main work that I do then as a designer is to integrate in this, in this case, it was, it was John, the engineer, integrate them to a point that John cares about the quality of the experience much more than it is for me prescribing every single thing myself. If the engineer you work with cares about the quality of the experience and understands what kind of user flows people might go through, what kind of examples they would build. So many problems I just don't have to design. So it's, in a way, it's a lazy way of like not defining everything, but in a way, it's just a nicer way of working and a more efficient way of working.
and it's fun because it pulls in people on the engineering side who sometimes don't necessarily have that much, exposure to these like [00:21:00] products slash design. Empathy kind of ways of building a product. If they care, it's just going to be so much better.
How Niko collaborates with engineers
And from a designer's perspective, it really is the case where it's like. I do not know all of the edge cases. I do not design all of the edge cases. It's not even a question that like, I'm going to do this. We work so closely with our engineering [00:20:00] partners that, for example, in the way we built the expression builder, I'm designing a couple of states.
I'm designing a little overview, maybe a mini prototype here for a simple flow, but. I think the main work that I do then as a designer is to integrate in this, in this case, it was, it was John, the engineer, integrate them to a point that John cares about the quality of the experience much more than it is for me prescribing every single thing myself. If the engineer you work with cares about the quality of the experience and understands what kind of user flows people might go through, what kind of examples they would build. So many problems I just don't have to design. So it's, in a way, it's a lazy way of like not defining everything, but in a way, it's just a nicer way of working and a more efficient way of working.
and it's fun because it pulls in people on the engineering side who sometimes don't necessarily have that much, exposure to these like [00:21:00] products slash design. Empathy kind of ways of building a product. If they care, it's just going to be so much better.
Designing a powerful expression builder (while keeping it simple)
Let's talk about that expression builder a little bit, because I think a big part of this project is you're kind of teaching designers how to think like engineers which can be a bit daunting for people. So you talk about that part of the design process a little bit more and maybe even more broadly, how you think about striking this balance between and simplicity in the product?
I think the expression builder is an interesting case because the like range of, of, of users needing to be comfortable in the spaces is pretty large, right? You want to be able to have a, the classic saying low floor, high ceiling. . But ultimately you want to be able to, to. allow people to start playing with it that don't [00:22:00] necessarily know how, what you would imagine to fill in here, they need to somehow find a way to do it. An empty text box is, is incredibly daunting. Cause it's like, what the fuck should I write? So that was one thing where it was like, okay, we need to find a way to make it kind of clickable. And that's like one thing where it's like, how do you make a textbox clickable? But then on the other end of the spectrum, right. You have people who are like, Oh, this is an expression builder.
It's basically like a mini code editor. And like, I can just write and I can like use double end end sign to do conditional connections , and, and like the double pipe sign for, or, and they just know this stuff and they just want to type. And so you have these like kind of opposite ends of interacting with this product.
Where it's like, Oh, just by clicking, I need to find out what this works. And just by typing, I need to be able to like complete these things quickly. So that's kind of like what we try to marry together here , we call it the operator drawer I don't know if that name makes total [00:23:00] sense, but it's where the variables pop up, it's where, the opera operators pop up, you can click on them and then it fills it in, and then shows you the next operator.
So you actually can just click together all of your expressions, but we needed to do that in a way that still allows you to type and allows you to smoothly type. And when we talk about typing, it's always like, oh, an input field, like, you know, how hard could it be? And it's like, oh yeah, but you have all these tiny, I don't even want to call them micro interactions. You have these like tiny interactions that are built in and expected in an input field. So the typing case was the case that was much harder in terms of edge cases. It's easy to build a kind of like a click together kind of thing, but it, it actually ended up being really hard to make something where typing feels smooth. And so we needed to do it in a way that like feels. Great for both and doesn't slow down more expert users and allows an [00:24:00] easier entrance, , for more novice users.
Designing a powerful expression builder (while keeping it simple)
Let's talk about that expression builder a little bit, because I think a big part of this project is you're kind of teaching designers how to think like engineers which can be a bit daunting for people. So you talk about that part of the design process a little bit more and maybe even more broadly, how you think about striking this balance between and simplicity in the product?
I think the expression builder is an interesting case because the like range of, of, of users needing to be comfortable in the spaces is pretty large, right? You want to be able to have a, the classic saying low floor, high ceiling. . But ultimately you want to be able to, to. allow people to start playing with it that don't [00:22:00] necessarily know how, what you would imagine to fill in here, they need to somehow find a way to do it. An empty text box is, is incredibly daunting. Cause it's like, what the fuck should I write? So that was one thing where it was like, okay, we need to find a way to make it kind of clickable. And that's like one thing where it's like, how do you make a textbox clickable? But then on the other end of the spectrum, right. You have people who are like, Oh, this is an expression builder.
It's basically like a mini code editor. And like, I can just write and I can like use double end end sign to do conditional connections , and, and like the double pipe sign for, or, and they just know this stuff and they just want to type. And so you have these like kind of opposite ends of interacting with this product.
Where it's like, Oh, just by clicking, I need to find out what this works. And just by typing, I need to be able to like complete these things quickly. So that's kind of like what we try to marry together here , we call it the operator drawer I don't know if that name makes total [00:23:00] sense, but it's where the variables pop up, it's where, the opera operators pop up, you can click on them and then it fills it in, and then shows you the next operator.
So you actually can just click together all of your expressions, but we needed to do that in a way that still allows you to type and allows you to smoothly type. And when we talk about typing, it's always like, oh, an input field, like, you know, how hard could it be? And it's like, oh yeah, but you have all these tiny, I don't even want to call them micro interactions. You have these like tiny interactions that are built in and expected in an input field. So the typing case was the case that was much harder in terms of edge cases. It's easy to build a kind of like a click together kind of thing, but it, it actually ended up being really hard to make something where typing feels smooth. And so we needed to do it in a way that like feels. Great for both and doesn't slow down more expert users and allows an [00:24:00] easier entrance, , for more novice users.
A surprise addition to the project
I think it's probably safe to assume that when you're dealing with a project of this size and this level of complexity, that everything probably didn't go exactly according to plan and probably wasn't like this super linear path to config day. And here's all of our work. So can you talk to us a little bit about a time where you ended up going a direction that you didn't anticipate from the beginning?
We've been talking a lot about advanced prototyping, but the other, , big flagship and temple feature that we were launching at config, was the inline preview, which is a little, , inline viewer that pops up by you still in the editor environment, and I think this is important, . Both like structurally and philosophically about like bringing the prototyping closer to where you're editing it and like offering the space, which says, Hey, it's not just for like packaging up this final product. This is the thing that can happen. While you're editing, you can open it and close it.
It's supposed to be designed to be semi ephemeral, right? It's a quick preview and then to close again. , but the way that we came [00:25:00] about it is actually, , not nearly that does not nearly have that level of foresight to it, which is essentially that another part of the house. The dev mode side, they had actually explored this prototype. They prototyped this little, , inline preview. I think they built it in about a week, as part of like kind of the handoff process.
Like, hey, what if part of, you know, handing off this design was also making it really easy to quickly preview the prototypes? It's a great idea. , and they're like, uh, you know, it's not quite right for our use cases here. We can see how it could work, but it's not, it wasn't the most important thing. And they kind of just, they tucked it to the side of the table.
And then we were sitting over on the other side of the table saying like, are you going to finish that? And so we kind of like, well, you know, what, what if we did the inline preview then if you're not interested in doing it and, It was really interesting because, the way that they built it, , for the prototype ended up actually being the thing that we shipped, , in a large part.
Obviously, we, we did months of improvements and tweaks and, um, changes to make it both, , perform better, but also be, you know, behave more holistically. , that's where most of the polish was, was like, you know, 90 percent prototype, get it functioning. The last 10 percent is actually the 90 percent of just like doing all the things you need to do to [00:26:00] make it work.
It didn't start as one of our tent-pole features, but, it certainly helps, tell a more cohesive story about what we're trying to do with prototyping and Figma, which is it's not just improving the functionality.
It's making prototyping a more deliberate part of the design process. , and well, we didn't arrive there in what might be the right way we did kind of take advantage of the experimentation and exploration that other parts of the company are doing. And honestly, like that. More than anything else in other companies I've worked at, like, that's one of the things that makes Figma, I think, particularly special, which is that you do have this environment that Nico describes where engineers are stakeholders in the success and quality and implementation of a product, but you also have, , a company that really leans into, , turning its experiments into actual features.
And there's a very real energy for doing so in a way that you might not see in other companies where they're, You know, we actively have these maker weeks, which are essentially, you know, make whatever you want within Figma or around Figma within the space. And many of those, , experiments become features here.
So inlinePuby is a good example of [00:27:00] that.
I love maker week as a Twitter observer,
It's
it means that my feed is going to be filled with all of these
so fun.
And, you know, it's interesting to see like what actually sticks and inline previews, like one of my
Yeah.
that you ship. So it's kind of funny to see that, you kind of stumbled into it a little bit.
Yeah, we did. It's, it honestly was really validating for us is like, you know, we turned it on for ourselves that, that week that we decided to pick it up. We all turned it on for ourselves internally. And I think it was like two or three days later, I messaged Nico, we had to turn the flag off for a day cause it broke something and I messaged Nico.
I'm like, I'm so, I'm so pissed right now. I can't use inline preview. This is so annoying that I have to like open a new tab. So we felt it right away.
It's so funny how some of those things are just. They just happen. Like in the preview, like the idea of having an in context preview, we've wanted this for years. And we often like somewhat overthought how we built this, how we design it and everything. And it's like, plop an iframe in there [00:28:00] and show the prototyping view and then that gets you like halfway there and you're like, Oh, wow, this feels so good.
, and that I think was kind of like the point where in a way, that's a little mini story about prototyping. Prototyping. That you get to feel something and you're like, oh, this is actually really valuable. This is worth it.
Garrett,
A surprise addition to the project
I think it's probably safe to assume that when you're dealing with a project of this size and this level of complexity, that everything probably didn't go exactly according to plan and probably wasn't like this super linear path to config day. And here's all of our work. So can you talk to us a little bit about a time where you ended up going a direction that you didn't anticipate from the beginning?
We've been talking a lot about advanced prototyping, but the other, , big flagship and temple feature that we were launching at config, was the inline preview, which is a little, , inline viewer that pops up by you still in the editor environment, and I think this is important, . Both like structurally and philosophically about like bringing the prototyping closer to where you're editing it and like offering the space, which says, Hey, it's not just for like packaging up this final product. This is the thing that can happen. While you're editing, you can open it and close it.
It's supposed to be designed to be semi ephemeral, right? It's a quick preview and then to close again. , but the way that we came [00:25:00] about it is actually, , not nearly that does not nearly have that level of foresight to it, which is essentially that another part of the house. The dev mode side, they had actually explored this prototype. They prototyped this little, , inline preview. I think they built it in about a week, as part of like kind of the handoff process.
Like, hey, what if part of, you know, handing off this design was also making it really easy to quickly preview the prototypes? It's a great idea. , and they're like, uh, you know, it's not quite right for our use cases here. We can see how it could work, but it's not, it wasn't the most important thing. And they kind of just, they tucked it to the side of the table.
And then we were sitting over on the other side of the table saying like, are you going to finish that? And so we kind of like, well, you know, what, what if we did the inline preview then if you're not interested in doing it and, It was really interesting because, the way that they built it, , for the prototype ended up actually being the thing that we shipped, , in a large part.
Obviously, we, we did months of improvements and tweaks and, um, changes to make it both, , perform better, but also be, you know, behave more holistically. , that's where most of the polish was, was like, you know, 90 percent prototype, get it functioning. The last 10 percent is actually the 90 percent of just like doing all the things you need to do to [00:26:00] make it work.
It didn't start as one of our tent-pole features, but, it certainly helps, tell a more cohesive story about what we're trying to do with prototyping and Figma, which is it's not just improving the functionality.
It's making prototyping a more deliberate part of the design process. , and well, we didn't arrive there in what might be the right way we did kind of take advantage of the experimentation and exploration that other parts of the company are doing. And honestly, like that. More than anything else in other companies I've worked at, like, that's one of the things that makes Figma, I think, particularly special, which is that you do have this environment that Nico describes where engineers are stakeholders in the success and quality and implementation of a product, but you also have, , a company that really leans into, , turning its experiments into actual features.
And there's a very real energy for doing so in a way that you might not see in other companies where they're, You know, we actively have these maker weeks, which are essentially, you know, make whatever you want within Figma or around Figma within the space. And many of those, , experiments become features here.
So inlinePuby is a good example of [00:27:00] that.
I love maker week as a Twitter observer,
It's
it means that my feed is going to be filled with all of these
so fun.
And, you know, it's interesting to see like what actually sticks and inline previews, like one of my
Yeah.
that you ship. So it's kind of funny to see that, you kind of stumbled into it a little bit.
Yeah, we did. It's, it honestly was really validating for us is like, you know, we turned it on for ourselves that, that week that we decided to pick it up. We all turned it on for ourselves internally. And I think it was like two or three days later, I messaged Nico, we had to turn the flag off for a day cause it broke something and I messaged Nico.
I'm like, I'm so, I'm so pissed right now. I can't use inline preview. This is so annoying that I have to like open a new tab. So we felt it right away.
It's so funny how some of those things are just. They just happen. Like in the preview, like the idea of having an in context preview, we've wanted this for years. And we often like somewhat overthought how we built this, how we design it and everything. And it's like, plop an iframe in there [00:28:00] and show the prototyping view and then that gets you like halfway there and you're like, Oh, wow, this feels so good.
, and that I think was kind of like the point where in a way, that's a little mini story about prototyping. Prototyping. That you get to feel something and you're like, oh, this is actually really valuable. This is worth it.
Garrett,
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
hello@dive.club
Ⓒ Dive 2024