Talking Tokens

Estimated read time: 1:20

Summary

In a webinar hosted by Knapsack, titled "Talking Tokens", experts explored various facets of design tokens within design systems. Chris Bloom, a developer at Knapsack, led the discussion with guests Jackie Li, Donnie, and Miranda Balk. They delved into the complexities of integrating and managing tokens, emphasizing the importance of semantic tokens, effective naming strategies, and the potential for artificial intelligence to aid in token adoption and implementation. The experts also shared their experiences on onboarding team members to token systems, governance challenges, and the need for clear communication and system consistency.

Highlights

Donnie stresses the need for clear naming conventions to maintain consistency in token systems. 🌟
Miranda shares insights on onboarding designers and engineers to use tokens effectively. 📚
The panel discusses the role of AI in enhancing token adoption and implementation efficiency. 🤖
Jackie emphasizes the importance of aligning token systems with organizational goals. 🎯
The discussion includes challenges faced in integrating semantic tokens within existing systems. ⚙️

Key Takeaways

Semantic tokens are vital for consistency across design systems. 🛠️
Effective token naming can reflect organizational values and improve system clarity. 🔤
AI has potential uses in token adoption and implementation, saving time and resources. 🤖
Onboarding and education are crucial for successful token integration. 🎓
Open communication fosters better token governance and community engagement. 🗣️

Overview

In the engaging webinar organized by Knapsack, industry experts dived into the complex world of design tokens, exploring their significance in building robust design systems. Chris Bloom guided a panel featuring Jackie Li, Donnie, and Miranda Balk, who shared their vast experiences and insights into leveraging tokens for system consistency and efficiency.

The conversation highlighted the essential role semantic tokens play in maintaining uniformity across design platforms. By using well-defined naming conventions, organizations can align their design systems with their core values and goals. The panelists also discussed how AI could revolutionize token management, potentially simplifying tokenization and reducing the manual effort required.

Attendees benefited from a detailed discussion on governance challenges and the importance of onboarding. The experts agreed that clear communication and educational initiatives are crucial for effective token integration, ensuring all team members are aligned and knowledgeable about the system's design and functional goals.

Chapters

00:00 - 00:30: Introduction and Overview The introduction chapter begins with a webinar welcome message. The host greets participants and discusses whether to wait for additional people to join or proceed as planned. Despite the initial decision to wait, the host decides to start without further delay, thanking everyone for their participation.
00:30 - 01:00: Welcome and Webinar Announcements The chapter titled 'Welcome and Webinar Announcements' begins with an introduction by Chris Bloom, a developer at Napsack. He expresses his enthusiasm for discussing the topic of tokens. Chris also takes a moment to announce an upcoming webinar scheduled for March 26, which will focus on creating accessible experiences in Design Systems. This chapter sets the stage for the discussion by providing a quick overview and upcoming events related to the topic.
01:30 - 04:00: Speaker Introductions The chapter introduces upcoming events and the speakers who will be attending them. Details include events in San Francisco, Chicago, and New York City where discussions on Design Systems and tokens will take place. The speaker encourages the audience to join and reach out.
04:00 - 10:00: Discussion on Roles and Responsibilities The chapter titled 'Discussion on Roles and Responsibilities' begins with the importance of cloud technology in SL events and a brief mention of the main topic: discussion on patterns. The host introduces several speakers: Jackie, Donnie, and Miranda, who all work with tokens in different aspects of their job. The session includes a request for the speakers to introduce themselves to the audience.
10:00 - 21:00: Naming and Token Structure Chapter Title: Naming and Token Structure Summary: Jackie Li, the lead UX designer at Opus, a Dow Jones company, discusses their role which includes managing infrastructure projects, handling design system tokens, and overseeing product development and design. The chapter appears to set the groundwork for understanding how these elements fit into the broader design and development structure at Opus.
21:00 - 31:00: Governance and Challenges in Implementation In this chapter titled 'Governance and Challenges in Implementation', the focus is on the complexities and strategies surrounding the adoption of design systems. Diato, an architect at Design Systems house, shares insights into Future Design Systems and emphasizes the importance of a structured definition for design tokens. Diato introduces a unique method called 'Mison mode' that enables efficient multibrand multi-theming, aiming to enhance accessibility. This approach is intended to streamline design processes for various brands and audiences.
31:00 - 48:00: AI and Future of Tokens The chapter titled 'AI and Future of Tokens' features a transcript that centers on the role of design tokens in technological advancements. It begins with a speaker expressing their dedication to sharing insights gained from extensive research over the years. Miranda, introduced as a Staff Product Designer at Instacart, is highlighted next. Although her introduction is initially muted, she shares information about her role, focusing on the consumer design system at her company. The chapter implies a focus on merging AI with design principles to innovate future token applications.
48:00 - 59:00: Q&A Session The chapter titled 'Q&A Session' features a discussion centered around Design Systems. The speaker highlights their work experience, mentioning their involvement with designing systems over the past eight years, including the uniform design system at Huddle, a video technology company. They express enthusiasm for transforming small issues into large-scale solutions, drawing a connection to the ongoing discourse about tokens, which seems to align with their perspective.
59:00 - 60:00: Conclusion and Closing Remarks The chapter begins with a thank you to the audience for attending. The speaker sets the stage for a discussion about tokens and introduces a list of general categories that will be covered. Not all categories will be explored, as time is limited. Specifics are postponed until after the initial presentation. The speaker emphasizes the forthcoming Q&A session, encouraging audience interaction through chat and a specific question feature in Zoom.

Talking Tokens Transcription

