Framework APAC: Office hours: Design systems, AMA

Summary

In this insightful session, Figma's designer advocate Corey and his colleague discuss the intricacies of Design Systems during an AMA session. They cover topics like variable scopes for typography, the use of Q&A for questions, and the utility of modes for translations. They also delve into the benefits of typography variables over styles, the coexistence of design guidelines and systems, and the potential of code connect for accessibility. The conversation provides a rich resource for designers looking to enhance their understanding and application of Design Systems in their work.

Takeaways

• 😀 The AMA session is focused on Design Systems and aims to answer questions related to design systems and recent feature launches in Figma.
• 🔍 Corey, a designer advocate at Figma, is working on variable scopes for typography, which are in the early stages and will have updates in the future.
• 🌟 Figma has introduced new features like typography variables, gradients, code connect data, and library analytics to enhance design systems.
• 📝 Users can utilize text variables for translations and change labels and languages using modes, which is currently possible with existing variable features.
• 🔄 Modes can be used for more than just translations, such as adjusting the tone and manner of text in a single language environment.
• 🔗 Code connect is currently in beta and open for organizations and enterprise plans, aiming to bridge the gap between design and code.
• 📚 Design Systems and traditional design guidelines are seen as complementary, with Figma offering a spectrum of documentation options.
• 🛠️ There is an ongoing discussion about the best practices for documentation, with some organizations using both Figma and external tools like Storybook.
• 🔑 Figma's approach to composite variables, such as typography and gradients, is to use styles that wrap individual variables together for easier management.
• 🔄 The session touched on the possibility of using variables for dynamic font scaling and testing designs across different platforms like iOS and Android.
• 🛑 The AMA session concluded with a Q&A, emphasizing the importance of community engagement and the continuous evolution of design systems in Figma.

Q & A

What is the AMA session about?

The AMA (Ask Me Anything) session is about Design Systems, where the hosts, Corey and Jess, discuss various aspects of Design Systems, answer questions, and talk about recent feature launches in Figma related to Design Systems.

What is the current status of variable scopes for typography in Figma?

Variable scopes for typography are intentionally being worked on and are still in their early stages. The audience is advised to stay tuned for more updates on this feature.

Can text variables be set for text layers in Figma?

Yes, text variables can be set for the value of a text layer, such as a button label, and can be changed using modes for different translations or languages.

What is the role of Design Systems in relation to traditional design guidelines?

Design Systems and traditional design guidelines are complementary. They should work hand in hand, with Design Systems providing a more interactive and scalable approach, while traditional guidelines offer detailed documentation.

How can developers add accessibility to components via Code Connect?

Developers can refer to the Code Connect repository on GitHub for examples on writing different ARA tags for components in various formats like React or Storybook.

Is it possible to use text variables for dynamic font scaling across iOS and Android designs?

Yes, modes can be utilized to test design variations for different platforms like iOS and Android, allowing for dynamic font scaling adjustments.

What is the current stance on composite variables for typography in Figma?

Styles are considered the composite variables in Figma. They allow packaging all typography variables together, making it easier to manage and apply as a whole.

Does Dev mode support low-code platforms like OutSystems?

The script does not provide specific information about OutSystems support in Dev mode. It suggests that more context or details are needed to provide an accurate answer.

Can Figma's Code Connect support other types of development frameworks besides React and Swift UI?

While React and Swift UI are currently supported, Figma is considering support for other frameworks like Angular, indicating that updates on this matter will be provided in the future.

How should a single component library be set up for multiple products with different theming?

A single component library can be efficiently set up using variables with separate modes for different themes. This allows for easy updates and theming across multiple products.

What is the benefit of using typography variables over Styles in Figma?

Typography variables are beneficial for scaling Design Systems, allowing for quick switching between different modes or brands. They also help in syncing better with the code base, bringing design and development closer together.

How does Figma plan to make its products more comprehensive for designers as new features are added?

Figma is aware of the increasing complexity and is focused on making the product more comprehensive. Designer advocates serve as a bridge between the product and the community, helping to educate and share best practices to adopt new features without overwhelming users.

