Sometimes it's hard to know when you ought to make something into a component. You might be worried it's "too soon", or that there's no need to because it's "just a quick wireframe", or that you've broken it down into a small enough pieces... and yet there's still a nagging feeling that not making components (or smaller components) could come back to bite you...
Whatever design tool you’re working in, if you’re creating digital interfaces there’s likely a feature that lets you create reusable building blocks, often called “components." Components are useful because they let designers establish visual and interactive patterns that get re-used throughout an interface, often with minor adjustments made. Buttons tend to be a favorite example: the text within the button usually needs to change to communicate what that pressing that button does, but the other visual attributes, like size, shape, and color, remain consistent so folks know the thing they’re looking at is indeed a button.
But not everything is an obvious candidate for compoenitization like buttons are... so how do you know when it's the right time to turn something into a component?
No matter which stage of the design process you’re in, whether it’s early wireframes or final specs, and no matter what you’re designing for, an existing product, or totally new concept, there are a few signals you should watch for to know when it’s time to make something a component. No matter what piece of UI it is.
... and adjusting characteristics like text, color, border-radius...etc. on those copies. Those are all things that could be handled by overrides, and if that’s all you’re adjusting then you might as well make the original into a component. Even if you know the styling of the component isn’t final, the fact that is is a component means you only have to worry about adjusting that styling in one place later on.
... of a would-be component. For example, you’re unsure if you want to use drop shadows on your cards or not; so make two versions: one with a shadow, and one without. Name them something useful so you can easily swap between them and test them out in the context of the screens you’re making:
DRAFTS/Card/Card-with-shadow
DRAFTS/Card/Card-without-shadow
For folks working specifically in Figma: it might also make sense to use variants for this purpose. Name the property: “?? Shadow” and give it true/false values so you can toggle the shadow it on and off. The “??” in the property name is just a way to let you and other designers know this variant is something being considered and it’s not a final decision. Or use emojis! 🤔 could serve the same purpose.
When I say “chance” I really mean even the tiniest sliver of a chance. For now, consider the obvious example: the humble button. Buttons are often frames that contain some combination of text and icons nested within it. When designing digital interfaces, it's likely you're using a library of icons in your design, but it's unlikely your button components will need to use every single icon in the library. Realistically your buttons will use only a handful of unique icons, but that doesn't mean when you go to build your button component that you're going to look at every single icon and ask "Hmm, would I ever use this in a button?" No one has time to try predicting the future like that! It's a waste of time. Instead, your button component ought to have full access to all available icons. Though, when thinking about design systems and crafting guardrails and rules for designers, it's not farfetched to imagine a scenario where you do want to restrict buttons' access to the icon library... but that's a journal entry for another time.
"Alice, wait, what does nesting have to do with whether or not something should be a component?"
Nested objects matter when we think about componentization because components are swappable. Remember that buttons often have icons nested inside of them. If your icons are components, you can easily swap out a button's icon for any other icon in you library.
That example is easy to follow because the pieces are so small and so foundational to the world of digital interface design. It’s easy to understand how componentizing an icon is valuable, both for swapping capabilities and aesthetic changes to the icons themselves. But what about when you're not sure if something will nest inside something else? The more complex, the bigger (literally bigger, like, the width and height of the object), and more bespoke an object is, the more difficult it is to predict if it might ever nest inside something else...
In these circumstances, I'd encourage you to be liberal with componentization. To some degree, it comes down to working styles, but if you’re like me and prefer to do a little up-front work to save your future-self time and effort, then it pays off to make most things components. I’ve worked on projects and prototypes where I’ve pushed this principle so far that it applied to every single element across all my screens, because everything was nested inside a larger object: the page itself! This was never a hindrance, in fact, it provided me even more flexibility than if I hadn't componentized nearly everything. With the ability to swap my components, I could change out nested instances at almost every level. It gave me great piece of mind knowing that even if a component only had a single instance being used, I knew if I needed to change something I would only need to do it once to the main component.
This is an especially important signal to consider, and it could trump all the others. If you know that the file you’re working in (no matter the program; be it Sketch, Axure, Figma, Balsamiq—whatever) is truly a one-time draft space that you’re never coming back to, and you know the effort of crafting a tight system of components isn’t the best use of your time then don't sweat making components. Sometimes you’re making something for a one-time use that will immediately get archived or tossed out. Examples of one-time files would be things like presentation decks or virtual workshop activities. These are things that you want to preserve and freeze in time, which is hardly ever the case when designing a digital interface. We want digital interfaces to be built it in a way that make them easy to update so we don’t have to start from scratch all over again... that’s where components come in. And this could sometimes be true for presentation decks and workshop activities too! Those tend to be more static types of documents, but not always. Ask yourself: is there any chance I might work on this again in the future? If the answer is yes, or even a hesitant “...maybe?” then do your future-self a favor and spend some time making components early on.
The TL;DR is: when it doubt, make it a component. The worst thing that can come from componentizing everything you make is that some of them go unused... though if you’re following atomic design principles (a great system for saving your future-self some time and effort) that’s unlikely to happen.
The worst things that can happen if you don’t componentize things is... your work risks being riddled with inconsistently styled objects, you may have to make hundreds (or thousands) of repetitive updates manually, and all the time spent manually doing the work that components could’ve saved you from is less time you have to design a well crafted experience.
Components relieve designers from the burden of pixel pushing and managing stuff that’s better left for computers. Free up your time and brain space for more important things, like designing more accessible experiences, running usability studies on your work, tightening up your copy writing, or testing multiple ideas via prototypes!
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. Readers get extra insight behind every post.
