When ⍚ base components became A Thing, folks were first using them in the context of their component libraries. This type of component was massively attractive to anyone who was building and maintaining a library because ⍚ bases allowed them to systematize things like padding values. Base components really seemed like the holy grail. You could effectively use components to create faux design tokens!
The very first time I used base components I sort of unknowingly stumbled into them with my colleague Jay Miles while we were building a massive open-world style prototype using a very basic UI kit (rather than our existing component library) to test a concept totally new product the company was exploring. This meant we were working with some other designer's components, and because the kit wasn't for any specific type of product, the components consisted entirely of atoms and molecules.
As we began needing to build larger and more complex ◈ interface reps, we got this idea to componentize really big chunks of them so we could manage and iterate on them more easily. The chunks on their own didn't make a lot of sense, but they helped us manage composition of larger components in more manageable bites.
Looking back, turns out this context was actually the perfect environment for ⍚ base components! For exploring different concepts before we settled on a design.
But Jay and I, like so many other designers who were also discovering ⍚ bases for the first time, took this idea (⍚ base components) and said "this will be so helpful in our component library." That's where we unknowingly took a wrong turn. That's not the say our re-factored library components that used ⍚ bases wasn't successful, it was! But the components we made were really expensive in two different ways. First, in layer count, which meant Figma's performance took a hit. Browser memory maxes out at 2GB, so our juiced up macbook specs don't come into play much when we were loading up Figma files with tons and tons of information in the form of layers. Second, the components were expensive in risk. The most gargantuan button I devised required 13 layers from a series of about 4 nested ⍚ base components, and the final component had 250+ instances to make the following 16 properties possible (8 of which were established by the ⍚ bases):
All in the name of making managing the <span class="figma-component">◈ button</span> easier, or so I thought... Teaching other designers this convoluted system of base components that underpinned the <span class="figma-component">◈ button</span> was really tough and it never really stuck. This meant I was the only person who could confidently debug the <span class="figma-component">◈ button</span> if something ever went wrong. Having that knowledge and skill locked up inside a single teammate's head isn't good for the health of a design system! And even if I had been successful in passing on that knowledge to my teammates, the teaching takes a lot of time, and the de-bugging of an ◈ interface rep that's made up of many ⍚ bases takes a lot of time. Sort of ironic, actually... ⍚ bases were so exciting because they seemed to be huge time savers and risk reducers, but they actually were quite costly in both those areas!
As I reflect on this experience, I'm hearing it rhyme with that famous line from Jurassic Park...
your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should...
But instead of resurrecting dinosaurs we were exploiting Figma's component swapping functionality to create faux design tokens. That's not to say ⍚ base components shouldn't be used though! I guess this is where this isn't quite like Jurassic Park... ⍚ bases aren't going to spit poison in your face or eat your jeep. They still have loads of utility and can offer loads of bene when you introduce them to your workflow, just so long as that work isn't component library work. And I can't take credit for this advice: I owe this idea to Ridd, creator of Figma Academy and Dive Club, for his thread from March 2022 for first planting this seed in my head:
And he wasn't alone! It was around this same time that I was seeing other folks beginning to share the same sentiment, that ⍚ base components were more trouble than they were worth:
I was a huge believer in ⍚ bases for component libraries, so these were hard pills to swallow. And seeing these tweets coming from Joey and Luis was a big deal—these guys worked at Figma. Their expertise goes deep. What I appreciated about Ridd's thread was that he wasn't saying designers should quit ⍚ base components entirely, but instead asking folks to switch up the context. The advice doesn't stop at "don't use ⍚ base components", there's another clause there: "... in your library files... Instead, try them in your local files to explore new designs."
A ⍚ base component allows you to natively systematize more visual properties beyond color and typography styles. This includes almost most every "knob" that's available to turn in the design panel, including: padding values, corner radii, combinations of multiple styles applied to many objects, auto layout direction, resizing rules, clipping contents, rotation, and blending modes and opacity. Because of this, ⍚ base components are extremely well suited for enhancing an individual designer's exploratory workflow.
I believe pairing a visual symbol with a title helps me remember the definition. Figma does this with ❖ and ◇; you see those glyphs and you know exactly what they mean, without labels! I want to do the same for these types of components.
Similar to the explanation I gave for ◈ interface reps, I think having a diamond shape for what's already a familiar component type is fitting. The little horizontal line beneath the diamond in ⍚ does a great job of symbolizing a "base", or "foundation."
⭐️ Use ⍚ bases for experimenting and iterating outside of a library file. If you've got a mind for systems, they may help trigger your creative flow-state and stay in it longer because you can act on ideas faster and more efficiently.
⭐️ Use them when you're working solo. Even if you're on a team and often collaborate with other designers, there's bound to be files (or pages within files) that are really your space. This means you can focus much less attention on component usability because you are the user! You're naturally going to build ⍚ bases in a way that clicks with your own mind.
⭐️ That ☝️ being said, it still pays to be organized. Be specific about each ⍚ base's the job. This will help you know where to turn certain "knobs." Sometimes a ⍚ base's job is more about making sure all the right pieces of content or data can be represented, other times the job is more about exploring the visual design or animation. There's a few points to this:
❌ Using ⍚ base components in your component library. Please don't do this. Remember, they're a powerful workflow buff for exploring ideas, but they come at the cost of layer count and with that comes added complexity. They're a huge help in an individual's local design file, but tend to cause expensive messes in libraries.
❌ Relying on ⍚ bases when collaborating with other designers. The reasons to not do this are similar to the first pitfall about using them in component libraries: ⍚ bases are often complex and expensive. That's not to say you can't mitigate that with good annotation notes on the canvas and layer naming, but because ⍚ bases primary benefit is to help you stay in that creative flow, having to stop and explain your ⍚ bases defeats their purpose. If you're jamming with other designers, at least commit to building ⍚ bases together, annotate and name them well, and rely on them as little as possible.
❌ Confusing a ⍚ base for a ✎ content carrier component. These seem similar because both ⍚ bases and ✎ content carriers share a characteristic where they exploit components to do create capabilities that Figma doesn't offer natively: design tokens and content management. These are different jobs for a reason! Be intentional, be specific.
❌ Not being mindful of what's an instance and what's a main component when adjusting your ⍚ bases! This tends to only come up when you're nesting ⍚ bases inside other ⍚ bases. It's very easy to make overrides to a nested instance of a ⍚ base within a main ⍚ base by mistake. It's not the end of the world, because remember, you're just experimenting in a local file. So while this can make it hard to debug your components later, you might not ever get to the "debug" or "clean up" stage to begin with! Remember, ⍚ base components are all about exploring ideas, not making the most usable components ever!
Quick definition recap:
An ◈ interface rep takes the visual design language of a product's brand and apply it to functional parts of a product, be it a website, mobile app, or software. The name is (purposefully) obvious: these things represent pieces of interface. They're what designers pull out of Figma's asset panel to compose mockups and string together prototypes. They're the "design expression" of what gets referenced by engineers who go on to craft the "code expression" (the real-life components) that get pushed to production.
◈ interface reps are great to use for grabbing chunks you want to use for a ⍚ base local files when you're exploring or experimenting with. These could be existing ◈ interface reps that you're iterating on, or completely new ones! There's a couple ways this pairing may manifest:
This might not apply to everyone in every scenario, but I think a really powerful thing the ⍚ base + ◈ interface rep pairing offers is the ability to very quickly evaluate new design ideas in context. If you're responsible for re-imagining a call-to-action (CTA) that encourages folks to exchange their email address for a free e-book, you'll want to see that CTA in context to make sure your design compliments other elements that will exist around that CTA. You can use instances of ◈ interface reps to set up those contexts (AKA screens, or mockups), and then drop in instances of the fully-formed <span class="figma-component">⍚ CTA</span> base.
And there's no reason to not do that as soon as possible! Like, the moment you have that fully-formed <span class="figma-component">⍚ CTA</span>, set it up in those context screens first and then start shaping up the design. As you tweak all the ⍚ bases that form the <span class="figma-component">⍚ CTA</span> you can bounce over to those screens to evaluate and know what needs to change. E.g. an increase in padding adjustment might've looked good on the canvas, but seeing it in the context of a screen it might taking up too much space relative to other content.
<a href="https://www.alicepackarddesign.com/blog/interface-representatives-are-the-center-of-the-figma-component-universe" class="button secondary" style="padding:16px,0px; margin:auto;">Read everything you need to know about ◈ interface reps</a>
Quick definition recap:
✂︎ Placeholders are often very simple components, sometimes just a single frame with a funky fill-color that's _not_ part of your design system ... their job is to be swapped out with another component.
⍚ Bases and ✂ Placeholders are the best of friends. They're on the same level of "goes together" as chocolate and peanut-butter. This pairing is especially useful if you're interested in setting up ⍚ bases to control things like padding, corner radius, and space between nested elements. Making a ⍚ base that uses a ✂ placeholder is simple:
I also use this same method whenever I need to make <span class="figma-component">◈ card</span> components, because cards can have highly variable content. No telling what might need to get placed in a card! This is a great segue into the next pairing:
Quick definition recap:
✎ Content carriers are concerned with the component holds: the type of content, how much content, how that content behaves (e.g. does it break lines or not), and what it looks like (e.g. what type and color styles, what image cropping rules, etc.).
⍚ Bases are all about saving designers time while exploring visual design, and similarly a big benefit ✎ content carriers provide is saving designers time by not having to make the same text overrides again and again. Remember earlier how I described setting up context screens to test the design of your ⍚ bases using ◈ interface reps? That's a good way to evaluate the visual design in different spaces, and ✎ content carriers help you evaluate your design with varying amounts or types of content.
Let's say you're re-designing twitter's notification panel. There's only so many types of things twitter will notify folks about:
Just 4 things! But if you only test your design with 4 content scenarios, you're not designing for reality. 1 person can reply to your tweet, but so can 1,000. What do those different notifications look like? And then there's the content of the tweet or reply that someone is "liking", "replying" to, or "retweeting." How does a like-notification on a tweet with only a video look different from a tweet with just text?
While it may take some time to set up enough ✎ content carriers to test out a sufficient (or at least realistic) set of scenarios for your ⍚ bases, it's less time than what you'd otherwise spend doing the alternative: manually overriding instances of your ⍚ bases every single time. And again, we're using base components to speed up exploration. If our goal is to be able to work fast enough to keep up with our ideas, then the ✎ content carriers that support your ⍚ bases should facilitate this too!
In the scenario where we're re-designing twitter notifications, we'll have a ✂︎ placeholder in the <span class="figma-component">⍚ Notification</span> base, and it's job is tom hold space for tweet content. That ✂︎ placeholder will get swapped out for various ✎ content carriers named <span class="figma-component">✎ Tweet content / 1</span>, <span class="figma-component">✎ Tweet content / 2</span>, and <span class="figma-component">✎ Tweet content / 3</span>. Working with realistic content will help us evaluate the design of the <span class="figma-component">⍚ Notification</span> base. Check out some examples of what this exploration might look like:
Quick definition recap:
⍂ Stater kits are meant to be detached from their main component. They are simply collections of instances of ◈ interface reps, that get used together often. The time-saving aspect is in not having to drag in dozens of tiny individual components from the asset panel, one by one.
Because ⍂ starter kits likely live in a UI library file and ⍚ bases are used for iterating on ideas in your local files, they're sort of not compatible in a sense. However, that doesn't mean ⍂ starter kits contents aren't useful! Remember, the defining feature of a ⍂ starter kit is that it's a vessel you detach and remove to reveal a curated assembly of ◈ interface reps. So after the "packaging" of the ⍂ starter kit is done away with, this pairing would actually wind up looking exactly like how you'd use ⍚ bases and ◈ interface reps.
Quick definition recap:
These components are for internal use only. They're not part of the product that designers are building. ✍︎ Annotations exist to help organize and make sense of Figma files. Unlike the other components, ✍︎ Annotations are only concerned with file hygiene. The only way they interact with other components, for example ◈ interface reps, is to make information about that ◈ interface rep more discoverable to anyone who might be exploring the Figma file.
Mentioned earlier in the ⭐️ Best Practices section, ⍚ bases + ✍︎ annotations are a good pair just to keep organized. That's sort of ✍︎ annotation components' whole deal really! To provide context to objects on the canvas.
When it comes to annotating your ⍚ bases, I find arrows especially helpful. Having an arrow that begins from a smaller ⍚ base and points toward a larger ⍚ base that the smaller one is nested in reminds me what "knobs" I've componentized, and guides me to where I should adjust things. You might remember the last ❌ Pitfall mentioned: it's keeps things clean when you stick to making adjustments on your main ⍚ base components rather than override instances of them within larger ⍚ bases.
Quick definition recap:
The same way we wouldn't not componentize a piece of interface we're using in more than one place, why would we draw the same kind of prototyping noodle more than one? That's what ⎌ Switchboards are for. They're particularly handy for larger prototypes that need to offer an "open world" or free-roaming experience (as opposed to following a scripted pre-defined path of clicks).
Feeding a fed horse here, but I think it's worth repeating: the reason ⍚ base components are useful is because they help us rapidly iterate on ideas. If you need to interact with your new ideas and not just look at them as static mockups, then yeah, bring some ⎌ switchboards to the party!
The best example would be a <span class="figma-component">◈ global navigation</span> component. Let's say you've got one in your library but you want to give it a glow-up, so you start a new local file and start making ⍚ bases to build it up. There's no reason that final ⍚ base component couldn't also double as a ⎌ switchboard! You could set up some screens, throw the ⎌ switchboard in, and you're ready to test!
If you'd like to be notified of when I publish a new blog post, joining my newsletter is a great way to keep up. Readers get extra insight behind every post.
