Managing Design Systems with Many Core Libraries

How you align design and engineering and synchronize releases depends on the frameworks, platforms and teams involved

Nathan Curtis
9 min readOct 28, 2024

Design systems come in many shapes and sizes, especially evident by how core catalogs of foundations and UI components are implemented across more than one code library.

As a system scales to meet expanding needs, it often grows to offer parallel component code libraries for web, iOS and Android along with commensurate Figma assets for designers. Four “core libraries” (three code, one design), parity of all relevant components, expanding and evolving over time. Let’s roll up our sleeves.

This post explores how expanding to support many platforms and frameworks impacts how you support and align it with a shared design source-of-truth. Success gets complicated as libraries increase, challenging how teams collaborate, designers test, everyone aligns API, and users still expect to see synced features each release.

The example of IBM’s Carbon design system offers a tantalizing public example of a core library implemented across many frameworks in parallel. Such a model inspires, even if it’s not necessarily a target to emulate for simpler problems most systems face.

Describing core libraries of design and code

A core library refers to a library of reusable assets implementing a design system’s core components like Text input, Button and Checkbox.

Platforms and frameworks

Each library implementation targets a specific platform (such as design, web, iOS and Android) and is built with a particular framework (such as Figma or Sketch, React or Lit or Angular, SwiftUI or Jetpack Compose).

Team model: central and/or federated?

For smaller design systems, design and code implementations are usually maintained by central teams dedicated to the work. As additional code implementations arise supporting other platforms and frameworks, the more likely each will be made by federated maintainers and contributors.

Design source-of-truth: specifications?

Designers and developers using a core libraries expect that library to support all core components like button, text input and checkbox. Each component is expected to implement a common design specification (that may include platform– and/or framework–specific considerations).

Code source-of-truth: the reference implementation?

In addition, one code library may serve as a reference implementation: a working component demonstrating how it should be correctly implemented and used. The reference is usually produced by the central team, showcases best practices, and reflects a recommended API. Such a “canonical” reference provides federated teams implementing additional libraries with a reasonable technical design to align with.

Example models, from simple to complicated

Managing and aligning one code library with design is delightfully simple compared to when two or more code libraries begin to scale. As a manager of design system work, it’s up to me to solve for concerns across libraries that include:

  • Roadmap: How do we align features across code libraries over time?
  • Collaboration: How do we enable collaborative best practices between design and multiple engineering teams, especically when federated?
  • API: How do we align API architecture across frameworks, platforms?
  • Testing: How do we integrate designers into testing code outputs?
  • Release synchronization: Do we align releases and communications across libraries? If not, what does that mean?

The example models that follow will progress from simple to complicated to highlight how these concerns get more complicated.

One code library, by a central team

The majority of design systems I’ve led support one design library (these days, Figma) and one code library (such as React) through the work of a central team. Production aligns three primary outputs — (1) Figma assets, (2) React code packages, and (3) docs published to the “doc site” — released in synchronization in a step-by-step process.

Steps to design and produce library outputs for a design system feature
  • Roadmap, collaboration, designer VQA and release synchronization? As easy as it gets managing a single central team.
  • API alignment? While crafting components with aligned features and API challenges designers and developers, a smaller group producing React and Figma can figure it out.

Many web core libraries, by a central team

A central team could implement multiple web code libraries, such as releasing parallel Angular, Web Components, and vanilla HTML/CSS libraries.

One engineering team producing Angular and Web components sharing a common CSS styling architecture, all three of which made available to adopters
  • Roadmap and collaboration? No different.
  • API alignment: Vagaries of different web frameworks can fray API alignment subtly. When they differ, which should Figma assets favor?
  • Designer VQA: As frameworks suggest an internal code waterfall, when are the right time(s) for design to test near-complete dev assets?
  • Release synchronization: Is it ok to release some web code changes before others? While they remain locked together in a single, synced release, this setup could tempt teams to release one before others.

Code could also diverge due to per-framework conventions, feature requests or fix cadences. However, these low risks can be mitigated by team processes and a single, directly responsible dev lead.

Core libraries across platforms, by separate central teams

A “team of teams” responsible for three libraries serving web, iOS and Android is very common in today’s design systems. More often than not, each platform’s library has a distinct dev lead and or more additional developers. Anecdotally in my experience, web has often 2× the developers of iOS or Android, for whatever reason.

Three platform libraries made by separate engineering teams centrally managed as a larger “team of teams”

Given the multiple dev teams and leads, things get more complicated.

  • Roadmap: Centralized but diversified into groups, persisting a shared roadmap takes a bit more effort.
  • Collaboration: Distinct dev leads per “platform team” need their own ceremonies, which can begin to diverge decisions and understanding. Are there routines where designers should participate? Previously “hot potato” behaviors give way to increasing focus on handoffs and specs for provisional decision making. Are all three dev leads in handoff meetings, or do we need multiple handoffs?
  • API alignment: Systems must allow for platform-specific conventions, so it’s up to leads to agree on guardrails of what’s shared or not. In this setup, I lean even more into component, property and option naming.
  • Designer VQA: A designer responsible for specs gets called back into visually test different platforms at different times. Review timing is less predictable and more disruptive. Tracking needs deliberate attention.
  • Release synchronization: The tug of independent releases strengthens considerably, allowing for code enhancements and fixes to release quickly to support business needs.

