https://www.alicepackarddesign.com/blog/base-components-are-still-useful-just-not-in-your-ui-library [5cc4b2dddca801978]BlogNewsletterTip jar [?] Base components are still useful, just not in your UI library Alice published this on October 3, 2022 Updated on Read time: 15 minutes 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): * 2 different sizes (as padding values, handled by a [?] base) * 2 icons on either side of the label (space between the label and icons, handled by a [?] base) * 2 text resizing settings (hug and fill, handled by a [?] base) * 2 different border radii options (handled by a [?] base) * 4 different states of interactivity * enabled VS disabled * 2 different functions (standard and destructive) All in the name of making managing the * button easier, or so I thought... Teaching other designers this convoluted system of base components that underpinned the * button was really tough and it never really stuck. This meant I was the only person who could confidently debug the * button 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: I'm starting to believe we're thinking about .base components the wrong way... They're extremely powerful but only when used correctly. So here are 5 principles for using .base components the right way pic.twitter.com/HjYKEy7nOX -- Ridd (@Ridderingand) March 6, 2022 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: Sorry, let me clarify Base components by nature are to protect us from significant change in the future e.g. massive brand refresh The likelihood is that these significant events happen so infrequently that our base components are really not required - complexity over usage -- luis. (@disco_lu) March 11, 2022 One change I've made when it comes to building components in @figmadesign has been to not rely on base components as often, especially when working with Variants. Adding *only* the relevant layers means less complexity & less probability of a variant option/layer mismatch. pic.twitter.com/yZ5brRJm53 -- Joey Banks (@joeyabanks) January 12, 2022 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." [?] Base components, defined 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. Why the "[?]" glyph for bases? 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." Best practices for building useful [?] base components [?] 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: * Use the component's name to specify what elements it's responsible for: [?] card padding, [?] list direction horizontal , [?] article metadata. * If you find yourself nesting many [?] bases within [?] bases, remember to make annotations on the canvas to help keep things straight. This can be as simple as arrows stemming from smaller [?] base components pointing toward larger [?] components that use instances of the small ones, text layers with notes, or whatever you find most helpful. Mistakes to avoid when building [?] base components 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! Pairing with other types of components [?] Bases + * Interface representative 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: 1. Iterating on an existing * interface rep from your library. You grab some instances of * interface reps. from your library and extract some of their internal frames and make them into a local [?] base component to experiment with. You could detach the first * interface rep and insert these new [?] bases to explore ideas. 2. Designing a new * interface rep for your library. You can start completely from scratch! Start componentizing the smallest pieces, building them up, until you have a series of [?] bases that get you to the * interface rep you had in mind. Now you can explore all sorts of visual designs for that * interface rep by adjusting your [?] bases. 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 [?] CTA base. And there's no reason to not do that as soon as possible! Like, the moment you have that fully-formed [?] CTA , set it up in those context screens first and then start shaping up the design. As you tweak all the [?] bases that form the [?] CTA 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. Read everything you need to know about * interface reps [?] Bases + [?] Placeholders 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: 1. Create or grab and instance of a placeholder. 2. Wrap it in an auto layout frame (shortcut: [?] (command)+ A). 3. Adjust the placeholder's resizing settings appropriately in anticipation of the components you'll be swapping in. 4. Turn the frame into a [?] base and boom. You've got a [?] base component to control padding. Consider naming it something like [?] padding. [633b8b7f15] Demonstrating making padding and corner radius adjustments on a [?][?][?][?]base component I also use this same method whenever I need to make * card 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: [?] Bases + Content carriers 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: * when someone follows you * when someone likes your tweet or reply * when someone replies to your tweet or reply * when someone retweets or quote-retweets your tweet or reply 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 [?] Notification base, and it's job is tom hold space for tweet content. That [?] placeholder will get swapped out for various content carriers named Tweet content / 1, Tweet content / 2, and Tweet content / 3. Working with realistic content will help us evaluate the design of the [?] Notification base. Check out some examples of what this exploration might look like: [633b8c82dd] Changing the styles of base components that are responsible for how profile pictures look. [633b8df3d8] Adding a stylized frame around a placeholder component in a base. [?] Bases + [?] Starter kits 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. [?] Bases + [?] Annotations 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. [?] Bases + [?] Switchboards 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 * global navigation 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! Main takeaways 1. [?] Base components job is to speed up a designer's workflow exploring new concepts, not as underlying architecture to the * interface reps in your UI library. 2. [?] Bases tend to be complex, which means they're better suited for solo work as opposed to collaborative work. If you are working with other designers and need to use [?] base components, make sure everyone understands how the [?] bases are set up so they can also too can reap the benefits. Otherwise the [?] bases will have the opposite affect. 3. [?] Bases pair especially well with placeholder components for the flexibility they afford, followed by content carriers for the speed-boost they can provide. Interested in more? 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. Right now I'm averaging 1 post every ~3 months (and trying to pick up my pace). First name[ ] Email address *[ ] [Subscribe] My newsletter is 100% spam-free! Nothing but respect for your inbox and you can unsubscribe any time. Thanks for signing up! Check your inbox for an email about confirming your subscription Shoot, I'm sorry. Something went wrong while processing your submission. Not your fault, the problem is on my end. In the mean time you can send me an email or DM me on twitter and I'll get you sorted out. [639154bc427fa1249bb26eb8_Screen] FREE Variants VS. Separate components VS. Component properties flow chart This resource distills the recommendations in this blog post into a fast and easy to use flow chart so you can follow best practices for using these features, and make swift and strong decisions when faced with multiple options. Email address[ ] [Get download link] Thanks for signing up! Check your inbox for an email about confirming your subscription Shoot, I'm sorry. Something went wrong while processing your submission. Not your fault, the problem is on my end. In the mean time you can send me an email or DM me on twitter and I'll get you sorted out. When you subscribe you'll get notified when I publish new blog posts. My newsletter is 100% spam free. Nothing but respect for your inbox and you can unsubscribe any time. [6341ff90e2412d5c91bfa541_Frame] FREE Component Quality Assurance Checklist Get the 12-point checklist to evaluate your own components right inside of Figma! Modify the list and add your own criteria to suit yours and your team's needs. Email address[ ] [Get download link] Thanks for signing up! Check your inbox for an email about confirming your subscription Shoot, I'm sorry. Something went wrong while processing your submission. Not your fault, the problem is on my end. In the mean time you can send me an email or DM me on twitter and I'll get you sorted out. When you subscribe you'll get notified when I publish new blog posts. My newsletter is 100% spam free. Nothing but respect for your inbox and you can unsubscribe any time. (c) Alice Packard, 2019 to Proudly built in Webflow Let's connect TwitterLinkedInInstagramContact Figma Community Forum Content BlogBlog RSSNewsletterYouTube Support my work Tip jar