How Meta builds design systems - Davy Fung

Name: How Meta builds design systems - Davy Fung
Uploaded: 2025-01-22T06:30:06.000Z
Duration: 1 h 58 min 55 s

Enterprise Tooling Design System Overview

Introduction to the Enterprise Tooling Design System

The speaker discusses their role in the Enterprise tooling design system at Meta, which supports all internal tools.

They aim for 80% adoption of a popular initiative called "fix aons," akin to hackathons focused on fixing issues.

Davey introduces himself as a product designer at Meta, working on Enterprise Design Systems for nearly three years.

Changes and Experiences in Design Systems

Davey reflects on his experience over three years, mentioning the evolution of design systems and his transition between teams.

He describes moving from a team focused on monetization to one that supports a broader range of developer tools.

The current team manages thousands of internal tools, ranging from simple data-gathering applications to complex task management systems.

Internal vs. External Tools

Davey contrasts his previous consumer-facing system with his current focus solely on internal tools used by employees.

He notes that while some components may overlap between systems, they are primarily designed for different audiences—internal versus external users.

Pressure and Feedback Dynamics

Working on internal products reduces pressure compared to consumer-facing products due to fewer users (around 70,000 - 100,000 employees).

The smaller scope allows for quicker deployment and feedback cycles; changes can be implemented rapidly without extensive testing periods.

Rapid Iteration and User Feedback

Internal tooling enables faster iterations; experiments can be conducted within weeks rather than months as seen with external products.

Quick adjustments allow for immediate feedback implementation, enhancing user experience based on real-time input from employees using the tools regularly.

Design System Insights at Meta

Interface Feedback and Design Considerations

The current interface around Riverside is not a rich black, which could enhance the perception of elevation in design. Suggestions include making the background darker for better contrast and visual hierarchy.

Team Structure and Contributions

The design team consists of approximately 6 designers, with a one-to-one ratio of designers to engineers, impacting velocity as designers often lead while engineers follow.

There is a strong developer advocate community that actively participates in hackathons to fix bugs and improve the system, contributing significantly despite fewer designer contributions.

Hackathon Frequency and Participation

Meta organizes hackathons every six months, alternating between general hackathons and "fix-a-thons" focused on resolving issues within the design system. Engineers are the primary contributors during these events.

Evolution of the Design System

The design system was initiated over five years ago by leadership aiming to modernize legacy systems and create foundational components for product-specific designs. This evolution has led to more flexible components that allow for tailored execution across products.

A shift towards pattern-based approaches has been noted, with an emphasis on developing local or satellite systems that utilize core components effectively.

Sharing Best Practices and Community Engagement

An internal Design Systems Summit was established two years ago to facilitate knowledge sharing among contributors, allowing discussions on scaling practices suitable for larger organizations like Meta.

An internal Facebook group exists where hundreds of designers and engineers share resources related to design systems, fostering community engagement and collaboration on best practices.

Design Systems and Community Feedback

Importance of Design Systems

The discussion emphasizes that updating design elements is not just about implementation but also about educating others on design systems.

Sharing new concepts, such as spacing tokens, allows for community feedback and collaboration on design practices.

Case Studies and Pilots

A recent pilot project involved testing a new variable font, with case studies documenting challenges and benefits to engage the community.

After conducting pilots, teams assess pros and cons to determine if the approach is suitable or if alternatives should be explored.

Team Collaboration in Tooling Projects

The code connect project involved collaboration with a larger tooling team to facilitate trials across different teams, including Instagram's design system team.

If a tool proves valuable across multiple teams, it may become an opt-in resource rather than a mandatory requirement.

Metrics and Workflow Evaluation

Evaluating time spent on new tools compared to previous workflows can be challenging; qualitative surveys help gauge effectiveness.

Engineers often prefer direct access to code snippets over using design tools like Figma due to efficiency concerns.

Token Management Challenges

Internal tooling has been developed for managing design tokens since existing market solutions are not permitted for use due to security issues.