Once multiple development teams and/or platforms get involved, it’s often time to invoke a “Release individually, communicate collectively” model.

Release communications occurring when all outputs are done, even if some (here, React and iOS) release quietly prior when ready

Here, React and iOS could release days or even weeks prior to Android, the Figma library and documentation site. Once Android is done, Figma and doc site materials complete the “Release” and communications across Slack, email and formal doc can broadcast new feature availability to the masses. This strikes a balance between enabling teams that need component code as soon as possible with a system driving (perceived) alignment across platforms.

If the gap between platforms is longer, then releases separate by platform. This is almost always the case when libraries are federated.

Web library by central team, iOS and Android federated

In my experience, it’s less common for iOS and Android to be centrally managed with and allocated with the same dedicated capacity as developers supporting a design system’s web code. Instead, I’m used to coordinating more loosely with iOS and Android library leads. These libraries emerge to serve their “main app,” and the benefit to teams making other apps is a secondary concern at best.

When working with those making federated libraries, ways-of-working diverge far more. Considerations include:

  • Roadmap: Very often, the “main app” product leaders get involved. Different interests — deliver a library (my outcome), “main app” integration (their outcome) — become clear. Artifacts to plan, distinguish and connect those outcomes become essential.
  • Collaboration: It’s very difficult to integrate federated dev leads into routine (weekly?) handoffs from design to the central dev team(s). Integrating them into critiques that precede handoff? Even more so. Therefore, collaborative value rises to the fore: do these libraries justify a separate handoff meeting? How about a separate planning meeting, and how often (tip: it ebbs and flows)?
  • API alignment: In this example, web code undoubtedly becomes the reference library, especially if synced strongly with design specs. However, results are uneven in getting iOS and Android dev leads to use that reference. To that end, I’ll work involve web dev lead to lean into handoffs and coordination too.
  • Designer VQA: No different, if spread more widely across the calendar.
  • Release synchronization: Releases aren’t synced, and trying to sync them is the wrong focus. Federated releases tend to lag central ones by months, quarters or even a year. So your communication challenge is two fold: set expectations clearly and clearly communicate the status of each item in each library to those that use them.

Case study: IBM Carbon as the federated dream

I’ve not contributed to IBM Carbon, but have watched its impressive progress for years. IBM Carbon supports code libraries across many web frameworks, each with a public code repositories that provide a clear glimpse into it’s evolving catalog.

In 2022, I analyzed commit activity across public repositories of IBM Carbon’s core libraries supporting Vanilla HTML & CSS, React, Angular, Svelte, Web components (now integrated into the core library) and Vue. The libraries emerged over years, with varying levels of activity and growth over time.

Table of IBM library metadata as of 2022, including age and quantity of core maintainers, recurring contributors, and light/one-time contributors

Per contributor commits made evident one or few core maintainer(s), additional contributors and a long tail of one-commit wonders.

Conversation with Josh Black, the dev lead in charge of the React library at the time, confirmed that React served as the reference implementation and the other libraries were not supported by the core team and released independently. A recent conversation with current team members confirmed that the central team had taken responsibility for and integrated the Web Components library. Other library implementations live on.

Github.com commit activity across React/Vanilla, Angular, Vue, Web components, Carbon for IBM.com and Svelte libraries, scaled to match vertical axis scale

Commit activity across repos visualized over time revealed trends like:

  • Some libraries like React + Vanilla and then Carbon for IBM.com evidenced persistent activity, whereas Angular seemed to fade in 2021.
  • As React + Vanilla spiked in late 2018 (due to generational change?), Angular similarly spiked as Vue and Web components entered the scene.
  • Vue and Web Component activity was lower than React + Vanilla , yet seemed continuous enough to trust each was being maintained.
IBM Carbon’s main documentation site (left), alongside screenshots of Storybook site navigation for various implementations

Despite my best intentions, there are situations where a federated dream is possible. However, my gut says IBM Carbon is more an exception than rule.

Virtually every other design system in the world will not achieve or even aim for IBM’s massive scale. Yet, seeing the models at play — central versus federated, web versus native, growth and strategic change over time — offer lessons we can all take away.

So get at it. Clearly communicate your system’s scope of core library support. Chip away at collaborative best practices to agree on API, critique each other’s ideas, test and ship as one. We’re in this together.

--

--

Nathan Curtis

Founded UX firm @eightshapes, contributing to the design systems field through consulting and workshops. VT & @uchicago grad.