Part 1: Optimizing Your Component Library: Structuring and Auditing for Designer Efficiency

In today’s fast-paced digital landscape, a well-organized component library is essential for any design team. At Aviatrix, we embarked on our design system journey two years ago and recently launched our Flight Suit design system to the Figma community. This journey has been filled with learning and reflection, and we’re excited to share our experiences and insights.

This is the first part of a two-part series on optimizing your component library. By the end of this article, you’ll have actionable strategies to foster both efficiency and innovation within your team. Stay tuned for the follow-up article, where we will delve deeper into techniques and case studies. We plan to release the second part soon, so keep an eye out for it!

Scope

In this article, we will not delve into the debate of using one large library versus separate libraries, as Figma has extensively covered the benefits and drawbacks of each approach. Instead, our focus will be on how to organize components within your library to maximize efficiency and adhere to best practices.

Structuring Your Component Library

When starting to build components for your design system, there are several key considerations:

• Should each component be on a separate page, or should multiple components be grouped on a single page?
• Should variations and states of each component be separated or nested? Separate components for states and variations or nest them within a single component?
• How should components be named to ensure consistency and clarity while making it easy for end users to find the components they need?

Our Team’s Approach

Research and Gather Insights:

• Read Articles on Best Practices: Explore articles and resources focused on best practices in building design systems.
• Review Our Previous Design Library: Identify frictions and areas for improvement in our existing design library.
• Audit Design Systems: Examine publicly available design systems and Figma community files to understand the naming conventions, structure, and grouping of components.
• Discuss with Experts: Engage in discussions with peers in the field to compare different approaches and gather diverse insights.

Define an Initial Approach:

• Decide on a strategy for creating, naming, and managing our components and styles.
• Begin working on the library, periodically reviewing and reflecting on the process.

Our team held daily syncs for about five weeks to keep every designer updated on the progress and to discuss questions and feedback before we launched the Beta version. After the launch, we no longer had designated meetings but shifted to asynchronous methods, such as leaving feedback in Figma and tracking action items in shared docs or discussing during our weekly UXD Team Meetings.

Iterate and Test:

• Treat the initial phase as a pilot stage. Publish the library and have design files adopt the work-in-progress library to build new designs.
• Continuously audit and monitor usage. Since our design team both builds and consumes the design system, we receive direct feedback. For cross-functional teams, regular meetings to collect feedback are crucial.

Understanding Component Usage and Optimization Strategies

If we’ve learned one thing from our users who build design systems, it’s this: Never lose sight of the end user [in our case, co-designers and UI Developers] who ultimately consumes the system you create. From Figma Best Practices

How Did We Audit?

Step 1. Understanding Component Usage

• Analyze Designer Interaction: Consider how designers use components and how Figma displays components when they work on design files.
• Identify Points of friction: Observe when and where points of friction arise during the design process, such as difficulty finding the right component.

Our Observations: Designer Behavior and Figma Capabilities

• Designers can insert components using two methods: searching or clicking to drill down.

Searching in the Components panel

Clicking on the Components Panel to drill down into the design libraries, then into each page, and the components on each page

• Similarly, designers may need to swap instances. They can search or drill down to find the component inside the Swap instance panel.

Swap instance panel

• Pages in the Components panel are sorted alphabetically, not in the order we created them in the library. When non-ASCII characters are used as the first character, their Unicode value determines the sorting.

Pages order in the Components panel (left) versus their original order in the design library (right)

• If components are inside a Frame, Section, or Auto Layout, all components within the container will be nested. Designers see the container first and need one more click to access the components.

How components inside a page (left) appear in the Components panel (right)

• Using “/” in component names nests related components with the same prefix. Nested components appear first in the list in the Components panel and the Swap instance panel, with the rest appearing in alphabetical order.

Multiple clicks are required to swap an icon button to a regular button due to nesting.

• The nesting caused by using Frames to wrap components and using “/” in component names makes it inefficient when swapping instances across different pages. For instance, in our case, it took the designer if a designer 8 clicks to swap a text input to a dropdown. But when we regrouped related components on the same page it took only 2 clicks.

Requires 8 clicks to swap a text input to a multiple-select dropdown

• If a page contains multiple components, they will appear in alphabetical order in the Components panel, regardless of how they were ordered on the canvas or in the Layers panel in the original design library.

Components are sorted alphabetically when displayed (left) versus their original order in the design library (right)

• Using an underscore (_) at the beginning of a component name hides it from publishing. However, updates to these “underscore” components only affect the current library file. If an “underscore” component is inside another library file, updates are not pulled through, causing inconsistencies.

When creating components in the library, our designers focused on layout, structure, and naming consistency from the library’s perspective, without realizing how it affects the end user. Now, seeing all the issues, it is time to address them.

Step 2. Addressing Key Issues:

• Improved Structure for Convenience: Define a structure that minimizes clicks and simplifies the search process, allowing designers to quickly find, insert, and swap components in their files.
• Grouping Related Components: Organize related components together to reduce the number of clicks required for swapping instances.
• Handling Slash in Component Names: Remove slashes in component names to prevent nesting. Establish two naming rules: use descriptive, concise names when possible, and apply prefixes in the name for grouping related components.
• Developing Strategies for “Underscore” Components: Explore alternative approaches to discourage the use of certain components without impeding updates across library files.

While this article provides an overview of these key issues, Part 2: Optimizing Your Component Library: Refining for Enhanced Efficiency will be published at a later date, where we will dive deeper into each of these topics with detailed strategies and solutions to further enhance your component library and improve designer efficiency.

Step 3. Extending to More Design Libraries:

• Progressive Implementation: Start by implementing changes in one design library branch, gather feedback from users and the design system team, finalize guidelines, and then propagate changes to other libraries in the design system.
• Testing and Scaling: If libraries are already published, conduct small-scale testing of changes to minimize disruption to existing design files.

Takeaways

1. When building the library, don’t just focus on the internal structure; put yourself in the shoes of the end user, the designer.
2. Decide on a structure from the beginning, including naming, and grouping conventions, and stick with it.
3. If you have multiple library files in a single design system, be aware of the usage of “underscore” components.
4. Remember that publishing the library is not the end; continuously evaluate and refine your component library as needed to stay updated with Figma updates, trends, and the needs of the team.

Giving Back to the Community

The design team at Aviatrix has recently published our Fight Suit design system to the Figma Community. We’re extremely proud of what we have accomplished. We encourage you to explore and find some ideas for your own design system.

Special thanks to a few design systems that have inspired us, and we appreciate you for opening your design systems in the Figma community:

• ADS by Atlassian
• Lightning Design Systems By Salesforce
• Twilio Paste Components
• Polaris by Shopify

Next… Your stories?

Please share your strategies on how you evaluate and refine your libraries in the comments.

Stay tuned for future articles where we’ll continue to explore more strategies and solutions to optimize your component library and enhance designer efficiency.