What is the difference between Storybook and Code Connect in the context of documenting design and code?

Code Connect is a native Figma feature that connects code repositories to Figma for documentation, while Storybook is a separate tool outside of Figma for documenting design and code together, with additional features not native to Figma.

How should a team approach modifications to an existing Design System to fit their business needs?

Teams should start with an existing design system framework and gradually customize it as their needs grow. It's important to build on the initial framework, adjusting and scaling it to suit the business requirements over time.

Outlines

00:00

🎨 Design Systems AMA Session Introduction

Corey, a designer advocate at Figma, introduces the final session of an AMA about Design Systems. The session aims to answer questions on Design Systems and recent feature launches. Corey explains the use of the Q&A option on Zoom for submitting questions. The discussion includes updates on variable scopes for typography, which are in early stages, and encourages participants to stay tuned for future improvements. The session also covers how to build and scale Design Systems, with a reminder of a previous 'Design Systems 101' talk.

05:02

🔍 Discussion on Design Systems and Traditional Guidelines

The conversation explores whether Design Systems are replacing traditional design guidelines. The participants agree that both should coexist, with Design Systems providing a spectrum of documentation needs. They discuss the use of Figma's description fields and Code Connect for documentation, alongside external tools like Storybook. The summary touches on the importance of documentation for different needs and how teams use a combination of tools.

10:06

📚 Addressing Documentation and Design System Queries

This section delves into customer approaches to maintaining documentation for Design Systems, including having separate sets for design and developer documentation. The discussion highlights the importance of having documentation that lives both within Figma and externally, such as in code repositories, to cater to different organizational needs and functions.

15:07

🛠 Customizing Component Libraries for Multiple Products

The paragraph discusses strategies for setting up a single component library that can be re-themed for multiple products. It suggests using variables to define aspects like color, size, and corner radius, with different modes for each theme. The summary addresses how to manage design libraries efficiently and the use of variables to adapt components to various themes.

20:08

🔑 Typography Variables and Design System Management

The discussion focuses on the benefits of using typography variables over styles when designing with Design Systems. It emphasizes the ease of switching between different modes or brands and the efficiency of managing individual values. The summary also touches on the coexistence of Styles and variables for ease of application and better syncing with the code base.

25:11

🤔 Navigating Complexity in Design Systems

This section addresses concerns about the increasing complexity of Design Systems and the challenges designers face in understanding and creating them. The speakers acknowledge the product's growing feature set and the role of advocates in educating the community on best practices and adopting new features without feeling overwhelmed.

30:13

📈 Comparing Storybook and Code Connect

The paragraph differentiates between Storybook and Code Connect, explaining that Code Connect is a native Figma feature for linking code repositories, while Storybook is an external tool for documenting design and code together. The summary highlights the overlap in functionality and the unique aspects of each tool.

🏗️ Adapting Design Systems to Business Needs

The final paragraph discusses the challenges of modifying existing Design Systems to fit business needs. The speakers suggest starting with a UI kit and gradually customizing it as the team and use cases grow. They emphasize the importance of not reinventing the wheel and building on existing systems to create a tailored Design System.

🎉 Wrapping Up the Design Systems Day

The session concludes with a thank you to the participants, highlighting the value of the information shared throughout the Design Systems Day. The speakers encourage continued engagement with Design Systems and invite participants to follow up on social media for further questions and interactions.

Keywords

💡Design Systems

Design Systems are a set of reusable design components and rules that ensure consistency and efficiency in product design. In the video's context, Design Systems are the central theme, with discussions on their creation, management, and use in various design and development scenarios. The AMA session focuses on answering questions related to Design Systems, indicating their importance in the current design landscape.

💡Figma

Figma is a cloud-based interface design and collaboration tool that is frequently mentioned in the script. It is the platform where the AMA session is taking place, and it is also the tool that supports the creation and management of Design Systems. The video discusses new features and updates in Figma that are particularly relevant for Design Systems, such as typography variables and code connect.