Efforts are made to integrate with Figma’s token management features despite limitations in their implementation for specific needs.

Inventory of Design Tokens

Each design system team operates independently regarding token management; there is no centralized inventory of reusable tokens.

While alignment with overarching brand systems is desired, individual sets of tokens remain separate for safety reasons.

Brand System Considerations

Variability in brand attributes can lead to mismatches in application; vibrant colors used in branding may not suit functional purposes like error messaging.

Design System Collaboration and Accessibility

Flexibility in Color Design

The design team collaborates with the brand team to ensure flexibility in color choices, particularly regarding chroma adjustments for specific colors.

The team utilizes a standard documentation site for color tokens, which aids in maintaining consistency across designs.

Accessibility Tools and Compliance

An internal plugin is being developed to help designers check contrast ratios and compliance with accessibility standards (specifically WCAG Level AA).

The plugin also detects if designers are using tokens from different libraries, addressing common issues of copying and pasting components that may lead to inconsistencies.

Adoption of Design System Components

There is no strict enforcement of the design system; however, token adoption is high among users. Foundational components see good usage but some components like list cells are often recreated by users.

Users sometimes prefer building their own components due to specific needs such as longer lists or additional functionality not provided by existing components.

Engineering Collaboration Challenges

Engineers who actively participate in the community often seek guidance on utilizing existing components effectively. They may request modifications or express needs for additional properties.

Feedback loops exist where engineers communicate their requirements back to the design system maintainers, allowing for asynchronous support and potential integration into the system.

Team Collaboration Techniques

Weekly meetings facilitate collaboration among team members working on similar products. Discussions focus on component development and critiques.

Design critiques involve presenting questions about existing components rather than fully developed designs, fostering a collaborative environment where ideas can be tested against current code implementations.

Collaboration and Design Systems in Engineering

Weekly Critique Meetings

The team conducts weekly critique meetings to address engineering challenges, focusing on the proper construction of components and APIs. Designers are invited but not required to attend these sessions.

Feedback and Collaboration Challenges

There is a common struggle among team members to provide constructive feedback while building design systems or prioritizing work effectively.

Flexibility in Component Development

The speaker emphasizes flexibility in component creation, suggesting that as long as components comply with the design system's core elements, unique compositions are acceptable even if they don't strictly adhere to one-to-one component usage.

Time Constraints in Component Creation

Developing new components can be time-consuming, often exceeding a month due to necessary steps like critiquing, demoing, and quality assurance by engineers and designers.

Custom Compositions Acceptance

The speaker expresses openness to custom compositions developed by team members as long as they utilize existing design tokens and components responsibly.

Adoption Metrics and Design System Flexibility

Differences Between Organizations

The speaker reflects on their experience at smaller organizations compared to Meta, noting that there was a stronger push for strict adherence to design systems previously.

Avoiding Bottlenecks in Launches

It's crucial for teams not to block progress due to rigid adherence to design system feedback; this could lead to missed launch opportunities.

Measuring Adoption Effectively

While some teams focus heavily on adoption metrics (e.g., aiming for 100% adoption), the speaker argues that other factors such as revenue impact or time savings should also be considered when evaluating success.

Metrics Implementation at Meta

Component Adoption Measurement Tools

At Meta, tools like linting plugins were used to measure component and token adoption within designs. This helped ensure compliance with established standards.

Dark Mode Compliance Testing

The team conducted specific tests for dark mode compliance by switching interfaces and identifying failures in color schemes that did not align with the system requirements.

This structured approach provides clarity on key discussions regarding collaboration within engineering teams focused on design systems while highlighting important insights into metrics related to component adoption.

Web Development Focus and Component Management

Web First Approach

The team prioritizes web development, focusing on creating tools that are responsive for both web and mobile platforms.

Internal tools like Wiki are essential for usability on mobile devices, ensuring accessibility for users who rely on work phones.

Previous experiences at Disney involved developing across multiple platforms (web, native mobile, television), making the current focus on web simpler.

