Building an automated multi-brand token workflow - Behind the System

welcome everyone thank you for joining us today for the first edition of our live stream behind the system my name is mike i'm the ceo and one of the co-founders at hema the company behind figma tokens we will attempt to host one of these live streams every month where teams using figma tokens give us a practical insight in how they have solved specific problems in their design system using design tokens today we are presenting building an automated multi-brand token workflow presented by chris kerr and nicole duncan but before we get there a little housekeeping and for that i'm gonna give the microphone over to robert on our team good day everyone my name is robert based in the netherlands and recently started with the figma tokens team you can see me as the man between the users and the team so if there's any feedback or questions you have feel free to reach out to me and now over to some housekeeping the session of the day is recorded and after our live stream it will be available on our website figma tokens.com on the bottom right you can find the chat please use the chat to everyone so everybody can see what you are saying next to that we have a questions button if you have questions for nico or chris please post them over there before you post the question please check if the question is already there and otherwise upvote that question so we can keep track of the questions you can use the hashtag behind the system to share about the event and this is supposed to be a safe and friendly space so please be kind everyone and respectful more information on this can be found on figma tokens.com code of content um keep an eye out on our channels as mike already mentioned we are planning to do a live stream every month so keep an eye on those channels to see for the upcoming events also if you have any ideas or suggestions to improve our live streams please contact us via support at figmatables.com and now i want to pass the mic to chris and nicole so we can dive straight into the talk thanks very much robert uh thanks very much mike hi my name's uh my name is chris uh real pleasure to be with you uh here today um we're going to as mike mentioned talk to you a little bit about how we're building out an automated multi-brand token workflow bit of a mouthful um but hopefully or will become more clear we hope as we go so as i say my name is chris kerr i am the principal product designer at performio and i'm nicole duncan i am a software engineer at performio and the dev leader on our design system uh so today uh in the way of a bit of an agenda for the session um we're going to start with a little bit of context around our design system uh how we got here and kind of where we're at some of the challenges we've faced along the way um a little bit of an overview then we're going to dive right into uh the figma files themselves uh so this whole uh series is about being kind of uh behind the system so we're with waltz and all in the actual file itself and we'll show you how we've structured our design tokens how we're trying to tackle multi-grain theming how we're tokenizing our icons uh some of you may have read an article that we've written about that and then we're going to be looking at how we uh implement our tokens actually in components in figma using figma tokens and non-local styles uh and then we will go uh through automate how we actually automate our token delivery workflow which will also include a dive into some of the uh code side of things with nicole so sweet so all right yes yeah just want to kick us off by first talking about the origins of our design system so performia is a large and complex app with many interfaces so naturally we face the challenge of developing a consistent user interface this is why performio introduced a design system which we've called electric to speed up the development of electric we decided to use a design system as our base after weighing up a few different design systems we decided to use chakra ui as it's well built and easy to implement if you would like to learn more on how we decided on a design system we do have a blog post on our performio product and engineering blog which is just on our performia website so we use a few tools to build our design system we've used storybook to help build and document our components and tokens and we use chromatic to complete regression testing where we can validate any changes made to electric since the last build of course we've got our figma component library that we use as a source of truth for all of our designs when we first started electric we did have very simple base tokens in our theme file for example a color token would be danger 100 or danger 200 which was a good start however we quickly ran into issues using these base tokens alone which press will explain further [Music] um yeah so this is where we kind of started our journey and over the last six months we've been working on how to tackle some of the challenges that we faced so as we started building out the design system it became apparent that if we were going to use a token-based system we needed to find a way to support our customers who use instances of our product which have a certain level of branding on them so today that really just involves some basic brand colors um but later down the track we're envisaging a greater degree of white labeling um the simple base tokens that nicole described uh also created some challenges um for the design team as well as the developers um most notably it's not very clear how to apply those tokens in the context of the components and so what we'd end up with is quite a lot of inconsistencies between similar concepts so different border colors on um on on buttons and so forth so it was leading to a few inconsistencies in there because the tokens themselves weren't very directive in terms of how to use them uh the other aspect uh was a bit of a reality check that particularly as you build out a design system uh there is a lot of change that goes on throughout the course of that process particularly in the early days and one of the things that changes an awful lot are your tokens and their values as you build those out and as you understand how to marry up the token structure you need to the component usage you envisage uh if you have just a manual workflow for that so we're just you know defining a token value somewhere in figma and then we're trying to hand that off uh in a manual way to the development team that's a very uh manual way as i say uh it's very high effort in terms of a workflow and it takes a lot of time causes a lot of frustration so we really wanted to address from the start when we look at this how can we work really really efficiently efficiently we're a small team and we want to make sure we're spending our time focused on solving the right problems so these are some of the challenges that we faced coming into it and so we took a next step uh we were very very fortunate i think to be starting this process really as uh figma tokens uh became so uh famous i think um and so we adopted it i i um yeah figma tokens have played a crucial role in our ability to actually roll out our design system uh as we see it uh we will see it uh we adopted a semantic token approach so the base tokens needed to be complemented by something which gave the designers and developers a much clearer understanding of how to apply these tokens within the uh i guess the opinions and the decisions that we're taking within the design system that those token namings they also needed to be standardized somewhat and very clear roles uh and structures for how we name tokens um which uh leads to obviously a much more consistent design system but also a much easier roll out of the design system itself as i mentioned we've started working on our automated workflow so this is about getting the tokens as they're declared in figma right the way through to the code and as i say nicole is going to talk us through a lot of that later and uh also using the uh some custom style dictionary transforms and github actions to support that automation which has also been a crucial and fairly recent development for us so uh before we dive into the files the figma setup we have it's pretty atypical uh it's what you'd expect to see in a lot of design system teams uh we have a theme library at the center that holds uh all of our styles this one happens to also hold our icons uh and this one will also support uh all of the different brand themes in a single file we don't have a separate library for our component library that's handling our little base objects be it your buttons your uh your your input fields your toggles and so forth we also have a patent library so this is where we build out more opinionated uses of those components uh we won't dive into that too much today but we do separate that out for ease of discovery and also for performance those components can get quite large and then separately from all that we have prototypes that the design team build out along with all the specifications for product features and they consume all of these items so uh pretty pretty atypical setup the real key here is the separated l theme library with the styles as many of you will know the recent launch of non-vocal styles and figma tokens has been a game changer here as well because we're allowing us to keep our styles in that library and then use figma tokens to apply those styles inside components patterns prototypes as we see fit whilst maintaining a centralized place for their styles all right let's dive in okay here we are in lovely figma um so uh this is our theme file uh i guess there's a way of a bit of orientation we have our styles downside as usual here you can see i have uh three themes in here i will explore those later with you we also have a documentation on uh our colors our typography space and size concepts shadows borders width and radius and our icons which we'll come back to okay so let's start with color because color is probably the hardest thing to work through from a token perspective uh it's the one that requires a lot of abstraction and a lot of thinking ahead um and can be really quite challenging to do this is my second design system and the first design system i put together uh we handled color probably in a less effective way than we're doing here so um i'll walk you through the differences between those two approaches as we go so let's start with a little bit of an overview then so a theme for us in figma sorry excuse me me get this guy's let me zoom in a bit um essentially we just keep it to three levels um three layers uh we'd like to keep that layering short i think if you over abstract with too many layers in your with your semantic tokens you can get into a real real mess with it real quick so keeping it simple until proven otherwise of the way so we have values this one might be like a hex value that's assigned to a base token and then that's assigned to a semantic or component token so it's a pretty straightforward uh structure but it's always strictly this way so semantic token always references a base token and never a value that's really crucial for the layering in the system so let's have a look at our colors in a bit more depth so uh we mentioned multi-brand so our system uh will allow our customers to choose a seed color for their primary secondary and accent so from this uh and we can see these declared here as pretty straightforward base tokens so this one's color palette primary and bass it's got of value and uh uh these bass tokens are then used to derive um semantic color ramps so here you can see we've got a few of these guys primary and secondary um the uh yeah so we derived these color ramps um and and all of this is kind of customizable so as i say the the users will provide a base color and then we will derive the color ramp algorithmically eventually but by hand at the moment all of these color ramps use a consistent contrast ratio between foreground background to help us with accessibility so that the 500 uh value of the color ramp uh gives us a double a um when we put the 50 of the ramp over and that's consistent right the way across our colors the brown colors these are kind of the the heart of the the differences we see in the theming at the moment we also have system colors uh handling those kind of basic system functions the usual suspects info success warning danger we also include neutral in here and the system colors for the moment are not something that we're offering for uh configuration uh the eagle eyed amongst you will notice that warning actually has a huge shift midway through it to try to tackle the dirty yellow problem and that makes it a little bit more complex to algorithmically define so we programmatically define sorry so we will um be looking to extend that at a later date we also have our opacity as well so we define opacity as a scale and this just allows us to make sure that we've got a really clear uh scaling for our opacity and it's all much easier to use and we understand they sort of i guess the relative opacity compared to the overall set and this is used quite extensively through our color system because we use um a screen blending for our or like mixins for our our different states hovers and and active so from a color perspective brown color system colors and opacities really act as our base tokens and everything references back to these three sets so the semantic tokens uh so we made a decision to go with component concepts as one of our organizing principles for semantic tokens um there's lots of different ways of doing this um i took some inspiration from the uh now fairly well known nathan curtis article on this and looking at the nate at the naming conventions uh and the idea of a concept that groups together um uh different different elements within the system but which had a common way of applying tokens it resonated with me so as you can see on the screen here we've got some various different ones we i thought this would be much when i started doing this with component tokens i thought this would get much worse than it actually did but as you can see there are quite a few tokens we have box buttons inputs menus navigation style links tabs tables tags toggles we've also got a global item so most of these um are pretty straightforward they're pretty self-explanatory semantically in terms of language they align with chakra quite closely as well which just helps with the overall lined up experience between our electric wrapper and and the chakra react components um uh let's just uh grab buttons for a minute and just dive into this so i can give you a bit of a closer look so if we take uh one of our buttons and our tokens here we have um clearly a color so we start with a category or type and then we have the component concept in this case button i then have a semantic usage so we have things like primary secondary accent info success and so forth uh we then have uh the concept of emphasis uh so this particular one's a solid but we also have subtle outline and ghost uh we then uh include state uh and then we include the uh the property that it will be applied to quite a lot to take in there so i'll try to break these down a little bit i'm gonna work from right to left actually so you can see we've got three tokens here background foreground and border it's quite important i believe to clearly define the relationship between these three properties when you're applying them stylistically we've seen this starting to happen in design systems like m3 uh the new material three um they they use foreground and background as well and i think uh personally for me i prefer explicitly declaring border as well um although it adds a few more uh tokens to the set um i think it makes it much clearer from an instructional point of view on how to style a component um uh you know in terms of states we've got idle here but always hover we have active and we have disabled um you different different components can sometimes have other states we have in input for example we have selected as well a few others um the emphasis is solid so this the concept of emphasis is a tricky one it's a slippery beast this um it's really is it's it's relative to its intended container which is a little bit abstract um in our particular case this is a light theme that we're dealing with we don't have a dark theme at this stage [Music] but um [Music] so in this particular case solid means that it appears solid relative to a light background our subtles um are quite fun they actually use opacity so you can see in the token value here we're referencing a base token for the the color palette primary 200 and then we're combining this with an opacity value so this notation in style dictionary allows you to generate opacities and it allows us to basically place these objects these buttons and have the background shine through which is actually quite useful when you have um like a hover state on a panel behind it say for example in a menu item or something like this so uh we do as i say end up with a lot of tokens um this is in fact a highly overspecified set of buttons we don't actually use all of these tokens at this stage but what it does also help us do is start abstracting out the concept of color styles which would allow bulks implementation of these uh programmatically but we're not quite there yet so uh that's uh that's a future one i might show you input as well just whilst we're here for some contrast uh i've got a few different you know and i think you can get like overly strict with yourself around naming and how you group these things it's really going to be about how you what what kind of makes sense is it discoverable can i repeat discover that can i kind of build it into my mental map of what i'm trying to apply these tokens to here i've got color input i've included field and label technically field is of course uh above input in this case uh around a field controller which would then contain an input works for our purposes um but we then have input we have idle active populated selected so you can see some of the different states that exist here fundamentally the reason why we have these is because the tokens and how i apply them to the background foreground and border for any given design choice is going to be different to how i apply those same colors to the different properties in an input field and if we keep it really vague and just talk in terms of you know a primary idle background and just kept it at that and didn't have any concept of what the component type was it becomes very abstract as to how you should actually go about applying these like where should i apply this primary um token is it to the you know on the background like what what when should i do that on an input shall i do the same thing on the menu what about navigation so the the component tokens i feel have become have made this much much clearer in terms of how we how we use the system [Music] okay so uh what i'm going to do now is i'm just going to dive into figma tokens let's bring it up and just give you a little bit of a walkthrough about how we structured this as well so everything that you see on here all of these little widgets are actually built out using uh the automated plugin uh using a script that will talk to figma tokens and generate them so it's actually very quick to document them and to be honest with you these documents don't the these items they don't really matter that much anymore because my documentation really is the json file in my figma tokens this is a far more effective way of documenting the design decision because it's transportable you can use it elsewhere whereas these objects here aren't that useful and um you know they're good for referencing and they look pretty um but that's that's about it because stigma tokens can also generate and connect to all of the styles i make all the decisions that i need to about the design system and its tokens in figma tokens and then use this to generate the styles and ensure that there's a link between those styles and the tokens in here and honestly it's it's life-changing when it comes to managing this there is no way that we could have taken on building this number of tokens without the aliasing capabilities of sigma tokens and whilst it didn't happen overnight i think we put most of this together probably about three to four weeks with a bit of a long tail at the end as i kept changing values and nicole kept having to update everything in github i'm sorry about that nicole um but um uh it did it did drive us towards automating our workflow so i suppose not a bad thing um so uh let's talk through the structures that i've got in here so i haven't got any themes uh so i've got three different themes uh i've got i'll make the formula one and a couple of test brand ones i've been working through uh so i can just select that guy there uh and in that theme um and i'm not going to go into how to build seems too much that's all pretty well documented in in the figma tokens documentation on the website but um this particular one we have a kind of a folder called shared i've semantic colors typography core and icons these are shared no matter what the brand and then i can spin up some some other brands so i created brand one and the only difference here is actually the color palette so you can see just the primary and accent colors uh it's just a single very over saturated bloom um and that's the only difference for brand two i went a little bit further i should just switch out to that theme so i went a little bit further so i actually uh decided to have a bit of a play just for the purposes of showing you guys some things today uh i built out a bit of a color variance in the palette again just changing primary and accent for demonstration purposes but we also went and changed a few of the typography tokens as well so i changed the uh the font family over the heading and body to roboto from our standard inter um and uh and i'll show you those all working later and then the same we did with the core as well so this one contains things like spacing tokens uh and these all use our size tokens as reference and i bumped up which size value they used uh for each of the different tokens which then gets applied in the components again you'll see all this fun stuff shortly uh cool so let's just have a quick look again just at the palette and start again so here you can see we just put labels on that's reflective of our color ramp these tokens are all pointing to an actual hex value you can't use hsl of course um we use hex for now um if we go to now our semantic tokens let's have a look say at that primary button background that we were looking at earlier uh you can see that it's referencing the token that i just showed you that primary base token as an alias we do that with the squiggly brackets around each side uh for now in our descriptions we're just replacing uh the the raw value uh but without the squiggly brackets don't put the squiggly brackets in it does funny things to the transforms uh sometimes you have squishy brackets in your description just as a hot tip eventually this may well get used for more instructional purposes but at the moment it's just it just contains the same alias that actually works out quite usefully in your styles uh so if i roll over one of these is it gonna behave you do i just decided not to hover over anything good i love it when it does that's great um wait here we go it should work there we go so as i hover over that value actually then in the description because that appears in the tooltip tells me what value that token is actually assigned to as an alias so this is all just about making sure you can connect the dots mentally um and you know it's assigned to the right uh the right token um it's quite helpful when you're using it uh so these are semantic tokens as i say uh it's reflective of all of this it you know it's a big list is why it's on its own um quite often i find myself making changes directly in the json editor uh and now with the snazziness of i think command s will save it uh as of the 11716 release uh it's pretty easy to use um uh i don't mind it if it gets really difficult i'll copy and paste this out into vs code make the changes copy and paste it back in and save it uh and that works pretty well too if you need to get a bit more advanced with the ide uh let's have a quick word about typography i mentioned it a little bit earlier so um [Music] excuse me switched our typography page so we try to operate base tokens and cemented tokens in a pretty similar way with color so the base level we have our typeset uh and that contains our declaration so font family size weights line heights and all that good stuff that make up our type uh and then we have our textiles which is really the typography components uh in figma tokens so let's just open one of these guys up uh and you can see in our textiles they're making you know references to all of the typeset tokens that we created and it works pretty well these are obviously quite important to do the typography because it's from these styles that you can generate your text styles in sigma so if you want your typography driven by figma tokens um and and being able to tokenize it you've got to have your typography tokens in place you don't have to um do the full aliasing you can put in absolute values but i would recommend that you don't and avoid that temptation and abstract it um it'll make it easier to scale and change in the future less destructive so yeah as i say we've got our various different um typography tokens we've got some fairly explicit ones here uh component specific around link and button we just wanted to treat those slightly differently for now we've also got a type style based around sorry a textile based around our icons so those of you who are familiar with the approach we're taking we use font awesome uh to drive all of our icons um and it really the magic really starts here with these typography tokens um so i will show you that actually now let's go and dive into that okay tokens for icons um i'm gonna do this pretty quickly because it's reasonably involved but hopefully um we'll give you a bit of a starting point so i've got to just clarify at the start of this this relies entirely on using an icon font now we use font awesome and this particular example i'm going to show you is completely specific to how font awesome implement so if you've got another kind of uh font uh icon font that you want to use your approach may differ if you're using svgs this approach won't work for you one of the reasons we went for font awesome is that recently they've made some pretty big updates um there's now an awful lot of um uh icons in their set i think at the last count it was a lot 16 000 or something mad there we go 16 150 there's a heck of a lot of icons uh they do them in different styles so these are essentially represented as weights from a font perspective solid regular light and thin and we treat them as such uh and as you saw just uh briefly there let's have a look at the alicorn um the way font awesome works is uh from a code perspective you're passing this value fa solid fa and then the name of the the icon and the solid there's representing the weight so if i chose regular you can see the class is updating um so it has this this kind of string that you pass through and it understands what to do in many ways font awesome is really acting as a in fact for your icons and by passing this through it will return this glyph which is really awesome i guess why they call it font awesome um so let's have a look at how i've implemented it so i have icon components i've got five different sizes of icon components they're strict size ones they then scale deliberately just to give us a bit more control uh each icon is uh turkish minute uh each icon is a um its own component and inside each component of variances are each of the different sizes so these guys are being driven by a uh a figma of text style right so you can see over here performer icon uh small and solid this one's medium large extra large and two xl uh so the the font is doing the heavy lift here right if i um if i change that to plus bash circle you can see font awesome is um doing its job and it changes the glyph out as you enter that text but you'll note that that text does not actually include any of that fa solid or fa and the name of the token so the way font awesome renders in a tool like figma or locally on the local installs you just pass it the name so back on our alicorn if i want to put alicorn in and render that we can just do that again [Music] and that's just copying and pasting the word out of calling it all right so with that base understanding of um how font awesome works let's look back on our figma tokens so as i've mentioned we use a text style so if we look at our typography you can see small solids have been applied here medium solid and so forth i can of course apply regulars as you can see here i use a regular weight instead for this icon and so it's just icon specific about how we do it uh so that's stage one so it's uh the actual component itself is is pretty simple um it's it's a text uh layer set to hug and then fix size wrapper around the outside um i have a tendency to auto layout absolutely everything so it's an auto layout and it's centered and justify center as well inside these components then are is a single text layer they're all called icon no matter which icon you look at and which sides and this is also really important for making this work because if those names are different figma will not respect any color overrides that you've applied and we'll reset it back to this base value when you change the icon which is quite frustrating so make sure all of those layers are named the same all right so with one of these layers selected as you see i've got that typography in there let's go into the icons themselves um so you won't see anything selected here um i'm just going to open up this add uh icon so in the raw value you can see this is the uh the the fa solid f8 plus excuse me um uh uh value for the class name class details that we want to pass through to um nicole and her code that's what we're passing there we don't actually use any of that here we just use the description for creating these icons so i've entered that as plus and if you remember just from the example i showed you i just need that name i don't need any of the rest and so for this particular icon i can right click on my component use the documentation tokens and use description to apply it so if i was to wildly update this i'll break it because i can't type i love it when i do things like that there we go let's try that again where i can type there we go so you can see it it changes basically instantly um this approach has been pretty game changing for us in terms of delivering icons like i can just i created a new icon earlier i did it in the import i was gone it's just here and i spun it up it took me about i don't know three minutes to put it actually into github and have it as a live component in the system it's incredibly quick staggeringly quick i've never seen anything like it to be honest um my last design system i i would sweat for days over trying to get all the items done and genuinely annoy my development team with the constant request for it and could you update the icon file again please and deploy this so that we can then use it in the component it was it was pretty painful i'm not going to lie so this this approach is working really really well for us um and again it's all about handling this stuff at scale uh you know this is just the ui icon we've got some product specific icons as well that are going on uh and and there's a lot and icon libraries can get pretty pretty big so so yeah so this that was just a kind of a i guess a little bit of a a walkthrough of um the icons i'm conscious of the time so i'm just going to press forward a little bit as i say that i've written like an article on the uh the icon usage and nicole's going to talk a little bit more about actually how we take that stuff and implement it later on uh all right so that's kind of like a bit of a whirlwind tour of our theme file um hopefully uh useful in terms of understanding the structures for names that we use um how we generate all of our figure styles which are all linked to our figma tokens um uh and and then managed centrally so what i'm going to do is i'm just going to hop over to another file so this is just a little sticker sheet i put together i i figured life messing around in our actual production component library was probably an unwise choice yep there we go as it shows loading good timing figma perfect um so i wanted to use this just to demonstrate a couple of things to you guys um the first is actually applying the tokens in uh in a component and then the second is the excitement of applying multi-brand so here are buttons pretty straightforward uh also use a plugin called uh prop star i think it is that one let's have a quick look did something like that i'll find it in a minute very good for documenting i put all these lovely purple bits in place which makes it really easy to um to document these because it will automatically fabulous i love it uh right let's have a look at our buttons so buttons are pretty straight forward ish there's a little bit of complexity these color shifts are actually done using opacities off the base you don't have to do it that way if anything i'm probably just being overly fancy with some of this um but it was working at the time um so let me just zoom in a little bit on good old primary button every design system person uses buttons as their demonstration he knows um if i now look at that layer and let's pop in a button here again sorry a little bit of a lag um you can see uh on our fill layer and our border that the token has been uh applied now this is kind of interesting because this object that you're seeing here is actually not the actual component it's an instance of the component in a library that is then pulling in the themes from let's see styles from yet another library so there's a few things going on here both the styles are external to this file and the component itself is external to this file and yet figma tokens through the awesomeness and magic of their amazing code is actually keeping track of all of this which means if i was to change this in my theme file and update the styles it's all just going to flow through beautifully works really really well so when you're applying all of these tokens in your components look it takes probably i wouldn't say more effort but you need to be doing it in conjunction with the component token creation process and you want to be pretty strict and disciplined with yourself about applying your tokens everywhere so be that the gap the space between and the padding values around it the text style making sure it's semantically correct making sure that the color for this particular state is using the correct uh foreground token and the same for the icon as well making sure the background is etcetera etcetera the border radii the board of width if you have a token and you can use it in figma you absolutely should because this gives you the scalability to switch out the themes if you don't take that approach if you only partially implement if you want to then multi-theme or you want to make changes centrally and have those cascades through the entire system um you will find parts of it do not update and that will be annoying and you'll have to go and do it manually and no one likes doing manual work so um all right so that buttons i can show you a couple of others i guess it's pretty straightforward um if i look at this card title for example you should see in the typography heading two is applied i'll look at the core tokens here i've got a 32 um pixel let's just complete the size actually for a second so space is what we use for handling padding and the space between and margins so it's really about thinking about space as a physical construct we separate that out and they abstract that out from size the size really provides us with our units of measurement rather than how we're going to apply them so in some ways um size is a as a base token and space is a kind of semantic token it's not component specific maybe it will be in the in the future but um we use this for for for our padding and and space between um we reference the different styles uh again you don't have to do this you could hard code it if you wanted um i would use the description there but um so this all works pretty well yeah uh so you know all of the components they're pretty pretty pretty similar uh inputs is a is a pretty big one we've got quite a few different kinds of inputs but probably no more than most uh we're opinionated with our input so personally when i'm doing components i try to be a bit more opinionated about them rather than being too abstract so rather than having input field with left icon as an abstract concept i just go it's it's text or its password or search or its number uh always thinking about uh is it fit for the purpose intended and is this the easiest designer and developer experience that we can deliver uh this particular component has uh uh it's the different types and the different states and then i've also got a um prop a component prop for switching whether it's populated text or hint text so cool so look that was a bit of a whistle uh stop tour of of of these uh components let's show you some magic uh now because that's enough talking for me and i'm gonna let the work do its thing so this sometimes takes a hot minute so everybody give it bear with me um i live on the sunshine coast in australia and the internet up here is not the best so um yeah all right i'm gonna switch this out to brand 2 now on the button so i'm just doing this on apply to selection so all of these components you've seen already you know they're pointing to this performio style you can see over here they're all using the performia theme and let's see if we can switch this out to brand 2. and hopefully by magic and a little bit of patience we'll start to see things transform the spawning of coral um so some of the changes going on here quite noticeably the colors but also the typography so i upped the sizes of the typography in all sizes i upped the size token that the spacing value for this this was using i changed the font to use a different font uh and um yeah it was real easy to to do like it's it's not much effort sometimes it takes a minute to work its magic but uh uh that's that's the nature of the beast it's certainly quicker than trying to do this by hand so you can see here it's all changing and scaling and being magical i love seeing this stuff it's great um inputs this is the thing let's try this guy it's not the slowest thing in the world but it takes a while to kind of a few cycles to go through things um but you can see i've kind of you know i've been pretty wild with my colors and color choices here um [Music] but i've increased the size and because we use auto layout so extensively in throughout because we've applied tokens uh figma tokens to handle gap and spacing and so forth you know this is all just automatically resizing um when you this is another tip when you are doing multi branding particularly with the fitness side of things more than the code um and you do want to have variances in the idea of space between your themes just make sure you're pretty careful with your uh use of auto layout use it extensively and assume that that component that that container that's containing this this object that you're going to change size is going to grow or shrink accordingly so it's pretty hard to get that perfect alignment in figma all automatically um you know without various constraint options and in widths and so forth min heights and max heights but you do want to if you're going to be changing spacing tokens in your theme you probably won't be mindful of that uh last but not least i thought i might show you a bit of a working page from from like a prototype um i'll show you that working across the page this one does take a few seconds um but you can see all of my tables will eventually magically resize all the color tokens are changing over the buttons already switched over just as another tip i found you know you're asking quite a lot of the system at this point um try not to click around and jump around too much let it do its thing be gentle i'm always still amazed that i'm doing this through a chrome browser in the first place not what i normally do that i use mac os just faster uh cool all right so that is um a bit of a an example of how multi-brand theming works um last but not least i'm just going to switch back to the themes um [Music] i've got an update to make here so this is this is how we start our journey uh off the token so i've been making some changes in here i've tweaked a few things so this environment is connected to settings uh it's connected to github in our settings i flick over to that but it will show you my license key for figma tokens so i'm not going to do that but trust me it's connected to our github repo and in that git help repo we've got a bunch of branches and we've set up just a dedicated branch for token updates and this just allows me to continuously deploy to this uh or sorry continuously commit to this branch in github uh and so then obviously i can always save these out and by putting it all up into github it allows me to then use those all my figma tokens in my other files as well and keeps them safe and sound and better than there's a file on my desktop so uh that's this is really where the magic starts uh so i would be able to just drop a commitment as usual um and off we go um so this is kind of the start of the journey so that's kind of an end to the the whistle stop of the figma files let's have a quick look at how we automate our workflow so i'll just touch on this very briefly uh we're defining the values assigning those values to the base tokens and then assigning the base token to semantic tokens create our themes and sets all the stuff you just saw side path of creating our styles but we commit to our dedicated token branch and github uh and then when we're ready we'll raise a pr to a feature branch which is normally where i asked nicole to take over which is a convenient moment for the cold to take over sweet you're going to show your screen yeah [Music] cool so now that chris has raised the pr the json token changes there are a couple of steps that take place before we complete the merge so previously these steps would be completed manually by a developer where they would first pull the branch locally they would run our style dictionary transforms if they were all good to go then the developer would commit and push the changes and then finally they would also run a chromatic build and send these results to chris to validate however now we've automated this complete process so that the developer doesn't have to be involved at all so we've done that by using github actions so now what happens when chris raises the pr is github actions will identify that changes have been made to the token token files it will automatically kick off our style dictionary transforms and then also run a chromatic build where chris can view the changes if chris is all happy with the changes he sees then we can finally merge the pr to the develop branch however with of course the approval of at least two developers okay cool so now digging how we actually complete the transforms of our tokens into css so we use a tool called style dictionary which takes out json files runs some transforms and then outputs our theme file on the example on the right which is our config file for style dictionary you can see that we actually have our own custom formatter the reason why we do this is because chakra have their own object structure for their theme that we need to replicate taking a token of size medium or md sorry as an example you can see how the token key and value have transformed from a json structure to a theme object structure from the output you can see that some changes have been made first of all the the token category has changed from size to sizes and that's to match chakra's thin key which is sizes secondary um the value has changed from 20 to 20 pixels so this is to make it valid css and finally we've also generated a typescript type for the token created which is md these changes happen as part of our own custom formatters so our custom formatters do a few things they first resolve the theme path it also resolves the the value from the token as part of this step we also run any conversions that need to be done so for the case of sizing every token with the type of size will run through a convert size token function which as you saw before applies pixel to the end of the token value it will then construct the theme object from the resolved path and values and finally we also generate typescript types for each of our tokens that we create uh i would also like to walk you through some of the cool things that we're doing with our um our icons so our icons do pass through the same formatters as our other icons do however we have added an additional formatter that will that sorry that will that will generate a file that imports our icons from the token set and then add them to our fun awesome library saving us having to do this manually so going back to the automation piece we no longer once chris ads or updates icons make any changes manually it handles itself which obviously removes any chances of us making mistakes or forgetting to add an icon to the library our limitation with chakra is that they don't actually have thin keys for some of our icon categories for example opacity and icons so to overcome this limitation we have created helper functions to retrieve a token value from a type token name and theme object so an example below you can see that we are retrieving a icon token value from the icon theme object and the type icon name finally just some helpful hints for the developers we do use our own in um custom formatters however we strongly suggest using the style dictionary in built formatters if possible um and only use custom when absolutely necessary if you do have to use custom formatters we suggest using dictionary.org tokens over dictionary.tokens the reason for this is because dictionary.all tokens returns the tokens in a flooded array structure versus tokens which uh returns the tokens in a nested object structure just making the tokens easier to deal with and working on them we also recommend that if you are using typescript to generate strongly typed token keys this is helpful for um for ensuring that people don't use the wrong type um the wrong tokens and also it's it's nice to have a bit of intellisense back when writing the code we also use storybook to print all of our tokens as well as of our components so you can see an example on the right hand side for some documentation on our icon comparing icon tokens so in that documentation we explained how to use the tokens and we also list all the tokens available we find that this is a really good resource for the developers to quickly figure out what kind of tokens they need and how to use them it's also not just helpful for that but it's also helpful for regression testing so again we use chromatic for regression testing so what happens if say we have our current build but then chris will submit a new icon chromatic will show you the difference between the past build and the current the brand new build and from there you can actually see that and it will highlight that a new icon has been created which is very very useful not just for the tokens but also for our components as well come thanks for listening in wow guys that was an amazing presentation i would say it's almost a master class i think this is of a lot of value for for so many teams so thank you so much i see we have only five minutes left based on the original schedule but um i think we can go on a little longer and go through some of the questions that are there um also everyone there is a link to a slack channel on our slack community in the webinar emails so uh if you have any questions that are not answered or you would like to catch up with chris and nicole or the people on our team after the live stream uh yeah please join the channel and i think now we'll quickly move on to the questions that were there for chris and nicole yes i will go through them uh via the upfront so let's start with the first one so one question over here uh by how do you deprecate all tokens what happens in the design files uh that reference all tokens how do you manage coexistence of deprecated tokens and with the current tokens in a system so i think i'm going to pass this on to chris she's starting off with the the curly ones right straight in there um uh look the long and short of it is that we don't really have a situation of old tokens right now to be completely frank with you based on where we are on our development we're very early on in that [Music] we haven't really run into it too much what we tend to run into more than anything is when uh i have i go oh this a whole approach isn't going to work i'm going to need to remap these to a new token set and we've already got our component tokens assigned in the code so we have a wrapper that's got our component token just passing through to the chakra props um so obviously if i'm changing the token that's assigned to the component itself that's going to require an update and that just requires some pretty close coordination between the designers and the developers um we're a pretty small team working on this right now although international we've got teams over in india as well and and uh and elsewhere so um we just work in very close coordination with a high degree of communication um i'd like to say it's robust we're not at that stage yet um probably less process in the early days is is quite beneficial so the focus has really been around creating a very flexible concept for the semantics to be described and that gives us quite a lot of flexibility you know we can rename them quite easily we can move things around quite easily whilst there's some coordination the change itself is not difficult and of course we can create new semantic tokens as we discover new components that we wish to include in the system thank you thanks and then the next question ah question from sylvia nice to you here sylvia very pro set up how do you onboard and teach other designers to use or create tokens and components themselves do you document how to set up something like this great question chris yeah um again just at the stage of development that we're at um there's a lot of knowledge within the team and within our heads uh we are trying to get that out it is a bit of a struggle to document and create simultaneously um we're often actually creating these components and doing them in the context of actual um initiatives that are going on within the organization rather than dedicated work on the design system so as is pretty classic of most product companies there's a a lot of um [Music] pressures and things going on at the same time and you've got to kind of work smart with how you do that so in terms of teaching other designers funnily enough that the last designer of our team that i taught last week i think it was actually on this uh this chat now uh hello christine um and uh look i i do a lot of manual walkthrough um with the design team there's a level of orientation this is all very new for all of us at the moment so there's a lot of just very close collaboration um we chat a lot um we brainstorm a lot um i like to do review sessions with everyone to get them involved in the components and so doing so helps with orientation around how the components work and getting orientated around the tokens um at the moment for the most part the use of figma tokens for the team was kept pretty much to me the team is using the styles that we have set up but obviously because it's magical and amazing that that's actually quite useful because it's not hard for us to then retrospectively apply tokens um to those components as we kind of harden them and make them ready for the ui kit so um [Music] so yeah so so there's that side uh nicole briefly mentioned i think the the storybook side of things and and how that's basically printed out uh which is also awesome because it's always kept up to date uh because of using chromatic and it's tying into the branch as well so it's it's really easy to actually digest what components we have and all the props that are available and all the different token options and colors and so on um a great deal of this is about familiarity and discoverability i think um most designers and developers who've kind of you know been around a little bit will not find it that hard to to get into using components configma can be challenging always uh as you try to replicate what we want to do in code but can't uh and um that can be that can be pretty challenging um so it is really about making sure that people are supported ideally on like a a one-on-one level as much as possible in group sessions all right thanks then the next question is from euron zwarter porter do you support a light or dark color scheme in your system and if so how yeah i think you already asked for that right there's no dark mode yeah the answer is no but in my heart of hearts the multi branding was really so i could have a dark theme in my application because yeah very something kind of guy yeah so um yeah i uh i i i would i would love to be able to do that from a technical perspective there's actually nothing stopping us it's just another theme uh all i actually have to work through with the team is probably a desaturated color palette um so uh that's it's more of a sequencing thing than anything else getting the color palette right for dark mode is quite crucial um you gotta you can't just use the same one that you've used on light mode uh the other thing that we would need to just kick the tires on is the concept of emphasis to ensure that uh we we can deal with that which we haven't really tested out yet there's actually someone hand gliding down the mountain behind you mike right now yeah yeah there's lots of lyrics over here amazing uh yeah so uh we we don't we don't do like a dart mode yet but i hope that we will in the future uh and the approach you saw today uh should work just fine for dark mode if you just define your values yeah like you said i think it's it's pretty much just a different theme so yeah you're almost there yeah all right all right next question next one from sylvia again how long did it take you to set this up and how did you convince stakeholders to get the budget for it thanks great session yeah that was for sure yeah yeah um well thank you very much very kind um how long does it take us to set up uh look end to end and bearing in mind we were working on a bunch of stuff in parallel to this so like the total duration was about three months but the total amount of effort could be measured in weeks i think in terms of what we apply to it i probably did a bit more because i actually we built the semantic token structure during the course of that because i decided that my old approach wasn't working as i mentioned before and switched into this component semantic concept um so that required a little bit of rejigging on my side but yeah it you know i to be fair like this isn't my first design system i'm pretty familiar with tokens i'm pretty familiar with the concepts behind them building components in this way in figma like i have done this before so i'm already at a probably an advantage to someone coming into this fresh i guess my my advice there is keep it as simple as possible until you need it to be complex in terms of convincing stakeholders i am extremely fortunate to have a wonderful line manager and friend who um gives me lots of support and help um with with this um i'm a on the tools kind of guy uh and and she helps me honestly with that um but uh when i arrived um the team was already pretty clear that there was an absolute need for a design system um uh we know that we needed to do um a a lot of work on our user experience and we knew that the best way that we could do this the most structured and and and hopefully that the way that's going to last us the longest right you know front end experiences are a bit more volatile than the back end side of things you know they come and they go they change with taste different features different teams they all evolved over time so we needed something that was really flexible there so that i was very fortunate i think with this insofar as we're a very technical team uh on potential even not just on the product side but actually our product is quite technical and so we've got a lot of people who understand scalability we've got a lot of people to understand that need for abstraction and the need to invest in really highly scalable very flexible tooling to enable the teams to deliver the best work so we are in a pretty fortunate position it's a pretty good crew and you know everyone everyone kind of gets the idea so from a budget perspective um we're a product team we're a fixed size product team so we're done on head count so we don't have to go asking for budget uh on that it's more about prioritizing the work which is why we work on the design system uh as a you know an emergent uh outcome of the uh project and splash initiative work that we do on the product uh through our okl cycle all right thank you then the next question is from lucas so all styles are in one library here so how would you do this if your brand one and brand two each have their own published libraries and styles how would you link token styles to external libraries good question a lot of upvotes here [Music] i haven't actually done it yet so um and you know what it's an interesting thing like i think that there's there's maybe an argument to say that you might want your brands in their own styles i think the thing to remember is with that theme file like i'm literally really using only to store styles in the the documentation around the outside is is representative it doesn't really worry me too much so um having it all in the one place can be advantageous obviously to be able to use the theme switching uh mike robert maybe this one for you i don't know if you've run into this uh whether you can use have a theme in one library styles over that library and then yeah let me take that yeah yeah yeah so actually with the uh non-local styles that we have right now right which is recently released out of beta into production you actually have a very sophisticated way of of doing this so you can not just have one theme in one published library right now you would actually be able to even take certain subsets of your styles and publish those in separate libraries and have them linked to a theme so you could have one one published library per brand you could have one published library per brand in light mode and in dark mode separately or you could even break it up more granularly at the same time the plugin also allows you to create a single library file where you you know publish all these themes in one go or all the styles in one go separate from your component libraries it also allows you to actually prefix all the styles with the team name i think that's what chris was showing as well like the team is right there in front of the style name so if you're publishing it from a single library that this definitely uh comes in really handy uh and uh yeah i think we are yet to publish a small video on the latest update of non-local styles because it's pretty pretty advanced so yeah this is all possible you can you can go either way and it's really a matter of preference it doesn't really matter for us essentially what we do is we associate style ids from a style to a particular token in a particular theme so that's how it works and you then be able to apply those from whatever library so uh yeah i think i think that answers should answer the question all right over to the next question from james does the design team use figma tokens plugin in their workflow for example to switch brands uh not yet but that is the intent i i'm hoping i'm hoping for a figma widget with a quick uh a quick change but on the way you know yeah on the way here uh so um uh that will be that that would be ideal i think like you've got to always think of these design experiences you know the designers need to be focused in solving the customer and business problems the tools should be pushed to the side whenever possible because if you've got you can because then you're focused right the tools need to get out of the way and enable you to do that work if we're bombarding people with a million different options the whole time i think it can get a bit overwhelming um and especially for sort of you know people coming into their design career as well like we want them to stick around not um so um i think uh ideally a simple theme switcher is a pretty good place to be going um [Music] and i personally prefer the idea of keeping for for us anyway using figma tokens for when you're building a component in the actual design system library but at the same time if somebody's comfortable using figma tokens when they're prototyping and concepting things outside of the library i and they want to use the same token structure i'm very happy with that because if they're leveraging the design decisions that we hold central in our tokens uh that's even if they design something completely different at least they're doing so within some kind of familiar structure and familiar decision uh boundary uh which should really be the ideal situation right they should have the freedom to solve the problems that they need to in that context and then you know build from that i kind of think of these things like gracefully failing over it's kind of like that contribution model thing um can i solve this problem using what i've got already today and if i can what what do i need to change but what can i also hold steady and the last thing you take away is the tokens the tokens should really be essentially you know there is nothing lower the lower down it's the the quantum foam if you will of the design system there is nothing left um at the end of it thank you all right thanks for that one next question from brett in the component tokens why do you reference color before button instead of the other way around so i think this is about the naming convention over here yeah yeah good question uh personal choice um part of it's just down to uh helping me organize a little bit i um i think about the color first or the proper the kind of top level category i like to categorize my token so i can then know what i should expect from there i think it's also quite useful for when you're using these and you're kind of you know typing it out um you know you're not going to be applying a typographic token to a fill uh or or anything like that and if you think about it in the code perspective if you were type scripting this you know you're again you're not you want to keep those token types quite separate they're different concepts they deal with different things can you do it the other way around absolutely you could i mean you could go instead button color and all of those you could then have like button text uh and and all that you have button icons if there were specific icons for your buttons you absolutely could do it that way around there is this is i think one of the things about the the token naming is you've got to decide on what works for you you want to be looking for commonality of the relationship um uh kind of between the same types of tokens and then the clear difference across other types of tokens so that you don't get confused and be as explicit as you can you know figma tokens what it lets you do is it makes you it lets you make tokens cheaply in the old days you have to do this by hand and it's expensive to make them right it takes time but because you can handle these things at scale and you can make them cheaply i say make more tokens that are more explicit so that it's ultimately clearer for those people who have to use it and yeah you could have probably abstracted it out into some very clever abstraction but does anyone understand how to use it uh and i think that's the thing we've always got to keep in mind is the balance between the the logical and the almost information architectural decisions you're making but then also the designer's experience in figma and the developers experience in the code and that human experience and the limitations and differences between stigma and code sometimes cause us to make decisions in a certain way is it right is it wrong time will tell um what works for you is the best way always yeah i think it's likely a matter of preference like you say and what works for the team all right i think you'll take one or two more questions and yeah this is the last so one reminder if you had any other questions that are not answered right here uh follow them up in the behind the system slack channel after the event i think chris and nicole will be happy to answer more questions over there all right next question from charles with the textile being used for fonts how do you handle unique icons that are not handled by the font yeah that's an interesting one what if the 16 000 icons are not enough so with font awesome you can actually submit icons to use so we have a paid account with them uh so we could specify a custom icon and submit it for use um so that's one way we haven't run into that problem uh as yet the font awesome is an amazingly quick way of bootstrapping your icons um [Music] is it perfect absolutely not it's designed pretty heavily for a 16 point grid and when you get off that grid at different sizes like you put in 13 point the icons can sometimes look pretty funky um and obviously on non-retina displays they're going to look a bit pixelated as well these are the the compromises that you make this is why figment this is why tokens are about design decisions this yes there's a design path but also remember it's a decision that you're making and you're documenting that decision why i like using font awesome was my ability to massively improve our workflow through these very formative times so that we could focus on the really important parts but whilst also um you know having a pretty reasonable icon set is it perfect no but we're managing and we've got some very abstract concepts in our products so uh 16 000 icons is still quite a few but if you've got your own custom brand ones and things like this um [Music] you know it would be worth having a look to see whether you could get that into fonts awesome that was an option or whether you can explore creating your own uh icon font uh that says your need and maybe there's a way to tokenize this um you just by passing the values in um i'd imagine you'd need a local uh true type or something installed on your your computer as well to reference it within figma but if you're able to follow a similar pattern uh if in fact you could improve on it and be able to use the same value and not have to use the description field in fact to populate the glyph and figma that would actually be even better um but yeah all right so we do short all right last question and it's time for the last question a question from grant do the seed colors fall into their associated color ramp um no uh all green so the colors you saw in there for performio um like we're we're building out a new experience in line with our current experience so we do have certain constraints that we have to make so the thing doesn't feel like two totally separate applications as we do it uh one of those is a legacy brand color that we have that green very excitingly fails double a testing on both black and white so that's awesome when you're trying to build an accessible color palette so i actually use the leonardo color io i actually don't use that website there's a plugin called accessible color palettes i think that's the one and that what that lets you do is set a foreground color and a background color and then you can apply contrast ratios and then i use those same contrast ratios throughout consistently um which gives me my my shades uh i will probably end up writing a little bit of an article on this one as well uh it's not a figma token thing but in the interest of we do actually we are tokenizing or have tokenized the contrast ratio uh and eventually um i hope that we'll be able to automate all of this and and show you the full thing but uh that's some time away yeah all right colors doing what i'm all right yeah chris nicole this was like a fantastic session there was so much value packed in this both in in the presentation as well as in the answers from the q a thank you everyone for joining the first edition of behind the system uh we will stream another one somewhere towards the end of uh next month so keep an eye out on our channels and like i said we have a dedicated slack channel if you want to discuss more on this subject or get in touch with nicole and chris they're all there the figma tokens team is there as well including robert and myself so once again thank you everybody and looking forward to the next one bye bye well thanks

Channel: Tokens Studio for Figma (Figma Tokens)

Views: 10,996

Keywords: #designtokens, #designsystem, #figmatokens, #behindthesystem, #designsystems, #figma, design tokens, design tokens figma, design tokens figma plugin, design system, design system figma, documentation tokens, style dictionary, figma tokens, figma tokens plugin, figma tokens plugin tutorial, designsystem, ui design, figmatokens, figma tokens pro, token package

Id: 7zWrEJVuP24

Length: 78min 59sec (4739 seconds)

Published: Thu Aug 25 2022