Facebook Design System: Component Library

Context

Design systems scale fast. Documentation, naming conventions, and component architecture don't always keep up.

When I joined the Facebook Design System (FDS) team at Meta, the system was already powerful, but the language around it was inconsistent. Components had different naming patterns across design and engineering. Documentation varied wildly in quality and depth. Designers struggled to find what they needed. Accessibility guidance was scattered or missing entirely. And as FDS expanded to serve more product teams, these gaps weren't just friction, they were blockers.

I saw an opportunity to do the thing most designers skip: make the system legible.

Approach

I came in as the content layer, not just writing about components, but shaping how they were named, structured, found, and understood.

Naming, first. Inconsistent component names were creating silent inefficiencies across design and engineering handoffs. I designed and socialized a standardized naming framework: formulas, rules, and style guidelines that could scale across the entire library. Getting buy-in meant workshopping it across disciplines, not just shipping a doc, so the framework landed as a shared standard, not a top-down mandate. It was eventually adopted across 50+ components.

Then, alignment at scale. The Entity Header, a foundational component used across Profile, Groups, Events, Dating, and Fantasy Games, had diverged into five different interpretations. I organized and facilitated cross-product workshops that brought all five teams into the same room to align on a single, unified design. Five product areas moving to one shared component means fewer duplicated efforts, faster launches, and a more consistent experience for the people using Facebook every day.

Documentation as a design artifact. I wrote 73 component documentation pages for FDS's documentation platform, and led motion and animation designers on 10 more. Each page wasn't just a description. It included accessibility patterns: ARIA labels, semantic markup, keyboard navigation, and WCAG compliance guidance built directly into the component spec. I treated documentation quality as a design standard, not an afterthought, and that bar became the new benchmark for the team.

Finally, findability. A well-documented system is only useful if people can find what they need. I led a reorganization of the FDS component taxonomy, restructuring a 200+ component library around intuitive categories so designers could navigate it without prior system knowledge. For example, grouping all action-triggering components under a single Actions category made it immediately clear what a component was for and how it was intended to be used. Less time searching means more time building.

And the details that hold it together. Some of the hardest design system problems look small on the surface. Placeholder text is one of them, seemingly minor, but deeply inconsistent across a system at scale in ways that quietly erode quality and trust. I independently designed a Placeholder text strategy for FDS: frameworks for how placeholder text should work, feel, and read across components, backed by cross-team workshops to align stakeholders on an approach that was genuinely complex to land. The result was a reusable, consistent pattern adopted across 130+ design system components.

Outcome

The work touched every layer of how FDS operates:

• 50+ components now follow a unified naming framework, eliminating cross-discipline inconsistency in a way that, as one engineering partner put it, "will pay dividends for years"
• 73 documentation pages created for a system used by 630+ designers and developers, with accessibility guidance embedded at the component level
• 5 product areas aligned on a shared Entity Header component, reducing duplication and accelerating launches across Facebook's core surfaces
• A reorganized 200+ component library with clearer information architecture, making components faster to find and easier to implement correctly
• A unified Placeholder text strategy adopted across 130+ components, elevating quality and creating a reusable pattern for one of the system's most overlooked design decisions

Insight

The through-line across all of this work is that systems problems are often language problems in disguise. The naming inconsistencies, the documentation gaps, the findability issues, none of them were engineering failures. They were communication failures. And communication failures have communication solutions.

What I'd do differently: involve engineering partners earlier in the naming framework process. We got there eventually, but earlier alignment would have shortened the socialization cycle significantly.

The thing that stuck with me most: good documentation is a form of accessibility. When a component is well-named, well-documented, and easy to find, it's not just efficient, it's equitable. Everyone on the team, regardless of their familiarity with the system, can use it confidently.

That's what a design system should feel like.