💡AMA (Ask Me Anything)

An AMA session is an open forum where participants can ask questions on a specific topic. In this video, the AMA session is dedicated to discussing Design Systems, allowing participants to engage with the hosts, Corey and Jess, on various aspects of Design Systems in Figma. The script mentions using the Q&A option in Zoom for this purpose.

💡Typography Variables

Typography Variables in Figma are a feature that allows designers to create and manage text styles dynamically. In the script, Corey mentions that they are working on variable scopes for typography, indicating an area of active development within Figma to improve Design Systems' text element management.

💡Variable Scopes

Variable Scopes refer to the context or conditions under which a variable's value is applicable. In the context of the video, Corey discusses the intention to develop scopes for typography, which would allow for more granular control over text styles within Design Systems, as seen in the script where he says, 'Cory are, variable Scopes intentionally emitted, for typography...'.

💡Code Connect

Code Connect is a feature in Figma that connects design components with their corresponding code implementations. This feature is highlighted in the script as a way to enhance the relationship between design and development within a Design System, allowing for better documentation and collaboration between designers and developers.

💡Accessibility

Accessibility in design refers to the practice of ensuring that products can be used by people with a wide range of abilities. In the script, there is a question about adding accessibility to components via Code Connect, indicating an interest in making Design Systems more inclusive and compliant with standards such as WCAG.

💡Modes

In Figma, Modes are used to switch between different sets of variables, which can be useful for managing different states or themes within a Design System. The script discusses using Modes to change text for translations or to adjust the tone and manner of text, as mentioned when Jess says, 'you can use the mode to change different languages...'.

💡Atomic Design

Atomic Design is a methodology for creating Design Systems based on the concept of atomic theory, where the smallest units of design (atoms) combine to form larger components. The script references Atomic Design as a foundational concept for understanding how Design Systems are structured and how variables are named and organized.

💡UI Kit

A UI Kit is a collection of pre-designed user interface elements that can be used to speed up the design process. In the script, there is a discussion about starting with an existing UI Kit and then customizing it to fit specific business needs, which is a common practice in building Design Systems.

💡Component Library

A Component Library in the context of Design Systems is a collection of reusable components that can be themed or customized for different products. The script mentions the idea of having a single component library that can be re-themed for multiple products, showcasing the flexibility of Design Systems.

Highlights

Corey, a designer advocate at Figma, and Jess discuss Design Systems in an AMA session.

They encourage participants to use the Q&A option on Zoom for questions about Design Systems.

Variable Scopes for typography are in development, with updates to be released in the future.

Design Systems 101 session from the previous week is recommended for understanding how to build scalable Design Systems.

New features like typography variables, gradients, and code connect data are discussed, with a call for feedback on favorites.

Text layers can utilize variables, allowing for dynamic changes in translations and label languages.

Modes can be used for different languages or to change the tone and manner of text in a single language context.

Code Connect is open for beta to organization and enterprise plans, supporting documentation and development.

Design Systems and traditional design guidelines are seen as complementary, with Figma offering tools for both.

Accessibility in components via Code Connect is addressed, with GitHub repo examples provided.

The possibility of using text variables for dynamic font scaling across iOS and Android is confirmed.

Styles are considered composite variables in Figma, packaging multiple typography variables together.

Code Connect supports other development frameworks beyond React and Swift UI, with more to be added.

Documentation strategies for Design Systems vary, with some organizations using both Figma and external tools.

Nested component properties can be selectively exposed in Figma, allowing for customization of instance properties.

Efficient setup for theming multiple products with a single component library is discussed, using variables for customization.

Typography variables offer benefits over Styles, such as faster setup and better syncing with code bases.

Figma's approach to making complex features more accessible for designers includes education and community support.

The difference between Storybook and Code Connect is explained, highlighting their unique features and use cases.

Atomic Design Systems are recommended as a starting point for understanding component structure and variable setup.

Advice on modifying existing Design Systems to fit business needs includes starting with a base and customizing as necessary.

