Meta, we have a range of design systems that serve a variety of products. Most of these are focussed on consumers. I work on Geodesic, our Business Design System that is leveraged by all of our business tools and applications.
Over the last year, I transitioned into being an owner of the design system I was once a consumer of. This meant that I was uniquely positioned to recognize some of the pain points felt by our partner teams.
One of the biggest challenges we faced was figuring out how to scale. We have a number of design systems at Meta and customer workflows often cross through them. We’re now responsible for a range of new products and focus areas that didn’t exist when the system was conceived. Whilst our scope has broadened, our team remains relatively the same small size.
How our team was set up
When the Business Design System first launched in 2019 we served ~25 tools. Most of which could be accessed from one hero product — Ads Manager. It was a highly fragmented experience, but enabled users to create, edit, test, and manage ad campaigns. Based on the amount of traffic running through the surface and the opportunity for improvement, we prioritized this pilot product to get the system off the ground.
The existing consumer-facing system, “Facebook Design System” didn’t effectively fit business needs.
Users need to complete very different tasks in a business mindset when compared to that of a consumer. We built a system that prioritized things like tight information density, and tasks like filtering, sorting, data visualization & charts.
This worked really well for a while. Teams were able to build experiences for most use cases using the Business Design System. We set a goal of 80% system coverage, allowing 20% flexibility for custom use cases; most of which could leverage system styling in one way or another. But even with this focus on one core product, there were always gaps that stretched beyond that 20%.
In my previous life on a product team, I worked on creative tools within Ads Manager. Our design system focused on core components like tables and text inputs. All valid choices for a design system centered around business need but, not so great when you need to design things like an image media library or crop experience.
In the screenshot above you can see how within a single product like Ads Manager we were catering to drastically different use cases. Even at this small scale serving one core product we were starting to see notable gaps in the system.
But then things changed
Over the last couple of years, our organization has scaled significantly. We’ve grown from a world in which we were centered around one core product to a place where we support several distinct product areas equally.
We’re now the sole design system that supports many distinct use cases. Our core product set includes:
Ads Manager — an advanced advertising product that provides users with a high level of transparency & control.
Meta Business Suite — a product targeted toward small businesses that prioritize simplicity & efficiency. It includes messaging tools that share patterns with consumer-facing messaging products.
Commerce Manager — retail tools that enable users to build and manage an online sales experience on our platforms.
Creator Studio — tools that support the creation, editing & monitoring of creative assets in one place.
Without expert knowledge of these use cases, it might be difficult to understand how these experiences are similar vs where they diverge. But similar examples can be found in everyday life.
Let’s zoom out a little
Popular chef Alton Brown has spoken at length on the topic of unitaskers vs multitaskers. He believes that “a cook is only as good as his tools and ingredients,” favoring robust multi-purpose hardware like the OXO measuring jug. He launched a one-man attack against single-use items like the avocado cutter, describing them as “strategic gifts for people you don’t like”. Whilst a 20-year vendetta against kitchen gadgets might be a little extreme, the concept of single-purpose vs multi-use items translates well to everyday life.
Take your local DIY superstore. At a high level, they provide the base materials, tools, and equipment needed to improve your home. Lots of these items can be used to complete different tasks. For example, a screwdriver might be used to fix the plumbing under your sink, hang a picture on the wall, or build a fence around your garden.
But there are some things that are more task-specific, like a paint roller. In the paint & decorating department you would expect to find an expert who should be able to provide information on all of the different products. As with any specialist, their expert knowledge of one department may not scale to another like lighting and electrical. And neither may the tool apply to any of those tasks.
If we apply this back to the design system, the atoms and molecules (like the screwdriver) continue to serve the system well. This means that the visual styling (e.g. typography, colors, and spacing) and base-level components (e.g. buttons, inputs, and headers) can scale across all of the use cases that we serve.
But we’re seeing an increasing need to build custom solutions (like the paint roller) that support the needs of individual products without scaling to other experiences. Some patterns that are designed for similar tasks don’t work for every use case. For example, the table component designed for our advanced advertising product would be more effective if simplified for products targeted toward smaller businesses.
As a centralized systems team, we prioritize components & frameworks that deliver value across the board. This can leave gaps for individual products. Whilst we could diverge and build individual systems, maintaining cross-workflow consistency is key.
We need to evolve our way of working by resourcing, enabling, and encouraging teams to unblock themselves whilst retaining the integrity of the design system. We’ve started working with several partner teams to explore the possibility of piloting a product system within their product area.
What this could look like
A product system sits at a level above the design system. It builds on top of the foundations of the design system as a product focussed sub-system that is owned by a product/platform team. This enables teams to build product-specific patterns that leverage the benefits of the design system (consistency, efficiency, performance, etc) without the dependence on resources from the core system team.
By scaling the impact of our team we believe that we can scale the impact of others.
Whilst we’re still operationalizing this concept, we’re exploring a three-point plan to get this off the ground:
- Building a network of trusted experts — advocates for the design system who can help identify the gaps in our system and work towards getting them resolved.
- Documenting everything — producing guidance to help product teams design and build like system teams.
- Defining process & setting expectations — helping partners plan for support, maintenance, and engagement with their product partners.
As a centralized system, this isn’t an automatic switch we can flip. Our partners have become dependent upon the model in which “we are here to serve you”.
We believe that our team is at an inflection point — we’re struggling to scale. Teams need to ship quickly whilst reaping the benefits of the system. We need to tap into and empower talent across the organization in order to ease the dependency upon ourselves.