Config 2024: Design systems best practices

Summary

The Figma Advocates, Anna, Alexia, and Chad, delve into building effective design systems. They emphasize core principles like caution in complexity, grounding in priorities, and validation before execution. The discussion includes actionable tips on Figma features, insights on user-centric design systems, and the importance of communication between designers and developers. They also highlight the significance of community building and data-driven decision-making for the continuous evolution and adoption of design systems.

Takeaways

• 🌟 **Embrace Complexity with Caution**: Design teams often face challenges with complexity, which can lead to rigid design systems and higher maintenance costs.
• 🔍 **Prioritize Wisely**: Aligning design systems with organizational priorities such as efficiency, consistency, and communication helps guide decision-making and reduce unnecessary complexity.
• 📊 **Validation Before Execution**: Teams that validate changes before full implementation avoid disruptions and maintain trust in the design system.
• 🔧 **Iterative Approach to Design System Updates**: Start small, gather feedback, and iterate to find the best solution for the design system.
• 👥 **Designer and Developer Collaboration**: Open communication between designers and developers is crucial for a successful design system.
• 🔗 **Leverage Figma Features**: Utilize Figma's component sets, props, and variants to manage complexity and create a user-centric design system.
• 📚 **Documentation and Resources**: Provide champions with resources like educational materials and documentation to help spread awareness and understanding of the design system.
• 🤝 **Building a Community**: Identifying and engaging champions who are enthusiastic about the design system can encourage others to adopt it.
• 📈 **Use Analytics and Metrics**: Both qualitative and quantitative data can provide insights into the usage and health of the design system, guiding future improvements.
• 🔄 **Adapt and Evolve**: Design systems are not static; they require ongoing attention and updates to support new use cases and technologies.
• 📝 **Plan and Communicate Changes**: When updating the design system, plan the changes, test their impact, and communicate them clearly to avoid confusion and disruption.

Q & A

What roles do Anna, Alexia, and Chad have at Figma?

Anna, Alexia, and Chad are designers and advocates at Figma. They come from design backgrounds and work with the Figma community to enable teams by sharing feedback, tips, tricks, and resources for using Figma.

What is the main focus of the discussion led by Anna, Alexia, and Chad?

The main focus of the discussion is on building Design Systems in Figma, including core principles, insights from their experiences, and actionable tips on Figma features for Design System journeys.

Why is approaching complexity with caution important in building Design Systems?

Approaching complexity with caution is important because introducing too much complexity can create a more rigid design system, which may require more time and resources for maintenance and enablement. It can also make it harder for designers to understand and utilize the system effectively.

What is the significance of being grounded in priorities when building a Design System?

Being grounded in priorities helps reduce complexity and guide decision-making, ensuring that the design system aligns with what's most important to the organization. It also helps in identifying quick wins and long-term projects, preventing the team from becoming overwhelmed.

What does Alexia mean by 'keeping a consumer-first mindset' in Design Systems?

A consumer-first mindset refers to focusing on the actual users of the design system, which may include designers or developers. It's about ensuring that the design system is user-friendly and meets the needs of those who will be using it in their work.

How can teams avoid introducing unnecessary complexity in their Design Systems?

Teams can avoid unnecessary complexity by not taking optimization too far, avoiding the creation of overly customizable components, and by not overproducing their design system to mimic larger organizations unless it's necessary for their own needs.

What is the purpose of using a prioritization matrix in Design Systems?

A prioritization matrix helps teams identify quick wins, long-term projects, and potential additional projects that can be squeezed in if time allows. It ensures that expectations are realistic and helps prevent the team from becoming overwhelmed.

Why is validation before execution important when making changes to a Design System?

Validation before execution is important to prevent shipping changes that may need to be rolled back, which can cause additional work and confusion for users. It allows for an iterative approach to ensure the changes are the right approach before full commitment.

What is the relationship between props and variants in Figma's component sets?

Props and variants work together in Figma's component sets to create a user-centric design system. Variants help designers visualize different states of components, while props guide them on parts they can override, such as icons or text content.

How can teams ensure that their Design Systems are aligned with both designers' and developers' needs?

Teams can ensure alignment by maintaining open communication channels, involving developers early in the design process, sharing knowledge and resources, and utilizing Figma's features like component descriptions and Dev mode to facilitate collaboration.

What are some strategies for building a community around a Design System?

Strategies include identifying and engaging champions who are enthusiastic about the design system, providing educational resources, recognizing and rewarding participation, and fostering two-way communication between the Design Systems team and users.

How can feedback and metrics guide the next steps of a Design System?

Feedback and metrics, both qualitative and quantitative, can provide insights into user behaviors and needs, help identify areas for improvement, measure the health of the design system, and inform decisions for maximum impact.

Why is it important to approach Design Systems as an ongoing journey rather than a one-time project?

Design Systems need to evolve with the products they support, requiring ongoing attention, collaboration, and adaptation. This includes incorporating design and code updates, and addressing changes in technology, use cases, or rebranding.

What are some best practices for managing updates in a Design System?

Best practices include making updates in a way that doesn't disrupt the source of truth, using branching for work in progress, planning and testing changes thoroughly, and communicating these changes effectively to prevent confusion for system consumers.

Outlines

00:00

😀 Introduction to Design Systems in Figma

Anna, Alexia, and Chad introduce themselves as designer advocates at Figma, emphasizing their role in assisting the Figma community with design systems. They outline the purpose of the video: to explore core principles and insights for building design systems in Figma, with the aim of guiding viewers through their design system journey. The advocates highlight the importance of sharing feedback, tips, and resources, and they set the stage for a deep dive into design systems, including actionable tips on Figma features and considerations for the audience to apply to their own design systems.

05:03

🚧 Approaching Complexity with Caution in Design Systems

The first principle discussed is to approach complexity with caution. The advocates explain that design teams often face challenges when they introduce too much complexity, leading to a rigid design system that is difficult to maintain and enable. They use examples such as over-optimized components and overproduced design systems to illustrate how complexity can hinder understanding and usage by designers. The principle encourages teams to be mindful of the balance between optimization and simplicity to ensure a more usable and flexible design system.

10:04

🎯 Grounding Design Systems in Organizational Priorities