Transcripts

[Music]

So today we're GNA do um oh I give quick

intro so I'm Corey I'm a designer

advocate here um at figma and I'm here

with just today and this is our final

session and we're going to do a AMA

about all things Design Systems so um

what we're going to do is um we have a

chat but um instead of using a chat you

should see a Q&A um option on Zoom so

we'd like you to use that Q&A option

there to write down your questions um

any questions you have about Design

Systems um we'll try to answer them

today y or anything in general

really but yeah specifically for Design

Systems or anything related to um any

feature launches that you guys have seen

um that was released particularly for

free workor we're here to answer

that so Jess is in Singapore and I'm in

yep are vable are sorry our variable so

here comes our first question Cory are

variable Scopes intentionally emitted

for typography

applications that is something we're

working on at the moment so I'd say like

stay tuned that we'll have some more

updates on that so at the moment there

are no scopes for tyover

specifically it's still in its early

stages so I think um really stay tuned

and keep a look out for any future

improvements yeah hope you guys have

tried out the typography variables or if

not maybe you guys have tried building

um a variable Library um we went through

a Design Systems 101 last week um so

hope that gives you a clear idea how to

um build the imun Design Systems and all

the way to scaling them to a bigger one

yeah so of all the features that kind of

launched this week with uh let's say

typography variables we have gradients

we got code connect data um Library

analytics which one was your favorite

love to hear from you guys on the chat

for all of you guys who are just

trickling in um or you know tuning in

sorry um this is an AMA session so any

questions that you have related to

design systems or any framework future

releases drop your questions on the Q&A

um button below

on the zoom navigation and we'll answer

them so Cory this is our next question

can we already have variables set for

text layers given the update to

typography variables in particular in

this use case could be helpful for

translations variable set for text

layers um is this in regards to that

just the text value itself yeah that's

the case and that that's you know um

that currently does work so for text for

text variables you can set them to the

value of like a text layer um so if you

have a a button with a label you can set

the variable um to the value of that

label and you can change the the label

language using modes um depending on the

different translations you have so yeah

that is currently possible with the

current variable yeah you can utilize it

as Norm as per normal with

strings and then you can use the

different modes to change like what

Corey mentioned to the different um

languages any existing or upcoming

features to cater for

translations um we are still currently

working on that I think as for now it's

probably using modes uh under

variables but I think Corey here or if

you happen to see Hiroki um I assume

they've met made some plugins related to

this I don't know right I think you guys

made some plugins um for transl

not really to translations but I think

for like when it comes to modes there's

some interesting things you can do you

can use obviously use a string variable

for um the text the text value of like a

button or something like that um and use

the mode to change different languages

but you can also use that for like a

kind of like a tone and manner like if

you have maybe you just have only one

language your your language is is solely

English but if you want to use um maybe

be a more polite type of like phrasing

and then in some places and more like a

casual phrasing in different places um

you can use modes to kind of change

between those things um as another just

different idea for how to use uh modes

with text when you don't have

translations yeah and should we go down

there um this co connect open to all

figma license type so this is actually

um currently open uh for beta for

organization and Enterprise price yeah

yeah with the trend towards Design

Systems would you think they are

replacing the traditional design

guidelines documents or do you see need

of both Trend towards Design Systems

would you think that they're replacing

traditional what do you mean by

traditional design guidelines I think to

me I mean this is my take but like I

think design both design guidelines and

design sys goes hand inand um I think it

should be I think it should accompany

one uh and another yeah I think it's a

gradient though of like of how much

people need um and again I think for

like fig mother we offer a certain you

know uh spectrum of that gradient as

well when it comes to like writing

documentation inside of figma we've seen

again DBS is example they had some

documentation on the canvas but there's

also things like documenting um and the

description fields and stuff like like

that and another we have COC connect

that also brings more documentation and

even with COC connect people still use

that um in conjunction with like story

book and external tools and stuff so I

think it really depends on your needs I

think there's still going to be maybe an

option for people who have more specific

