The Fallacy of Federated Design Systems
Avoid the damage and distress of glorifying the wrong model
Avoid the damage and distress of glorifying the wrong model
My inquiry of “So, how can I help?” was met with design system distress.
Six months back, the design system team disbanded. In its place, a “federated model” of design and engineering staff (none relieved of other responsibilities) was designated to drive design system progress. Yet, the system stalled. Assets are aging. Trust is shaken. Heads are scratched as everyone wonders what to do. Putting a prospective project at risk, I bluntly responded “Well, you deallocated people responsible for doing the work. What did you expect?”
In 2015, I established three models of forming teams for scaling design systems: solitary, central, and federated. The article progressed through each, scoffing at solitary, considering central, and favoring federated based on the section’s positioning and proportional length.
Since then, design system practitioners throughout our community (see articles as examples below) have leveraged and extended the models to frame thinking, promote opportunities, and sell stakeholders on how and why to pursue systems in a federated way.
Favoring federated was and is wrong. Since publishing nearly a decade ago, I’ve been clarifying, nuancing and even contradicting what I wrote. It’s time to set the record straight.
In this article, I’ll dig into how federated is not a choice, it’s a facet. In practice, it’s never pursued first and never without central investment. In most cases, it’s optional and its outcomes can be so expensive and frustrating that it’s not worth it. Even worse, positioning federated as a primary objective anchors so many stakeholder myths to unwind that it damages system potential and even threatens its existence.
Federated dreams are not most people’s reality
Organizations in general and system practitioners specifically strive to involve people. The “People” part of design systems is essential, effortful and often difficult. My colleague Jina Anne has made that people point in her long running, well known Design Systems are For People talk.
For, of, and by the people?
Couple that focus on people with expectations of governance, and conversations quickly veer into principled territory. A design system shouldn’t be just for the people, but also of and by the people, right? In many mindsets, that implies of and by all the people.
But from a practical and historical perspective, all people making the design system simply isn’t how it ends up working. Design systems I encounter are made by directly responsible, dedicated teams or individual designer(s) and/or developer(s). Aka, “Central people” making a design system as a product, serving products.
Sure, there’s also services supporting a community to steward participation, influence and even contribution (those are different concepts, mind you). Those contributions matter, right? I guess so. However, virtually all productive output is delivered by central people.
Federated-only exceptions distract and muddle conversations
I can hear a few of you now: “I got federated-only to work!”
Sure, maybe in a limited context or temporal endeavor. Those situations are inconsistent with how I define design systems: deliver foundations and UI components via evolving, ideally mirrored design and code libraries that scaling organizations depend on.
Sure, maybe it works if exceedingly rare conditions hold. I’m aware of a fellow expert that combines inarguable talent, sharp intelligence, supreme confidence, and unassailable authority to drive product outcomes without a central design system team. I’ve read righteous claims of a small group of collaboratively-tight, high-performing, coding-capable designers evolving a product without a design system at all (there are systems in there somewhere, nevertheless). The federated dream comes alive!
Federated people don’t and can’t prioritize (extra) system work
However, my experience suggests a different reality. The hope for aligned outputs emerging from independent federated contributors driven by altruism is at best misplaced. At its worst, it’s recklessly naive. I see organizations orient priorities to evolve products, individuals align to those priorities, and no one set aside an allowance for system contribution.
My consulting across 80+ design system spans diverse setups: product or marketing, adopter communities large (100s) or small (10s), design-only or design-and-code, etc. Every organization sought system success and was willing to invest.
How many had a wizard oozing confidence, tight-enough collaborative culture, or other secret that made federated–only magic happen?
In the spirit of Steve Carrell’s memorable portrayal of disdainful expert Mark Baum in The Big Short: “Zero. Zero. Zero percent [of design systems thrived without centrally allocated people to make and support it].”
None experienced federated-only success without a investment in central capacity. Federated-only is not a choice.
Federated is a False Choice
So let’s get to it. Why isn’t federated-only a choice?
The diagram’s arrangement implies choice, unfortunately. Should your design system be centrally managed or a federated community?
The article bridged to federated misleadingly with “if a central model doesn’t fit, there is a more complicated path to pursue…” The implication was clear: choose federated! Ugh. Positioning central versus federated as a mutually exclusive choice was a mistake.
Embracing federated doesn’t mean avoiding central
That’s thinking in binary, described well in Black and White Thinking:The Burden of a Binary Brain in a Complex World. Just because there’s two options doesn’t make them mutually exclusive. It certainly doesn’t mean that if federated is desirable, then central isn’t. Shift that or to an and.
In my practice, successful design systems always have a central team and always seek the participation (and, if worth it, contribution) from a federated community. Evolving models to invest in both to varying degrees.
Being only federated doesn’t work
When discussions get tough, bracket the conversation with an uncomfortable extreme. Injecting an intentionally impractical assertion can establish the value of centrally allocated people:
It’s not as if we should create an empty Figma library file, empty code repository, and empty ZeroHeight instance and encourage contributors to have at it.
Instead, central people setup architecture, create tools, define process, create playbooks, and support the platform. 100% of the time, those central people make and maintain the core components too.
Don’t choose federated. Instead, add federated. Gradually.
As you consider your system’s future, consider how to progressively add federated contribution gradually to a centrally supported endeavor.
If federated work really succeeds, you may even tune down central investment as circumstances permit. A stable and complete core architecture (when the design system isn’t going through a period of generational change) can evolve with federated contributions coupled with a lower investment in central curation. Don’t hold your breath, however. I’ve rarely experienced conditions in the past decade where either stable or complete hold for long, let alone both.
Federated is optional.
Some teams gradually incorporate federated influence, such as via tiers and shared libraries. However, many systems thrive and create tremendous value without a focus on contributions. Some systems even transcend contributions, shedding responsibility to let the community fend for itself.
I revere Atlassian’s design system and have cited the Atlaskit code catalog for years as a vibrant melting pot of contribution. Their community-supported Editor component hit major version 197 recently! Yet, Editor seems a concern now separate from the core system, which explicitly limits contributions to fixes:
We are currently accepting … fixes … At this time, we are unable to take [small enhancement, major enhancement, and new component or pattern] contributions.
Their rationale cites familiar values: build for widely shared need, ensure quality, avoid being a bottleneck. Just because Editor is a component, serving and evolved by a community doesn’t mean it “goes in the design system” (even though it’s clearly in a system). I love it!
Federated Anchors Damaging Myths
Stakeholders anchor assumptions the moment they see that diagram.
An anchoring bias is a cognitive bias by which stakeholders rely heavily on what’s first presented (and how they interpret it), and new information is referenced relative to that anchor rather than considered objectively. This distorts new information, impairing influence and decision making.
Many of those assumptions are damaging myths, including:
⚓︎ Everyone can, should and will contribute.
⚓︎ Every component made goes in the system.
⚓︎ Anyone that makes UI is capable of contributing.
⚓︎ All UI components of any level of composition are welcome.
⚓ ︎Federated contribution is a primary success indicator.
⚓ Federated gets you a design system for free.
When educating stakeholders, you want to be on the front foot. You want to confidently build a rational case so they understand impacts, opportunities, risks and efforts ahead. You don’t want to position yourself as saying “No” repeatedly to correct mistaken assumptions of superiors that approve or deny the system’s existence.
So, you face a choice: let the anchored myths stick, or contradict your stakeholders and unwind the myths. Weighing anchor is difficult, effortful and worst of all, risky. Let’s dig in to each one.
Myth: ⚓ Everyone can, should and will contribute.
Fact: Few if any contribute meaningful new features and enhancements.
Wait, if almost no one will contribute, then this isn’t made by everybody?
(Yes.)
That’s bad.
It can be very, very good to have central team makes a library everyone depends on. A central team can focus on details, solicit shared needs, architect small parts into a cohesive whole, document and release it, and support others. Federated people don’t, can’t and/or won’t do that.
Myth: ⚓ Every component made goes in the system.
Fact: Almost all components made across teams don’t belong in the system.
Wait, so the system will have barely any components our organization makes, and most of the UI everyone makes isn’t going to be shared?
(Yes.)
That stinks.
Design systems offer assets that serve widely shared needs and prioritize features that can evolve in a stable way to serve many groups.
You should expect that teams will still need to create considerable UI using system assets. You should also expect that most components that teams make — even low level components — will not serve a need shared by other teams, and thus don’t belong in any system.
Myth: ⚓ Anyone that makes UI is capable of contributing.
Fact: Most contributors lack systems experience generally and knowledge of this system’s architecture specifically to contribute efficiently.
Wait, so people can’t contribute because you say they lack skills?
(Yes.)
That’s terrible gatekeeping and risks morale.
Design systems are about business value. If the cost to steward a contribution (effort of all participants plus maintenance and opportunity costs) exceeds business benefits (value of reusable assets and staff personal development), then the contribution is a bad idea. Only do it if it’s worth it.
Additionally, identifying directly responsible individuals (DRI) and teams leads to the clarity needed for a satisfying workplace. Positioning capable and talented staff in DRI roles is a strength.
Finally, central systems practitioners are responsible to support system integration, pair with others, and curate contributions that do arise. Sharing knowledge and resolving incidents responsively are ways of how system practitioners can be a rising tide lifting everyone’s capability.
Myth: ⚓ Components of any level of composition are welcome.
Fact: Design systems are visual foundations threaded through a library of usually lower-level UI components that equip teams to compose digital experiences on their own teams.
Wait, system UI components are limited to a bunch of low-level widgets?
(Yes, at least in the core library.)
That’s lame and lacks business value.
There’s a ton of business value in that. Have you seen what goes into a system’s button, alert , textInput or modal? Each relies on 10s or 100s of visual attributes across a component’s anatomy, property configurations, layouts, behaviors and other stuff. That’s measurable work, done at a high-level of accessible quality, packaged as design and code libraries so that other teams don’t need to make that stuff.
Myth: ⚓ Federated contribution is our primary success indicator.
Fact: Core libraries made by a central team and containing no contributions from outsiders can be extremely valuable.
Wait, if our goals are to make a library and enable other people to use the library, how does users that contribute to the library matter?
(Exactly.)
That feels wrong.
When semi-annual or annual planning season comes along, federated contribution is rarely a published objective and never an existential one focusing a significant proportion of central people’s capacity (although efforts to like Figma Shared Libraries are pursued secondarily).
Instead, federated investments are often on the periphery, deprioritized in favor of other efforts. It’s never a galvanizing singular focus of a system’s team relative to responsible people making system outputs and enabling others to successfully use them.
Myth: ⚓ Federated gets you a design system for free.
Fact: Successful federated activity requires a non-trivial capital expense and ongoing operational costs to make and maintain a platform, support federated people, and curate contributions. It’s not free.
Wait, so I need to pay for a group of people to build a platform and make it all work when seconds ago I thought this was largely free?
(Yes.)
That’s expensive.
Going federated in the long run means more than composing a designer’s playbook (often not read) and developer’s CONTRIBUTING.md. There’s far more work needed.
Once built, using platforms isn’t a long leap for developers. Coding in systems should be familiar: build modularly, manage dependencies, run test suites, commit to repos, review a pull request. Tasks are familiar (if with some system spice) such that once setup, running a platform can be predictable. However, there’s still the work of curation, quality and approval for core engineering maintainers to do.
Familiarity is less true for designers, where diverse tasks carry unfamiliar system-specific expectations. Audit and synthesize shared needs. Compare existing component examples. Devise an API. Document usage. Produce and test high quality Figma assets. The bar is higher and skills are different than “normal product design work.”
Learning takes practice and collaboration time with system experts (read: operational cost) to produce good things and grow individually. I love that work, which offers tremendous intrinsic reward. But it’s time consuming. You reap what you sow.
Did you notice how verbose it is explaining away those myths? Did you even read the text above, or did you skim it as your mind drifted?
Now, imagine you are a stakeholder that had to listen to someone — often lower level or from a different group — contradicting what you believe. So be careful. Explaining what you don’t get with federated contribution isn’t just complicated. It risks irritation, boredom, distraction, insufficient time, indignation, and dismissiveness. Such emotions are not to be trifled with.
References to Central v Federated Models
The following posts all reference the concepts of central and federated models described in Team Models for Scaling a Design System.
The Salesforce Team Model for Scaling a Design System by Jina Anne, 2015
Designing a Design System (a step by step guide) by Louis Henrich, 2017
The Paradox of Design Systems by Brendon Manwaring and Josh Mateo, 2018
Design Systems: Why Do They Matter? by Marcela Morales, 2021
Remarkable UX Design Teams by Isadora Agency, After 2019
How do teams work with your Design System? by Raktim Chatterjee, 2022
Is your design system performing? by Alicia Cheung and Rebecca Holland, 2022
Design Systems: Investing in the People Behind the System by Reneé Cagnina Haynes, 2022
From Vision to Reality: The Roadmap to Building an Enterprise Design System by Oleksii Popovych, 2023
Opening up the Design System for Everyone — The Federated Model by Anirudh Hothur, 2023
Implementing a Design System in an Existing Product byJustyna Klimkowska, 2024
The merits of design systems by Balanet, 2024
How to build effective enterprise design systems for your company by Webflow, 2024
Keeping design system contributions in check by Wart Burggraaf