[Music] welcome everybody I'm Anna I'm Alexia and I'm Chad and we're designer Advocates here at figma all of us come from design backgrounds and we work with all of you out there in the figma community to help enable your teams by sharing feedback uh sharing tips and tricks and resources with using figma we're super excited to dive deep on building Design Systems in figma starting with a couple of core principles that we've gathered from working with the community and hope can help guide you no matter where you are in your Design Systems Journey we're also going to dive into a handful of insights from our experiences working in figma and working with Design Systems and you we've seen a lot of great things we've had success and we've learned from mistakes and both our own work and from talking with so many of you and you can expect to walk out of thee dive with some actionable tips on figma features as well as some considerations that we'd love for you to take on board Your Design system Journeys awesome well with that let's start by first grounding ourselves in a couple of core principles we want to acknowledge that we understand everyone here is at a different stage of their Design Systems journey and with that means that you have different needs and challenges but we hope that by grounding ourselves in these principles it'll help guide you on your next steps and figure out which ideas to run with after this talk so going to our first principle approach complexity with caution probably the biggest challenge that we've seen design teams experience is when they inadvertently introduce too much complexity and the problem with complexity is that it means that you're going to create a more rigid design system and it also means that you'll also probably have to spend a lot more time and resources when it comes to maintenance and enablement one of the most common reasons in which teams accidentally incorporate too much complexity is when they take optimization too far take the example of a component where you're trying to support a ton of use cases and customizations with a single component this might feel like a really great way to simplify Your Design system by potentially reducing the number of components that you have but the issue with this is if you take it too far it'll be a lot harder for your designers to understand when and where should they use this component and what are the different overrides that you can apply in combination with it they might spend more time trying to configure this component to fit their specific use case than whatever you had before another example that we've seen where teams over introduce complexity is generally when they roduce too much their design system so when you're building things out in your design system generally for teams that try to mimic larger organizations that need to support more Brands themes platforms Etc you accidentally add too much to it and as many of you have probably experienced it's a lot easier to create new components Styles and variables than it is to remove ones that are already embedded in your design system so it's a lot harder to make changes the more that you add to it and as Nathan CTIC pointed out in a tweet the more you add the more diminishing returns you'll get as well so for example the more components you add to a library the higher the cost and the less value each individual component will give to your consumers so all these examples of complexity come from a place of good intention you want to give your product designers and Engineers the tools that they need and you want your design system to be as optimized as POS possible but if you take these too far you're going to end up with more rigidity and complexity making it hard for you to make changes and also for your users to understand how to effectively utilize your design system which leads me into our second principle which is being grounded in your priorities this is going to help reduce complexity and your priorities are essentially going to help guide your decision- making and ensure that everything that you do to your design system aligns with what's most important to your organization and as you know there's some really key important things when it comes to figuring out your priorities and they could be a bunch of different things as Pedro Hernandez from data dog says it's really important to figure out what these priorities are to see what drives Your Design system and make decisions from there some examples that he gave in this little fireside chat was efficiency helping your designers and engineers build faster or maybe it's consistency creating a more consistent experience across your different features and products or it could be around communication helping designers and Engineers better understand each other all of these are valid priorities uh to ground Your Design system in and you can have multiple but if you do try to make sure that you have some hierarchy to help with your decision- making and something that's important too whether you're revisiting your priorities or you're developing for the first time is understanding that they're also going to change over time as your organization evolves so too should your design system and your priorities and also once you've identified those priorities we've commonly seen teams use some kind of variation of the prioritization Matrix so taking your priorities and from there identifying what are some quick wins projects we can start working on right now what are some things that we can need to plan for more long term and then what are some projects we can squeeze in if we have time and the important thing about this is that this way way you're going to prevent your team from becoming overwhelmed with all the possible things you could work on with your design system and also to make sure that your expectations are realistic that you understand what is possible within a given time frame so your priorities are going to help you figure out what to do and when but as for how that leads into our third principle which is validation before execution we've seen a lot of success from teams who want to make changes to their design system take the time when it comes to planning out the changes they want to make and then validating that those is the right approach before fully committing to it this is going to be an iterative approach where you start small test it out gather information see if you're on the right track or if you need to make some kinds of changes and slowly iterate your way to the best solution for your design system what's going to be helpful about this is that it's going to prevent you from Shipping a change to your entire organization only to have to roll it back which is more work for your yourself but it also is going to cause a lot of whiplash for your users and potentially impact how much people trust your design system so with all that said there's no one right way to build your design system as someone on a Design Systems team it's your responsibility to figure out what does that look like for your organization but by following these principles hopefully they can this can help you figure out what are the next steps and help you build a design system that fulfills the greatest needs of your organ organization while remaining as simple and usable as possible so with that I'm going to hand it over to Alexia to talk about our first insight and discuss how to build a user Centric design system thank you Anna okay so I want to go back a bit on what Anna was talking about about with complexity just now and talk about the first Insight we want to share with you all today which is keeping a consumer first mindset every step of the way as you're working on your Design Systems and when I mean consumer from first mindsets in this case I don't mean the end consumers of the products that you're building with the design system but really the actual users of that design system whether that be designers or developers and as I mentioned we see a lot of teams that are introducing a great deal of complexity in their design system in the hopes of building best-in-class Design Systems and we also see a lot of teams that are getting really hacky and smart with all the features that now figma offers um and it's interesting to see that but I want to acknowledge first that design complexity in design system sorry complexity in Sigma has evolved over time as we've been building the product to close that gap between design and code um if we take components for instance if you remember we came from a world of components being bound together by those forward slashes which created this kind of friction that I think limited Us in terms of adding a lot of complexity that we would organically grow into it otherwise and we've gone to a world of component sets that are now packed with props and variants and all those other cool things it's really become a playground for complexity and we're definitely seeing a lot of teams taking advantage of that I want to do a quick show hands in the audience right now how many of you here have already created a component set with a 100 variants at some point in their life or their F experience wow okay I'm seeing actually a few hands raising which I'm very surprised by good job guys you hack the system um I this one is more of a rhetorical question how big do you think because we track those things at Sigma how big do you think the largest component set in terms of amount of variance has been since last config so since a year ago do you think it was about a th000 maybe 10,000 it's actually over 20,000 um and this image is not the actual component but it's very similar in terms of scale so just to give you a sense of that and when we go to that deep end and we create so many options how do our designers even know to find what they're looking for when we go there are we trying to just outsmart figma and be clever in the way we're working or are we actually just trying to be clear for our designers and so in figma the thing that we would love for all of you to always think is how can I get to my designers what they need in their workflow quickly this can impact how you think about Library structure it can impact how you think about component structure or variable structure and we will not have time to go through all of it today but I do want to highlight a few mechanics in figma that uh you can consider as you're moving forward so since we're talking about large sets of variants let's start there if we take this very schematic representation of a component there can we guess what it is is it an input is it a drop down is it a text area is it a bird is it a plane is it a super component if your component is getting to that stage where you're kind of getting not so sure what it might be it's probably time to step back and challenge the complexity that you've been creating until that point and I like to always challenge teams into thinking about two things when they get there which is firstly are you certain that for your users of your design system all the available options behind the default version of that component is going to be crystal clear the moment that they see it especially if the naming is quite generic and the second one is are you certain that every single variant in that inside that component set are interchangeably used in the same use cases by your designers and if the answer to either of those questions is a no it might be time to start considering SPL this component set and it's really as simple as just selecting all the options you want out dragging them out and rebundling them into a new component set the links will be preserved because figma keeps the IDS that way and if the layer structure is the same it'll even guarantee that overrides will be kept as your users actually swap the components around later now if you're think and you're pretty convinced that your variants all belong together but you haven't leveraged component props yet component props is may be something that you want to look at so for those who don't really know props that way well they're essentially a way to bring your components closer to code and in the process inside figma to reduce the size and weight by up to 50% if not more sometimes and when people ask us about the difference between variance and props as advocates we like to kind of schematize that by saying okay variance is really to help your designers visualize what are the different states of your design of your components and props are there to kind of guide them and highlight the parts where they can actually override so things like an icon they can swap or a text that they can change the content of and props are great because they're very self-documenting they're excellent for creating that extra discoverability in the design panel of your designers and together with props sorry props and variants together are 100% the best practice to implement in your Design Systems one thing to keep in mind with props when you're using them is that as you're adding them in your component by default they're just going to stack in that Designer experience exactly in the order you're creating them which may not be the most intuitive way of aligning them so you want to take AG of the fact that in figma when you're creating that component you can actually drag and drop and reorder your props and make sure that the ones that are related to each other belong with each other so for instance the best use case is a Boolean prop that's when toggled on is activating the visibility of another prop you really don't want those two to live in separate parts of the design panel for your designers you want to make sure that they're stacked together and that they're visually intelligible for your designers naming is another big thing naming is what can really guide your designers and so really recommend to think about making sure that things are consistent and consider leveraging things like action-based verbs or action-based namings when it comes to things like variants or booleans that are very self-explanatory as to what the intended reaction of that Fe that uh parameter of that component will be for your designers okay so at that point let's say we've done all that we've got some nice leans components with props we're happy with them these components might end up in other slightly larger components with a bit more complexity and when that happens in figma you get the option to do what's called nesting instances so it's a great way to Bubble Up every single parameter of that nested instance at the same level as the parameter of the M component um this means that you're essentially creating even more of discoverability which sounds great on the paper the thing is when you get to that part of complexity in your design system where you're starting inside the same component to pile variants and props and nested instances it's starting to create that really long side panel for your designers potentially and really create an information overload and you really want to be mindful of that inflection point past which you're kind of stopping to create discoverability and you're starting to make your designers's job harder when they're trying to use that component so a couple tips on working with nested instances where you get that point the first one is really be mindful about considering whether that nested instances absolutely needs to be surfaced up at surface level um is it going to be key to the user flows that your designers are building for instance if we're doing some kind of form that check field component is probably not going to be really needed because it's going to be toggled on by default all the time so no need to surface that another thing you want to think of is by default if you're repeating several times the same nested instance inside a bigger component what's going to appear in the drop down of your designers is just the layer name and so if that compon that instance is repeated it's just going to be several times the drop down with the same name you really want to consider actually renaming and overwriting the layer name in the side panel um for their designers to actually see the difference and understand a bit better what they're navigating through and finally if you're just concerned that you're running out of space and you don't want to pile more stuff that your designers can interact with but you still want to bring some kind of awareness to it consider using component documentation they're just a great space you can fit in every extra information that may not belong everywhere else okay trying to speed front for this so we' talked a lot about components I do want to spend a bit of time giving some love to variables because hey one year anniversary it's been a year ago since we release variables thank you and variables I just want to clarify a first thing about it which is that tension between variables and styles I think when we first announced variables this time last year a lot of people felt like they might just simply be a enhanced version of styles and our vision at figma is really uh that they're not contradictory they're better used in combination with one another especially when it comes to supporting more complex UI decisions so in figma design system world this means that there are some values that absolutely should be consumed as individual variables and these will be values that will feed directly into the UI layouts that your designers are building things like an actual color or you know the dimension for Noto layout Ping On The Other Side you've got what we would consider to be composite variables so composite variables are made of a multiple of variables and this is where Styles come in because Styles can act as a package for that so for instance that's like a gradient a drop shadow or you know most recently introduced a textile so let's talk about textiles for a bit since this is the latest addition to our rooster I know that a lot of you guys are very excited for textil to finally come around when we announce VAR variables uh sorry for text variables to come around when we announce variables last year um when it comes to typography tokens essentially what you want to do is create those individual variables for each of your typography parameter inside your variables table embed those directly into your textiles and then you're going to publish that textiles and it's going to be very seamless in terms of how your designers actually consume it it's basically integrated in their existing workflows but it's all backed up by the really cool architecture that you have in place and if you do that because you're the one as a design system maintainer creating that complex architecture you don't want to feed that complexity to your designers do you so what you want to do is consider hiding any sort of backend quote unquote variables from publishing and make sure that only the style is being fed and when we're talking about hiding complexity remember I just mentioned earlier right there will be variables that you will feed directly through your designers like colors and number values for paddings and margins so when it comes to those you really want to consider using the scoping feature of figma if you're not too familiar with what this is this is essentially what it looks like uh it's accessible in the options of your variable panel and what scoping is is essentially targeting the application of a specific value to specific Fields within your designer interface so for instance if I'm scoping this border width to specifically stroke it's never going to appear if my designer is trying to apply a numerical value on an oo layout margin and this is really going to reduce considerably the Clutter and the amount of noise that your designers are receiving on their end allowing you to create as complex architecture on the back end as you want but still making sure that they get only what they need when they need and that it's going to be consistent UI throughout as they're building their interfaces so to rec out what we touched on when it comes to building libraries you really want going back to what Anna was saying in introduction to challenge the complexity that you're creating every step of the way and really think about that tension between increasing discoverability for your end users but also as you're increasing that discoverability moving down the volume on all the noise that you might be creating by using different ways of leveraging that Sigma side panel and finally when it comes to variables Styles hide and scope are your best friends and we talked a lot about designer workflows and I realized that design system is definitely not just about designers developers are part of all the decision- making and I'm going to leave it with Chad to talk a bit about developers all right thank you Alexia all right so when we're working on Design Systems whether we are the designers crafting components or we the developers making them real through code we need to ensure that we're communicating with one another throughout the process that we have a two-way street of communication this way we can get our assets to production faster and support those who utilize our design system so we often have different ways of working though and different processes different ways of communicating let's think about the question who should start the work who here is a designer that works on a design system all right awesome so we need to build and we need to design those components first right they have to be designed before they can be built we want designers to start using them in their designs it's the way it is all right well hold on any developers in the room design system developers all right awesome we got a few too awesome so what happens when there's a change in the API or we need to update the code that's going to impact what designers are using maybe the default value is going to change from medium to large we're going to update the code and we'll fix the design later right well designers did you tell the developers that the components were ready to be built and developers did you tell designers that this changed well let's remember the importance of communication in our work especially with Design Systems where the designer and developer workflow is really one of or if not the most important partnership and I've experienced these benefits firsthand when you have great communication and collaboration between design development and I've experienced when there hasn't been such great communication and we know from talking with developers in the community that not all teams have this today we did a survey with 200 front-end developers across the product and design system landscape and we published in a report on figment.com called decode the developer now in that 55% of the front-end developers said that they wish they were included earlier in the design process and less than half really only 43 % said that they work with designers on a daily basis so all of my fellow designers here our developers want to work with us they want to understand more earlier in the process it's okay to share work early bring developers in and talk about potential hurdles and opportunities for alignment especially in the design system should a prop name be aligned to code or should we maybe make it friendlier in design or maybe code doesn't support something today that we want to add add to make things a bit more clear so let's talk about a component share the little details designers we love pill-shaped buttons right let's use our friendly little button right here have we thought about all the different use cases or how we might adapt it for different things like when it comes to internationalization and our text strain gets longer what happens what should we have our developers do do we truncate the tax do we completely switch it out for a different word just let it run out the side of the view or do we wrap it and we turn our pill-shaped button into this cute little squirkle but how about usability considerations also with the visual treatment are people going to understand them is this a tab is a navigation bar is it linear progress steps do people understand the intent of our components designs when we share these details and why certain designc were made or any feedback from testing it can help us ensure that we have that alignment as the components are being built as well as for when consumers are using the components in their designs really what I'm trying to say is that communication it's everything and you know whether it's synchronous or async sharing knowledge and resources can help everyone get their work done and Alexia briefly touched about using the component description Fields when you are configuring components and figma but also for our developers let's make sure that we are utilizing our developer resources in Dev mode this is where we can include additional information on our component such as links to our storybook docs or maybe we want to put a link in our component code from GitHub and load that right up here in figma and the great thing about this is even if designers are using these components in their design and they detach that component these Dev resources are going to stay connected so that way as developers are inspecting designs built with these components they're still going to have the links to the information that they need and they can always compare back to what the component is in the design system so designers let's not just hand off our files to developers and hope that there's enough there for them to work with or wait around for them to come to us and ask questions questions let's also leverage some of our resources leverage our documentation and use that to help Elevate our conversations in partnership with our developers at the end I'm really just trying to say designers bring your developers along through the process developers bring your designers into your process as well continually collaborate with one another throughout the building of your design system and honestly even in your products after all as Diana mount has said great collaboration isn't throwing designs over a wall it's designers developers and the rest of the team collaborating together so when we talk about collaborating together and just together really Design Systems are about people and this is where as people when we share our knowledge we share our resources and we build collaborative relationships with one another it's going to help everyone in the process of getting their work from design to production faster for both makers of the system and for the consumers so now let's hand it back to Anna who's going to share a bit more about approaches that we've seen teams take to help enable and support their organizations as Chad said Design Systems are about people and you can take this way of thinking to how you approach not only building your design system but also educating and advocating for your design system which is why I want to talk about the value of building a community around your design system and how it can help you with scaling your efforts creating a fly wheel effect that helps amplify your message and eventually hopefully leading to larger adoption of your design system so the first step to building a community around your design system is identifying your Champions these people are going to be initially people who are already enthusiastic about your design system looking at how you can identify Enigma you can look for people who have maybe left comments in your various design system and Library files or maybe they've directly made edits to them maybe someone created a branch and proposed a new pattern and then you could also look at library analytics which we're going to cover on in a bit to see which teams are already heavily using your libraries if that's the case it probably means that there's someone in that team that's already advocating for your design system system and once you've identified these people reach out to them and see if they'd be interested in helping you out in a more formalized way and the idea is that these people's enthusiasm for your design system will help encourage others to learn more about it adopt it and maybe even contribute to your design system a second group of people I think are incredibly valuable to become your Champions are people who are influential so this could be from just having a lot of respect maybe they were at your company for a while or it could be built into their role if they're in operations or if they're a manager on a design and engineering team they have a direct impact on their team's processes and workflows and so even if they're not initially bought in if you can convince them of the value of a design system get them to become a champion for you they can have a huge impact on how embedded Your Design system is in their team's workflows so once you've identified your Champions the next step is to provide them with the resources to help them succeed generally creating educational materials that they can reuse and repurpose to help spread the message you don't feel like you need to create all these from scratch figma has a bunch of really great resources on our YouTube help center and in figma community such as our playgound files which already have a lot of important contextual information on features several of them related to design systems such as Auto layout component properties and variables and built-in examples where designers can get hands-on experience learning how to use these we've seen teams take these playground files and incorporate their own examples from their own design system so that teams can learn and understand how these features work within the context of their own organization or using these as a template to build their own custom playgrounds for example Janna Choy and last year's config talked about how Capital 1es design system team modeled their flight simulator off of figma playground files as a way to create an interactive onboarding experience to help teams learn about their design system and also increase the brand awareness of their design system as well and as Chad mentioned earlier documentation is also a really great resource you can look into building those within figma using existing documentation kits such as this one pictured here by Oliver Engel that already have components built out with common documentation layouts and assets um with auto layout automatically built in that you can go ahead and use and component configurations panel is also a really great way to just put lightweight information you can also try to play around with the formatting to make it easier to read and Link out to other docs if they exist in another website in another figma file or maybe storybook or GitHub and lastly I want to really emphasize the value of recognizing and rewarding people's participation in your community and contribution to your design system we've seen some teams directly incorporate this into their leveling chart so having designers who are contributing to your design system actually have it be incorporated into their performance reviews because it does demonstrate and allow them to have a larger impact on their organization and then there's also the option to create external signals if it's badges or certificates if people complete a training if you're creating custom Zoom backgrounds or swag that people who have participated in your community can wear and it just helps them feel like they're a part of something bigger and it also helps serve as larger visibility in creating an external signal to others and just building awareness of your design system so I really want to encourage everybody to look outside of their Design Systems teams to see how building a community can help you scale your efforts in educating advocating for and eventually increasing adoption of your design system and also these Champions aren't just there to advocate for you they provide a really valuable way of creating two-way communication between your Design Systems team and your users so with that I want to hand it over to Lexia to talk more about how you can use feedback and metrics to guide the next steps of your design system thanks again and we're back okay so let's talk a little bit about getting a sense of where you might be going next with your Design Systems um as Anna mentioned if you already have an Engaged Community around you and you're probably already getting direct feedback from them which is a great place to be now we often also times work with teams who unfortunately don't work that closely with their end design system consumers and that could be for a multitude of reasons it could be because um these designers and developers are just too far scattered around their organization it could be because there's a lack of resources but really when it comes to Design Systems it's kind of just like user research it's really that combination of having insights around behaviors around your design system comine with uh a solid sense and grounding in your Design Systems priorities that together bring you Clarity on where you should be focusing your efforts for Maximum Impact regardless of how much resources you have at your availability and just like in user research there's a pendulum of data that you can play with around your Design Systems so on one hand qualitative and on the other hand quantitative in design system World qualitative might feel to some like the most accessible because it's a lot of one-on-one conversations it's a lot about digging deep into the functional needs needs around your Design Systems um and on the other hand quantitative can feel occasionally a bit more intimidating because you know maths not necessarily are best friends for everyone um and it does however require slightly less active engagement from your design system Community which could be interesting to some um and quantitative specifically is really about that big picture of your design system about feeling the heart bit of that design system together just like us a research they bring the most complete picture right you'll get your hypothesis on one side and you'll get the valid and the other but really any insight is better than nothing and better than just making decisions in a vacuum so it's completely okay to just start wherever you have the possibility of starting so let's talk about qualitative data real quick there are many ways to capture qualitative data around your Design Systems Um this can be more or less structures this can be outside your figma files they can be inside your figma files and there isn't a better way by the way it's just really dependent on what kind of data you need and this should infer where you're going to get it in figma since you know config we're talking about figma here uh what we often see in terms of behaviors is we see people leveraging comments uh as external users of the design system directly onto the design system Library files and occasionally we'll see people being even more proactive in their contribution by using branching to suggest updates now I want to focus on commencing very quickly because that's a feature that is used by many uh I think it feels very accessible even non-designers get a feel for how it works so it's great for asynchronous discussions in this way but it's also extremely unstructured as a way of gathering data if you don't do anything about it you know like letting things organically pile up makes them very hard to synthesize so if you and your team are thinking or are already using comment we would really recommend you to think of ways where your team can better structure that qualitative feedback that you're getting and we see for instance the teams at hubs swop and hassa that have come to agreeing on specific shared vocabulary around their feedbacks that can be shared vocabulary around the priority levels of the feedback or things like the expected actions that should come out of that feedback or it can be really as simple as just you know a colorcoded emoji and the reason we're talking about shared vocabulary or emojis is really this notion of tags that you can input directly into figma comments so good thing to know about figma comments is there is a search function that scans across the entire file if you have a design system Library any comment or any comment inside that comment frad that that carries the tag will be able to be surfaced when you're doing a search through that file um and that can be a very very easy way to set up future you for an easier access of scanning and consolidating the feedback you're getting from your users okay that was for qualitative feedback let's touch on quantitative feedback real quick so if you're going to think quantitative feedback in the context of Design Systems you're going to think yourself the questions of metrics and metrics is a huge question that there are many many many smart people out there that are trying to to crack around Design Systems and not going to pretend that there's a perfect way of measuring it once again very dependent of your organization very dependent of where you are but it's interesting to think of metrics in design system as layers so you definitely have that one layer of design system metrics that really is grounded directly into your organization's priorities what Anna touched on at the beginning of this presentation regarding is your priority about efficiency is it about driving consistency and can you measure those things there's another layer that it's also very important to look at which is what we would call Design system health and that is more about you as a design system team building a sense of progression on your design system Journey keeping an eye on patterns and potentially anomalies that you pick up on because these can inform the decisions that you make in terms of your next steps and it can be things like measuring scale or you know adoption and let's look adoption for a minute because adoption is one that we see a lot of teams trying to calculate and keep an eye on so once again no King metric when it comes to adoption surprise surprise um we see loads of Team measuring it differently and it's completely dependent on their own context and where they are and what they're striving for we see teams that for instance measure adoption by Bread so in figma terms that's something as simple as maybe measuring how many teams out of the total number of teams you have are actually yes or no using a design system Library we also see some teams measuring adoption by depth so that would be something in figma context like how much of the files being handed off to my developer is actually being covered in terms of the number of layers by Design system derived layers and if you don't really know where to start with adoption there are some really handy free plugins that you can leverage on community uh a lot of them take the form of lining plugins which essentially scans through the files and just tells you how much is using or you know forgetting to use the design system and some of those some of these come in with really handy metrics even as far as percentages which can help you give and like keep an eye and monitor what's going on into your design system files sorry into your actual design files not design system files because if you want to pull back and have a bird ey and actually happening at design system level there's this other feature you could look at potentially which I sometimes discuss with teams and I'm surprised that not everyone is aware of it but if you want here it is this is the new entry point in the new UI um it's called design system analytics accessible from any design system library that is published on figma and when you open it it gives you essentially a very quick overview at a glance of what the usage is looking like which teams importantly are you actually using your design system and if you want to leverage that data and start getting a bit manual with it you can also export it as CSV which can be really handy now all this might still feel a bit basic for some there are people out there with much more Advanced Data need than just that and if you're part of those teams then you're going to probably start thinking about apis and at figma we have a an API called the rest API there's this really good article by Pinterest the Pinterest team that uh dates from a little bit over a year ago now where they detail how they actually leveraged figma's rest API to essentially build fully custom dashboards that are tailor fit to their specific ways of measuring and tracking adoption in their teams and that article as I said is from a little bit over a year ago since then two months ago we just announced that framework that we're adding some more design system analytics end points into the rest API so we're really really excited to see what the most nerdy teams out there are going to do with all those new ways of measuring data potentially in our apis okay I hope with this brief overview I've given you a sense of how figma might be a ble to help you capture data uh whether it's qualitative or quantitative because really being data driven is not only just about driving more impactful decision- making on where you're going next with your Design Systems but it's also going to help you build trust and build the perceived value of your design system in your organizations by unlocking things like reporting and once we know roughly where we're going next then the next question is how the heck do we get there and Chad is going to talk a bit about that all right thank you again Alexia so the great thing about data is it tells us what's going on and you know I think one thing that we're always going to see with our Design Systems when we look at the data is that nothing is forever with a design system so let's think about that for a moment for everyone here who has worked on a design system who here has launched it and thought all right we did it people are using it let's check that box we're done we've all felt that right well just as products change our design system is going to need to change it's going to be an ongoing Journey because we're going to have to eventually support new use cases maybe new technology or we might need to address um components and patterns that become less and less used everyone remember giant rotating image carousels or you may encounter a Rebrand so in my previous company we worked through two complete rebrands with our multibrand design system and had started Explorations on a third and when we made updates to things like color and dimensions and type it was overwhelmingly straightforward and it got us most of the way there but there were still challenges for consumers of the system to fully inherit or Implement due to design overrides custom patterns to address unique use cases or entirely different code bases used across products maybe you've experienced this as well and while Design Systems may lead updates in situations like rebrands or maybe introducing new figma features into your assets generally Your Design system is not going to move at the same speed as your product or its consumers in fact it really shouldn't after all maintainers we don't want to be constantly riffing on our ideas and Publishing them out creating chaos for consumers who are just trying to get their work done wondering well is this the flavor of the week what should I be using especially if you're publishing at speed like this don't do that generally we want to wait and have our design system be informed by our product and by the consumers of it that way we can incorporate those updates to support different cases when and where it's appropriate and when we do begin that work it's important to remember not to disrupt the source of Truth so it could be truth or truths maybe it's your code repo maybe it's your main figma design library in figma what this typically means is if you're doing a massive overhaul we may see teams making a duplicate version of their library and making those large changes there and creating a migration path to a new version or we'll often see large teams leverage branching which Alexia briefly touched on before and some of the benefits of using branching for making our changes both small and large is when we look at something like these tags or chips here we can make these updates and ensure that designers who are coming into the library and using it as a sticker sheet they're not seeing work in progress and potentially using components that aren't ready to be used yet and the best practice that we see teams take when they are using branching is sharing that Dev mode link from the branch with their developers and then working together to coordinate when changes are merged to when the code code is ready and then they publish that in harmony with one another but of course let's acknowledge that not everything we explore intends to see the light of day maybe not now or maybe not ever well if we're working in branches it's actually really handy because we can just archive our branch and preserve all of our work at that point in time it becomes locked from future updates but we can always revisit it and restore it to pick our work right back up in the future so here we can see we were looking at a contribution for a danger input type or notification type and all we had to do was hit restore and we could pick the work right back up addressing the comments that were left on the component and as Anna mentioned in the beginning really with all updates we need to remember that it's important to have a plan test and of course communicate what those changes are so we can hopefully prevent unnecessary stress for the consumers of our systems especially if this is a breaking change because we know that as your systems are going to mature you're going to have to introduce breaking changes at some point in time it does become inevitable and this is where our planning testing and communication becomes essential so often times what we see teams do is start out with a straightforward component and use that to plan and test how they're going to incorporate updates taking note of things that are added or removed what gets renamed what might impact other components that utilize that one then they'll move on to a bit more advanced component and then to the biggest most complex one they have maybe they'll also bring in example uh design files and Test new components within them the big thing to ask at the end is does it still work great publish it you're good to go but if there's a chance it breaks or people need to make updates and Chang this is where we need to think about how are they going to know what they need to do and if you tuned in to framework by figma a couple of months ago Talia and saz from the Verizon design system team gave an insight into their deprecation process and their figma technique that they call deprecation mode and we've already seen some teams start to mimic this out there in the community as well as models outlined in article posted on medium by Steve Dennis A couple of years ago and both of these really outline great approaches and we've seen teams start doing these where they leverage component naming and introduce visual visual references such as components or shaded areas that need to be updated making it easy to identify what needs to be updated and switch to something new so definitely check out Verizon's talk on the figma YouTube channel and look up Steve's article on medium so remember everyone our Design Systems they're not static they're going to require ongoing attention collaboration and adaptation and they're going to need to incorporate those design updates and those code updates as they go and PJ onori really summed this up well saying it's inevitable that almost everything you make in the system no matter how good will run its course now he acknowledges that interface paradigms change new platforms show up and the product that you built the system for evolves so as you embark on those inevitable changes remember the principles that Anna shared at the beginning approach complexity with caution always be grounded in your priorities and seek validation before execution these are principles we've outlined from talking with so many of you in the community who have found success with building and growing Your Design Systems so thank you for sharing Ing and allowing us to connect and learn from you so with that let's recap what we've covered today all right we're going to keep the screen up a little bit so you guys can remember all these different insights we had but just as a gist Design Systems should be built in collaboration between your design and Engineering teams and between your Design Systems team and your consumers and you should always continue to re-evaluate and iterate and remember that nothing is forever and as we wrap up we just want to take a minute to thank everyone out there in the design system Community who is out there sharing resources publishing article publishing plugins publishing files not that every article plugin file whatever resources you put out there we see it we appreciate it we share it around us with other teams so thank you so much for doing that and in the spirit of sharing we've left a little link that should bring you to a design file where we've actually input all the resources that we touched on throughout the presentation and with this thank you for listening thank you thank you [Music]