needs to use something external um or

people who have um maybe not as specific

needs can use something more streamlined

and just depend on only FMA

itself

yep can you provide any sights into

adding accessibility to components via

code connect oh this looks like

yeah would be I would say just check our

um code connect repo on GitHub um and

then there's some good examples of how

to actually write like different um ARA

tags um for your components whether it's

in react or like story book format and

stuff like that so um yeah please check

the code connect repo on GitHub for some

good examples on that

will it be possible to use text

variables to test Dynamic font scaling

across IOS and Android designs I believe

so

um I believe yeah I think you can also

utilize modes to kind of test those

design or if you are separating your

files you can actually separate those

variable libraries

accordingly yeah if you go back to the

session earlier with Anna um she did

Show an example of that when she was

showing type type variables she had a

font size and she had different modes

that she would um change between and

then the font size was changing so you

could use that again user modes for iOS

versus Android um toale and you can

scope I think going back to scoping now

it's not like scoping towards like um

Corner radius but you can actually use

the variables to kind of um tag it to

your leting or curing and even font

sizes to kind of scale that

mhm are composite variables for

typography on the road map detaching

from

textiles I would say that like um our

current stance is that styles are

essentially the composite variable um so

that's that's just the the reason why

they still continue to exist together is

that styles are the ones that allow you

to you know package all those variables

together um again a great example was

the session today where she had all the

different you know typography variables

of like the name um the line height the

size Etc and then you wrap that in a

single style which is essentially the

same as a compositive variable um the

same thing with gradients as well

gradients are you know two to three

different colors for example and that

goes into a style that you know wraps

them all together so I would say that

those are the the the current solution

or direction for UNC composite tokens or

composite variables

here

M okay next question question does Dev

mode also support low code platforms

like out systems oh I've never heard of

out systems have you I haven't heard of

it specifically um I'm not

sure yeah maybe we need some more

context on like what type of support um

whether it be you me

Cod

yeah any plans to allow changing modes

for language and presentation mode that

are easier than exist ing work arounds

um I would say again we are definitely

working um something around that um so

stay tuned on any updates about

that for code connect with their be

support for other types of development

Frameworks since right now it's launched

for react and Swift UI for

now yes um we do have a lot of other

support on the works I think things like

angler and stuff like that are current

being considered so um look for some

updates on that

soon have you noticed um have you

noticed customers to having two sets of

documentation for their Design Systems

for instance design documentation and

FMA and

developer documentation elsewhere

curious to hear some approaches you've

you've see in and if there are any been

preferred any platforms to have allinone

documentation oh this is actually a

great question I can um answer on that

and then Cory can take over I think um

based on our learnings or rather my

learnings is that let's take for example

DBS s dbs's session earlier on um to

them I think documentation is such an

important uh process or aspect of it so

they actually did both um documentation

um on the code repo and for the ux

engineers to uh take a look at and also

that lives on figma for the Design

Systems designer so that but I guess

everything still Tellies together so um

it kind of really depends on uh case to

case or how big is your organization or

maybe the function of it um

but there are some instances that they

both of those documentation live

together um yeah I don't know what are

interesting insights that you've seen

Corey

yeah I think on both sides so there's a

certain overlap point where um you know

on the design side and the development

side we need to speak the same language

and talk about the same thing um for

this component but there are also Parts

where they don't exist on either side

there are some things that exist in figa

that you need to know about to you know

use design and build more design with

that component but don't actually show

up in um code and the same thing with

code you know when you translate to code

then you have more things like you have

um and you have data like that you know

and a button component in figma um f

word designer doesn't really have to

worry about like what happens if on on

click on this button right uh what is

that function that's that's um attached

to that right um but with like a

component say um and code you might want

to think about like oh what is this

there's a function on click on here and

there's a call back and it does these

other other different things and this is

how you import data into this component

right um so there's going to be like

extra information on both sides um so

sometimes it's not really relevant for

for a designer to look at all the

information same information as a

engineer right so there are kind of use

cases where it makes sense to have like

