Figma Shared Libraries

Extend a design system with assets maintained by contributors

Design systems are gradually moving away from a single, monolithic, centralized libraries of every thing in one place managed by one team, a concept I explored abstractly in 2019’s Design System Tiers. Since then, Figma library features have gradually improved permissions, component architecture, dependency management, branching and publishing.

Library quantity is exploding. Before, the Figma Libraries dialog exposed one or a few libraries managed by a design system team. Now, it overflows with 10s or 100s to choose from. Two types are most common: dependable core libraries from a system team or irrelevant or less predictable assets from other teams you don’t know. However, there’s a third type: libraries by contributors intentionally shared with everyone under the auspices of the design system. I refer to these as shared libraries.

This article explores shared libraries: what they are, why and when they emerge, and where to put them. As shared libraries extend a system, the system must set expectations, model how they work, and help with curation. This article aims to inspire thoughts of roles, tasks, and the library life cycle and offer ideas for workshops to get your team started.

About Shared Libraries

Every organization I work with exposes core libraries to everyone in their Figma organization. Teams use those core features in project files.

A core library includes style, components and other features that everyone needs and is made and maintained by a design system core team.

Industrious teams will invest in reusing styles and components in a library used locally within their Figma team.

A local library extends a core library with features only one team needs and is made and maintained by that team.

What about extensions made by contributors relevant for and shared with everybody? Such libraries nestle between core and local endeavors.

A shared library extends a core library with features many teams need, and is made and maintained by contributors not on the design system core team.

What could YOU call this practice, anyway?

Different organizations use different terms for shared libraries, such as:

• Shared library
• Expansion packs
• Feature library
• Supplementary library
• Extensions
• Community library

I’m drawn towards expansion packs, a playful concept used in video and board games to add on new areas, characters, weapons, objects, and storylines to an already released starting point. That said, I prefer shared libraries because it directly captures the central tenet — shared need — and also fits better on a scale of core to shared to local.

I’ve discouraged terms like “Product Component Library” and “Product UI kit.” To me, the term product evokes the essence of work relevant to only one group of people. That’s local. That said, it may be a relevant term for businesses delivering omni-channel, where each team delivers work that impacts a journey spanning products. To each their own.

What kinds of shared libraries are there?

In my recent consulting, I’ve encountered shared libraries like:

• A wireless carrier’s web navigation, iOS navigation, .com components, and conversational libraries.
• A social media company’s notification, messaging, search, feed, ads and share widget libraries.
• A product company’s editor, help, media, notifications, and search kits.
• An e-commerce company’s shared library trio of “smart” (organisms connected to a backend), “CMS” (built into AEM), and “community” (any contribution not supported by the core team).

Shared libraries – Editor, Help, Search – built upon Core library tokens and UI components

Few features amid libraries in these examples were the design system team’s responsibility. All were positioned as formal extensions of core libraries. The examples reflect that shared libraries address different kinds of needs:

• Complex features including sophisticated components and patterns like a rich-text Editor kit, robust Card and Media Object kit, or — most commonly — a place for Global Navigation components and templates not maintained by the design system core team.
• Platforms where features are limited to or tailored for iOS, Android (Toggle, anyone?), or a content management system like AEM or Drupal.
• Frameworks when features are for one but not all libraries supporting React or Angular or Vue or Web components.
• General contributions when a feature is widely needed but doesn’t warrant the effort, depth or formality of belonging in a core library.

When and why a shared library?

Shared libraries serve shared needs that can’t — or SHOULDN’T — be served by the core team. But how broad of a shared need warrants a shared library? How long should it last to make it worth it? I’ll start conversations with “How about features needed by 3+ teams/groups (including the library’s maintainers) for 12+ months?” and tune expectations from there.

Why not 1 team? Ahem — that’s not a shared need. Keep things local until it’s clearly evident that many others need them. Why not 6 months? If something is more temporary than that, something less formal may be sufficient.

Where do you put shared libraries?

