Eternal Struggle of the Systemless Design File: Getting Into the Habit of Using Components in Figma

The more powerful Figma gets, the more it feels like there are “right” ways to go about things. Components used to be too brittle to be reliably usable, and we all kinda accepted that any robust project would end up with countless detached instances of components.

But now we have auto layout! And variants! And library switching! And all sorts of small enhancements that add up to the ability to rely on components. Especially when it comes to systematic designs, where pretty much everything in your design is part of a repeatable system of elements and blocks. Ideally, by the end of a project, your Figma file is a logical system made up almost entirely of functional, intact components.

But what about the start of a project? I feel like I’m supposed to say you should be making components as soon as you open a blank page and start designing. It’s efficient! And you can always keep editing your component after you create it, so just do it!

And yet. In the beginning, I need the looseness, the informality of NOT feeling like I’m canonizing anything in order to experiment quickly, and be creative and thoughtful about my approach to a design. But go on too long with that attitude, and suddenly going back and componentizing everything becomes a monumental task. And in the meantime you’re stuck with dozens of one-off pages that each require manual editing for every little change.

First of all, why is it worth making components? Even if you end up in my aforementioned scenario of having to make each edit repeatedly to individual pages, Figma’s so fast and easy, isn’t that good enough? It’s still good to componentize for

• It benefits Present You. Defining components, text styles, and color styles saves you time and effort when you’re whipping up screens and pages, while still defining the details of the overall design direction. Change a footer design, or button style, or even just a tint of a color once and it instantly propagates to the dozens of instances spread throughout your project.

• It benefits Future You (and other Future Designers). When the client comes back for updates two years later, it’s easier to drop back in when you left the project well documented and cleanly componentized. Or if it’s another designer, they can easily get their bearings and a sense of your design system, without having to go through and learn the nuance of dozens of pages.

• It benefits Developers. Components help identify what about your design is a repeatable element. It stops you the designer from scope creeping your way towards creating several slightly different variants of what should be a single element that the dev’s only scoped to build once. And it makes for an easier handoff since it creates a shared understanding between design and dev about what is and isn’t a repeated module in a design, and what can change about it from instance to instance.

So components and defined styles are good to have! For you and everyone you’ll work with on a project. But when’s the right time to put your foot down with yourself and define them? I do not have perfect answers, but I do have a few tips from my personal experience.

Start With a Separate Library File

We’re starting to adopt this system as the standard at Viget. So often a one-off project turns into a series of projects. If you defined styles and some base-level components like buttons and form elements in the “Client Landing Page 2019” file, it’s not clear that that’s the file you should add as a library to “Client Marketing Site 2022.” So new client projects now start with two files: a general library file of styles and universal components, and a project file of comps, prototypes, and project-specific components.

• The good: It keeps things cleaner and scales well over time.

• The bad: Keeping two files synced is cumbersome early on, when you’re still experimenting with styles and changing everything every few minutes.

• The suggestion: Give yourself permission to be a little inefficient at this point. Maybe it’s easier to experiment with a page or two in the library file, and then copy those comps over to the comp file after it’s settled. Maybe it’s easier to do the inverse, experiment in the comps file, then circle back to the library to codify the styles and components you come up with in there. Whatever works for you, stop every few hours and define what you can in the library. You’ll be glad you did in the long run.

Make Your Header and Footer Components ASAP

You know they’re gonna be repeated on every page and you know you don’t want to manually update every instance one by one. Just make your header and footer components as soon as you start them.

Make a Component as Soon as You Know You’re Going to Repeat Something

Making a listing? Cards? Make one, make it a component, then lay out a series of instances of the component with auto layout. Now you’re in a good spot to experiment with that one component and instantly see how it looks across an entire listing. So much nicer than selecting every last headline in a listing to change a style across them all.

Make Variants for Mobile Design

Another natural spot to stop and make a component is when it’s time to design an alternative breakpoint. So mobile, if you design desktop first. (Or vice versa if you design mobile first.) It’s very satisfying to have desktop and mobile versions of the same component and combine them as variants. It’s a bit of setup, but the payoff comes when it’s time to create a full mobile comp and you can just duplicate your desktop design, swap each component to its mobile variant and voila, a mobile comp in under a minute!

These are a few of the simple rules I’ve set for myself that have made componentizing start to feel less like a chore and more like second nature. Good luck getting into the componentizing habit on your projects!