Figma Components: The Frontify Way

“This design system is flawless!” — No one, ever.

Components are filthy, wild creatures that we as product designers have collectively set out to tame. Our masochistic tendencies aside, there are obvious reasons to do so. We want to save time and create high-quality, brand-consistent, reliable products.

Whether you’re just starting out with your first button, or stuck in the mud of a growing component library, bear with me as I explain in painful detail how we do things at Frontify. It’s far from perfect, but perhaps you find an idea or two for your own imperfect system.

I’ll explain how we structure and name components, our basic versioning workflow, some Figma efficiency-boosting tips, and briefly share how we document our work using Frontify (our own product) to build our Arcade design system.

BEM Like a Designer.

For those of you unfamiliar with BEM (Block, Element, Modifier), it’s essentially a naming format/methodology for front-end components. The Block is the component (e.g. button), which contains Elements (e.g. button__text) and Modifiers produce the possible variations (e.g. button--primary or button__text--bold).

It emerged as a necessity to manage unruly stylesheets and incomprehensible markup. Despite the massive impact of frameworks on component development, this naming pattern and way of thinking is still strong. As our own development team uses it, it formed an excellent basis for structuring components in Figma.

Enter our Component Frame — this handy helper is the starting point for any new component we design. While it doesn’t strictly follow all the terminology of BEM, it does follow its principles.

Our beautiful Component Frame

I’ll talk you through how one might build this Slider component using the miraculous Component Frame. If you’d like to follow along you can grab the demo file for yourself. Note that you need to detach the Component Frame to use it properly.

The Slider component we’ll build

Name

Easily overlooked, we try hard to align at least the name of the component between developers and designers, so that we have a shared language.

In Figma the name of our Component Frame should match the component followed by the version number. In this case “Slider v1”. We also edit the heading on the Component Frame itself to match.

Contains

While not strictly part of the BEM methodology, this section can be really helpful for both designers and developers. For designers it acts as a kind of audit; they can get a quick impression of whether they’re making good use of existing components. For developers, it lets them know which dependencies to import when building the component.

Our first step in building a component is to break it down into its constituent parts. If any of these parts can be covered by an existing component, then we add an instance of the component(s) here. For the rest, we move on to Elements.

For the Slider, I know that we’ll need our Icon Component (which if you’re curious, uses a Figma hack to maintain the icon’s overridden fill color).

“Contains” section of the Component Frame

Elements

We don’t have a specific rule for what constitutes an Element. Sometimes it’s a combination of several layers, sometimes it’s a single layer, in some very simple cases, one might skip the Elements altogether. It’s not even a matter of finding what works for your team, but rather for each individual component.

In the Slider’s case we’ll keep it simple with an Item and a Box. We need the Box because of some limitations with auto-layout, and we’ll group everything else into Item for simplicity.

For the Box:

1. Create a frame.
2. Style it.
3. Make it a component.
4. Name it:

• “_” — because only the final component should be published to the library
• “Elements/” — so that it’s clearly separated in the component chooser
• “Box” — no need to get verbose, it’s not going to get published anyway

Box Element

Very easy. On to the Item… not so easy.

When an Element requires variants we use a Master to maintain consistency and ease of editing. Such is the case with the Item in our Slider component. The steps are as follows:

1. Add all layers (that are needed by any variant) into one frame.
2. Make it a component.
3. Name it, just like with Box but adding “MASTER” (i.e. “_Elements/Item MASTER”) so we can distinguish it from the actual Element that we’ll create next.
4. Style it to reflect the default state of the Element.

Item Element Master

Now we need to create variants from that Master, so, here are the first few steps with keyboard shortcuts (Mac OS) so you can do this like a pro:

1. Duplicate the Master (⌘ + D).
2. Create Component (⌘ + ⌥ + K) — this will create a new component with an instance of the Master as its only child.
3. Rename it (⌘ + R) — according to which variant you want to create first e.g. “Active=False”.
4. Duplicate this new component (⌘ + D).
5. Detach it (⌘ + ⌥ + B).
6. Create Component (⌘ + ⌥ + K).
7. Rename it (⌘ + R) — e.g. “Active=True”.
8. Select both of these new components.
9. Combine as variants (no shortcut 😭).
10. Name the set (the purple dotted border), in this case, “_Elements/Item”.