um two separate um sources or or sources

of documentation for the same thing um

and one for one written for engineers

one written for

designers yeah I think um we kind of

discussed about this last week during

our um designs 101 I think it's also

great to kind of identify like who are

your consumers when you identify and

understood like who are your consumers

and kind of your producers as well then

you'll be able to identify like okay

that means that I kind of need to Branch

out my documentation so that um both

consum types of personas or consumers

are able to um speak the same language

with it being having to like types of

documentation

regardless okay on to the next one for

nested component properties uhhuh are

there any plans to customs select what

individual properties show up within the

nested

component

we I think this is in reference to when

you have a component with a nest

component and then you have exposed

nested properties uhuh um so right now

if you do exposed nested um let me

double check I thought I believe you

could actually choose choose yeah

specifically which yeah I'm pretty sure

that you can choose which um n

components to expose when you're

exposing properties that way um so in

that case then you would be able to do

individual component

properties yeah maybe go it just give an

example

here let me grab a okay I can't find

any let me find a complicated comp

component that has okay we'll go back to

that you'll find once you find the uh

good example for that um double check

that so I'll go to the next one here

while you're looking for that component

um is it possible to have one component

library that can easily be re themed for

multiple products um so that when you

update a component and it updates all

products say five products with the same

component library but different theming

how would you suggest setting this up um

I think that's there's a lot of

different use cases on that

um I would

say if you have a single component

library and then you just have um really

the changes being applied via variables

that would probably be like the most

efficient setup that way um so then that

way you'd have just say some basic you

know um vanilla components like a you

know here's a here's a button but um the

color this the size you know um the

corner radius all those different

aspects are all defined in variables and

all those variables have a

uh separate mode um per different like

theme and then changing that the the

look and feel of things based on that

would probably like the most I guess

straightforward way to set that up if

that makes sense um so like yeah the

actual construction um of your design

library in that case could be a single

file with a single component Library um

but those are linked to a collection of

variables that have a um mode column per

different theme that you want to use and

that will change everything I think that

would be like a good place to

start um same for like and then the last

part can you easily theme a button but

it doesn't um theme the hover States um

so I wouldn't

use variables for States like hover

States right so when we think about like

um modes we tend to think about modes as

something that applies to the whole page

the whole screen right um so things like

hover States I think those are best

um Define more like an invariance um

rather than um using a mode to change

those and the last followup for that

would be this would mean we should have

component level tokens um doesn't

necessarily mean you need component

level tokens I think most cases people

would have a um primitive set and just a

semantic set um I think component level

tokens you know depending on your needs

they could work but in most cases I

think sometimes you know it's a little

bit just more work for not really much

kind of payoff it's um when it comes to

dis

management hope that answers your

question I think I found um a file by

Louie um Cory you might want to check

that let's see if it's actually relevant

to it because it's actually

a card component that is being nested

and nested and

nested okay what's the component

here so if you go to want to go to

the main component here um and then so

sorry I have a bunch of windows open

there so then we have some instances in

there and

then if another instance is in

there yeah so if did you want

to Define one of these instances as a

implanted property

oh here um the button

itself yeah Define maybe a component

property there so here you go exposed

from nested instances here's the menu

I'm talking about here um if you can see

my screen um in this case here when we

expose properties from nested instances

you can see that there's a check mark

for each and that way you can choose you

could say like I just want this ID

instance versus this EX instance um so

in this case you can see like each of

these Banner rows um is an Ned instance

as part of this Banner grid list um so

if I just want the first I want the

first one and not the other three I can

remove that there and then now I've

Exposed on neity instances for just that

first Banner instance so I think that

maybe answers the question there is that

um when you know setting the exposing

instances you can custom select which

individual individual property show

actually that might be oh I'm sorry I

think I think going back to that

question there I I actually understand

it now um so it's not the actual

instance it's the properties on that

instance here um so in that case um for

example we have this nested instance

here of we have Banner grid instance

then we expose Banner row um as a

exposed nested instance Banner row has

its own properties here all these like

