A Product System is a design system maintained and built by a product team. It's a federated approach to extending the Facebook Design System (FDS), enabling teams to build patterns for their specific area of expertise, contributing back to the larger system.

Facebook App Design — now more than 700 Designers — has outgrown the system one small central team can operate. Meeting the needs of every product team would require a system without constraint or a design culture of rigid adherence to the rules.

The status-quo was that Facebook App designers were leveraging FDS on a best-effort basis. There was no rigid adherence to the system, because FDS wasn't designed to solve every problem. Our “Core” library is comprised of many small building blocks that enable designers to create new patterns and interactions, without needing to re-imagine fundamental UI. This level of flexibility meant that many interaction patterns existed, but without the definition and standardization that would enable them to be shared.

FDS — the team — has expertise in defining and maintaining holistic systems, but we need partner teams to create, test, and iterate new patterns that evolve our offering. We needed teams to work and think more like systems designers, and teams need more flexibility to grow and change their UI. We had three goals for this program:

    1.) Create app-wide standards for re-usable Interactions and UI patterns.
    2.) Improve Design alignment with FDS and Product Teams.
    3.) Increase code adoption of Core FDS UI components.

The first step was helping teams dissect and organize their products into standardized groupings of people problems. The result is a shared taxonomy that helps teams align their components to clear objectives. This exercise enabled FDS to more deeply understand the nuances of each product and helped teams zoom out to see their work from a more holistic point of view.

Once teams had their taxonomy, it served as a living to-do list. For every component and pattern the team identified, they were responsible for creating Usage Guidelines (documentation) and distributable design elements (components). These artifacts would become canon alongside our Core UI library to help other teams better understand and leverage their systems.

In order to achieve our goals while maintaining consistency across all systems, we created standards that new contributions are measured against. We require that designs are leveraging existing FDS components, adhere to our usability & accessibility standards, are complete with Usage Guidelines, and have successfully mapped to a people-problems centric taxonomy. We ensured this by doing the work with teams, but eventually we had more teams lined up for our workshop than we had time to host; word got around. As a team of three — one Designer, one Content Strategist, and one DPM — we couldn't keep up.

We now have a playbook for teams to do this work without us. For their Usage Guidelines we provide structured writing templates that ensure every new contribution will follow a familiar format. For designs we provide examples, templates, and standards for creating engineering specs. Now we host weekly reviews to vet all Product System contributions which helps us scale our effort and decrease the amount of time we spend.

Over the course of 2020 I lead 17 workshops with over 113 designers, content strategists, and PMs resulting in over 84 Usage Guidelines and 172 Components. This was an 845% increase in component creation from our 2019 output and a 250% increase in guidelines written in total.

This work is only the beginning of how FDS is evolving our design system. We are a crazy small team (4 designers) delivering buttons to billions of people every day. If you're interested in hearing more about Product Systems, I was recently interviewed on The Design Systems Podcast – Episode 25; give it a listen!