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 agood 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!
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 "Frame 1851" or "Rectangle 234" objects lying around by using general terms like "container", "row", and "column." Dimitry Bruin encourages this for folks who work solo, and I think it's a nice way to keep tidy enough without feeling like you're embarking on a deep clean (unless you like doing that).
Whatever you choose, be consistent, and document your naming conventions. Looking for even more ideas? Consider subscribing to my newsletter so you know when I post a list I'm compiling that will cover all the ways designers name their Figma layers.
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, separate swappable components, and libraries that explains why.
In this GIF it took me 8 clicks and 9 seconds to adjust the "Star rating - slow 🐌" component from the default value of 5 stars to 3.5 stars. Meanwhile "Star rating - fast 🏎" 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!
Figma has made this quality even easier to achieve with the release of "component properties" that was announced at Config 2022! This feature will relieve us of the burden of making and maintaining hundreds of variants, and make it even easier for designers to understand what parts of an instance they can make modifications to. Before, with just variants, component users's gaze had to traverse the canvas, back and forth, between the design panel and layers panel. Often times the controls over an instance were split between these two spaces. And with more complicated components, it became important to make modifiable and editable layers easy to find, often employing emojis to make the layer tree more scannable:
But now, with component variants, we no longer have to force designers to go spelunking through the layers panel to make component swaps or edit text! And for anyone wondering what Figma says about best practices regrading variant props and 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!
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 this "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.
"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.
If the component is part of a library that's meant to match the code components that make it into production, it's suited for high fidelity mocks and prototypes. But those aren't the only libraries to exist; perhaps it's part of a wireframing kit meant for mid or low fidelity ideation. No matter the case, the component should support 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 documentation comes along for the ride no matter what, so it's best to give them time and attention.
But then all the there's the documentation that isn't glued to the component via Figma's interface. This material might live in a tool like Storybook, Frontify, 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)
One core reason I believe base components to be worth the additional file memory they require is that they can 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.
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."
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, why not have a property called "size" and make variants for those 2 options? If you make it easy for designers to follow the design system, they will.
This is only important when you're working with base components as they require you to be thoughtful about the job each base component does. For example, the fill color of a button should be handled by a ✿ Fauxken (this will be a future blog post, but for now just know a Fauxken is a base component acting like a design token. Figma doesn't natively support design tokens, but we can kinda sorta use components to do the same thing. Like I said, more later). Don't leave it to be handled later downstream as an override that gets applied.
"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 (which 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 in their description fields, and 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! 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.