say BP type and stuff like that um and

in that case maybe they will uh the RO

poster here wants to um expose maybe

just BP and not and not type right um in

this case no that's not possible when

you expose n instance it will expose all

properties that are attached to that

nested intense itself um

yeah i' say if you wanted to make it a

little bit cleaner um you could try

using say b booleans um where we have a

Boolean and then um and if you show our

that depending on that then you show the

other kind of like

dependent properties um with that um you

get the example is like um an icon

sometimes you have a um icon instance

inside of like a button um what you

could do is you could do a show or hide

the icon and then if the icon is hidden

then the instance for that icon instance

um won't actually show up um that makes

sense there um so yeah I think that'll

answer that question there

sorry a long question there no problem

thanks for answering Cory um what's the

benefit of using typography variable

over Styles just in terms of Designing

one thing I can think of is the type

system would be faster to set up from

scratch any other major benefits you had

in mind while launching um variables H

great question I think um while we still

want to Styles I think for um typography

variables it's really useful for scaling

Design Systems particularly um like you

don't want actually to have like all all

your colors and semantics um set up for

um all your buttons and all that but

when you want to change maybe you have

multiple brands or platforms that

requires you to change those

texts um I think um typography variables

actually really helps a lot for you to

be able to quickly switch um from one

mode to another or like from one brand

to another I think it really helps to

package the whole um variables or tokens

um as a whole but um I think in terms of

styles itself it is definitely useful on

its own feature for example if maybe I

sit on marketing and like um I want to

be able to just um use um styles for a

simple deck for things like that and I

think um Styles is still useful for pro

probably cross functional Partners so

that's kind of where the my thought is

that yeah just to F that I would say

like um from a management St standpoint

obviously for typography you want to

manage every single value individually

but from the application standpoint of

someone using it like the design system

user they don't want to have to click on

um you know the right line height the

right font the right font size all these

things by one right that's like you know

you know five or six things they need to

apply every single day time they apply

text um layer so instead of that it's

like just put a style here's heading one

right um here's you know label right um

much much easier um to apply those

things um as one but manage them as many

I think so that's why again Styles and

like variables would continue to coexist

I think another thing that I would also

add here is that we've been talking so

much about like bringing um design to

development closer and like with um

typography variables it kind of syncs

better with your um code base so that

you know you don't have to keep on like

inviting the Tex stle all over again and

again so really it's all about bringing

design to development

closer yeah do you have a link to the

talk about creating Design Systems I'm

starting to create one wish you could

move variable between Collections and

group as I got this wrong to start

with we can send you some resources

there's a lot of resources how um you

might want to consider when you stack

um Design Systems with variables uh yeah

I'll so we did a I was call out that we

did a Design Systems 101 talk the other

day um I think that should be up on as

an archive pretty soon on our um my's

page there so definitely check that out

um

yeah so we've got a lot of questions

left so maybe let go pretty quickly um

yeah last few

minutes is there plans for inbuilt

accessibility auditing um in figma to

check uh the component with the wcag

compliant um I don't think I've heard

anything about that so yeah not natively

yeah not at the moment yeah that would

be a good plugin though mhm do you think

with these design some friendly features

rolling it's getting harder for

designers to understand and create

design system design freely using

variables just because it might be too

complicated and overwhelming for them to

understand if so how figma how is figma

planning to make products more

comprehensive for designers to use oh

actually I can answer this thing um it's

such an interesting topic because I

think for designer Advocates both cor

and I and hoki as well we kind of also

um are the people between um almost like

are responsible for product education as

well um I we kind of don't want to deny

the fact that the product is getting

more complex it's getting more there's

more and more features embedded onto the

product because we want to cover all

grounds and all use cases and all

personas so I think um the way to answer

is that like um we on the product side

of course they are always thinking ways

to be more comprehensive to really

onboard users more easily but there are

that's also the reason why um we have

kind of Advocates as the bridge between

the product and the community uh we are

here to kind of help you upscale or

educate you or really just to share best