The second principle focuses on being grounded in priorities, which helps reduce complexity and guide decision-making within a design system. Priorities can vary, such as efficiency, consistency, or communication, and they should align with the organization's goals. The advocates suggest using a prioritization matrix to identify quick wins, long-term plans, and potential side projects. They stress the importance of revisiting and evolving priorities as the organization grows and changes, ensuring the design system remains relevant and effective.

15:06

🔬 Validation Before Execution in Design System Development

The third principle is validation before execution, which the advocates recommend for teams making changes to their design system. This iterative approach involves starting small, testing, gathering information, and iterating towards the best solution. The importance of this principle lies in preventing the deployment of changes that may need to be rolled back, which can cause additional work and confusion for users. The advocates highlight the need to ensure that changes are beneficial and well-received before full commitment.

20:08

👥 Building a User-Centric Design System

Alexia discusses the importance of keeping a consumer-first mindset when working on design systems, focusing on the actual users of the design system, which include designers and developers. She addresses the issue of complexity and the evolution of Figma's features, such as component sets with props and variants, which can be a playground for complexity. Alexia encourages teams to consider the needs of their users and to challenge the complexity they create, ensuring that the design system remains clear and accessible.

25:10

🛠️ Leveraging Figma Mechanics for Design System Efficiency

This section delves into specific Figma mechanics that can be used to enhance the efficiency of a design system. Alexia talks about managing large sets of variants, the use of component props to reduce complexity, and the importance of clear naming conventions. She also touches on the use of nested instances and the potential for information overload, offering tips on how to manage complexity while maintaining discoverability for designers.

30:13

🔄 The Dynamic Nature of Design Systems

Chad emphasizes the dynamic nature of design systems, which require ongoing attention, collaboration, and adaptation. He discusses the inevitability of change in design systems, such as supporting new use cases or technologies, and the importance of not disrupting the source of truth when making updates. Chad also highlights the use of branching in Figma to manage changes without affecting the main library, ensuring that work in progress does not confuse or mislead users.

35:15

🤝 The Importance of Communication in Design Systems

Communication between designers and developers is highlighted as crucial for the success of a design system. Chad discusses the importance of including developers early in the design process and maintaining a two-way street of communication. He cites a survey indicating that many front-end developers wish to be included earlier and work more closely with designers. The summary underscores the benefits of collaboration and the need for shared understanding and resources between teams.

40:15

🌟 Building a Community Around Your Design System

Anna talks about the value of building a community around a design system to aid in scaling efforts and increasing adoption. She discusses identifying champions within the organization who are already enthusiastic about the design system and can help advocate for it more formally. Anna also mentions the importance of providing educational resources and recognizing and rewarding participation in the community, which can lead to a larger impact on the organization.

45:16

📊 Utilizing Feedback and Metrics to Guide Design System Development

Alexia discusses the importance of using both qualitative and quantitative data to guide the evolution of a design system. She talks about leveraging comments and branching in Figma for asynchronous discussions and suggests structuring qualitative feedback for easier synthesis. Alexia also touches on quantitative metrics, such as adoption rates and usage analytics, and the use of Figma's REST API for more advanced data needs.

🛑 Managing Deprecation and Change in Design Systems

The final paragraph addresses the need for careful management of deprecation and change within design systems. It discusses strategies for introducing updates and deprecated elements, such as using 'deprecation mode' to visually indicate components that need updating. The importance of planning, testing, and communicating changes is emphasized to prevent disruption and confusion for users of the design system.

Keywords

💡Design Systems

Design Systems are a collection of reusable design components and guidelines that ensure consistency and efficiency in product design. In the video, the theme revolves around building and maintaining Design Systems in Figma, emphasizing the importance of collaboration, iteration, and community engagement to create a robust system that serves both designers and developers.

💡Figma

Figma is a cloud-based interface design and collaboration tool that is central to the video's discussion. It is used as the platform for creating and sharing Design Systems, allowing teams to work together seamlessly on design projects and systematize their design processes through features like components, variants, and libraries.

💡Complexity

Complexity in the context of the video refers to the challenge of managing the intricacies of a Design System without making it overly rigid or difficult to use. The script warns against introducing too much complexity, which can lead to maintenance issues and hinder the system's usability, as illustrated by the example of over-optimization of components.

💡Priorities

Priorities are the fundamental goals and values that guide the development and direction of a Design System. The video emphasizes grounding a Design System in clear priorities, such as efficiency, consistency, or communication, to ensure that it aligns with the organization's needs and supports decision-making processes.

💡Validation

Validation in the video is the process of confirming the effectiveness and appropriateness of changes to a Design System before fully committing to them. It is part of an iterative approach that helps prevent the negative impacts of rolling out changes that may not be well-received or functional, as mentioned in the script's discussion on avoiding 'whiplash' for users.

💡User-Centric

A user-centric approach focuses on designing with the end-user in mind. In the script, Alexia discusses the importance of keeping a consumer-first mindset, meaning that the design system should be built with the needs and usability for its actual users—designers and developers—in mind, rather than just the end consumers of the products.

💡Component Props

Component Props in Figma are a way to parameterize components, making them more flexible and closer to code. The video explains how props can reduce the size and weight of components, increase discoverability, and guide designers on which parts of a component can be overridden, playing a key role in managing complexity within Design Systems.

💡Nesting Instances

Nesting Instances in Figma refers to the practice of using instances of components within other components. While this can increase discoverability, the video warns that it can also lead to information overload and complexity, especially when combined with variants and props, and advises being mindful of how these are presented to designers.

💡Variables

Variables in Figma are used to manage and centralize design aspects like colors, typography, and spacing. The script clarifies the distinction between variables and styles, emphasizing their combined use for complex UI decisions, and discusses the importance of using variables to feed directly into UI layouts for consistency.

💡Community

Building a community around a Design System is highlighted in the video as a way to scale efforts, create a network of support, and increase adoption. Champions within this community are identified as enthusiasts and influencers who can advocate for the system, provide feedback, and contribute to its evolution.

💡Metrics

Metrics in the context of Design Systems are used to measure the effectiveness, adoption, and health of the system. The video discusses both qualitative and quantitative data, emphasizing the importance of understanding how the Design System is being used and where improvements can be made, with examples including the use of Figma's design system analytics and third-party plugins.

💡Collaboration

Collaboration is a recurring theme in the video, stressing the importance of communication and partnership between designers, developers, and Design System maintainers. Effective collaboration is portrayed as crucial for the successful implementation and evolution of a Design System, ensuring that all stakeholders are included in the process.

