Jan 25, 2024
The three big Figma regrets
What are we doing in Figma today that we’ll regret 6 months from now?
I got to jam with Molly Hellmuth on this idea recently…
If you zoom out it’s pretty clear that history repeats itself.
And I think it’s happening again 👇
😣 The 3 Figma regrets
When Figma released variants in 2020 it immediately became 10x easier to make components and swap between them.
So we made all the variants—literally every single possible combination 🤯
The larger the variant sets, the more painful they were to update, which led us to regret #1 👇
Regret #1 — .base components (~2021)
.base components were our solution to updating massive variant matrixes.
The mistake is that we created a strategy to fix a half-baked feature.
Little did we know that two massive updates were dropping the next year:
Almost overnight, .base components became irrelevant…
And if you adopted this tactic you might still have night terrors about undoing all of the nested components (and I know multiple companies still stuck in this world) 😱
But the cycle repeated itself 👇
Regret #2 — super components (~2022-2023)
The release of component properties allowed us to remove redundant variants by putting certain configurations in the layers panel.
So naturally designers flipped out and assigned booleans to everything...
Yet again we prioritized the component creation process above the component consumption experience which led to situations like this 👇
Fast forward a year later and we’re starting to realize that maybe this isn’t the best strategy for a few reasons 👇
Less discoverability (can’t search for exactly what you want)
More clicks (designers are constantly using drop-downs and toggling between states)
Worse visibility (hard to see what states are available)
Now the pendulum has swung to the point where the Figma gurus are separating button types into standalone main components.
So the question is… what’s the next thing we’re going to regret?
Regret #3 — going too far with variables (2024?)
Hopefully, by now you see a trend emerging 👀
To make it clear, I love variables in UI Kits and they are super powerful for prototyping...
But I think we’re going too far with variables in our layouts.
“Ya but have you used them in responsive design yet?? Now I only need one component!”
Indeed my Figma friend, indeed…
But there are two reasons why I think we’re going to regret using variables like this:
Less visibility (key design decisions are buried in the local variables menu)
More redundant (handoff requires a visual representation for each state)
Variables are great at automating updates across breakpoints—it’s MAGIC to drag UI into a new frame and see it respond.
But if I’m sharing a file with developers I need each breakpoint to be defined visually anyway (something like this)👇
So that magic starts to feel like extra work for me and friction for my engineers 😬
Key takeaway
When you’re experimenting with new features and creating components in Figma ask yourself these questions:
What would it be like for a designer with way less context to use this component?
What would it be like for a developer hopping into my file to build this component?
If you make that a practice then I feel confident you’ll avoid the next regret 😇
🎨 Mastering the latest Figma features
When I think of Figma power users who inspire me, Molly Hellmuth is right at the top.
She has one of my favorite newsletters (Friday Five) and she's taught hundreds of students in her Design System Bootcamp.
So this episode gets into the nerdier side of the Figmaverse 🤓
When it does and doesn’t make sense to adopt variables
Molly’s favorite Figma plugins for design systems
How she’s building components differently in V8 of her UI Prep design system
How she positions herself as a design systems consultant
+ a lot more
Listen on YouTube, Spotify, Apple, or wherever you get your podcasts 👇
What are we doing in Figma today that we’ll regret 6 months from now?
I got to jam with Molly Hellmuth on this idea recently…
If you zoom out it’s pretty clear that history repeats itself.
And I think it’s happening again 👇
😣 The 3 Figma regrets
When Figma released variants in 2020 it immediately became 10x easier to make components and swap between them.
So we made all the variants—literally every single possible combination 🤯
The larger the variant sets, the more painful they were to update, which led us to regret #1 👇
Regret #1 — .base components (~2021)
.base components were our solution to updating massive variant matrixes.
The mistake is that we created a strategy to fix a half-baked feature.
Little did we know that two massive updates were dropping the next year:
Almost overnight, .base components became irrelevant…
And if you adopted this tactic you might still have night terrors about undoing all of the nested components (and I know multiple companies still stuck in this world) 😱
But the cycle repeated itself 👇
Regret #2 — super components (~2022-2023)
The release of component properties allowed us to remove redundant variants by putting certain configurations in the layers panel.
So naturally designers flipped out and assigned booleans to everything...
Yet again we prioritized the component creation process above the component consumption experience which led to situations like this 👇
Fast forward a year later and we’re starting to realize that maybe this isn’t the best strategy for a few reasons 👇
Less discoverability (can’t search for exactly what you want)
More clicks (designers are constantly using drop-downs and toggling between states)
Worse visibility (hard to see what states are available)
Now the pendulum has swung to the point where the Figma gurus are separating button types into standalone main components.
So the question is… what’s the next thing we’re going to regret?
Regret #3 — going too far with variables (2024?)
Hopefully, by now you see a trend emerging 👀
To make it clear, I love variables in UI Kits and they are super powerful for prototyping...
But I think we’re going too far with variables in our layouts.
“Ya but have you used them in responsive design yet?? Now I only need one component!”
Indeed my Figma friend, indeed…
But there are two reasons why I think we’re going to regret using variables like this:
Less visibility (key design decisions are buried in the local variables menu)
More redundant (handoff requires a visual representation for each state)
Variables are great at automating updates across breakpoints—it’s MAGIC to drag UI into a new frame and see it respond.
But if I’m sharing a file with developers I need each breakpoint to be defined visually anyway (something like this)👇
So that magic starts to feel like extra work for me and friction for my engineers 😬
Key takeaway
When you’re experimenting with new features and creating components in Figma ask yourself these questions:
What would it be like for a designer with way less context to use this component?
What would it be like for a developer hopping into my file to build this component?
If you make that a practice then I feel confident you’ll avoid the next regret 😇
🎨 Mastering the latest Figma features
When I think of Figma power users who inspire me, Molly Hellmuth is right at the top.
She has one of my favorite newsletters (Friday Five) and she's taught hundreds of students in her Design System Bootcamp.
So this episode gets into the nerdier side of the Figmaverse 🤓
When it does and doesn’t make sense to adopt variables
Molly’s favorite Figma plugins for design systems
How she’s building components differently in V8 of her UI Prep design system
How she positions herself as a design systems consultant
+ a lot more
Listen on YouTube, Spotify, Apple, or wherever you get your podcasts 👇
What are we doing in Figma today that we’ll regret 6 months from now?
I got to jam with Molly Hellmuth on this idea recently…
If you zoom out it’s pretty clear that history repeats itself.
And I think it’s happening again 👇
😣 The 3 Figma regrets
When Figma released variants in 2020 it immediately became 10x easier to make components and swap between them.
So we made all the variants—literally every single possible combination 🤯
The larger the variant sets, the more painful they were to update, which led us to regret #1 👇
Regret #1 — .base components (~2021)
.base components were our solution to updating massive variant matrixes.
The mistake is that we created a strategy to fix a half-baked feature.
Little did we know that two massive updates were dropping the next year:
Almost overnight, .base components became irrelevant…
And if you adopted this tactic you might still have night terrors about undoing all of the nested components (and I know multiple companies still stuck in this world) 😱
But the cycle repeated itself 👇
Regret #2 — super components (~2022-2023)
The release of component properties allowed us to remove redundant variants by putting certain configurations in the layers panel.
So naturally designers flipped out and assigned booleans to everything...
Yet again we prioritized the component creation process above the component consumption experience which led to situations like this 👇
Fast forward a year later and we’re starting to realize that maybe this isn’t the best strategy for a few reasons 👇
Less discoverability (can’t search for exactly what you want)
More clicks (designers are constantly using drop-downs and toggling between states)
Worse visibility (hard to see what states are available)
Now the pendulum has swung to the point where the Figma gurus are separating button types into standalone main components.
So the question is… what’s the next thing we’re going to regret?
Regret #3 — going too far with variables (2024?)
Hopefully, by now you see a trend emerging 👀
To make it clear, I love variables in UI Kits and they are super powerful for prototyping...
But I think we’re going too far with variables in our layouts.
“Ya but have you used them in responsive design yet?? Now I only need one component!”
Indeed my Figma friend, indeed…
But there are two reasons why I think we’re going to regret using variables like this:
Less visibility (key design decisions are buried in the local variables menu)
More redundant (handoff requires a visual representation for each state)
Variables are great at automating updates across breakpoints—it’s MAGIC to drag UI into a new frame and see it respond.
But if I’m sharing a file with developers I need each breakpoint to be defined visually anyway (something like this)👇
So that magic starts to feel like extra work for me and friction for my engineers 😬
Key takeaway
When you’re experimenting with new features and creating components in Figma ask yourself these questions:
What would it be like for a designer with way less context to use this component?
What would it be like for a developer hopping into my file to build this component?
If you make that a practice then I feel confident you’ll avoid the next regret 😇
🎨 Mastering the latest Figma features
When I think of Figma power users who inspire me, Molly Hellmuth is right at the top.
She has one of my favorite newsletters (Friday Five) and she's taught hundreds of students in her Design System Bootcamp.
So this episode gets into the nerdier side of the Figmaverse 🤓
When it does and doesn’t make sense to adopt variables
Molly’s favorite Figma plugins for design systems
How she’s building components differently in V8 of her UI Prep design system
How she positions herself as a design systems consultant
+ a lot more
Listen on YouTube, Spotify, Apple, or wherever you get your podcasts 👇
Go deeper…
Join 10,000+ designers
Get our weekly breakdowns
"Dive is the single most important factor in my growth"
@grannellmat
Join 10,000+ designers
Get our weekly breakdowns
"Dive is the single most important factor in my growth"
@grannellmat
Join 10,000+ designers
Get our weekly breakdowns
"Dive is the single most important factor in my growth"
@grannellmat
hello@dive.club
Ⓒ Dive 2024
hello@dive.club
Ⓒ Dive 2024