Should every completed screen be a component?

It’s a good idea BUT this may affect your decision:

“Note: It’s not possible to push overrides to a component that’s nested within another component. You will need to make those changes to the main component itself.”

Reference

I used to do this sometimes but found that when I needed the screen in question I always needed for something where I had to change things around. So everytime I’d detach the instance and work on it, which defeats the purpose hahahaha. And as @Ludwig_T pointed out, you can’t push overrides on nested components, which also may introduce some problems in your workflow.

If the idea is to always have a “master” screen that can be accessed on multiple files by multiple people, maybe it’s something you can achieve with Figma’s enterprise plan, where you can have branches and a master file containing the most updated and final version of the screens you want.

I always do a component from every screen I design. Quite often it is required to illustrate a flow where the same instance to be used. My rule of thumb is a very simple one. If the element is being used more than once it deserves to be a component and I don’t have to bother with constant design updates.

It works especially well on a large scale, I own application family with 20+ apps that are interconnected. Component driven approach proved itself to be a very effective way to design at that scale; it let’s me to reuse designs that are always up to date.

However it takes a lot to turn your head around and find your way how to properly organize your assets

That’s good to know thank you!

I see, thanks for sharing your experience!

Interesting!

I usually do this too, create components out of screens that are often reused.
Regarding the replies above, how do you manage instances of components used inside of the screen that is also a component? Maybe that requires, as you said, organizing the assets properly.

Well, at the very end every data structure is a tree 😉 So I would nest my assets accordingly. Here is a quick example I would normally follow

• client-widget-details ← top level screen
  • description
  • workflow-steps ← larger component, top level screen is made with these
    • actions-dropdown ← smaller parts that belongs to the larger component above
    • status-list-dropdown
    • workflow-step

This way on the top I have only screens, everything else goes down accordingly

Have you tried the heart button?

As for nested instances, I use variants for various states so each sub-component reflects a state or interaction that it supposed to have. This gives me a design constructor to work with. Once the larger screen is ready I would work with individual sub components instead to add more functionality. Once it is there I would simply make another instance of the screen and change sub-component state to reflect a flow or a state, for simple cases an override is enough, for complex stuff I would use variants

Thanks for sharing! Appreciate it!

This is such an awesome approach! Thanks for sharing this.
I wish I could this more in detail 🤞