💡Breaking Changes

Breaking Changes refer to updates or modifications that may require significant adjustments from the consumers of a Design System. The video discusses the inevitability of such changes and the importance of careful planning, testing, and communication to minimize disruption and ensure a smooth transition.

Highlights

Introduction of the Figma design advocate team emphasizing their role in enabling teams through feedback and resources.

Core principles for building Design Systems in Figma, starting with acknowledging different stages of the Design Systems journey.

The challenge of introducing complexity in design systems and the importance of caution to avoid rigidity and maintenance issues.

Common reasons for over-optimization leading to complexity, such as supporting too many use cases with a single component.

The impact of complexity on designers' ability to understand and apply design system components effectively.

The principle of grounding in priorities to reduce complexity and align design system efforts with organizational goals.

The use of a prioritization matrix to manage design system projects and maintain realistic expectations.

Validation before execution as a strategy to prevent large-scale changes that may need to be rolled back.

Importance of a user-centric approach in building a design system, focusing on the needs of the design system's users, not just the end consumers.

The evolution of Figma's component features and the potential for increased complexity they introduce.

Strategies for managing large component sets, such as splitting them into smaller, more manageable sets.

The role of component props in reducing design system complexity and improving alignment with code.

Tips for working with nested instances in Figma to avoid overwhelming designers with too many options.

The one-year anniversary of Figma's variables feature and their integration with design systems.

Differentiating between variables and styles in Figma, and using them in combination for complex UI decisions.

The importance of scoping variables in Figma to reduce clutter and ensure consistent UI application.

Encouraging collaboration between designers and developers in the context of design systems.

The significance of communication in the design system workflow and the benefits of including developers early in the process.

Utilizing Figma's Dev mode and component descriptions to facilitate better communication between designers and developers.

Building a community around your design system to aid in scaling efforts and increasing adoption.

Identifying and nurturing champions within your organization to advocate for the design system.

Creating educational materials and resources to empower champions and facilitate the spread of design system knowledge.

Recognizing and rewarding participation in the design system community to encourage contribution and adoption.

Using feedback and metrics to guide the evolution of your design system and make data-driven decisions.

The importance of maintaining a data-driven approach to design systems to build trust and perceived value within the organization.

Adopting a layered approach to metrics in design systems, aligning with organizational priorities and monitoring design system health.

Leveraging Figma's commenting and branching features to capture qualitative and quantitative data on design system usage.

The availability of Figma's REST API for advanced data needs and custom dashboards to track design system adoption.

Design systems are not static and require ongoing attention, collaboration, and adaptation to remain effective.

Planning, testing, and communicating changes in the design system to minimize disruption and stress for consumers.

The inevitability of breaking changes in mature design systems and strategies for managing deprecation smoothly.

Recap of the principles and insights shared for building and evolving successful design systems in Figma.

Transcripts

[Music]

welcome everybody I'm Anna I'm Alexia

and I'm Chad and we're designer

Advocates here at figma all of us come

from design backgrounds and we work with

all of you out there in the figma

community to help enable your teams by

sharing feedback uh sharing tips and

tricks and resources with using figma

we're super excited to dive deep on

building Design Systems in figma

starting with a couple of core

principles that we've gathered from

working with the community and hope can

help guide you no matter where you are

in your Design Systems

Journey we're also going to dive into a

handful of insights from our experiences

working in figma and working with Design

Systems and you we've seen a lot of

great things we've had success and we've

learned from mistakes and both our own

work and from talking with so many of

you and you can expect to walk out of

thee dive with some actionable tips on

figma features as well as some

considerations that we'd love for you to

take on board Your Design system

Journeys awesome well with that let's

start by first grounding ourselves in a

couple of core

principles we want to acknowledge that

we understand everyone here is at a

different stage of their Design Systems

journey and with that means that you

have different needs and challenges but

we hope that by grounding ourselves in

these principles it'll help guide you on

your next steps and figure out which

ideas to run with after this

talk so going to our first principle

approach complexity with caution

probably the biggest challenge that

we've seen design teams experience is

when they inadvertently introduce too

much complexity and the problem with

complexity is that it means that you're

going to create a more rigid design

system and it also means that you'll

also probably have to spend a lot more

time and resources when it comes to

maintenance and

enablement one of the most common

reasons in which teams accidentally

incorporate too much complexity is when

they take optimization too far take the

example of a component where you're

trying to support a ton of use cases and

customizations with a single component

this might feel like a really great way

to simplify Your Design system by

potentially reducing the number of

components that you have but the issue

with this is if you take it too far

it'll be a lot harder for your designers

to understand when and where should they

use this component and what are the

different overrides that you can apply

in combination with it they might spend

more time trying to configure this

component to fit their specific use case

than whatever you had

before another example that we've seen

where teams over introduce complexity is

generally when they roduce too much

their design

system so when you're building things

out in your design system generally for

teams that try to mimic larger

organizations that need to support more

Brands themes platforms Etc you

accidentally add too much to it and as

many of you have probably experienced

it's a lot easier to create new

components Styles and variables than it

is to remove ones that are already

embedded in your design system so it's a

lot harder to make changes the more that

you add to it and as Nathan CTIC pointed

out in a tweet the more you add the more

diminishing returns you'll get as well

so for example the more components you

add to a library the higher the cost and

the less value each individual component

will give to your

consumers so all these examples of

complexity come from a place of good

intention you want to give your product

designers and Engineers the tools that

they need and you want your design

system to be as optimized as POS

possible but if you take these too far

you're going to end up with more

rigidity and complexity making it hard

for you to make changes and also for

your users to understand how to

effectively utilize your design system

which leads me into our second principle

which is being grounded in your

priorities this is going to help reduce

complexity and your priorities are

essentially going to help guide your

decision- making and ensure that

everything that you do to your design

system aligns with what's most important

to your organization

and as you know there's some really key

important things when it comes to

figuring out your priorities and they

could be a bunch of different things as

Pedro Hernandez from data dog says it's

really important to figure out what

these priorities are to see what drives

Your Design system and make decisions

from there some examples that he gave in

this little fireside chat was efficiency

helping your designers and engineers

build faster or maybe it's consistency

creating a more consistent experience

across your different features and

products or it could be around

communication helping designers and

Engineers better understand each other

all of these are valid priorities uh to