practices what we think it's best and

how to best adopt these features uh

without really having to overwhelm all

of you

yeah um great one um next up let's talk

about what's the difference between

store book and code connect oh that's a

difficult one but I would say like um so

code connect is a netive feature in in

in figma to connect your your code your

repository um to figma and document that

right natively um storybook itself you

know um I would say you're documenting

your design and code together but it's

not a native feature and outside of

figma so there are some overlap on being

able to um document you know design and

code in the same place but it's not need

to be built into figma it's a separate

tool as well as there are other features

in in story book as well that um you

know don't exist in figma yet or R um

you know are more interior oriented um

outside of like the context just design

or just the the way the um the component

looks in figma so yeah it's it's a comp

ated space there but like uh I guess

that's the best I can answer at the

moment thanks

guys to three minutes here we just spoke

about this um last week again on our

design SS 101 but I think

it's I think on the topic of atomic

Design Systems a lot of people have

probably different approach but I think

for both of us um an atomic design

system is probably a great way or an

entry point to kind of understanding how

um things are being set up how um code

is being set up as well and why are why

do you kind of have to set up variables

in that manner or why do you have to

frame or sorry name your layers and

frames in a certain manner it's all of

those are actually connected to one

another so I think uh having a basic

understanding of how Atomic design

system design works is actually a great

way to understanding a lot of things so

we will link our slide SL deck in the

chat yeah this is a slide deck from the

other day um definitely check that out

on the figma community guess we have

time Forbe one last question here yeah

one or two yeah okay

[Music]

seeing Oh okay if devs are already using

some design system framework it seems we

do not necessarily have to build Design

Systems from scratch however it's often

painful to make modification based on

Design Systems k K provided to fit the

business need any suggestions and

advices on this that's a great

question you want to go first now or

should I

go uh I'll I'll process this and you'll

go first and then I'll I'll take my um

take on

this um I mean I think it's good to have

a start point if if possible I think for

you know again building things from

scratch takes a lot of effort and if you

don't need to to build it from scratch

um and you can take something that's off

the shelf and and slightly customize

that I think that good but I think

eventually you're going to as you build

your product you'll probably run into

areas where you need more custom things

so um I think eventually you have to

build something um more customized um to

meet the needs of your designing and

have the best design possible um so it's

just a matter of when maybe you start

with like a um an existing UI kit and

because you know it has that designs are

already and like the Cod is are already

but then you slowly P slowly build off

that and create your own design um

system or you can go from scratch I

think there's just many different

options there yeah I think my take here

is that I've definitely been in your

shoes as well I understood like oh

sometimes it's so iffy and having to

change everything because you need

modification I think um not having to

reinvent the wheel is a great way to

start um you at least have a base to

start with um when it comes to

modification it's almost like a muscle

memory when you think that the team

grows bigger or like the use cases gets

bigger as well and there are more

complexity in the usage of Design

Systems that's where you kind of start

to transition and really you don't have

to kind of do it alone um so I

understand that uh those modification

might be difficult but I think it's also

um when

you uh start off with like a UI kit it's

almost like you're practicing or that

it's almost like a muscle memory to kind

of

get it get things adjusted and how

things can uh best suit your Design

Systems for your business and your

company if that makes sense yeah all

right I think we're at time now so what

we'll do is well there's a lot of

questions that are still still there I

sure you have a lot more questions um

we'd love for you to fill up this

um this poll here um just to uh get some

more information there but um if you

have more questions you can always find

us like on social um look for us on like

X or say Instagram or lington um and

maybe we can follow up there and we can

answer your questions but um I think

that's all for today do you want to wrap

it up chess yeah um thank you so much

all of you uh it has been really a great

session thanks for tuning in for all the

sessions from shows keyot to um Anna and

Jake's Deep dive to DBS session and

finally to our Amy we've come to the

framework um day to an end I hope

everyone finds today useful and keep on

creating Your Design system so happy

Design Systems day have a great day

everyone um I'll see you guys on the

next

webinar thank you very much

[Music]