Design token takes, pt. 2 | Knapsack A Tale of Two Tools: How Knapsack and Storybook Stack up Knapsack for Engineers: Spend less time maintaining and more time coding Patterns: An event for design, engineering, and product leaders. Apply now! Features Dynamic DocumentationDesign Tokens & ThemingComponent & Pattern ManagementPrototyping & CompositionPermissions & ControlsIntegrationsProduct Tours Solutions For Product TeamsFor Design System TeamsFor Product Executive TeamsCase Studies Resources InsightsEventsDocumentationROI CalculatorFAQs Solutions DesignersDevelopersProduct ManagersUX Writers Enterprise ROI Calculator PlansBlogHelpBlog Accessibility AI Announcements Collaboration Design Systems Design Systems Design Tokens Events Insights Podcast Product Webinars Contact Sales April 26, 2023 | Chris Strahl Podcast Design token takes, pt. 2 ‍ Transcript Chris: Hi, and welcome to the Design Systems podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design, code, and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think, go ahead and tweet us @TheDSPod. We'd love to hear from you. Hey, everybody. Chris here with the Design Systems Podcast. This is part two of our two-part episode where we're talking with experts in the design systems community about their takes on tokens. If you haven't listened to part one, that's probably okay. Each of these can be sort of their own standalone episode, but please be in mind it is a two-parter. I also want to let you all know that registrations are still open for our webinar on April 26th where we're going to be hosting all four of these guests in a panel discussion. I hope you register, and I look forward to seeing you all there. Without further ado, here's part two. Hey, everyone. I'm here with Darren Simons. Darren is a designer and going to give us a deeper design take on the structure and thoughts about design tokens. Welcome to the program. Darren: Thanks for having me. Chris: Can we talk about where you work? Is that cool? Darren: Yeah, I work for MuleSoft, which is a acquisition of Salesforce, and love my team and love where we're at right now. Chris: Awesome. So with that, I think that the perspectives that we've had so far have been really great at talking about a lot of the interactions with design tokens in practical workday. When it comes to you as a designer interacting with tokens, before the show, we talked about two core things, and first was how you think about tokens and leveraging tokens, and then secondly, how do you think about what comes after you in that process and how you set up developers for success with tokens that you're using. Darren: Yeah. So currently, we are thinking about tokens. We have not implemented them yet within Figma, but we have been writing a lot of hooks for our components. So that's primary what I do within my specification is writing these hooks, or styling hooks. Styling hooks is unique to Salesforce, and that's where that derived from, which is probably just what people call custom properties in CSS. But yeah, that's all I'm writing right now is for our developers right now, or a developer. Chris: So you have a Figma file and you have a bunch of CSS custom properties that ultimately end up in the hands of an engineer, and those CSS custom properties, you call those hooks. And so where does that come from? Where does this thought process and workflow originate? Darren: So I work with an awesome dev manager. His name is Jon Levine. He actually worked with Jina Anne at Salesforce, and they came up with the whole design token strategy, those two. Jon was on the engineering side and Jina was on the design side. So styling hooks is really I think coined by Jon, so that's why we implement them. Chris: Gotcha. And so tell me a little bit about how that relates to your workflow. So you have a Figma file. You've got a new feature or something you're modifying about that Figma file. And what is happening is you're thinking about design tokens, even though tokens aren't fully implemented in Figma. What happens then? You've built that thing. How do you go and transform that into something that ultimately an engineer can then use? Darren: Yeah. We have started to identify our needs more. Salesforce has given us some really great groundwork on how to lay out these hooks. And so when I look at a component, and maybe we're saying a label of an input, I need to understand how I can give that to a developer. And like we talked about earlier, maybe not everything needs a hook is what we're kind of finding out, but we need to hit on the color, the background color, border color, all these different things. But how does that look like in a hook essence? So we have different identifiers, which can be the name space, whatever your system is called. The scope. So is it a global component? Is it a shared component? Is it going to be a component? An object. And objects can be a component, an element, or a group of components. And then we have different types, so you have categories, properties, and a concept we're wrapping our heads around that was a [inaudible 00:04:16] thing that we were looking into. And then a modifier. So variance, state, scales, and mode for light or dark. Chris: Interesting. So you have a convention that you've put in place that represents the hierarchy of how these hooks flow through your system. And that convention applies not just to individual components, but it actually can apply to groups of components as well? Darren: Yeah, totally. So if we have subcomponents, we can then have a shared scope. So if it was Knapsack-S for scope, so we're abbreviating it to be S, and then whatever the component is, let's just call it a label because that can be shared across an input text label, input select label, or component I should say. But that's how we're starting to think of that nature for writing our hooks. Chris: Gotcha. And then those are basically anything that represents some sort of visual styling? Darren: Correct. So like I said, color. If there's a border width on that input text component, we're coloring up that border too. Chris: So if there was a Knapsack scope that would represent the scope of our app. And then you could have another scope that would represent a state or a particular part of the app. So component browser. So I want to browse my components. Looking at that component browser, I can have different properties for that than I could for a different state in the app or a different section of the application. Darren: Yeah. Sure. Chris: Cool. So what form does this actually take inside of Figma? And where are these things getting written down? Basically, they're in a text editor writing a JSON file? Are you in the code mines or are you just sitting there doing a bunch of custom field stuff inside of Figma? Darren: No. So we have a Figma file where we will show a visual. I'll just keep the input text or input, select a reference, and then underneath of that visual we'll have a table of it will be property name, CSS property, the fallback value, and a description. And so that's how we are writing everything. It's very manual right now. We do want to play around with some of the newer plug-ins that are coming out, but we also know all these plug-ins aren't going to be a one size fits all. So we need to figure out how we're going to do that. But right now, that's how we're creating our specifications. And then we're also creating kind of a source of truth in a Google Doc of all of our shared hooks so that they're easily accessible and we can see, "Oh, cool, then we can filter on things if we need to." I mean, it's a very visual there too. You can imagine trying to update all this in a Figma file is not the easiest, so doing it in a Google Sheet or something is probably a little bit easier. Chris: I love the gritty, hacky nature of the tools, like "Hey, this is really hard, so let's figure out a solution that works." I think that people underestimate how much of design systems implementation is still this, "Hey, I don't have a perfect solution for this, but I have something that works that allows me to achieve a goal." And I think that it's a great example in the case of I have a bunch of global styling, I don't have a schema or a spec definition that I can easily stick that in that everybody can look at, so let's put it someplace where you can have it as a reference that everybody can at least view and use. Darren: Totally. I mean, and obviously, our process is always evolving just like anyone else's from team to team. You learn as you go. And I have been finding that out, which I really enjoy. This is my first design systems team that I've been on. I've been always a part of a one-man show. So it's nice to have all these different collaborators to help make myself a stronger designer. And as I learn on the go too, I learn different things. So it's a really cool experience for sure. Chris: Tell me about that collaboration a little bit. You've got a small team that you're working on that is basically your charter is like, "Hey, let's figure out styling and let's figure out how those elements work between design and code." Talk to me a little bit about how that team functions and works together. Darren: Yeah. So we all kind of have our own lane that we're working on. I'm more on the side of building the components. I'm making them, I'm architecting on how they will look. Obviously, we have a visual style that we want to adhere to as we're building that up. But I always look to my peers, whether it's another senior product designer, my lead, or my manager. We're in constant communication to make sure that this is the direction we want to go in as far as visually and stylistically from a styling hook standpoint, or I will make my attempt as best as possible. I'm definitely not a CSS wizard. I am far from that. That's one of my goals this year is to become better knowledgeable in that realm. So yeah, we'll just review all this work together to make sure it makes sense with a developer so we're all on the same page at all times. Once I complete the spec of writing these hooks, then we have a sync and we make sure we can go through this if this makes sense or not. Chris: That's great. I think it's interesting. What has pushed you into the realm of learning more about code and thinking more about code? Because as somebody that is in the design space, we do the same thing. We have a senior product designer at Knapsack who makes poll requests into our application, and that has been something that, luckily, they've been very comfortable with. I don't think that it's always that way. What has led you down that pathway? Darren: For a long time, I feel like after I took my first Python class in college, I was intimidated by code because it's just a whole different type of brain that you have to use. And I'm a very visual person, so to look at code, I always get intimidated. But I feel the more I am in the design system space, it's kind of a necessity at least in my work. And I don't mind that though. I like to be challenged and I want to learn more. And if I can talk to a developer in their language, man, that relationship is just going to become stronger and they'll respect me more. And I think vice versa. I would want the developer to try to be a little bit more design edgy too. And we have great developers who are like that, and I love that. Chris: That communication's a great point because developers are making design decisions every day, and the ability to have that collaboration so they're not making those design decisions in isolation and you're also able to have, to some degree, more control, but it's really much more about…