Sunsetting Components

The discussion revolves around deciding when to sunset a component versus updating it; this is a new approach for the speaker's current team.

A newer component with enhanced functionality may replace an older one if it can be easily swapped in the codebase.

Collaboration with engineers and designers is crucial when proposing to swap components, leading to successful transitions.

Legacy Component Management

For legacy components not from their system, community engineers have been effectively running code modifications to replace them over the past year.

The team's collaborative environment allows community members to contribute fixes without needing core designers or engineers to manage everything.

Risks of Not Sunsetting Components

Keeping outdated components in the codebase poses risks as developers might inadvertently use older versions due to alphabetical ordering or lack of awareness.

Design System Updates

When updating design libraries, components are labeled with indicators like emojis (e.g., triangle emoji for upgrades available), allowing users to recognize changes without immediate deletion of old components.

This strategy helps users understand what has changed in the library while providing time for them to adapt before removing old versions completely.

Communication Strategies

The speaker discusses using gentle messaging instead of alarming signals (like red dots), which can scare users into thinking they need urgent action regarding updates.

AI and Design Systems Perspective

There’s skepticism about AI's utility in generating UI elements within design systems; however, there’s potential for automation in other tasks related to design systems.

Automation in Design Tasks

The Role of AI in Design Automation

Discusses the potential of AI to automate repetitive design tasks such as changing layer names and assisting with Auto Layout, though the speaker has not yet implemented it internally.

Highlights using AI for content writing, specifically to truncate long blurbs on documentation sites and articulate key points more effectively.

Mentions the utility of AI in identifying hidden layers and addressing duplicative linting, emphasizing its role in enhancing accessibility which is often overlooked by teams.

Challenges with Current Tools

Points out that relying on designers to opt-in for plugins can hinder efficiency; suggests background checks could be more beneficial.

Reflects on a desire to reset workflows due to outdated systems, indicating a need for improvement after five years of use.

Refactoring vs. Rebuilding Component Libraries

Evaluating Component Libraries

Notes an inflection point when component libraries reach two years old, raising questions about whether to refactor or rebuild them entirely.

Emphasizes that refactoring components does not impact engineering directly and can be done incrementally without major disruptions.

Current Library Audit

Describes an ongoing audit of the library with plans for refactoring specific components rather than starting from scratch.

Expresses concerns over complexity and performance issues within existing libraries due to incremental builds over time.

Library Management Strategies

Organizing Components Effectively

Shares insights on managing all components within one library but acknowledges performance issues arising from this approach.

Advocates for breaking down components into specific pages or files as recommended by Figma, aiming for better organization and reduced mistakes.

Learning from Peers

Discusses the importance of collaboration and sharing work among team members to gain diverse perspectives on building design systems.

Highlights that different teams may have varying approaches regarding naming conventions, structure, and usage of props, underscoring the value of collective input.

Learning and Documenting Design Systems

Team Refactoring and Documentation Practices

The speaker discusses their team's structured approach to building, emphasizing the importance of documenting refactoring processes to ensure consistency and repeatability.

They highlight personal practices of documenting naming conventions in Google Docs, facilitating collaboration for future team members.

Sources of Inspiration

The speaker mentions that they primarily seek inspiration from external sources rather than internal ones, particularly through content on platforms like LinkedIn.

They note a shift in reading habits over time, indicating a preference for longer-form content on Medium and Substack instead of traditional books.

Recommended Resources for New Designers

The "Atomic Design" book is identified as a foundational resource that effectively articulates design principles relevant to design systems.

While no specific design system books are recommended beyond "Atomic Design," the speaker emphasizes the value of podcasts as rich resources for insights into various topics related to design systems.

Community Engagement and Networking

The speaker encourages following their podcast series, which covers numerous useful topics and insights gathered from their experiences and those of others in the field.

They suggest connecting on LinkedIn as an effective way to stay updated with community discussions and shared resources within the design systems niche.