Beware: it’s easy to make any library visible to an entire organization. To users, it may be difficult to distinguish local libraries from libraries intended for everyone. Using local libraries also carries risk, since they may avoid activities that make a system a system: following conventions, changing predictably, keeping dependencies fresh, communicating change effectively.

On the other hand, both contributors and users expect that shared libraries are a trusted extension of core assets made with reasonable rigor and support. They also don’t want to hunt around an entire Figma organization to find the library they need. As a result, consider co-locating and yet distinguishing shared libraries with the core library.

Shared libraries colocated, branded, and provided with same access permissions as core libraries

How does a shared library work?

To start a shared library, consider who’s involved and what they’ll do to make, maintain, and even eventually sunset a library and features within it.

Identify maintainer(s), contributor(s) and who do what

Designating a motivated maintainer (or two or three) is an important step.

A shared library maintainer is responsible for curating features, sustaining quality, publishing, communicating and monitoring library use over time.

“Maintainer” carries expectation: this isn’t just making, but maintaining and running the library too. A maintainer is an advertised point-of-contact for both the core team and the library’s users and contributors.

Yet, while maintainers are usually heavy contributors, they need not do all the work. I’ve had success discussing library tasks on a scale of permissiveness:

• Any contributor must be able to do production tasks (marked with a ✅ ).
• Some tasks are limited to a library maintainer (marked by a ⚠️ ).
• Library contributors should coordinate some tasks with a design system core team steward (marked with an 🔶).
• A system core team steward handles a few tasks (marked with a ⛔️ ).

While teams define who doest what differently, the lists below include prepended emoji (✅, ⚠️, …) corresponding to my default recommendation.

1. Setup the library

Getting a library off the ground is a collaboration between a core team steward and a library maintainer. Responsibilities include:

🔶 Who decides that a library can be created?
🔶 Who names the library, such as “Shop” or “Editor” or “iOS”?
⛔ Who owns the library’s Figma team, project, and file?
🔶 Who are editors of the file’s main branch?
🔶 Who administers access and permissions for the library?

Because shared libraries are part of an ecosystem, they are often located adjacent to core team libraries. Therefore, I suggest that the design system team owns the file while maintainers are the primary library curators.

To get started, maintainers benefit from points-of-reference that include “Look how the core library does it” and a thoughtful library file template with:

• Standard Cover page
• Templates for front matter like About the library and Version history
• Template for component and style pages, including frames for audits and inventories, making features, and capturing documentation.

Shared library file template, with templates for common page types

2. Plan the (initial) features

Once the library is setup, it’s off to the races!?! Not exactly. Seasoned librarians have a plan of not just what’s going in, but what’s most important to built first, next, and later. Typically, that’s the maintainer(s) job and is captured on a “Component Status” page in the library’s front matter.

⚠️ Who organizes features across pages?
️⚠️ Who prioritizes features that will go in the library?
⚠️ Who approves that work on a specific feature can begin?

How do you discern what belongs by when? Factors that influence that conversation include:

1. Urgency: Is this needed in 1 week, 1 month, 1 quarter, or in a half year?
2. Near term shared need: How many teams need it within 1–2 months?
3. Long term shared need: How many teams will ultimately benefit?
4. Maker availability: What contributor(s) are available to design, spec, document, and/or publish components? How about developers for code?
5. Maintainer availability: Will contributor(s) stay on as maintainers, or will the library maintainer or design system team bear that burden?

3. Produce a feature or three or five

Feature production may follow a complicated workflow spanning many steps. Regardless, contributors should be in the driver’s seat to confidently discover, design, spec, document, and complete their work.

🔶 Who names and scopes the feature?
✅ Who audits relevant experiences for existing patterns?
✅ Who scopes and solicits feedback on feature requirements?
✅ Who designs the feature?
✅ Who builds the Figma component, including layers, props, styles, etc?
✅ Who specs the feature enough to be coded by a developer?
✅ Who documents the feature with use when, examples, …?

Prioritize outputs that matter. As evidenced above, there’s many things you could enable contributors to produce. Yet, you need not do everything, particularly early on. Therefore, focus on workflows and outputs that matter most for what your library needs.

