Organizing and structuring components

Now that we understand how components work and why they’re important to use, let’s walk through best practices for organizing and structuring components.

1) Use clear naming conventions and frames to organize components

A good organization and naming system makes it easy to find components in the assets panel, swap related components, and increase the usability and adoption of the system by other team members. Two of the most useful conventions to use when thinking about how to organize your components are forward slash naming and frame containers. Using both of these conventions gives you a robust and flexible organization framework. Here’s how they work.

Forward slash naming

Forward slash naming is a component naming convention that uses forward slashes to create an organized hierarchy for your components. For example, if you had input fields with supported states, you could use the forward “/” naming convention like this:

Input/Field/Text — Active

Input/Field/Text — Default

Input/Field/Text — Disabled

Input/Field/Text — Feedback

Input/Field/Text — Filled

Input/Field/Text — View Only

Input / Field / Text shows how forward name slashing nicely organizes components in assets panel.

For access to a wider subcategory of “related components” in the instance menu you can combine the last two labels, ie. input type (text) and input status (default), by separating them with a dash instead of a slash. This is particularly useful for larger categories with many subcategories. You can see this in use in the assets panel above.

Frame containers

Group and organize your components into collections using frames. This makes your component names shorter and makes it easier to visualize component relationships.

When you combine both conventions you get the best of organizing your assets panel and instance menu with the self-documenting nature of using containers to organize your components.

Here’s another example using Frame containers and forward slash naming convention.

2) Choose easy to understand method for structuring component states and variations

As your components grow you’ll need to have a system in place to manage and structure component states and variations. If you don’t have a way to organize different states and variations of a component your system will start to become unruly and painful to use.

There are a few methods to help you manage these dependencies. Each has pros and cons and depending on how your team works one method may be more applicable to you than the other. I’ll breakdown each method and share the tradeoffs of using each method.

a) Separate master components for each variation

This method is simple and straight-forward. You use a separate master components for each variation or state you need to support. It’s self-documenting nature makes it easy to understand and use.

Pros:

Easiest way to maintain consistency.

Fastest way to change the state or variation of an instance.

Ability to change multiple instances at the same time.

Ability to save text overrides when updating the state or variation.

Cons:

More components in assets panel and instance menu.

Example of using separate master components for each button state.

b) Nest all variations into a single master component

This method uses a single master component with all variations nested inside it. While this seems like a great alternative to the shortcomings of (a) above, it does present its own unique challenges.

Pros:

Fewer components in assets panel and instance menu.

Cons:

Difficult to discover variations.

Not possible to change multiple instances at the same time.

Not possible to preserve text overrides when updating the state or variation.

Example of using single master component with nested variations for each button state.

c) Create overrides for all variations using single master component

This method uses a single master component and creates all variations using instance overrides.

Pros:

Fewer components in assets panel and instance menu.

Faster initial setup.

Cons

More difficult to maintain consistency.

Takes more time to update instance if multiple overrides are required.

Example of using a single master component for all variations.

Keep in mind it’s not an either/or decision. You can use a hybrid approach to support different component states and variations. That said, I recommend using A (separate components for each state or variation) as your primary method. Use B and C if the component lends itself to nested variations or simple instance overrides like the profile avatar example above.

3) Use nested atomic components as global building blocks

A well structured component system is easy to maintain and reason about. One of the best ways to make components more maintainable is to use atomic components. The concept is inspired by Brad Frost’s atomic design methodology, where an atom represents the smallest incremental property of a UI element. You can think of these atomic components as building blocks. For example, the shape of a button or an icon.

The best approach for this is to create a set of reusable atomic components with the sole intention of nesting atomic instances inside other related components. Take textfields as an example. We can turn a textfield’s shape into an atomic component and nest it’s instances inside every other textfield component we create. This means all textfields use the exact same building block (i.e., the atomic instance) and if the shape of textfields were to change, all we’d need to do is update the atomic component and all other textfield components would update too. Using an atomic approach allows you to seamlessly apply globalized changes to components which makes it much easier to maintain your system.