00:00 - 00:30 [Music] all right uh I think we have started the webinar hello and welcome um do we need to wait a minute or two for any more folks to hop in or can we just get going I'm just gonna get going all right welcome and thanks for joining us uh we've got a number of auspicious fol f
00:30 - 01:00 with us here today to talk about tokens and I'm going to share my screen a little bit so we can get some slides out of the way real fast we are talking tokens today uh I'm Chris Bloom uh Dev here at napsack uh I really like tokens I'm excited to talk to the folks that we're going to be talking to uh first off quick little announcement we've got another upcoming webinar March 26 we're going to be talking about accessible experiences in Design Systems how to make Design Systems accessible
01:00 - 01:30 first we have some neat folks we'll be talking to uh about that as well so please sign up for that uh if you can uh we also have the patterns Event in San Francisco March 13th uh April 24th in Chicago and May 15 New York City get a bunch of uh napsack and other guests on stage and we talk about Design Systems uh as you can tell we like Design Systems we like tokens uh and we're putting on a number of these events so uh please get with us uh hit us at naps.
01:30 - 02:00 CL SL events the doc cloud is very important SL events and let's talk patterns uh so we got a couple speakers uh today and I'm going to have y'all introduce yourself uh but I'll just run through the names here really quick we have Jackie Donnie and Miranda and uh they're going to they all deal with tokens in various ways uh throughout their uh work and if you could please I'm going to stop sharing just so that we can see your faces Jackie could you introduce yourself please uh everyone
02:00 - 02:30 Jackie Li here I'm with Opus a dowj company and I'm the lead ux designer here and um a part of my position is to handle infrastructure projects and design system tokens and all that good stuff it falls under the infrastructure project another part would be um product development and product design so and that would be something that is also on my plate uh over to Donnie
02:30 - 03:00 hey folks diato here I'm founder in ch architech of a company called Design Systems house where we're dedicated to Future Design Systems as I think uh many folks on the on the U webar might know that I'm very into design tokens uh maybe a small part of you might know that have a very strict definition when it comes to those tokens that's related to uh a approach that I call Mison mode which helps uh do multibrand multi- theming uh things in a more accessible way uh for a lot of folks so um in order
03:00 - 03:30 to do that correctly um design tokens is a big part of that uh and I'm definitely here for um my insight into um the research that I've done over the number of years for that awesome Miranda tell us about yourself you are muted what I said about tech this morning H hi everyone I'm Randa balk I'm a Staff product designer at instacart um I work on our consumer design system
03:30 - 04:00 called Pantry which then gets themed into multiple Design Systems across multiple products I've been working on Design Systems for about eight years my previous was the uniform design system at huddle a video technology company my favorite thing about them is taking tiny little problems and making them large scale Solutions so I know that sounds pretty Niche but that's I think why everybody's here because tokens definitely fits that
04:00 - 04:30 thank you all for being here uh let's nerd out about tokens uh I'm not going to leave this slide up for very long but I do uh have a set of General categories we're going to talk about we're probably not going to get to all of these but here they are I'm going to flash them up on stream before I ask y'all some specifics all right we will have a little bit of time for Q&A at the end uh feel free to dump your questions into chat I believe Zoom has a specific ask question question feature please use
04:30 - 05:00 that all right so I'm going to start with uh let's talk about roles uh let's talk about roles for people who do tokens in organizations um what roles for tokens do you have specifically within your organization is a tokens person a title is it separate from the overall design system how do you how do you cat oriz people who do
05:00 - 05:30 this within your organization yeah go ahead Donnie no go ahead I was start before we we um jump into that I I just wanted to point out like naming tokens is such an interesting and in-depth field and it has history in scientific naming infrastructure in information naming system and then um it
05:30 - 06:00 it really expands to in-depth idea about naming things and then it also ties to your your organization's um goals and your culture and how things runs what's important to your company so um but unfortunately like for a lot of companies token naming isn't really part of uh um a a specialized role it's like
06:00 - 06:30 we all like I'm doing naming tokens but then I'm not specialized in that and I can you know over you know to see what uh Donnie am Miranda has to say for other organizations but for us it is in a particular specialized role yeah the same is true at instacart um I think it would be kind of risky to have a single person be the one and only tokens person I kind of live and die by
06:30 - 07:00 the hit by a bus Theory um or that somebody goes on a vacation and then everything is gone um so at least on our team it's a pretty wide group effort um I can say single-handedly like I'm kind of driving the workflow but um I can't do it by myself so I'm working very closely with our uh staff content designer Rachel Rachel she's helping us with our nomenclature like how do we C categorically separate things I'm also
07:00 - 07:30 working with our Engineers to make sure that there's certain things that we can avoid or you know things we've already established that we should fold into our system um that definitely wouldn't happen by myself so I would say there's probably five people contributing um but there is definitely not a single person responsible for tokens I it's interesting we talk about the naming of the directly with the roles thing because I actually think about the role roles not necessarily
07:30 - 08:00 with the naming because I'm thinking about okay there's a couple of different roles that are sitting in the space that that require to work with tokens so as a really good example of that is like you know you'll have someone that's creating a theme let's call it like the Valentine's Day theme for your brand right that person isn't necessarily like naming tokens there they're going to be working with the existing tokens that were potentially provided to them and then assigning values to them that's what I call Cur right they're going to
08:00 - 08:30 Cate values to existing tokens to then convey what it means to be the Valentine's Day theme so that's one role that's basically like the brand manager or marketer or whatever the person that's trying to convey a brand or an expression that way so they're working with tokens there and then on the complete opposite side there are people working with the tokens to apply that token to a place in the UI such it does get that value right so there's the probably an engineer maybe a designer as
08:30 - 09:00 well that is taking a token and saying okay where does this token go in the interface such that it gets the right value so there's another person's implementing that and then certainly there's a person in the middle that's trying to determine what that connection looks like and that's I think where the naming part comes in such that the person who's curating a value has a good understanding about what where that value is going to end up once it gets to the interface and and similarly that person who's a signing the token to an
09:00 - 09:30 interface part knows that they're applying it to the right place because of the naming so the naming part obviously is important I'm sure we'll get more into that later but in terms of roles I've always seen it as what I would like to call three individual roles right for those three sections but what happens very often is that you'll have a team that ends up doing two of those roles so maybe those two roles are the curation and the naming
09:30 - 10:00 or maybe it's the naming and the application the execution and what happens there is that people get confused about what part of the role that they're going to be in such that like you know they'll introduce their own bias to the naming such that it works out for them in the curation step or it works out for them in the execution step and that's like the the the gray area that ends up happening but me personally I like the like the very specific roles about what
10:00 - 10:30 you're supposed to be doing and identifying that that's happening do do yall find their naturally uh sort of arrives a token Steward right someone who's who is pushing this long Miranda you mentioned that's kind of you right someone who's like most passionate about this most understands this is there naturally someone who kind of Rises to that that role I say there has to be I'm I'm a token tyrant honestly I have like I said
10:30 - 11:00 I have a I have a very strict definition when it comes to the the tokens that I deal with uh and any deviation from that isn't going to work at at at the vision that I have for tokens now granted like you know it's entirely possible to have additional tokens and I have systems that do like customization there but when it comes to the north star of what the I see the system is providing to be as scalable as possible it's important for the tokens to have a system behind them and maintaining that system needs
11:00 - 11:30 to be U you know done in a in a way that uh um is regular and has consistency and has a pattern behind it yeah I I also agree with Donnie because um when I first started a um design system that utilizes one of our product as a pilot I created all my design tokens and then I use um figma token Studio to that and then it has its own logic it
11:30 - 12:00 has its own patterns and in order for it to expand in a way that I wanted to it has to follow a certain logic to it you can't deviate from that logic and if there are different uh patterns or different directions different business needs that will kind of Branch out of that but still has to follow the same logic and if it doesn't then you you get to that restart
12:00 - 12:30 again yeah and I would say from our perspective like it's a team effort to kind of do that like I kind of Steed you know the spreadsheet behind this kind of thing um but our our Engineers are also aware like if there's another team trying to create something TP even just yesterday we had an engineer come in and say that hey this doesn't look like our colors or our type tokens like is this something we should be adding um and so like it becomes a team effort to make sure that we're managing and um governing those
12:30 - 13:00 tokens and if we do need to figure out like okay maybe we need to expand something or add something new um we kind of come as a a group consensus um so we all feel a little bit of ownership in it awesome um you know uh talking about tokens and the responsibilities and the governance around this that feels like you know there's a lot of there's a lot of thought there's a lot of planning that goes into tokens but i' love to hear about your
13:00 - 13:30 experience starting from scratch with the understanding we're going to start with tokens versus something that already exists and we have to backport tokens into it right uh because I know you know every prod every design system isn't perfect sometimes we go oh this is something we need to add in later what are your experiences in that kind of design system life cycle of starting with tokens or trying to get them in later I can say I've been on both sides and it's so much easier to do at Green Field when you're creating a design
13:30 - 14:00 system and you're like okay we're going to create these components and then we're going to have to implement them and migrate everything over to the design system it's so much easier to Define and set things up for Success Through a brand new design system I'm currently in a situation where we're like backing the tokens into our system um the the system's been around for about five years we're going through a major migration and everyone's very familiar with our primitive level but we don't have any semantic level stuff and so
14:00 - 14:30 there's a mountain to climb in education of getting people's mental models to shift over from referencing like grayscale zero to actually this is going to be button label um and so there's a whole different ball game and a whole different strategy to implement tokens at that level than it is just saying we created a token pallet and we think we're going to start here and we're going to build a button compon component and then implement it and shift things
14:30 - 15:00 um as necessary though I will say in my previous design system we we learn the hard way too um it kind of goes back to the naming our very first breaking change was fixing the names of some of our tokens because we named things like um I can't remember it was like electric blue or something and people were like I don't know what this means or how do I reference it so there's definitely tradeoffs um I wouldn't say that one is like preferred because I don't think you can choose but
15:00 - 15:30 being on the Green Field startup from a design system from nothing is easier so to speak um than backing it in at least from my perspective plus one Miranda plus one I mean that the the I can't um the amount of a mental model shift that it needs to take to to go from a color red 500 to something semantic is still a problem today and I think when we finally unlocked dark mode as a concept that's I think the best
15:30 - 16:00 thing in terms of explaining to people hey this thing can't just be white it doesn't it's not going to be white Forever there's going to be a situation where the the background is going to be dark and it doesn't make sense for us to you know have this conditional that says if this then put this color in and if this put this color in at this level of the page where we have to bother Engineers to do that that that kind of
16:00 - 16:30 conversion we want to take that away from from the complications and just say there's a variable in here that could either be black or white without suggesting that it is either black or white that is literally just you know page background or something like that so that mental model shift is is the biggest hurdle when getting into what we need to do in in in the token land I I agree yeah um definitely when you start from the beginning to set up
16:30 - 17:00 your token uh logic it's easy in a way but at the same time when when I'm was doing it um I was both the consumer as well as the designer for it so I had to like battle myself have these mental fights with myself and trying to rationalize uh some of the decisions that I made um and then and then to your point uh Miranda like what to adopt a
17:00 - 17:30 new system is a is a whole different thing like adopting tokens in a new system is a whole new ball game and on top of that to merge between the two different system that's that's even tougher so it's like three different levels of um challenges awesome I like I like I like the Insight around um uh dark mode kind of being the thing that kicks this off right that hey do we really need tokens
17:30 - 18:00 it's like well I've got a value here and it needs to be one of two things depending on some kind of context that gets I think a lot of people thinking in this space uh which is super awesome with tokens um got a question for y'all naming uh let's talk about naming for just a second um how many tiers is too many tiers for naming tokens right we've got our like three you know uh brand dark 500 we
18:00 - 18:30 mentioned earlier uh is what about four what about five what what don't give me an aneurism Chris I don't want me what is your experience what do you prefer and what's too much don't you freaking dare five second te I don't need this tears oh my God I want you to I want I want the webinar to know that he already instigated in the email earlier about this particular question and knows that I'm going to be fired up here's the thing for me okay and I I write about this in a lot of stuff Peter says of
18:30 - 19:00 warming up I say this in a lot of a lot of the work that I do that I I do truly believe that you could have a fully um covered system with a single tier of tokens if you name them correctly and um that single tier being semantic tier that depends of course on it being um uh well defined like I was saying earlier about being the token Tyrant so the Primitive level of tokens in my opinion is really only for two reasons and it's
19:00 - 19:30 both human related reasons number one being that you want to convey the idea of this specific red to somebody it's much easier to say color red 500 than it is to say hash ff66 CC right like that's very like cumbersome to say so it's a lot easier to just say color red 500 it's like okay I know that's a red I know it's somewhere in the middle is fine and the second reason that we have those print of tokens is to reduce the amount of kinds of red that we could potentially choose from so we reduce that to the 10
19:30 - 20:00 or 12 or whatever it is such that it makes it easier for us to choose Hicks law right we want to make sure that we could choose easily by reducing that set so that's why Primitives exist but you don't need Primitives necessarily you can assign values directly to semantic tokens and totally be fine it's just that people feel like those tokens being there makes it a moreit more descriptive to a human it's totally fine on the other side which I um was on a webinar last year with a couple of folks for Supernova we talked about component
20:00 - 20:30 tokens and how I'm also against component tokens that's because they are too specific to the interface right so basically if you wanted to change the modal backdrop color sorry not the modal backdrop but the modal background color separately from any other surface in the system that starts to deviate your consistent system look and feel right so you having all these specific little things that you can tweak makes everything a lot less and less consistent and it also makes it such
20:30 - 21:00 that you have to curate more and more values to cover the entire system when instead when you do a semantic token you can generalize it and say all surfaces at this level are this background color all surfaces this way or this background color so that makes it a lot simpler to to handle yeah um Kevin and I we had a lot of discussions when it comes to which level of which tier of tokens that we should um you know uh publ publ size right so
21:00 - 21:30 semantic layer is definitely the key to go about doing things because you have better control of how it's used with the intent that you want it to be used um definitely like to Donnie's Point having that primitive token is basically a way to reduce the amount of choices because you have the gammoth of all the colors that's out there but it's reduction so it's it forces you to work with what you have and maybe around 10 to 12 whatever
21:30 - 22:00 it is um but then from then on you assign these semantic token however you wanted to uh express your brand and your um what what you wanted to do and then only like this is the only set of tokens that should be released and then when it comes to um component tokens Kevin again and I we we did some calculations on this and just the button alone we put in
22:00 - 22:30 all of the the different variations for a button and we're not even done with all of the buttons and we already got to over a hundred tokens and the amount the sheer amount of tokens that you have to keep track of just for a button component is way too overwhelming and it's nobody can keep track of that so it's better and and this is something that I always wanted to um argue not argue but push for is to keep the
22:30 - 23:00 component token in the code level and not something that the design system people have to it doesn't go back Upstream to the token definition absolutely yep yeah uh we're similar uh though there are certain component level comp uh tokens that we do have to support mainly because of our Enterprise customers uh we have a system that supports native web web and then we have everything that's changed based on an
23:00 - 23:30 omni Channel presence and so in order for us to actually theme things like buttons because people want to change the look and feel of their quarter radius or if it's got a a border or whatever um certain component levels um are required for that in order for us to avoid on that side of the house over customization and configuration for each of those people and we can just manage that at the design system level but there's definitely a line because and I
23:30 - 24:00 will say just because some components have component level tokens does not mean that all need component level tokens also um we're very specific um yes you could potentially change everything with a headless theme to to make it look completely different than what we provide but there is a benefit to scope and so we keep things a little bit smaller and say these are the sets of components that are are allow for those configurations so we'll allow um
24:00 - 24:30 for component level tokens to be there but anything beyond that is crazy town to me well that's I I would challenge that actually a little bit because what's the line right how do you tell anyone like hey these things over here they're allowed to have component tokens but these they're not allowed to have component tokens like that's the difficulty that I'm seeing here is it's like well you know at what point do you draw that line or do you not even have line in at all and just like oh if component T exist maybe that's okay you
24:30 - 25:00 know um you know and I'm wondering where you would draw it so actually this gets into this gets into the governance question i' like to ask yall right which is and Miranda if if if you could take this one right like how how do you handle you know the rules of this system right how do you handle what's allowed what's not allowed how do you handle you know specifics on implementation when you're allowed to override or you're not allowed to override uh talk talk to me about that yeah um it's definitely a
25:00 - 25:30 work in progress uh we have a pretty vocal engineering community and a vocal design community and they feel pretty trusted to come to us through office hours or our slack channels and say hey this is what I'm thinking and we also have retailers that are just like no I want this and so there's definitely some level of Business Development on that side whether or not we're going to allow for certain configurations which is separate than the design system but then from the Design Systems perspective itself we're saying we're only going to
25:30 - 26:00 go this far and the reason is is because you shouldn't have to be thinking about the look and feel or the structural changes of these components because the business value that we provide you give is given through the design system you shouldn't be reconsidering all of these data points and all of this consideration we've taken into it we've done that work for you you get that for free the same thing is true with our accessibility right like they don't think about accessibility because we provide and so like they shouldn't be
26:00 - 26:30 reconsidering some of that stuff and we should not be giving them the option to reconfigure that unless they're willing to take on that burden themselves right like if they're willing to change that then the compliance then Falls to them and so when it comes to governance we'll have designers or Engineers saying hey we've got something we're we're thinking about challenging this and it typically starts with a conversation and then we'll have that conversation and we'll either say actually I think this is is a way you could go or we have something
26:30 - 27:00 else similar that you don't need to go this far um obviously it's really it sounds really vague because you can't really give specifics but it's just a really collaborative conversation and we end up reaching a good resolution sometimes we do make changes um I won't say that we go into every conversation with a Flatout no but we do tell people like have a good reason for why you want to change this and we consider it because you know the product and the people better than than we do we want to support you but if it doesn't match with
27:00 - 27:30 the rest of the rules that we have then it's going to have a hard time to get adopted and moved in awesome does anybody else want to talk talk to us about governance I guess the one thing I'll talk oh okay Jackie go ahead I've been talking a lot I just wanted to reiterate that um the foundational it like you can use them differently but
27:30 - 28:00 it it's best not to use it and just not to even say it because what end up happening is you have unintended uh consequences when it's being used elsewhere right like for instance it let's say if we wanted to use our brand blue for um the lake for mapping uh purposes right and then what if our brand blue changed to brand pink what's going to happen to the lake in the in
28:00 - 28:30 the mapping process so you really have to think about how things are connected to each other how it's related to each other so so in those cases you have to create a separate tier two where it's consuming from separate uh color line in the foundational token area yep the the thing that I think about is I see a lot of folks doing like token workshops uh especially like with in
28:30 - 29:00 individual and their teams and things like that and they're like okay how should we name these tokens what would be what would be helpful for you Etc and I always find that to be very odd because a mechanic doesn't necessarily ask its user that's driver um what the best brakes are to put into your vehicle right no you're no expert you just drive the car right you're no expert in the way of the brake is supposed to be working in your car they're going to talk to other experts in mechanics and and and brakes and aut automobiles to
29:00 - 29:30 determine what the best brakes are to put in your vehicle so when it comes to governing how tokens work that should be amongst experts people who are working in this stuff uh to determine what the best thing is just to Jackie's point about thinking about the system and how it affects the system as an organization across is something that is very very um specific as a as a as a role for an
29:30 - 30:00 organization because what we're trying to do is we're trying to support individual features and if any individual feature designer comes in and says hey what about me we're don't don't worry we're trying to take you into account that's definitely happening right but on the on the flip side your recommendation is typically specific to your use case and we have to think about the general use case so even if the thing that we're talking about ISM when we're saying okay what's the best break
30:00 - 30:30 to put in this vehicle we're considering unfortunately all cars right at once as opposed to your specific car at this time and granted like there are specific brakes that are for specific cars when I do this analogy here but we're taking into account such that we can go ahead and maintain the the right amount of tokens right because if we had too many tokens like every individual kind of break we' have component tokens versus you know having semantic where we have a you know 20 different kinds that do
30:30 - 31:00 satisfy the majority of cases and then the the outliers we can handle you know on the side in some other kind of uh you know process um yeah you actually uh got into an area that somebody just asked a question about gtha asks do you run into people working around the token system uh if where they feel like they don't have a voice in the governance right like like how do we I mean should we you mentioned experts right we're making these decisions trying you we're trying to make this easy for you shouldn't be picking out your brakes I got you cover
31:00 - 31:30 just let us install the brakes um but that sort of situation right uh folks who maybe want a voice or uh you know don't have it how do you handle that I think that goes right back to user research you know like it it you never ask the user hey do you like this right you ask the user can you do this right and what that's getting out of there is is it solving the problem problem right so a person or I'll put in the terms of
31:30 - 32:00 the designer designer says hey I I need this right well when you actually speak with the designer you get to the root of the problem you get to the root of the thing that you're trying to actually do and it's not the thing that it's necessarily asking for what they're what they're trying to do is something broader or or specific or whatever and that conversation might get you to a compromise such that you are continuing to use the system but they also get what they want and it I think that's the education app that comes in here sometimes right you think that you only
32:00 - 32:30 have you know 20 tokens to work with and you're like oh my God how do I only have 20 tokens how am I supposed to put this background color on this thing well if you do X Y and Z you will get the background color that you're looking for oh I didn't know that great move on to the next education you know session that I need to do with this person and it's a slow slog but you'll eventually hopefully get to uh some solutions without you know a problem yeah it's
32:30 - 33:00 definitely the office hours that helps a lot and just to to Donnie's Point like um in the scientific naming system taxonomy like nobody can just go there and say I'm going to name this species something something everybody actually have to get like a master degree or doctor degree in order to contribute towards that naming system because it follows certain logic and then it places things where it belongs so that the next person pick up a new or see a new animal
33:00 - 33:30 they can you know map it back to the source or put it in the same right the right category that's why sometimes you say like you see that this animal is misnamed and then they change the name to something else right there's a reason behind that they so they could categorize them efficiently like properly yeah the reality is we can't stop them from doing anything right like we only own our code we only own our tokens
33:30 - 34:00 there's nothing stopping someone from hardcoding a hex code or creating their own token um I think what the real power comes from what do you do with that once it's done right there are points in the process where you could meet and potentially rectify the solution before it even goes out to production right like that's where an office hours or a conversation comes in or maybe there's an educational gap or there's an opportunity to update your documentation right like there that's like the
34:00 - 34:30 beautiful moment but more over than not it's we need to ship this we need to ship it now the design system is not ready you guys are slowing me down you're blocking me we're going to just go ahead and do this we need to experiment and see what happens and there's nothing from us like there's nothing that we can do to stop them and I think that's how Design Systems grow because how else are you going to understand like additional use cases we have kind of a a a rule where it's um a across three different products or three different surfaces that use the same
34:30 - 35:00 thing then it's gaining enough traction that we should probably start considering that it actually has a real solution or has a real need inside the design system and so we've kind of taken the approach of diverging and converging a little bit where it's go forth do what you need to do we're monitoring we will guide you if we think there's a good Solution that's already existent we will strive you towards that we can't stop you from doing anything anyway obviously we want you to use the design system or
35:00 - 35:30 we can um but if you can't go ahead and then we come back the following half or quarter or whatever and say okay this has started to proliferate across a couple different surfaces let's patternization after because the reality is we're not only just trying to be cutting edge to token and getting everybody the features they need for all
35:30 - 36:00 of our components but we're also trying to maintain a system that keeps breaking or stuff needs to change or we need to refactor something and or we're bringing it into a new product like there's a lot of moving pieces and we can't hold all of them in the air and this gives people the opportunity to test and experiment and see what can happen with us being in the know and then we can figure out how do we actually make this work long term how how are y'all writing this down
36:00 - 36:30 how are you communicating this I heard about office hours a minute ago right hey this is here come talk to us right we're going to show you how to do this stuff how are you putting this into digestible communicable you know forms for not just you know designers and developers but let's go up the chain right stakeholders right uh folks folks we have to convince the value of this how does this become communicable I love the communication parts of Design
36:30 - 37:00 Systems um we personally we release a bi-weekly newsletter for each of our Sprints we follow scrum Loosely um and so every Sprint we will catalog what we've done from the figma library to the documentation to upcoming initiatives to the web Android and iOS packages everybody contributes to that and we post that through slack um eventually it will live on our duck site we also have specific um newsletters now that are going for like the two different
37:00 - 37:30 variants of the design system the tooling system and our Caper cart Hardware system um from there that's more like IC manager level we'll pitch things in management meetings make sure everybody's kind of keeping up with that information it's available all the time people can search for it we're talking about it in our office hours um but then when we're trying to raise things up the chain we actually have a quarterly meeting with our leadership team um and we're giving updates on what's happened what
37:30 - 38:00 we're going after um why it matters the you know the logic behind the Mayhem of why we choose to work on what we do um also field questions and things like that so there's a lot of different you know gears working in one big machine on how we can communicate these things it even goes down to every single time that we publish the figma library we have detailed release notes of what's inside of that figma update and people can see that um
38:00 - 38:30 yeah I have a take on this and it is that no one reads anything that period that no one reads anything uh you know so that's why it's really hard for me to say hey we're gonna like like Branda is saying about you know here's an announcement here's some docs here's this here's that all of that in my opinion is cya it's basically saying look we put out the documentation it's your fault you didn't read it and that's that from a user stand Point actually feels bad right because like oh I didn't
38:30 - 39:00 read the docs it's my fault that I didn't read the docs right or on the flip side that we put out documentation from a design system perspective and it didn't have the thing that they were looking for now we feel bad because we missed something right so it's feel bad both ways and uh you know I unfortunately I I know this is this is not a documentation webinars otherwise I would talk about an hour for this but the bottom line for me is the the reason for what we do is for folks to execute
39:00 - 39:30 on stuff right we're in production environments people are just churning things out they're moving at a fast pace Fast Pace whatever um but what they're trying to do is they're trying to get unblocked all the time so when they're trying to get unblocked they just need to get the thing done and them stopping to read something is a roadblock for them so there's a world where we can meet them in the space where they're working such that they can continue
39:30 - 40:00 working in that space right and you can imagine maybe in like a code editor where you kind of like see the Tailwind you know uh classes pop up in your editor it makes it really easy to pick the right one right so like there's that maybe in figma there's you know a limited set of tokens that you could choose from to do this one particular thing but there's definitely more to be done in that space because in some cases you don't even know how to pick the right thing and you again sitting down in in documentation I don't think is
40:00 - 40:30 going to help I think some of the more generic naming that we have for tokens which I'm completely guilty of also doesn't necessarily convey what to do with a token so there is something missing in the education piece that again isn't them sitting in documentation you know traversing it getting lost Etc stopping them from doing what they're doing but there's also something that could allows them to continue what doing what they're doing right maybe it's it's a copile AI it
40:30 - 41:00 says hey it looks like you're trying to you know use tokens for a button have you considered these right something of that nature that maybe helps out in that way such that again we're not just cing documentation we're really you know uh helping these folks along to make the right decisions without slowing them down I think dos and don'ts in those documentation is very helpful but then uh a lot of times I'm actually seeing components being used in creative ways that I I would not be able to guess the
41:00 - 41:30 don'ts so so it's it's it's a tricky thing but I think a lot of times sitting in meetings with them while they're developing things can help too just reviewing some of the um designs that comes out of it utilizing your design system thank you um this is this is pretty insightful and you know Don you mentioned AI um I know it's it's it's kind of uh everywhere you know and it's
41:30 - 42:00 we're gonna we're going to bring it into this conversation here tokens are structured data right so they're very parsable they're very easy for a robot to figure out what's going on um is there a space is there a place for AI to help token adoption in coding or designing right Don you mentioned like hey the popup can you know you're typing and it just autocompletes for you right um that's on like the development side
42:00 - 42:30 of this on the uh you know the generation side of this as well there's something that AI could potentially help us with right like make me new tokens that might be missing right might have gaps in our system do any of y'all have experience yet with this right uh or is it just a glorified linter for our code talk to me I got something for you um so I've been working on a book actually that talks about Z mode which is which is the the technique that I've been
42:30 - 43:00 pushing around a little bit and one of the things that I landed on in writing that was this this idea that when you look at a immense token Set uh and you get overwhelmed by the number of values that you need to apply to that thing what's really interesting is is that you have a understanding already of what you want to do in your head right I want to convey napsack in a Valentine's Day way well why can't can't we just have ai say you already know what napsack looks like
43:00 - 43:30 you could Traverse its pages and determine this is what napsack is supposed to look like we could feed it what Valentine's Day is supposed to look like please take those two concepts put them together right give me the structured data that assigns you know what it means for a for a button to be in Valentine's Day for knac and then ass associated with the correct token right any anybody any of the 200 people that's in the chat steal the idea make a startup for it okay please honestly
43:30 - 44:00 please I've been to AI conventions asking them about this exact like it's all just data framework yeah I want them to do this I want an AI to look at an a UI and say I understand this and I can create structured data that it represents this that could then be assigned to tokens right because what that does unfortunately it does take some designers of jobs away right I was talking about that role of the marketer that would have to go ahead and assign values to each one of those tokens that's that's gone and now what gets
44:00 - 44:30 introduced is the ability to tweak and say well napsack actually looks like this now right or Valentine's Day actually looks like this now or we need to introduce dark and what does that mean right so now we're we're we're talking about a different kind of role that isn't just you sitting in a dark room assigning values to tokens it is instead trying to influence the thing that's going to eventually assign what it means to be napsack and Valentine's Day to these these properties so I think
44:30 - 45:00 that's a really great place to be honing AI because the amount of time it takes to curate tokens I did a survey on this a couple years ago it can take um almost two hours on average to determine what value is supposed to go with a token right you multiply that number by the number of tokens that you have in your system that's how long it takes to curate an entire theme okay so you can
45:00 - 45:30 just take think about the number of tokens you have right now times that by two and that's hours and in some cases that's an entire Sprint and I know G's in the chat but in adobe's case that's an entire month um so that's a long time and I think we could definitely um do better in that case especially using AI I want to see AI Implement my tokens um I want to see uh a world where this
45:30 - 46:00 migration that we're doing where we're backing tokens into our system I want AI to handle that um I don't know that we're in the position yet given our life cycle currently um to have it create new tokens or help us with new theming or you know exactly what Donnie's describing I think there's a future for that I think when we're working with partners and new retailers and new business Investments like that has a perfect opportunity but I think that's
46:00 - 46:30 something that's more applicable at least in our case is how can we get tokens used across everything um especially since we're coming from a world where people are hard coding things or they're using the Primitive layer and we we've got to like help teach them that um we've got like anybody hundreds and thousands billions of lines of code and when it comes to changing something it takes so long to make sure that things are looking and
46:30 - 47:00 rendering the way that we want whether or not that's a manual audit or we're using some kind of tool like chromatic or whatever it is that you want to see to screenshot test whatever um I think back to this time last year where we simplified our type ramp and we changed our type tokens and we mapped 38 down to five different type tokens and the effort in which it took to look through all of that and check it out and make sure that we're working the way that we
47:00 - 47:30 want to and it's represented the way that we need it to be and then it's actually you know using the right type Styles or it's using the back string the backend strings that are not actually being changed like that's where I think AI has a lot of value because that's the kind of menial work that means a lot for a design system but it's very hard to get feature teams or even the space for a design system team to have the runway to do that work but that's the meaning of it right like that's where you say
47:30 - 48:00 you want something to be able to flip a switch and we want to be Valentine's Day next Friday cool we can do that only if tokens are like implemented and implemented correctly and so everybody loves that future but like the work to get there the reality and the step by step and the code line by line you have to go through in order to integrate those tokens that's the hard cell but that's the work that really matters and so that's where I want AI to go yeah definitely it's like Miranda you
48:00 - 48:30 what you're saying is like if data is garbage garbage in garbage out and then the same thing with how design tokens are applied if it's applied incorrectly then it's useless but Donnie you're up to something because the whole idea of how AI is possible is because of the all these tokens and the systematic way of mapping things and if that is doable then there should be a way for AI maybe we should are something I mean this this gets into
48:30 - 49:00 you know if I could just bring you know napsack into this a little bit because you know this is my baby uh right we we we always talk about with our our tokens as some as structured data right if you can store something as structured data it can be parsed right and you know everything in napsack is structured data all of the content all of the props all of the you know especially our entire tokens engine and you know one of the things that you know we talk about with tokens to folks who are looking at appac is just like hey once you have this and
49:00 - 49:30 it's easily accessible right we provide this for for folks that use an napsack you can do anything with this right uh Miranda you mentioned like hey can we have it backfill all of the stuff that's not using tokens right the idea of being able to say like find every hard-coded value in my code base and try to find the closest potential token value to that is a you know o we've had that for a couple of years in a right like it's right there and it's so easily parsable
49:30 - 50:00 once it's data when we were only storing tokens you know think back a couple of years ago we used to just store it all as like I don't know SAS variables or you know pre CSS variables right we didn't put it as data and we only had this idea like hey maybe this should be Json in the last couple of years I think there's a lot of unexplored ideas Donnie right you told the audience hey go make the startup right like there is a h huge potential here and it all starts with the structured data of tokens and you
50:00 - 50:30 know napsack loves to store uh data as structured uh at rest um we are right at the time for QA and I'd like to get to some QA uh questions from the audience here there's a lot I'm just kind of kind of read through these some of these are questions from back when we were talking earlier let's see if we can kind of uh run through these really quick um we got a question here how would you go about onboarding design system users to use uh tokens of their work basically it's an
50:30 - 51:00 onboarding question we talked about documentation we talked about um you know office hours anything else around onboarding and and teaching new new folks how to use this stuff we have a session that every new hire designer goes through um and we have them review you know basically the Primitive level stuff um so all of our atomics um talking about the type talking about our base level um colors and that's simply just because our we
51:00 - 51:30 don't have a like a semantic layer to tokens yet um but we do make a point to get in front of folks when they first join um mainly because we also use it as an opportunity for us to gather as much information from them as possible um before their bias changes to the way that our company works like once you start using the system tell us all the stuff that sucks so that we can fix it um it's a great opportunity for that but when it comes to teaching them about
51:30 - 52:00 tokens and how to use them um we give example uis we go through components together and we explain those principles on an individual level and fortunately that's because of the size of our team and the number of folks that come through um on a monthly basis uh it's definitely difficult to do it scale but that works for us awesome um here I'm going to grab another question from the audience here really quick um why does naming tokens even matter
52:00 - 52:30 for example why not use a unique hash ID for the name and then set of descriptions that go uh in the idees right why don't we just call all of our tokens x29 s right why even give names humans are the problem as usual humans are the problem that's that's that's what's going on is that some human needs to read this you know it was interesting because there was there was a there's a video flying around right now with two AIS that are talking to each other in English and then they realize that each
52:30 - 53:00 other is AI and then they turn and they say hey can we just use like computer code to talk to each other like yeah let's do that and they're like so like it's very interesting how fast they were talking which yeah absolutely if everything just hash and the computers are just talking to each other yeah we don't need this anymore in fact that AI world that we're talking about saying like oh you know just assign the values and and move on with no human intervention absolutely make them hashes the like I said earlier about the reason why the the Primitive tokens exist is
53:00 - 53:30 because of humans and because humans are still doing this work we still need to make that easy for humans to understand why we're doing all this stuff and where it's supposed to go uh until you know the the machines take over they'll they'll continue to be um nonh hased IDs yeah I I wanted to touch upon the naming um because it it really reflects what your organization is the value of your organization and what you price as the important thing to you like just
53:30 - 54:00 want to um reflect back on my Chinese name my Chinese name I have my family name and also I have my generation name and then I have my own name right so if I introduce someone to to my family member if I'm at a family gathering if I say my name then people know where that generation name which generation I belong to that goes back to the culture my culture value relationship and where
54:00 - 54:30 you place within that relationship so that again that goes back to humans humans are involved so if we follow the same logic and we communicate the same value then great if you understand the hexico of whatever you just mentioned everybody else understand the same thing great all powers to you but if you if there's a disconnect that becomes the problem awesome uh another question how do we
54:30 - 55:00 encourage or instruct designers and Engineers to break it says it in a way that they can more easily come back I think that means how do we how do we allow them to make changes or find gaps and feed that back into the system is that just PLL requests is that just like taing somebody on the shoulder and being like hey uh there's a gap here yeah I mean the system isn't perfect because I going back to the flesh is
55:00 - 55:30 weak thing thanks Chris um humans are the problem and we're going to uh make mistakes and need to improve and iterate and etc etc uh you would think that we would have figured out how to make a button by now but maybe that isn't the case um so it's entirely possible that uh you know we need to uh improve on some things um I do know and it's interesting that that g um put that question in because looking at Adobe Spectrum one of the things that uh my team looked at uh was the fact that if
55:30 - 56:00 you um override something in their Library not necessarily tokens but more so Styles um it actually um removes all the styling underneath it and it kind of says oh you want to update the styling here well now it's all on you right now it pushes back and says hey you know you want to do one thing well you're going to do the whole thing right because we made some uh important decisions in here and if you think you can do better then you're doing the whole thing better and
56:00 - 56:30 I'm confident that some of that and he I'm sure gar could say some things of this but I'm sure some of that informs what to actually improve in that button right so if you continue to see that same change happening um not exactly what you intended thanks G um if you can see what's going on in that system uh you can uh then improve it because of of what's going on in there but gu will go in the comments and and and tell me what's really going on because again that's only what I'm seeing from the outside about uh what
56:30 - 57:00 what I am assuming in there but uh he can he can say more on that awesome um what developer experience or tooling plugins make it easier for your team to use tokens uh there's like intellisense explanation obviously we've got a lot of AI agents now and a lot of our our developers what have you found that makes it easy to just hit a button and see what's available lending's been pretty good for us um I
57:00 - 57:30 will say from the figma side of things we invest a lot in building our own personal plugins as well um because we're trying to get Engineers involved in figma at a better level so they understand what they're looking at um obviously they have features like code connect and stuff like that will that will help um we have not implemented that but at this point it's pretty minimal um um curious what others are doing when I
57:30 - 58:00 when I was working with token Studios I was able to we were able to um push out a Json file and within that Json file it has all of the tokens that we could um utilize and then also we we use napsack we also publish our um tokens there too so it is available for everybody to see excellent all right we are right here at the end I wanted to thank everybody for awesome awesome conversation around this stuff uh no fist fights this time that
58:00 - 58:30 was really that was definitely an improvement um uh last little thing as we finish up we've got uh weekly demos uh uh for napsack uh every Thursday tune in check them out just showing off what we do it's pretty fun take a lot of questions from the audience as well also in March we've got this new thing in apps set called a consumer roll tune in every week find out what that's all about and uh Donnie Miranda Jackie thank you
58:30 - 59:00 so much for your time thank you so much for being here and uh I really appreciate this opportunity to talk about tokens thank you everybody thanks for having me have a great day guys [Music]