ground Your Design system in and you can

have multiple but if you do try to make

sure that you have some hierarchy to

help with your decision- making and

something that's important too whether

you're revisiting your priorities or

you're developing for the first time is

understanding that they're also going to

change over time as your organization

evolves so too should your design system

and your

priorities and also once you've

identified those priorities we've

commonly seen teams use some kind of

variation of the prioritization Matrix

so taking your priorities and from there

identifying what are some quick wins

projects we can start working on right

now what are some things that we can

need to plan for more long term and then

what are some projects we can squeeze in

if we have time and the important thing

about this is that this way way you're

going to prevent your team from becoming

overwhelmed with all the possible things

you could work on with your design

system and also to make sure that your

expectations are realistic that you

understand what is possible within a

given time

frame so your priorities are going to

help you figure out what to do and when

but as for how that leads into our third

principle which is validation before

execution we've seen a lot of success

from teams who want to make changes to

their design system take the time when

it comes to planning out the changes

they want to make and then validating

that those is the right approach before

fully committing to it this is going to

be an iterative approach where you start

small test it out gather information see

if you're on the right track or if you

need to make some kinds of changes and

slowly iterate your way to the best

solution for your design system what's

going to be helpful about this is that

it's going to prevent you from Shipping

a change to your entire organization

only to have to roll it back which is

more work for your yourself but it also

is going to cause a lot of whiplash for

your users and potentially impact how

much people trust your design

system so with all that said there's no

one right way to build your design

system as someone on a Design Systems

team it's your responsibility to figure

out what does that look like for your

organization but by following these

principles hopefully they can this can

help you figure out what are the next

steps and help you build a design system

that fulfills the greatest needs of your

organ organization while remaining as

simple and usable as possible so with

that I'm going to hand it over to Alexia

to talk about our first insight and

discuss how to build a user Centric

design

system thank you Anna

okay so I want to go back a bit on what

Anna was talking about about with

complexity just now and talk about the

first Insight we want to share with you

all today which is keeping a consumer

first mindset every step of the way as

you're working on your Design Systems

and when I mean consumer from first

mindsets in this case I don't mean the

end consumers of the products that

you're building with the design system

but really the actual users of that

design system whether that be designers

or developers and as I mentioned we see

a lot of teams that are introducing a

great deal of complexity in their design

system in the hopes of building

best-in-class Design Systems and we also

see a lot of teams that are getting

really hacky and smart with all the

features that now figma offers um and

it's interesting to see that but I want

to acknowledge first

that design complexity in design system

sorry complexity in Sigma has evolved

over time as we've been building the

product to close that gap between design

and code um if we take components for

instance if you remember we came from a

world of components being bound together

by those forward slashes which created

this kind of friction that I think

limited Us in terms of adding a lot of

complexity that we would organically

grow into it otherwise and we've gone to

a world of component sets that are now

packed with props and variants and all

those other cool things it's really

become a playground for complexity and

we're definitely seeing a lot of teams

taking advantage of that I want to do a

quick show hands in the audience right

now how many of you here have already

created a component set with a 100

variants at some point in their life or

their F experience wow okay I'm seeing

actually a few hands raising which I'm

very surprised by good job guys you hack

the system um I this one is more of a

rhetorical question how big do you think

because we track those things at Sigma

how big do you think the largest

component set in terms of amount of

variance has been since last config so

since a year ago do you think it was

about a th000 maybe

10,000 it's actually over

20,000 um and this image is not the

actual component but it's very similar

in terms of scale so just to give you a

sense of that and when we go to that

deep end and we create so many options

how do our designers even know to find

what they're looking for

when we go there are we trying to just

outsmart figma and be clever in the way

we're working or are we actually just

trying to be clear for our designers and

so in figma the thing that we would love

for all of you to always think is how

can I get to my designers what they need

in their workflow quickly this can

impact how you think about Library

structure it can impact how you think

about component structure or variable

structure and we will not have time to

go through all of it today but I do want

to highlight a few mechanics in figma

that uh you can consider as you're

moving forward so since we're talking

about large sets of variants let's start

there if we take this very schematic

representation of a component there can

we guess what it is is it an input is it

a drop down is it a text area is it a

bird is it a plane is it a super

component if your component is getting

to that stage where you're kind of

getting not so sure what it might be

it's probably time to step back and

challenge the complexity that you've

been creating until that point and I

like to always challenge teams into

thinking about two things when they get

there which is firstly are you certain

that for your users of your design

system all the available options behind

the default version of that component is

going to be crystal clear the moment

that they see it especially if the

naming is quite generic and the second

one is are you certain that every single

variant in that inside that component

set are interchangeably used in the same

use cases by your designers and if the

answer to either of those questions is a

no it might be time to start considering

SPL this component set and it's really

as simple as just selecting all the

options you want out dragging them out

and rebundling them into a new component

set the links will be preserved because

figma keeps the IDS that way and if the

layer structure is the same it'll even

guarantee that overrides will be kept as

your users actually swap the components

around

later now if you're think and you're

pretty convinced that your variants all

belong together but you haven't

leveraged component props yet component

props is may be something that you want

to look at so for those who don't really

know props that way well they're

essentially a way to bring your

components closer to code and in the

process inside figma to reduce the size

and weight by up to 50% if not more

sometimes and when people ask us about

the difference between variance and

props as advocates we like to kind of

schematize that by saying okay variance

is really to help your designers

visualize what are the different states

of your design of your components and

props are there to kind of guide them

and highlight the parts where they can

actually override so things like an icon

they can swap or a text that they can

change the content of

and props are great because they're very

self-documenting they're excellent for

creating that extra discoverability in

the design panel of your designers and

together with props sorry props and

variants together are 100% the best

practice to implement in your Design

Systems one thing to keep in mind with

props when you're using them is that as

you're adding them in your component by

default they're just going to stack in

that Designer experience exactly in the

order you're creating them which may not

be the most intuitive way of aligning

them so you want to take AG of the fact

that in figma when you're creating that

component you can actually drag and drop

and reorder your props and make sure

that the ones that are related to each

other belong with each other so for

instance the best use case is a Boolean

prop that's when toggled on is

activating the visibility of another

prop you really don't want those two to

live in separate parts of the design

panel for your designers you want to

make sure that they're stacked together

and that they're visually intelligible

for your designers naming is another big

thing naming is what can really guide

