Davy Fung
Product Design Lead, Design Systems
Davy stands out as the design lead at Meta, heading the expansion of the design system across 40 apps within the Meta Business Suite. His role involves directing a team to manage over 300 Figma components, orchestrating a bi-weekly release program, and ensuring style consistency across Meta's evolving brand and modes. He's the accessibility champion, setting standards for inclusivity and usability in design.
His operational mastery has streamlined the design process, from documentation to release, enhancing product quality and user experience. Through qualitative research and quantitative metrics, Davy has significantly improved design component adoption and efficiency.
With a knack for navigating business transitions and a dedication to design excellence, Davy's leadership over the past two years has not only fostered team growth but has also set a new benchmark in design system management. His blend of technical skill, strategic thinking, and a positive team approach makes him an invaluable asset to Meta.
Previously he worked at:
Disney Streaming
Goodreads.com
CBS Interactive
Can you walk us through the current state of the design system you're involved with?
We have 20 design systems.
The landscape is very expansive, and I'll talk about the optics from outside for design systems at large companies. At Meta, we have numerous design systems tailored to specific products. We even have top level global system called Cross Meta Design System, tying together over 20 unique systems.
The system I'm working on is likely one of the three largest. These three include the Cross Media Design System, the Blueprint (Facebook's design system), and my system, called Geodesic, which serves as the business design system.
The four main components of our planning systems typically include:
Documentation
Figma components
React and native mobile components
Support groups
Documentation, which we manage with our internal docs tool covering design and code. We also have Figma components and, for the web, React components and for native mobile, iOS, Android, etc. The fourth key aspect is the support that we manage within the Meta ecosystem.
Everything at Meta follows a Facebook-centric theme.
Each team has its own internal Facebook group, and we use this platform for different purposes. For example, we have a “Annoucements” group where we post updates and release messages. If I release a new version of a component library, I provide a detailed write-up with screenshots and a link to the release notes, highlighting what has changed, etc.
The second most popular group within for us is the support group. This group is primarily used to process support inquiries that are submitted to the support group. Typically, you list your design problem and propose a potential solution linked to the artifact—whether it's in Figma or code. We use this feedback and support groups as a mechanism to assess incoming work. So, those are the four key elements.
What tools do you use to build and maintain your design system (Off-the-shelf solutions, custom, etc.?)
There are several tools we use to maintain documentation. One of them is called Dimsum, which is ideally designed for both designers and engineers. Figma is the primary tool from a design perspective. We also have other tools that integrate with these two. Depending on your role, there are unique tools available.
However, there's another underlying tool tailored more for engineers. It provides a better view to search React components and iOS and Android components. While linked to our docs site Dimsum, its interface is more user-friendly, in UI docs, the search is more performant, with features like if-then type statements for efficient searching.
These are the three primary tools we utilize. In the world of prototyping, we have our internal tool called Origami, which is more widely known in the design community. Additionally, there's interest in other prototyping tools like Proto Pie, which is gaining popularity and is quite advanced, allowing for more functionalities than Framer, for example.
OUR TOOLS:
Figma
Origami
Proto Pie
Docs site Dimsum
Internal Facebook Groups
React
Do each of these systems have their own team, or do you have one team where designers take care of the rest of the design systems?
At a company of our scale, there's a division of responsibilities. Designers are often assigned to very specific tasks or flows. Each design system team has its own designated designers and, for the most part, their own engineering counterparts. Despite being a design system team, we are divided between design and engineering management. While we collaborate closely, we report to different functions.
How do you balance the need for consistency with the desire for creative freedom among your designers?
One philosophical approach of our business design system is a primary focus on atomic to molecular components. For example, we have many components that are more subcomponent-based. While we do have cards, lists, list components, and dropdowns, we don't focus much on templates. The reason behind that is, that as we support many different products, we don't want to dictate how you compose your page.
The risky part of this approach is that we now have all these different permutations of components that we never assumed would be put together this way. Our intention was to provide this degree of flexibility. We're going to implement an approach, at least from the Figma side for designers. For instance, if we identify a typical template pattern, we could document it in Figma and allow people to grab and reuse it.
Our components are more molecular and atomic in nature, that’s why we experience much broader adoption. People utilize smaller pieces to build their screens. The lowest level of adoption that we aim for, which allows the most flexibility, is a combination of utilizing our tokens in conjunction with the smaller components.
How do you stay true to your vision for the design system, even when faced with external pressures or trends?
Maintaining the quality of work during business changes and layoffs can be challenging. To ensure the best results, we rely on how designers use the tool and gather feedback through the feedback group. In terms of the component libraries, specifically the 'foundations' area, my group, which includes myself and 2 other designers we support components, docs, education and the support channels. Our primary goal is to simplify the components and reduce their complexity.
The number of variants has been reduced by 50% with the introduction of nested instances and other enhancements. People can access the component libraries through our native Figma plugin, but some find browsing the libraries like window shopping for the right component, such as a card for a specific use case. We have implemented a successful method called 'sticker sheets,' although I do not prefer that term.
Our aim is to have a frame or section next to the components that contains all the different permutations of the components listed on our documentation site. We often call this a sticker sheet, which isn't a term I'd prefer to use, but it's stuck here. These instances are automatically filled, and overrides are created to match specific use cases found in the product and our documentation.
Many people use this feature by copying and pasting into their own working Figma filesl. I find this approach useful not only for designers but also for engineers or anyone who wants to understand how everything works. Understanding how people use this tool is a significant aspect.
How does your team collaborate on the design system?
Our systems use a combination of practices.
Designers "On Call"
Roadmaps
JTBD
Figma files
JTBD (Jobs to be Done)
Designers "On Call"
Are you tracking your design system? If you had to choose one metric to measure the success of your design system, what would it be and why?
We collaborate with the product team to support them in solving any issues or testing business hypotheses.
Product designers on specific teams address product design problems, and we support them. As design system specialists, we actively participate because most of us were product designers before. We typically partner via workshops or sprints with design teams. After a one-week workshop or sprint with the team, we often produce a presentation, such as a Google slide deck or Figma prototype. However, we may also create a written medium post that outlines the issues, results, and next steps.
As for tracking tools, we use internal tools, but it's very similar to Omlet. We track many of the same things as Omlet and the tool Pinterest built, which they open-sourced.
Our focus is on Figma/React component adoption and token adoption.
If you could go back and change one decision you made in your design system journey, what would it be and why?
Gaining engineering adoption is the biggest hurdle. The biggest challenge I would say is overcoming that hurdle. To establish a design system team of at least two members or obtain engineering resources, even if they're part-time, is crucial to move away from this only a design initiative.
Do you use any kind of automation or AI tools?
It would be great to see some of the things that Diagram is doing. However, it gets a bit tricky since, due to data sources, Meta might not be allowed to use that technology internally. In such cases, we need to depend on building our models for it.
Where do you see design systems heading in the next few years?
AI might step in to support areas like component creation or documentation. This could allow us to shift focus to other aspects, such as working one-on-one with designers to adopt these technologies. There are numerous facets of support we can explore.
What's one thing you wish more people understood about design systems?
One thing I wish more people understood about design systems and often their complexity, especially in areas like data visualization and accessibility. It's important to explain why these systems are complex and try to make them simpler and easier to understand.
In your opinion, what are the most overrated and underrated aspects of design systems?
In my view, the most overrated aspect of design systems is the belief that they are just about using tools like Figma. It's not just about designers creating things in Figma. The most underrated part is the research aspect and understanding how designers actually work.
A big problem in design systems is the lack of support and not fully understanding how designers use the tools and resources provided. For example, I wasn't initially keen on the idea of a sticker sheet, but I realized if it's something the company uses and is familiar with, I need to accept and support that approach.
If you could have a coffee chat with any person from the design (system) space, who would it be and why?
I'd choose to have a coffee chat with Brad Frost. Before him, I really wanted to talk to Dan Mall, and now chat sometimes on X. I also had the chance to meet Nathan Curtis at a Zeplin/Omlet event during Config, which was great.
Coffee with Brad Frost?
What's one piece of advice that you would like people to remember from this interview?
Design systems are expansive, with various areas to choose to focus on. One aspect I didn't delve too deeply into is that design systems become highly successful when a design ops mindset is applied. Beyond components, whether in Figma or React, the challenge is in how to efficiently distribute and implement them.
What's your favorite thing to do when you are not in design systems?
Sports. In the last ten years, I've been into sports data, whether that's fantasy sports or just tracking how players and teams perform. I think it's another way to engage my mind in something analytical yet different.
Right now, I love basketball. The NBA is my number one, and I've been supporting the Sacramento Kings since I was a child.