Then you just need to create all the necessary variants and name the properties accordingly.

Item Element

Master (Block)

The main Component Master should be easy now as it follows the same pattern as an Element Master:

1. Take all the possible Elements for the Component.
2. Put them in a frame.
3. Make it a component.
4. Name it:

• “_” — so it’s not published
• “Slider” — the name of the component
• “MASTER” — to distinguish from the actual Component

Component Master

Component (Modifiers)

This is the only component from this whole frame that we’re actually going to publish (although we break this rule occasionally).

Similarly to the Element, we take _Slider MASTER and nest it inside each variant, using overrides to create the different compositions and styles. Then we give it the most simple name of all… “Slider”. This is how it will appear in the component chooser when selecting from this library.

Component

Bonus Dev-friendliness

As mentioned initially, this presents the component in a way that is familiar to our developers (BEM-ish). But there are some additional benefits:

• The Masters (whether for the Component or a particular Element) can often be translated directly into markup (e.g. HTML), before the developer even starts thinking about all the different variants.
• Style inheritance is clear, as everything runs top to bottom. That means that the developer can confidently define the default styling for the Component or its Elements, and use modifiers to create the variants.
• In our case, we only strictly align on the Component name, but if a developer is stuck, or struggles with English, then the names of the elements, properties, states, etc. are already defined for them, and clearly labeled.

Versioning — Snap it, Work it, Quick, Erase it.

Perhaps we use this component for a while and it starts to reach its limit. We need it to do something that it was never meant to do, or we want to split one of its Elements out into its own component for use elsewhere.

We follow a very simple workflow for this, and so far it’s been fine.

Duplicate the Entire Component Frame

Self-explanatory right?

Relink the Components

1. Detach (⌘ + ⌥ + B) and (re)Create Component (⌘ + ⌥ + K) for any Masters.
2. Change any instances from the previous version to the new version. So for example, we have v1 of _Elements/Item in our v2 _Slider MASTER. As we haven’t yet changed the name of the frame they’ll be right next to each other in the component selector. Easy switch. See the “Bulk Editing” section below for a tip on making this step even more painless.

Reassigning Elements from v1 to v2

Make Your Changes

Now you’re free to adjust or even totally revamp the Component. Don’t forget to increment the version number in the Component Frame’s name and the heading.

You might be wondering if you’re going to make significant changes to the Component anyway, why bother with all that faff of detaching and reassigning components? Well, it’s just easier to do it all at once so you don’t miss something. Personally, I prefer hitting it with a hammer before I start over picking through it with tweezers when a problem arises.

Deprecate

This is at the designer’s discretion. We generally make the old version private (add an “_” in front of the name) as a minimum and move the component (with all of its Elements etc.) to a page called “Archived”. That way if there’s work in progress that relies on that component it can still be used, but only the new version will be discoverable.

At some point of course it’s important to do a cleanup of those archived versions — and we generally do this in the most brutal way of deleting everything on that page when there’s a good opportunity to do so.

Plugins & Shortcuts — This is the Way.

If you’re yet to be inducted to the Fellowship of Timesavers, let me show you the way, with a few tips & tricks that have been particularly useful in our system.

Structuring Variants with Simple Sort

Some shameless plug(g)in(g) here. I made a Simple Sort to help us organize our variants without too much fuss. While Figma did add auto-layout functionality to variants, this is far from ideal with the more comprehensive components.

Simple Sort organizes variants into a grid, based on some simple configuration options. Just select the variants’ frame (the purple border), and run the plugin. Running “Manual” gives you all the options, and “Auto” applies either the last-used settings for a particular set of variants or the default settings if it hasn’t been used yet. You can read more about that on the plugin’s page.