your designers and so really recommend

to think about making sure that things

are consistent and consider leveraging

things like action-based verbs or

action-based namings when it comes to

things like variants or booleans that

are very self-explanatory as to what the

intended reaction of that Fe that uh

parameter of that component will be for

your

designers okay so at that point let's

say we've done all that we've got some

nice leans components with props we're

happy with them these components might

end up in other slightly larger

components with a bit more complexity

and when that happens in figma you get

the option to do what's called nesting

instances so it's a great way to Bubble

Up every single parameter of that nested

instance at the same level as the

parameter of the M component um this

means that you're essentially creating

even more of discoverability which

sounds great on the

paper the thing is when you get to that

part of complexity in your design system

where you're starting inside the same

component to pile variants and props and

nested instances it's starting to create

that really long side panel for your

designers potentially and really create

an information overload and you really

want to be mindful of that inflection

point past which you're kind of stopping

to create discoverability and you're

starting to make your designers's job

harder when they're trying to use that

component so a couple tips on working

with nested instances where you get that

point the first one is really be mindful

about considering whether that nested

instances absolutely needs to be

surfaced up at surface level um is it

going to be key to the user flows that

your designers are building for instance

if we're doing some kind of form that

check field component is probably not

going to be really needed because it's

going to be toggled on by default all

the time so no need to surface that

another thing you want to think of

is by default if you're repeating

several times the same nested instance

inside a bigger

component what's going to appear in the

drop down of your designers is just the

layer name and so if that compon that

instance is repeated it's just going to

be several times the drop down with the

same name you really want to consider

actually renaming and overwriting the

layer name in the side panel um for

their designers to actually see the

difference and understand a bit better

what they're navigating through and

finally if you're just concerned that

you're running out of space and you

don't want to pile more stuff that your

designers can interact with but you

still want to bring some kind of

awareness to it consider using component

documentation they're just a great space

you can fit in every extra information

that may not belong everywhere

else okay trying to speed front for this

so we' talked a lot about components I

do want to spend a bit of time giving

some love to variables because hey one

year anniversary it's been a year ago

since we release variables thank

you and variables I just want to clarify

a first thing about it which is that

tension between variables and styles I

think when we first announced variables

this time last year a lot of people felt

like they might just simply be a

enhanced version of styles and our

vision at figma is really uh that

they're not contradictory they're better

used in combination with one another

especially when it comes to supporting

more complex UI decisions so in figma

design system world this means that

there are some values that absolutely

should be consumed as individual

variables and these will be values that

will feed directly into the UI layouts

that your designers are building things

like an actual color or you know the

dimension for Noto layout Ping On The

Other Side you've got what we would

consider to be composite variables so

composite variables are made of a

multiple of variables and this is where

Styles come in because Styles can act as

a package for that so for instance

that's like a gradient a drop shadow or

you know most recently introduced a

textile so let's talk about textiles for

a bit since this is the latest addition

to our rooster I know that a lot of you

guys are very excited for textil to

finally come around when we announce VAR

variables uh sorry for text variables to

come around when we announce variables

last year um when it comes to typography

tokens essentially what you want to do

is create those individual variables for

each of your typography parameter inside

your variables table embed those

directly into your textiles and then

you're going to publish that textiles

and it's going to be very seamless in

terms of how your designers actually

consume it it's basically integrated in

their existing workflows but it's all

backed up by the really cool

architecture that you have in

place and if you do that because you're

the one as a design system maintainer

creating that complex architecture you

don't want to feed that complexity to

your designers do you so what you want

to do is consider hiding any sort of

backend quote unquote variables from

publishing and make sure that only the

style is being fed

and when we're talking about hiding

complexity remember I just mentioned

earlier right there will be variables

that you will feed directly through your

designers like colors and number values

for paddings and margins so when it

comes to those you really want to

consider using the scoping feature of

figma if you're not too familiar with

what this is this is essentially what it

looks like uh it's accessible in the

options of your variable panel and what

scoping is is essentially targeting the

application of a specific value to

specific Fields within your designer

interface so for instance if I'm scoping

this border width to specifically stroke

it's never going to appear if my

designer is trying to apply a numerical

value on an oo layout margin and this is

really going to reduce considerably the

Clutter and the amount of noise that

your designers are receiving on their

end allowing you to create as complex

architecture on the back end as you want

but still making sure that they get only

what they need when they need and that

it's going to be consistent UI

throughout as they're building their

interfaces so to rec out what we touched

on

when it comes to building libraries you

really want going back to what Anna was

saying in introduction to challenge the

complexity that you're creating every

step of the way and really think about

that tension between increasing

discoverability for your end users but

also as you're increasing that

discoverability moving down the volume

on all the noise that you might be

creating by using different ways of

leveraging that Sigma side panel and

finally when it comes to variables

Styles hide and scope are your best

friends and we talked a lot about

designer workflows and I realized that

design system is definitely not just

about designers developers are part of

all the decision- making and I'm going

to leave it with Chad to talk a bit

about

developers all right thank you

Alexia all right so when we're working

on Design Systems whether we are the

designers crafting components or we the

developers making them real through code

we need to ensure that we're

communicating with one another

throughout the process that we have a

two-way street of communication

this way we can get our assets to

production faster and support those who

utilize our design

system so we often have different ways

of working though and different

processes different ways of

communicating let's think about the

question who should start the work who

here is a designer that works on a

design system all right awesome so we

need to build and we need to design

those components first right they have

to be designed before they can be built

we want designers to start using them in

their designs it's the way it

is all right well hold on any developers

in the room design system developers all

right awesome we got a few too awesome

so what happens when there's a change in

the API or we need to update the code

that's going to impact what designers

are using maybe the default value is

going to change from medium to large

we're going to update the code and we'll

fix the design later

right well designers did you tell the

developers that the components were

ready to be built and developers did you

tell designers that this changed well

let's remember the importance of

communication in our

work especially with Design Systems

where the designer and developer

workflow is really one of or if not the

most important

partnership and I've experienced these

benefits firsthand when you have great

communication and collaboration between

design development and I've experienced

when there hasn't been such great

communication and we know from talking

with developers in the community that

not all teams have this today we did a

survey with 200 front-end developers

across the product and design system

landscape and we published in a report

on figment.com called decode the

developer now in that 55% of the

front-end developers said that they wish

they were included earlier in the design

