5 Ways Facebook Scales Their Design System
Product designer Jeff Smith shares insights, expert advice, and actionable tips based on the design process at Facebook.
What is your definition of a design system?
In the context of product design, I think of design systems as a cohesive set of components—like buttons, cards, navigation elements, and icons–that are used across a product’s design and engineering teams.
A design system is not a style guide. Yes, the components should be consistent with the visual language of the app and somewhat aspirational, but they should also map to implemented code and be flexible enough that both designers and engineers actually use the system.
At a company like Facebook, with literally hundreds of designers and thousands of engineers working on a single app at any given point in time, a design system helps ensure our designs are consistent and that duplicative code is minimal. A design system can also act as a channel to communicate to designers changes in our visual language or the addition of new components.
How is the Facebook design system set up?
I’ve contributed to and heavily benefited from our systems and can speak to the basic structure of how they are set up: we have a library of components easily accessible to designers in the day-to-day design tools they use that map directly to the components that engineers use in their tools. Distribution of these components is automatic and updated regularly. Our design tool and systems teams are tightly coupled (they’re a part of the same team), and thanks to their outstanding work, the integration of these components is near seamless. Our tools make it incredibly easy to search for a component, access a component documentation, quickly add a component, and read which component was used in any designer’s specs.
What are 5 points to consider if you want your design system to scale?
Design systems don’t work if they’re not used. A good design system should strike a balance between being visually aspirational for the design team, while still being highly functional for the team’s engineers. Along those lines, here are a handful of considerations when setting up a design system:
1. Tie your design system to development
Design components should attempt to map to functional code—or soon-to-be functional code. Having the designed and engineered components share the same functional and aesthetic traits will help encourage teams to not write or implement duplicative code. It’s also very helpful if the system shows the implemented status of a component—even if the component isn’t live yet. If a designer knows this, she might be able to have her engineer build it instead of the design systems team.
2. Create guidelines and documentation
There should be a single source of truth. Whether it’s a folder for a small team or a bespoke system built by a large company, the assets should live in a single place. They should also be well documented. Often, there is a mixed level of experience and many points of view within a design team. So it’s important to provide clarity within the system itself when a component—say, a segment controller—should be used or not used.
3. Make it accessible and easy to use
A design system should be easily accessible for everyone using it, whether designer or engineer. At best, it should be baked directly into the tools designers and engineers use. In my opinion, one of the huge advantages of Framer X is that component libraries are a core part of the tool via the Store. Framer decided from the outset that design systems were going to be a foundational part of Framer X, and they built the Store as part of the initial release.
4. Assign ownership and include stakeholders
Consider having a single, centralized team that owns your design system. Early on at Facebook, we had something of a committee that owned our component library. New components could be suggested by any designer and would get folded in as they were approved by that loosely assembled committee. This was problematic as we scaled, for a number of reasons. Unless someone is responsible and held accountable for that system, everything tends to go out of date quickly and rarely gets the level of resourcing that’s required to make it effective.
“A caveat: while in my experience it’s best to have a single team responsible for a system, it’s just as important that people who don’t own the system are meaningfully able and encouraged to contribute back to it with their input.”
5. Assess your design system by the strength of its code base
From the outset, consider evaluating a design systems team’s performance on the amount of the app’s code base that is actually composed of their components. This may sound counter-intuitive from a designer’s point of view, but if your design system isn’t well-crafted visually or is inflexible, the designers using that system will quickly start diverging from the system. Subsequently, the code their engineers create will bloat or diverge completely from the components that were built by the systems team. The more effective a design systems team is, the more the code base should reflect that system’s components.
If you think your product team would benefit from having an integrated workflow, read Framer Head of Product Tom Watson’s views on building internal design systems or talk to us about getting your company set up with a Team Store in Framer X.