This comes in really handy with theming too, as with some particular manipulations and a special gradient fill set on the variants’ frame, you can achieve something like this:

How we present themes for our Input Label

Bulk Editing

You can achieve insane bulk-editing efficiency with these 3 tricks, especially when combined.

⌘ + ⏎ / Shift + ⏎

After telling a colleague about this one, they were blown away — I imagine others might have missed it too. When you have a layer, or multiple layers, selected hitting ⌘ + ⏎ will select all of the child layers. Shift + ⏎ will select the parents of all selected layers. The uses of this in bulk editing are endless.

Most commonly, I use ⌘ + ⏎ for reassigning components when creating a new version (as explained above) — select the variants’ frame (purple border), hit ⌘ + ⏎ to select all variants, ⌘ + ⏎ to select the Master inside of each variant, and voila — you can change them all at once.

Shift + ⏎ comes in really handy for selecting “wrapping elements” such as an auto-layout frame one might put around text and an icon. Use ⌘ + Click to select the text, then Shift + ⏎ to select the parent frame. Really helpful when you want to select several such things at once (for example across a bunch of variants).

Select Layers Plugin

This plugin is fantastic and has tons of ways of selecting exactly the layers you want. As we are very careful with naming, we’re able to use “Select Layers by Name” quite often.

Let’s say you want to hide the icon in half of your variants. You select the variants (bonus tip: use ⌘ + Click’n’Drag / ⌘ + Shift + Click’n’Drag), run the command with the query “_Elements/Icon” and hit delete.

Rename

Most of you will be aware of this already but for those that aren’t, Figma has an amazing native feature for bulk renaming. Simply select the layers (this is where Select Layers can come in handy), and hit ⌘ + R. You’ll be presented with some really powerful renaming options — most importantly the ability to match and replace a particular string within the names of the layers you’ve selected.

Perhaps for a particular component, you want the Elements to be published. Select the Elements, hit ⌘ + R, and replace “_” with “”(empty string).

Documentation — Keep it Schnitzel

“Keep it Schnitzel” is Frontify’s take on the classic “Keep it Simple”.

No design system is really complete without documentation, but it can be overwhelming, and in our case, it turned into a sort of “busy-work” — where the value of all the time we were putting in became less and less clear.

We’re a small team, so this may not be the case for you, but we recently switched to the leanest of lean documentation and it has been fantastic for us.

Component Frame

On the Component Frame itself, we have, aside from the component name and version number, a place for notes — a totally free-form area where designers may put relevant pointers for people editing or using the component.

Figma Native

Figma has two fields for documenting each component. We use the description field for really important notes — that way it really jumps out at you when you use the component. We use the documentation link to point to Frontify.

Frontify

As a leader in brand management, we know that not only is every brand unique, but the ways in which people manage them are unique.

In the case of our own product design team, we use Frontify for our super lean documentation. Each component features only:

1. A list of synonyms — to aid in search-ability.
2. A brief description.
3. A preview, either from Figma or Storybook, at the writer’s discretion.
4. A table of relevant links (most notably Figma and Storybook).
5. Free-space.

That last one was an important change for us, as previously we had a page template with lots of sections on it that we should fill in for each component.

Components are wild beasts, each one is unique in its own special way, and trying to cage it in a box using a checklist or template proved to be almost impossible.

We have the few mandatory fields mentioned above (1–4), and then we’re free to simply put the most pertinent information, so designers and developers can use it effectively without wading through irrelevance.

How the Slider Component we just built might look on Frontify

Frontify acts as a hub for us. Figma and Storybook are incredible tools that we love using — we let them do a lot of the heavy lifting, and Frontify is a simple place in which to bring the work and the people together.

“This is great! I’m going to copy it exactly!”

Don’t. There’s no one-size-fits-all for design systems.

If you really like some of the things we’re doing I’d suggest you dig deeper into the demo file, sign up for a free plan or trial on Frontify and really think about which parts might work well for your team, your components, and your way of working.

And good luck, we’re rooting for you.