process and less than half really only

43 % said that they work with designers

on a daily basis so all of my fellow

designers here our developers want to

work with us they want to understand

more earlier in the process it's okay to

share work early bring developers in and

talk about potential hurdles and

opportunities for alignment especially

in the design system should a prop name

be aligned to code or should we maybe

make it friendlier in design or maybe

code doesn't support something today

that we want to add add to make things a

bit more

clear so let's talk about a

component share the little details

designers we love pill-shaped buttons

right let's use our friendly little

button right here have we thought about

all the different use cases or how we

might adapt it for different things like

when it comes to internationalization

and our text strain gets longer what

happens what should we have our

developers do do we truncate the tax do

we completely switch it out for a

different word just let it run out the

side of the view or do we wrap it and we

turn our pill-shaped button into this

cute little

squirkle but how about usability

considerations also with the visual

treatment are people going to understand

them is this a tab is a navigation bar

is it linear progress steps do people

understand the intent of our components

designs when we share these details and

why certain designc were made or any

feedback from testing it can help us

ensure that we have that alignment as

the components are being built as well

as for when consumers are using the

components in their

designs really what I'm trying to say is

that communication it's everything and

you know whether it's synchronous or

async sharing knowledge and resources

can help everyone get their work done

and Alexia briefly touched about using

the component description Fields when

you are configuring components and figma

but also for our developers let's make

sure that we are utilizing our developer

resources in Dev mode this is where we

can include additional information on

our component such as links to our

storybook docs or maybe we want to put a

link in our component code from GitHub

and load that right up here in

figma and the great thing about this is

even if designers are using these

components in their design and they

detach that component these Dev

resources are going to stay connected so

that way as developers are inspecting

designs built with these components

they're still going to have the links to

the information that they need and they

can always compare back to what the

component is in the design

system so designers let's not just hand

off our files to developers and hope

that there's enough there for them to

work with or wait around for them to

come to us and ask questions questions

let's also leverage some of our

resources leverage our documentation and

use that to help Elevate our

conversations in partnership with our

developers at the end I'm really just

trying to say designers bring your

developers along through the process

developers bring your designers into

your process as well continually

collaborate with one another throughout

the building of your design system and

honestly even in your

products after all as Diana mount

has said great collaboration isn't

throwing designs over a

wall it's designers developers and the

rest of the team collaborating

together so when we talk about

collaborating together and just together

really Design Systems are about people

and this is where as people when we

share our knowledge we share our

resources and we build collaborative

relationships with one another it's

going to help everyone in the process of

getting their work from design to

production faster for both makers of the

system and for the

consumers so now let's hand it back to

Anna who's going to share a bit more

about approaches that we've seen teams

take to help enable and support their

organizations as Chad said Design

Systems are about people and you can

take this way of thinking to how you

approach not only building your design

system but also educating and advocating

for your design system which is why I

want to talk about the value of building

a community around your design system

and how it can help you with scaling

your efforts creating a fly wheel effect

that helps amplify your message and

eventually hopefully leading to larger

adoption of your design system so the

first step to building a community

around your design system is identifying

your

Champions these people are going to be

initially people who are already

enthusiastic about your design system

looking at how you can identify Enigma

you can look for people who have maybe

left comments in your various design

system and Library files or maybe

they've directly made edits to them

maybe someone created a branch and

proposed a new pattern and then you

could also look at library analytics

which we're going to cover on in a bit

to see which teams are already heavily

using your libraries if that's the case

it probably means that there's someone

in that team that's already advocating

for your design system

system and once you've identified these

people reach out to them and see if

they'd be interested in helping you out

in a more formalized way and the idea is

that these people's enthusiasm for your

design system will help encourage others

to learn more about it adopt it and

maybe even contribute to your design

system a second group of people I think

are incredibly valuable to become your

Champions are people who are influential

so this could be from just having a lot

of respect maybe they were at your

company for a while or it could be built

into their role if they're in operations

or if they're a manager on a design and

engineering team they have a direct

impact on their team's processes and

workflows and so even if they're not

initially bought in if you can convince

them of the value of a design system get

them to become a champion for you they

can have a huge impact on how embedded

Your Design system is in their team's

workflows so once you've identified your

Champions the next step is to provide

them with the resources to help them

succeed generally creating educational

materials that they can reuse and

repurpose to help spread the message you

don't feel like you need to create all

these from scratch figma has a bunch of

really great resources on our YouTube

help center and in figma community such

as our playgound files which already

have a lot of important contextual

information on features several of them

related to design systems such as Auto

layout component properties and

variables and built-in examples where

designers can get hands-on experience

learning how to use these we've seen

teams take these playground files and

incorporate their own examples from

their own design system so that teams

can learn and understand how these

features work within the context of

their own

organization or using these as a

template to build their own custom

playgrounds for example Janna Choy and

last year's config talked about how

Capital 1es design system team modeled

their flight simulator off of figma

playground files as a way to create an

interactive onboarding experience to

help teams learn about their design

system and also increase the brand

awareness of their design system as

well and as Chad mentioned earlier

documentation is also a really great

resource you can look into building

those within figma using existing

documentation kits such as this one

pictured here by Oliver Engel that

already have components built out with

common documentation layouts and assets

um with auto layout automatically built

in that you can go ahead and use and

component configurations panel is also a

really great way to just put lightweight

information you can also try to play

around with the formatting to make it

easier to read and Link out to other

docs if they exist in another website in

another figma file or maybe storybook or

GitHub and lastly I want to really

emphasize the value of recognizing and

rewarding people's participation in your

community and contribution to your

design system we've seen some teams

directly incorporate this into their

leveling chart so having designers who

are contributing to your design system

actually have it be incorporated into

their performance reviews because it

does demonstrate and allow them to have

a larger impact on their

organization and then there's also the

option to create external signals if

it's badges or certificates if people

complete a training if you're creating

custom Zoom backgrounds or swag that

people who have participated in your

community can wear and it just helps

them feel like they're a part of

something bigger and it also helps serve

as larger visibility in creating an

external signal to others and just

building awareness of your design

system so I really want to encourage

everybody to look outside of their

Design Systems teams to see how building

a community can help you scale your

efforts in educating advocating for and

eventually increasing adoption of your

design system and also these Champions

aren't just there to advocate for you

they provide a really valuable way of

creating two-way communication between