Namespace features. Once a shared library’s published features are put into good use, it’s helpful to prepend a namespace acronym (such as ESDS Editor or just Editor) to distinguish styles and components from the core design system (such as ESDS) and local features in a file.

Involve the system core team. When naming and scoping, minimize unanticipated redundancy with features already in the core and limits change if the feature ever graduates to the core.

4. Review features, and if so, how much?

With Figma’s branching capability taking hold, more teams are limiting main branch work to maintainer(s) and production work to contributors on branches. This branching workflow helps in a range of ways to clarify where work is done, how work is reviewed, and how contributor(s) — as needed — don’t have their fingers on the publish button.

⚠️ Who approves that the feature is designed sufficiently?
⚠️ Who approves that the feature is built well (layers, props, etc)?
⚠️ Who tests the feature prior to publishing?

Organizations vary considerably in how well a shared library feature must be built. Some require quality approaching that of a core library. Others can be grossly indifferent about feature polish, stability, and completeness. What matters most? Norm on expectations, and communicate those expectations clearly to those using the library.

Figjam to identify what must, should, could, or doesn’t need to be done

I’ll use a Figjam template that lists quality criteria as grouped rows and participants then color cells to answer if a feature Must, Should, Could, or Doesn’t need to meet that criteria. Criteria includes things like:

• Expected capabilities like states, responsiveness, or theming.
• Build quality, such as descriptions, property and layer naming, design tokens, spacing precision, and autolayout.
• Documentation like examples, use when, and/or specs.

No shared library does everything perfectly, but nearly every one does require at least a few of these.

5. Publish features

While it may quickest to enable anyone to publish anything, that’s a bit cavalier for a library used across many diverse groups. Therefore, many prefer to limit contributor work to branches, and leave branching merging and feature publishing to library maintainers.

⚠️ Who publishes library styles and UI components?
⚠️ Who communicates changes to that library’s users, and how is that done?
⛔ Who can promote a feature from a shared library to the core library?

6. Monitor usage and enhance and upgrade over time

After a first release of shared library features, activity may heat up or cool down. That said, avoid publishing a first batch and then putting the library on a shelf to age without change. As requests roll in, it’s up to the maintainer to triage work and federate updates to contributors that stay involved.

Just as important as fixes and enhancements is staying up-to-date with how the core library evolves. Shared library users expect that it exists in an ecosystem that evolves together, such that it updates when core updates.

⚠️ Who pays attention to usage via Figma analytics?
⚠️ Who responds to requests for enhancements and fixes?
✅ Who extends existing features with enhancements?
✅ Who fixes defects in published things?
✅ Who upgrades and refactors a shared library when core libraries change?

Workshop tasks with prospective maintainers and contributors

Consider a workshop to dig into challenges of setting up and running a shared library. I use a Figjam template that lists responsibilities as rows and participants as column. Each participant colors cells down their column to map that task to the permissiveness scale.

Figjam to identify who can do what by role

Results hone in to how participants perceive task ownership across roles:

• Is nearly every answer green? ⚠️✅✅✅✅✅✅✅⚠️✅✅✅
  This is common with people unfamiliar with the complexities of design systems. Beware of chaotic, ungoverned disrepair. Suggest benefits from more workflow controls and a stronger presence of a library maintainer.
• Is nothing green? ⚠️⛔⚠️🔶⚠️⚠️⚠️⚠️⚠️⚠️🔶⛔
  This is common when one person expects to make everything, and maybe that’s ok. Or, maybe, goodness gracious, relinquish some control! Improve your templates! Get people involved! Don’t do everything yourself.
• Are most answer orange or red? 🔶⛔🔶⛔⛔🔶🔶🔶⛔⛔🔶🔶
  This is common when talking shared libraries with only design system practitioners, who get stuck in making for rather than enabling others. Isn’t the purpose to extend what the system isn’t already doing? Can you better equip maintainers and contributors to work independently?