Whether you're building and using them for yourself, for your teammates, or publishing them for the wider world to use, every component you make is a tiny product in and of itself. And good designers are concerned with producing products that offer the best possible experience for the people using them. But how do we ensure we're delivering on good UX? We can turn to Patrick Thornton's post about the 5 areas of UX, and use those areas to evaluate the UX of any product:
This post is about applying those areas to Figma components. If you've spent any amount of time in anyone else's files, you've probably noticed they set things up differently than you do! There's a lot we can learn from each other by sharing our work, but when we're producing components for others to use, we should make sure the folks on the receiving end are getting a good product. For each area of UX, I've explained which characteristics of Figma components contribute to that area.
By the end of this post you'll have the information you need to go back and improve past components you've made, and well equipped to make excellent ones from this day on!
<a href="#now-what" class="button secondary" style="padding:16px,0px; margin:auto;">Skip down to the free checklist resource</a>
Patrick writes that usability is all about "discoverability and understanding [...]. Can a user easily discover key features? Once a user discovers key features, are they able to understand how and why to use them?"
Thoughtfully designed signifiers are instrumental to creating a highly usable product. Signifiers show us what actions a product affords us, and when we understand those actions we understand the ways in which the product can be used, and how usable it is.
There are 4 distinct qualities a highly usable Figma component has:
How, when, and if you name layers entirely depends on how you and your team use Figma.
For example, if you use the Google Sheets Sync plugin, your layers will be named after column names in the sheet so the instances can accept data when you run the plugin. The names will reflect the category of information held in each column, for example: "First name", "Last Name", "Phone number", "Age", "isCustomer."
Or perhaps you want to prioritize engineer's experience in the file by including CSS class names in your layers. Luis has published a figma community file outlining when and how you'd take this step.
Or you just keep your layers "clean enough" and free of any <span class="figma-frame">Frame 1851</span> or <span class="figma-frame">Rectangle 234</span> objects lying around by using general terms like "container", "row", and "column." Dimitry Bruin encourages this for folks who work solo. I think it's a nice way to keep tidy enough without feeling like you're embarking on a deep clean (unless you're into that).
Whatever you choose, be consistent, and document your naming conventions. If you're curious about how many different approaches there are to layer naming, consider subscribing to my newsletter! I'm compiling a list of Figma layer naming methods that I'll eventually publish here on my blog.
Something else to note about thoughtful layer naming: it's necessary in order for other qualities, such as 2 and 7, to be done successfully.
This will save folks from deep-clicking, and that in turn can save lots of time. It is especially important if you use base components or atomic design principles, and tends to come up for complex molecule-level size components and beyond.
Imagine a star rating component. it contains star icons, and some text. If the default variant is a 5-star rating, but you need one that depicts 3.5, designers have to dig into the layers and update all those icons, and change the text. That's a lot of effort for information that's so predictable and unlikely to change! Instead of layer-spelunking, you could build out variants that handle all possible ratings and make them available at the top level of the component. Why variants instead of separate components? I've got an entire journal entry about when to use variants VS. separate swappable components that will explain why.
In this GIF it took me 8 clicks and 9 seconds to adjust the <span class="figma-component">Star rating - slow 🐌</span> component from the default value of 5 stars to 3.5 stars. Meanwhile <span class="figma-component">Star rating - fast 🏎</span> only required 2 clicks, and took 3 seconds. I also didn't have to make any adjustments to the text, which protects me from accidentally making a typo!
And with the release of component properties announced at Config 2022 followed by an open beta 4 months later that let's us bubble up nested instance's properties, set preferred instances, and hide layers that aren't associated with any component props, this quality is easier than ever to achieve! These expansions of the properties feature will relieve us of the burden of making and maintaining hundreds of variants that would've been needed to surface nested instances' swaps and properties at the top level. No longer will designers have to to split their attention between the design panel and the layers panel. After variants were introduced (but before component properties), only some control over composition was available in the design panel. When you had more complicated components with deeply nested layers containing instances that might need to be swapped (like icons), it became vital to make those modifiable layers easy to discover. Employing emojis became a standard practice to help the layer tree more scannable:
But now, with component props and the ability to reveal nested instances' props, editing text, swapping instances, and changing up a component's composition has never been faster and easier! I don't believe this feature will cover 100% of component modifications (there are still tricks with auto layout to make things like progress bars editable that require layer-spelunking), but it's still a huge quality of life improvement. The introduction of variants was a huge leap forward in component usability, and component properties only adds to it. Figma also has shared best practices regrading when to use variant props VS component props! Check out the frame from their component properties community playground file:
You know that thing where you're making an override to some text and the string you've copied to your keyboard doesn't quite match where you're about to paste it? Say you're working on a high fidelity prototype and you're populating the screens with realistic content, and that content lives in a spreadsheet somewhere. No way are you going to hand type it all because you know it's quite likely you'll accidentally fat-finger something and not notice! Copying and pasting text is not only faster, but ensures accuracy. But sometimes we're forced to manually correct mismatches between the data source (a spreadsheet) and how we've set up our text layers. This often comes up when we mix numbers, strings of text, and special characters, such as "3 days ago", "20% complete" or "12:00pm ET."
If you're pasting in a bunch of values from a spreadsheet, or even if you're just punching in random numbers, you might not want to override the special characters, or parts of the string that describe the values. You just need to change the number! Depending on your workflow and what kind of file you're working on, it could be advantageous to separate the "3" from the "days ago" as two separate text layers. Separate "20" from "%."
And of course you could just append "days ago" to the end of the number values in your spreadsheet, or copy "pm ET" to your clipboard and paste that in after you punch in the timestamp. The "best" workflow here is whatever workflow makes most sense for you personally.
Should you decide to separate special characters from number and string values, know that this could impact file performance. For what would've been a single text layer, you're potentially doubling or tripling it. The more layers you have, the more risk you take on of winding up with a bloated file. But don't be discouraged, I'm working on a blog post about safeguards you can put in place to preserve the snappiness of your libraries and local files that allow you to work with high layer counts. If you don't want to miss when that one drops, subscribe!
<h3 id="quality-4">Quality 4: Properties and their variants are thoughtfully named and organized.</h3>
This means eliminating any meaningless default values like "Property 1" and "variant 8." Unlike layers, I think properties and variants are important to spend time naming even if you're the only one working with them.
Consider the order they're in, and consider if certain properties are repeated across components. If you're handling breakpoint with variants, make sure it's always called "Breakpoint" and not "Device" or "Size."
Standardize the order of your variants as well, where possible! If 30% of your components have a "Breakpoint" property, consider placing it in the same place (when possible), for example maybe "Breakpoint" is always the last property. You can also sort your variants by usage. If you have access to library analytics, look and see which variants have the most usage as a group across files—for example if your button's "hierarchy" variants are getting lots of use, consider bumping that property up in your list.
Something else to think about is that the properties you create (whether they're variant props and component props) is that they need to make sense among other components propterties too... with the introduction of expose nested instance's properties in the September 2022 open beta, this quality becomes even more important. I realized the importance of this twice in the 006 session of my YNAB live build stream:
First, when I was trying to reveal and then re-name three nested ◈ interface reps in my <span class="figma-component">◈ sidebar</span> component:
And then again when I saw an opportunity to reveal a dozen nested <span class="figma-component">◈ Month tile</span> components:
"Utility gets at the value of something. Do[es] this product or feature help me do something?" (Thornton)
Utility can vary depending on the audience. Something that has high utility for designers may not for developers, and vice versa. For the purposes of this post, I'm prioritizing qualities that are first useful for designers who use components, but engineers also benefit from these as well. A useful component should help designers get in that flow state:
A useful Figma component lets a designer work as quickly as she likes. It doesn't dog her down, or get in her way. This quality isn't as tangible as the rest of the qualities because it's dependent on the other qualities being achieved. Consider auditing your components and ask folks who use them "which components are easiest to work with?" or "which components are a drag to use?" The data about detachment activity from your library analytics might be another way to gather clues, especially for components with nested instances, or one's with lots of properties.
Also think about the kinds of mockups and prototypes designers are building. If the component is part of a library that's meant to match the code components (the ones that actually make it into production), it's suited for high fidelity mocks and prototypes. Those components probably ought to have things like baked-in interactive states to, again, save designers time. But hi-fi mockups and prototypes aren't all there is! Perhaps you and your team also have a wireframing kit meant for mid or low fidelity ideation. Those components might not need all the same properties or options for modification as the production-ready ones to be useful.
No matter the case, it boils down to this: a useful component should support, and not hinder, the work that needs to get done.
Documentation is a crucial element to having a usable, healthy design system, and it'll happen whether or not you put active time and energy into it. What I mean by "it'll happen whether or not," is if you build and publish a Figma component, it has inherent self-documentation (it's name, it's size, the colors it uses, etc) that designers will use to understand how they should use it. All that stuff comes along for the ride no matter what, so it's best to give them each time and attention.
There is also all the documentation that you don't get for free. This material might get documented in a tool like Storybook, or some internal website maintained by design system contributors:
This isn't an exhaustive list, it's just what I've seen in the wild in terms of component documentation for designers. And to be clear, that entire list won't apply to every single component (e.g. base icons don't have much going on anatomy wise... they're just icons!), and not every product team needs to worry about every section (e.g. not every product has color theme-ing).
"Does this product and its features work as intended? Is this product reliable? Is this product well made? Is it free of defects and bugs? Does it have a high level of fit and finish?" (Thornton)
"a product must be both internally consistent (consistent with itself) and externally consistent (consistent with other products from the same company and consistent with well-understood concepts)" (Thornton)
This area is essential to get right if you want folks to have a good relationship with your components. Fumbling on functional integrity will erode trust. Apart from a component straight up not existing, this is what I think causes folks to detach. There's something about the component that isn't working right, so designers pull it in, detach, make adjustments, and (maybe) re-componentize it as a local main component. This is bad for a couple reasons:
First, you've got duplicates of the same component floating around. Second, designers have written off the component in the library and are unlikely to reach for it a second time (especially if they've built their own, better version). But there's a silver lining! If folks are detaching, modifying, and re-componentizing, that means they've discovered a way to de-bug and fix up the original component. It's quite likely the modifications they made can be applied to the original component. This is an opportunity to collaborate and restore trust. Jump on it. But to avoid this problem in the first place, make sure your components have these qualities:
One core reasons I used to believe ⍚ base components to be worth the additional file memory they require is that they could play a big part in safeguarding overrides. Designers go to great lengths to plug realistic content and data into their mockups and prototypes. It's a shame when all that hard work is lost during a predictable swap or variant change. When overrides aren't preserved on swaps, it feels like a bug or an error. Lost overrides erode designers' trust in that component. To create a reliable component, we need to design them so overrides are protected. Now, I mentioned ⍚ base components being one way to protect overrides, but I'd discourage folks from using them to architect the components for a library. Luckily, there's other ways to protect overrides, and it's a throwback to quality #1!
First you need to understand the mechanics behind overrides and swapping: Figma decides whether or not to preserve overrides during a swap based on the layer architecture and layer names of the instance you're swapping out, and the instance you're swapping in (this also applies to changing between variants). In the case of variants, Figma also checks whether or not "layer properties you've overridden originally match between variants." To be honest, that documentation confuses me. I had to post in the forum for help understanding what the deal is with variant selections) (still waiting for a reply). So we know layer architecture needs to be tight in order to achieve sound functional integrity. This is yet another reason to make your components usable too! Remember, usable components have thoughtfully named layers, and "text layers are designed to facilitate easy, accurate overrides."
<h3 id="quality-8">Quality 8: The component has built in guardrails that ensure its intended visual design and interactive behavior are respected, even in extreme cases.</h3>
As much as possible, Figma components should be designed to behave as the coded component will behave.
Purposeful friction should be introduced to components that makes it difficult to squash and stretch it into ridiculous, unusable dimensions. If a button component is meant to maintain a 40px height at all times, the auto layout settings should be configured in a way that when someone vertically stretches the component, it will remain 40px tall.
Purposeful friction can also be leveraged to bias toward certain content overrides.
Friction isn't the only tool at our disposal: components can also encourage certain behaviors by being highly usable! When properties and variants have been thoughtfully named and organized, you reduce the burden on designers to memorize or reference documentation. For example, if icons are only allowed to show up at 2 sizes, you could use Ridd's icon wrapper method and offer designers variants for those 2 options! If you make it easy for designers to follow the design system, they will.
It seems like a basic thing, but because Figma has few opinions about how folks use the tool, you can't rely on any native feedback that will warn you about a regular hex code being used somewhere that also matches one of the styles you've set. It's all too easy to rely on the eyedropper tool or get loosy goosy with copy/pasting text layers when you're building fast, so this is mostly a reminder to slow down and make sure you're making use of your styles before hitting publish.
Have you ever experienced that thing where you're swapping out nested layers in an instance and then the whole component suddenly goes 🥴 😵 and looks all crunched up and totally broken? This is a common bug that happens when you're using auto-layout and lots of nested layers. It happens when there is a conflict between the resizing rules of the component you're swapping out (such as a ✂︎ placeholder) with the component you're swapping in. I see this happen when I swap something that was set to hug ↔ horizontally for something that was set to fill ↔ and it comes in all wonky because Figma overode that setting to be fixed ↔.
My solution to this has been to do extensive testing on components that folks will be swapping different sized content into. When you run into a case where auto layout freaks out, examine the instance's settings that are getting swapped out and see if you can fix things there to make sure swapping goes smoothly.
"Is this product visually appealing? Is [the visual design] edifying[...]? You can make a product that nails every other area of UX, but if it looks and feels like a scam or spam product, people will assume it is." (Thornton)
I want to be clear: this is not about the visual design language of the product or site you're building! This is only about the Figma interface around the component instance, very little of which is under our control. For example, we can't change the purple color that component instances fames' have. But there are some things that make a difference:
This means no draft ideas lurking around in hidden auto-layout layers.
If you make liberal use of auto layout (again, I think every component should), you can correct this by setting the resizing rules to "hug." If you're not a fan of auto-layout, be warned that if you keep reading my blog you might just be converted...
There a couple exceptions to this quality would include zero frame components, or interactive components that expose elements like tooltips.
"Persuasiveness is the ability to get people to use your product and do key tasks. If the job of your website is to get people to buy products and people aren’t, you have a persuasiveness issue. An e-commerce website that fails to get people to buy products can’t be considered well designed." (Thornton)
A persuasive component has credibility in your library. It presents itself as an obvious, safe, smart choice to use in mockups and prototypes. It helps designers work quickly, accurately, and with no frustration. This is easy when there's just one item to choose from (and that item meets all the rest of the criteria mentioned above), but that's not always the case! You might have multiple button components in the same library, or you're sourcing components from two libraries that have similarly named components! If you're presented with multiple options for the same kind of component, it's hard to have confidence you're choosing the right one.
There are three things you can do to help reduce confusion when multiple versions of the same component are accessible from the asset panel:
As discussed in component usability, the way you name and organize your components matters a great deal. This is the most powerful tool at your disposal for eliminating the perception of having duplicate components in your library. If you run into this problem, re-examine your naming and organizational conventions.
Next, document the difference between the components. Include usage notes about when, where, and how to correctly use the component. Outline when you should use one over the other.
Lastly, components that use variants (and you can have a single variant component) or that are contained in another frame on the canvas can make use of background colors in the asset panel. This is especially helpful if you're overhauling a library and will have periods where legacy components will intermingle with new ones (e.g. the legacy components that will be deprecated should have a background color that warns folks against use).
Don't leave this feeling overwhelmed; if anything the takeaway should be that there are so many ways you can improve the usability of your components, which means you have options. There's so much more you can do than cleaning up layer names! To help you in this endeavor, I made a checklist component containing all 12 of these characteristics. Use it to evaluate your own Figma components, right in the file!
{{free-component-quality-assurance-checklist}}
And only do what makes sense for whoever is going to use your components (you might not touch everything I mentioned). Get your component users' involved in the process, don't go it alone! Not everyone wants to spend time naming layers, I get it, but maybe they can tackle filling out descriptions while someone else handles layer names! Lean on each other's strengths. Take the time to polish up your components' UX. Deliver a superb experience to your component users.
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).