your Design Systems team and your users

so with that I want to hand it over to

Lexia to talk more about how you can use

feedback and metrics to guide the next

steps of your design

system thanks again and we're

back okay so let's talk a little bit

about getting a sense of where you might

be going next with your Design Systems

um as Anna mentioned if you already have

an Engaged Community around you and

you're probably already getting direct

feedback from them which is a great

place to be now we often also times work

with teams who unfortunately don't work

that closely with their end design

system consumers and that could be for a

multitude of reasons it could be because

um these designers and developers are

just too far scattered around their

organization it could be because there's

a lack of resources but really when it

comes to Design Systems it's kind of

just like user research it's really that

combination of having insights around

behaviors around your design system

comine with uh a solid sense and

grounding in your Design Systems

priorities that together bring you

Clarity on where you should be focusing

your efforts for Maximum Impact

regardless of how much resources you

have at your availability and just like

in user research there's a pendulum of

data that you can play with around your

Design Systems so on one hand

qualitative and on the other hand

quantitative in design system World

qualitative might feel to some like the

most accessible because it's a lot of

one-on-one conversations it's a lot

about digging deep into the functional

needs needs around your Design Systems

um and on the other hand quantitative

can feel occasionally a bit more

intimidating because you know maths not

necessarily are best friends for

everyone um and it does however require

slightly less active engagement from

your design system Community which could

be interesting to some um and

quantitative specifically is really

about that big picture of your design

system about feeling the heart bit of

that design system together just like us

a research they bring the most complete

picture right you'll get your hypothesis

on one side and you'll get the valid and

the other but really any insight is

better than nothing and better than just

making decisions in a vacuum so it's

completely okay to just start wherever

you have the possibility of starting so

let's talk about qualitative data real

quick there are many ways to capture

qualitative data around your Design

Systems Um this can be more or less

structures this can be outside your

figma files they can be inside your

figma files and there isn't a better way

by the way it's just really dependent on

what kind of data you need and this

should infer where you're going to get

it

in figma since you know config we're

talking about figma here uh what we

often see in terms of behaviors is we

see people leveraging comments uh as

external users of the design system

directly onto the design system Library

files and occasionally we'll see people

being even more proactive in their

contribution by using branching to

suggest updates now I want to focus on

commencing very quickly because that's a

feature that is used by many uh I think

it feels very accessible even

non-designers get a feel for how it

works so it's great for asynchronous

discussions in this way but it's also

extremely unstructured as a way of

gathering data if you don't do anything

about it you know like letting things

organically pile up makes them very hard

to synthesize so if you and your team

are thinking or are already using

comment we would really recommend you to

think of ways where your team can better

structure that qualitative feedback that

you're getting and we see for instance

the teams at hubs swop and hassa that

have come to agreeing on specific shared

vocabulary around their feedbacks that

can be shared vocabulary around the

priority levels of the feedback or

things like the expected actions that

should come out of that feedback or it

can be really as simple as just you know

a colorcoded emoji and the reason we're

talking about shared vocabulary or

emojis is really this notion of tags

that you can input directly into figma

comments so good thing to know about

figma comments is there is a search

function that scans across the entire

file if you have a design system Library

any comment or any comment inside that

comment frad that that carries the tag

will be able to be surfaced when you're

doing a search through that file um and

that can be a very very easy way to set

up future you for an easier access of

scanning and consolidating the feedback

you're getting from your

users okay that was for qualitative

feedback let's touch on quantitative

feedback real quick so if you're going

to think quantitative feedback in the

context of Design Systems you're going

to think yourself the questions of

metrics and metrics is a huge question

that there are many many many smart

people out there that are trying to to

crack around Design Systems and not

going to pretend that there's a perfect

way of measuring it once again very

dependent of your organization very

dependent of where you are but it's

interesting to think of metrics in

design system as layers so you

definitely have that one layer of design

system metrics that really is grounded

directly into your organization's

priorities what Anna touched on at the

beginning of this presentation regarding

is your priority about efficiency is it

about driving consistency and can you

measure those things there's another

layer that it's also very important to

look at which is what we would call

Design system health and that is more

about you as a design system team

building a sense of progression on your

design system Journey keeping an eye on

patterns and potentially anomalies that

you pick up on because these can inform

the decisions that you make in terms of

your next steps and it can be things

like measuring scale or you know

adoption and let's look adoption for a

minute because adoption is one that we

see a lot of teams trying to calculate

and keep an eye on so once again no King

metric when it comes to adoption

surprise surprise um we see loads of

Team measuring it differently and it's

completely dependent on their own

context and where they are and what

they're striving for we see teams that

for instance measure adoption by Bread

so in figma terms that's something as

simple as maybe measuring how many teams

out of the total number of teams you

have are actually yes or no using a

design system Library we also see some

teams measuring adoption by depth so

that would be something in figma context

like how much of the files being handed

off to my developer is actually being

covered in terms of the number of layers

by Design system derived layers and if

you don't really know where to start

with adoption there are some really

handy free plugins that you can leverage

on community uh a lot of them take the

form of lining plugins which essentially

scans through the files and just tells

you how much is using or you know

forgetting to use the design system and

some of those some of these come in with

really handy metrics even as far as

percentages which can help you give and

like keep an eye and monitor what's

going on into your design system files

sorry into your actual design files not

design system files because if you want

to pull back and have a bird ey and

actually happening at design system

level there's this other feature you

could look at potentially which I

sometimes discuss with teams and I'm

surprised that not everyone is aware of

it but if you want here it is this is

the new entry point in the new UI um

it's called design system analytics

accessible from any design system

library that is published on figma and

when you open it it gives you

essentially a very quick overview at a

glance of what the usage is looking like

which teams importantly are you actually

using your design system

and if you want to leverage that data

and start getting a bit manual with it

you can also export it as CSV which can

be really handy now all this might still

feel a bit basic for some there are

people out there with much more Advanced

Data need than just that and if you're

part of those teams then you're going to

probably start thinking about apis and

at figma we have a an API called the

rest API there's this really good

article by Pinterest the Pinterest team

that uh dates from a little bit over a

year ago now where they detail how they

actually leveraged figma's rest API

to essentially build fully custom

dashboards that are tailor fit to their

specific ways of measuring and tracking

adoption in their teams and that article

as I said is from a little bit over a

year ago since then two months ago we

just announced that framework that we're

