Design Tactics #8 — 4 strategies for component properties
How to get the most out of Figma's new feature
👀 Where I'm at with component properties
I’m grateful to work in an industry where sometimes it feels like it’s hard to keep up :)
Not kidding…I’ve easily been asked 100+ times how Config has changed the way I approach building in Figma.
Over the last couple of weeks I’ve been tinkering and writing, so here are four thoughts on component properties 👇
—
1 — I’m not rushing to refactor everything
If I’m being honest, the current state of component properties feels a bit incomplete. Certain improvements feel inevitable—the biggest of which is variant swapping.
Until variant swapping is available, I’m going to use component properties somewhat sparingly (mostly focusing on booleans) and not fully refactor my systems around them.
I recently wrote a thread that goes into detail on how variant swapping can work and why it’s a necessary improvement 👇
If you decide to go all-in on a system refactor in its current state, you’re almost certainly going to have to take things that were in variants and turn them into separate components. Personally, I’m not ready to make that jump.
I’m also excited about the potential for other quality of life improvements like image swapping and better organization within the design panel🤞.
2 — Boolean properties increase the need for great documentation
By now you’ve probably seen a few of these before/after screenshots like the one below:
Pretty cool, right?
There’s a big “but” though…
In the example above, you’re losing the high-level picture of all the possible states this button can take. Not only that, we lose a ton of control over how our states can be combined in the design panel. So I would argue that this might actually be more confusing for the rest of your team.
Now I’m not saying “don’t use component properties”. Quite the opposite actually…
I’ve consistently questioned whether variant matrixes were the best way to communicate every potential state to developers. So I think it’s a good thing that component properties eliminate our reliance on variants.
But that means it’s now up to us to discover better ways of communicating all the potential forms our components can take.
Maybe that looks like assembling decks of example instances, explaining how the different component properties interact with each other, or explicitly defining ways components shouldn’t be used.
On one hand, component properties make our lives easier…
But on the other, they do add a bit of new work to our plate. Because now it’s our responsibility to guide designers/engineers to ensure our components are being used correctly.
As a whole, this all feels like a massive step in the right direction though. And I’m really excited to see how it pushes designers to communicate more effectively moving forward.
3 — Exposing nested components at the parent level is a BIG deal
If you’ve been following me for a while or enrolled in Figma Academy, you know that I am a huge fan of nested components and all that they unlock.
Up until Config, the only valid reason for avoiding them was that they weren’t intuitive because you couldn’t immediately see which nested instances lived inside of the main component. Well not anymore…
Now we can add an instance swap at the parent level. That means when someone clicks on a component they can immediately see which subcomponents are interchangeable.
This unlocks the full potential of atomic design.
But by far my favorite application is how it affects “Slot” components 👇
If you want to go even deeper into component properties + slot components, Miggi also just released a pretty awesome 10 min video on the topic.
4 — Component properties make .base components less valuable
I was already scaling back my usage of .base components in design systems before Config. So honestly I haven’t really changed my opinion all that much now that component properties are a thing.
And as a whole, my last deep dive still holds true 👇
It comes down to this…
If you’re using .base components to address large variant matrixes, then component properties definitely reduce that need (largely through the use of booleans).
But if you’re using .base components to address complex layer lists and make it easier to explore new UI using interactive components, then component properties don’t change all that much.
👆 I’m very much so in the latter camp and will continue to use .base components when it makes sense to do so.
💪 Speaking of preserving your overrides...
I recently created a step-by-step walkthrough to make sure you never deal with broken overrides while using interactive components 👇
💥 Some random goodness
☞ I’m close to officially launching my Youtube channel and recently finalized my new logo animation 👀
☞ A super exciting job opportunity to work at Major League Baseball just popped up on the job board.
☞ I recently read two share-worthy articles:
Design systems are flawed >> Talks about how we typically approach design systems like architecture when it really should be about gardening.
Disregard the words >> As designers of new technology, we tend to get caught up in maintaining shared vocabulary. But oftentimes, the most transformative products are the most difficult to describe.
☞ Lastly, here’s a meta example of how I use .base components to power the Figma Academy curriculum system 👇
How I use .base components in the Figma Academy curriculum system
7 rocket ship companies I'd love to join 👇
And if you’re going to apply… try using this tip 😉
👋 Get to know me a bit better
There’s a part of me that wants to be more than just a Twitter avatar :) So I recently joined a few podcasts to give a little glimpse into who I really am👇
Episode #1: The Design MBA podcast
In this episode, we go deep into my journey as a creator and all of the things that led to me releasing Figma Academy.
Episode #2: Make Lemonade podcast
In this episode, I pull back the curtain to give people a sneak peek into my day-to-day business as well as a glimpse of what’s coming next.
Episode #3: The Product Design podcast
In this episode, we talk about my journey as a designer, how I think about improving my skills, as well as how I approach design education as a whole.
P.s. I’m working on something big behind the scenes. Like… really big 😉
P.s.s. What’s one way I can improve this email? I read and respond to every reply ❤️