Config 2024: Design systems best practices
Summary
TLDRThe 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
😀 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.
🚧 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.
🎯 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.
🔬 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.
👥 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.
🛠️ 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.
🔄 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.
🤝 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.
🌟 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.
📊 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.
Mindmap
Keywords
💡Design Systems
💡Figma
💡Complexity
💡Priorities
💡Validation
💡User-Centric
💡Component Props
💡Nesting Instances
💡Variables
💡Community
💡Metrics
💡Collaboration
💡Breaking Changes
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]
関連する他のビデオを見る
Step by Step UX Product Design Roadmap for Beginners 2024 (100% Free)
How to Become a UI/UX Designer in 2024 - Step by Step Roadmap 💯| Saptarshi Prakash
Config 2024: How we redesigned Figma (KC Oh, Ryhan Hassan, & Joel Miller, Figma)
WHATSAPP System Design: Chat Messaging Systems for Interviews
Best Web Design Resources 2024
Ep049 - Service Design en el Sistema de Diseño - Karen Gushiken - La suma de DesignOps
5.0 / 5 (0 votes)