adding some more design system analytics

end points into the rest API so we're

really really excited to see what the

most nerdy teams out there are going to

do with all those new ways of measuring

data potentially in our

apis okay I hope with this brief

overview I've given you a sense of how

figma might be a ble to help you capture

data uh whether it's qualitative or

quantitative because really being data

driven is not only just about driving

more impactful decision- making on where

you're going next with your Design

Systems but it's also going to help you

build trust and build the perceived

value of your design system in your

organizations by unlocking things like

reporting and once we know roughly where

we're going next then the next question

is how the heck do we get there and Chad

is going to talk a bit about

that all right thank you again

Alexia so the great thing about data is

it tells us what's going on and you know

I think one thing that we're always

going to see with our Design Systems

when we look at the data is that nothing

is forever with a design system so let's

think about that for a moment for

everyone here who has worked on a design

system who here has launched it and

thought all right we did it people are

using it let's check that box we're done

we've all felt that right

well just as products change our design

system is going to need to change it's

going to be an ongoing Journey because

we're going to have to eventually

support new use cases maybe new

technology or we might need to address

um components and patterns that become

less and less used everyone remember

giant rotating image

carousels or you may encounter a

Rebrand so in my previous company we

worked through two complete rebrands

with our multibrand design system and

had started Explorations on a third and

when we made updates to things like

color and dimensions and type it was

overwhelmingly straightforward and it

got us most of the way there but there

were still challenges for consumers of

the system to fully inherit or Implement

due to design overrides custom patterns

to address unique use cases or entirely

different code bases used across

products maybe you've experienced this

as well

and while Design Systems may lead

updates in situations like rebrands or

maybe introducing new figma features

into your assets generally Your Design

system is not going to move at the same

speed as your product or its consumers

in fact it really

shouldn't after all maintainers we don't

want to be constantly riffing on our

ideas and Publishing them out creating

chaos for consumers who are just trying

to get their work done wondering well is

this the flavor of the week what should

I be using especially if you're

publishing at speed like this don't do

that generally we want to wait and have

our design system be informed by our

product and by the consumers of it that

way we can incorporate those updates to

support different cases when and where

it's

appropriate and when we do begin that

work it's important to remember not to

disrupt the source of Truth so it could

be truth or truths maybe it's your code

repo maybe it's your main figma design

library in figma what this typically

means is if you're doing a massive

overhaul we may see teams making a

duplicate version of their library and

making those large changes there and

creating a migration path to a new

version or we'll often see large teams

leverage branching which Alexia briefly

touched on

before and some of the benefits of using

branching for making our changes both

small and large is when we look at

something like these tags or chips here

we can make these updates and ensure

that designers who are coming into the

library and using it as a sticker sheet

they're not seeing work in progress and

potentially using components that aren't

ready to be used

yet and the best practice that we see

teams take when they are using branching

is sharing that Dev mode link from the

branch with their developers and then

working together to coordinate when

changes are merged to when the code code

is ready and then they publish that in

harmony with one

another but of course let's acknowledge

that not everything we explore intends

to see the light of day maybe not now or

maybe not ever well if we're working in

branches it's actually really handy

because we can just archive our branch

and preserve all of our work at that

point in time it becomes locked from

future updates but we can always revisit

it and restore it to pick our work right

back up in the future so here we can see

we were looking at a contribution for a

danger input type or notification type

and all we had to do was hit restore and

we could pick the work right back up

addressing the comments that were left

on the

component and as Anna mentioned in the

beginning really with all updates we

need to remember that it's important to

have a plan test and of course

communicate what those changes are so we

can hopefully prevent unnecessary stress

for the consumers of our systems

especially if this is a breaking change

because we know that as your systems are

going to mature you're going to have to

introduce breaking changes at some point

in time it does become inevitable and

this is where our planning testing and

communication becomes

essential so often times what we see

teams do is start out with a

straightforward component and use that

to plan and test how they're going to

incorporate updates taking note of

things that are added or removed what

gets renamed what might impact other

components that utilize that one then

they'll move on to a bit more advanced

component and then to the biggest most

complex one they have maybe they'll also

bring in example uh design files and

Test new components within

them the big thing to ask at the end is

does it still work great publish it

you're good to go but if there's a

chance it breaks or people need to make

updates and Chang

this is where we need to think about how

are they going to know what they need to

do and if you tuned in to framework by

figma a couple of months ago Talia and

saz from the Verizon design system team

gave an insight into their deprecation

process and their figma technique that

they call deprecation mode and we've

already seen some teams start to mimic

this out there in the community as well

as models outlined in article posted on

medium by Steve Dennis A couple of years

ago and both of these really outline

great approaches and we've seen teams

start doing these where they leverage

component naming and introduce visual

visual references such as components or

shaded areas that need to be updated

making it easy to identify what needs to

be updated and switch to something new

so definitely check out Verizon's talk

on the figma YouTube channel and look up

Steve's article on

medium so remember everyone our Design

Systems they're not static they're going

to require ongoing attention

collaboration and adaptation and they're

going to need to incorporate those

design updates and those code updates as

they go and PJ onori really summed this

up well saying it's inevitable that

almost everything you make in the system

no matter how good will run its course

now he acknowledges that interface

paradigms change new platforms show up

and the product that you built the

system for

evolves so as you embark on those

inevitable changes remember the

principles that Anna shared at the

beginning approach complexity with

caution always be grounded in your

priorities and seek validation before

execution these are principles we've

outlined from talking with so many of

you in the community who have found

success with building and growing Your

Design Systems so thank you for sharing

Ing and allowing us to connect and learn

from you so with that let's recap what

we've covered

today all right we're going to keep the

screen up a little bit so you guys can

remember all these different insights we

had but just as a gist Design Systems

should be built in collaboration between

your design and Engineering teams and

between your Design Systems team and

your consumers and you should always

continue to re-evaluate and iterate and

remember that nothing is forever

and as we wrap up we just want to take a

minute to thank everyone out there in

the design system Community who is out

there sharing resources publishing

article publishing plugins publishing

files not that every article plugin file

whatever resources you put out there we

see it we appreciate it we share it

around us with other teams so thank you

so much for doing that and in the spirit

of sharing we've left a little link that

should bring you to a design file where

we've actually input all the resources

that we touched on throughout the

presentation and with this thank you for

listening thank you thank you

[Music]