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. Good designers are concerned with producing products that offer the best possible experience for the people using them. But how do we know we're delivering a good user experience?
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 with someone else’s components, you've probably noticed they build them differently than you would have. Sometimes different is just that: different. There are certain choices you will make when building a component that are optimized for you and your team. To someone else, that choice could look inefficient, clunky, even a drawback. But just because it’s “wrong” to them, doesn’t mean it was the wrong choice for you and your team.
There are also choices that are generally good practice no matter what. And I’ve listed these qualities out below, organized by each area of UX mentioned above. 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; border-bottom:0px solid">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, or 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 need to 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: <span class="inline-code">First name</span>, <span class="inline-code">Last name</span>, <span class="inline-code">Phone number</span>, <span class="inline-code">Age</span>, <span class="inline-code">is Customer</span>.
Or perhaps you want to prioritize engineer's experience in the file by including CSS class names in your layers. Luis Ouriach has a figma community file outlining when and how you'd take this step.
Alternatively you can 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 relatively clean without feeling like you need to fall down a naming rabit hole (unless you're into that).
Whatever you choose, be consistent. Better still, document your naming conventions somewhere designers will actually read it. Make it part of your onboarding process. Talk about it during peer review or critiques.
An important note: thoughtful layer naming is required in order for other qualities, such as 2 and 7, to be done successfully.
Having this quality achieves two hugely important things:
This quality will come up less for atom-size components and more for molecules and organisms. To illustrate the value, here’s an example:
Imagine a <span class=”figma-component”>❖ Star rating</span> component. It contains instances of star icons, and a label. By default it’s set to 5/5 stars, but, of course, consumers will need to make overrides if they want to present real-world (or at least believable) data in their mockups or prototypes.
Making those overrides, or modifications, should be easy, fast, and accurate.
The worst way to build this component would look like something like this
The architecture depicted above is actually great. The problem is what the screenshot isn’t showing you is:
Nothing about this component helps designers:
If I want to update an instance of that <span class=”figma-component”>◈ Star rating</span> to show a 3.7 rating I must:
FIFTEEN STEPS 🥵 Four of which involve traveling between the canvas and the design panel. It took me about 11.7 seconds to go through them at a normal pace.
There’s a better way, of course: using modern features like variants or component properties allow us to make modifications accessible from the component’s top layer. In this <span class=”figma-component”>❖ Star half</span> example you it is an or situation when it comes to which of those features you pick.
I personally would consider this a configuration change. And configuration changes are best made with component swap property with preferred values to swap between <span class=”figma-component”>❖ Icon / Star full</span>, <span class=”figma-component”>❖ Icon / Star half</span>, and <span class=”figma-component”>❖ Icon / Star empty</span>.
Let's see how many actions this more modern set up required
That’s 40% fewer steps! And only once do I have to travel between the design panel and canvas. That’s probably the biggest benefit here: everything I need to properly configure this component is available as a property.
If you’re designing a high fidelity mockup or prototype, you’re going to need to inject realistic data into Figma. And there is no way you’re going to hand type it all, right? Of course not!
Copying and pasting text is not only faster, but ensures accuracy. But sometimes we're forced to manually correct mismatches between the data source (like a spreadsheet or google doc) 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." Here’s a classic mismatch: names.
This could be resolved one of two ways:
Back to special characters: if you're pasting in a bunch of values from a spreadsheet, or even if you're just punching in random numbers, you need to be careful not to override the special characters, or the label that describe the value. 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 because it means increasing the layer count. 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. If you find yourself with a bloated file that’s about to crash, I’ve got you covered with instructions for conducting a successful Figma-file-memory rescue mission.
This means eliminating any meaningless default values like "Property 1" and "variant 8." Unlike layers, I think properties and variants always 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. Many of your components will have prototyping connections on them. Your “State” property shouldn’t sometimes be “state” (lowercase “s”), or “Interactive states.” Just pick one name, and stick with it. Same goes for your values: don’t waffle between “pressing” or “tapping” or “clicking.”
Standardize the order of your variants as well! If 70% of your components have an “is Focused” boolean property, but it doesn’t see much use in mockups and prototypes, order it so it’s at the bottom of the property list across all the components that have it. 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.
You can see above the properties these three components share. Luckily their naming is consistent, that’s an important first step, but the placement isn’t. <span class=”figma-component”>❖ Thumbnail</span>’s <span class=”inline-code”>Color mode</span> property (this was before variables mind you) is the last variant property in the list, while <span class=”figma-component”>❖ Button</span> lists it first. This could be intentional! Or it could simply be the result of the order the properties were created in.
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 properties too... with our ability to expose nested instances’ properties, 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 optimized for designers who use components to build both static mockups and prototypes. Second to that would be engineers who consume those designers’ local files.
A useful Figma component is one that helps you achieve your goals. Which means it’s very important that you’re clear about what yours and your teams end goals are. It’s dangerous to make assumptions here!
The way a design team gets work done varies from one company to the next for a whole host of reasons. Just because we’re all making mockups and prototypes, doesn’t mean we’re all making them in the same way and for the same reasons.
A useful Figma component lets a designer work as quickly as she likes, and ideally in the way that she likes to work. It doesn't slow 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. If you don’t have a good sense of what that work is, ask your designers if you can shadow them sometime while they work in a file. Take good notes. Watch out for repetitive tasks that could be automated.
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 that 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, an internal website maintained by design system contributors, or my favorite: Coda:
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).
Dev Mode is a big help for this quality. Take advantage of "dev resource" links and plugins to external services like GitHub. And don’t stop with adding a link to your design documentation. Add links to communication channels where folks can get help if they need it. This might be something like a public design system slack channel. You can also link to instructions for making contributions, or a form that folks can fill out.
"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. When there’s something about the component that isn't working right, designers insert it, detach, make adjustments, and (maybe) re-componentize it as a local main component for themselves. 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.
Figma components should be designed to behave as the coded component will behave. There will be times where getting a 1-1 match does not make sense, but this is a pretty good goal to always aim for.
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 such a way that if 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 it, there is no native feedback to warn you that, "hey, you're using a raw hex value when you should have used a variable!" But there are linter plugins in the community, like "Roller" by Contrast.
Have you ever experienced that thing where you're swapping out nested layers in an instance and then the whole component suddenly crunches up? I call these "wrinkles." They often happen when you're using auto-layout and lots of nested layers. Wrinkles occur 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 overrode 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. If you want to iron out auto layout wrinkles fast and efficiently, check out my blog post that walks through detailed steps for various kinds of wrinkles.
"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 are a couple exceptions to this quality would include absolute positioned objects inside the component that purposefully spill over the edge (like a notification badge).
"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 to achieve 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).
