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 that expression of intent, to have that more concretely tied to the product, I think is always a great way of thinking. And this is the power of democratization at work. Being able to speak engineer and have an engineer be able to understand an interface with a designer around the intent of a system, that's really valuable to make better product.
Darren:
Yeah. I mean, I love what my manager has told me recently, "Try to learn enough CSS to be dangerous." That way if I can open up a code pen and I can code my own component, not saying I want to do that all the time, but it'd be nice to see it live and in action versus creating a bunch of interactive prototypes per se. I know Figma gives that great ability of the designer, but I think it'd be cool to learn that other aspect of our work.
Chris:
Where do you see things going from here? How do you see this progressing for you in your career? I mean, we talked a little bit about AI in other parts of the episode, but look, we're seeing all this AI around generative space. We're seeing design systems continue to reinforce code models ahead of visual models for design. Where do you see this headed for you? Because I think that you're in this interesting place where you have this deep design background, you have this understanding of how design works at scale, you work in the world of design systems, and you've taken that step to get familiar with code. What do you see as the next step?
Darren:
I think for me personally, as I become better, I think and more confident within the understanding of code in CSS, I think my ability, I'll just get faster. Because right now, I move at a slower pace than I like just because one, we're new, we're trying to understand how we're designing and writing these hooks. So it's one, understanding.
I would really have to have a cheat sheet of how we're writing these hooks of, okay, here is the identifiers of each one of these. What are the name space, what are the scope, the context, element, category, et cetera. But as I get faster at that, I feel like we'll just crank out more components.
As far as next steps, I feel like that's really it. It's just being more comfortable and confident in writing these hooks. That way, if there's another designer that comes on board, I can easily onboard them too. I love teaching. So if I can help another person out understand this work, I think that would be what I would love to do is pass that down too. Because it's not easy work, but it's passionate work for me, if that makes sense.
Chris:
Yeah. And I love it. The passion definitely comes through, especially given your willingness to be challenged and your desire to learn new stuff. It's awesome to see. And I think that as you get this understanding and familiarity, you probably don't even know what you're going to be able to do next. I think there's a lot that unlocks that is really cool, that allows you to, again, build better, more interesting products.
Darren:
Yeah. I mean, going back to your question, I've always thought about in the learning realm of teaching, there's a lot of great designers out there that teach systems. I would love to see come together designer and developer and practical application, some sort of teaching mechanism for that. How that looks, I have no idea.
Chris:
Right, right.
Darren:
But I think I would love to be a part of that. I just don't know how to even implement such a thing to... I really feel like if you want to be a design systems designer, you need to work hand in hand with the developers so you all can see the output in action, if that makes sense.
Chris:
Yeah. I mean, it needs to stand up in the medium it's destined for and you need to be able to see what it looks like.
Darren:
Yeah.
Chris:
Well, Darren, thank you so much for your time. I really appreciate you jumping on talking to us about your perspective, and I look forward to having you back again someday.
Darren:
Yeah, would love that. Thank you.
Chris:
Hey, so I'm here with Kaelig. You're a man that needs little introduction. You've done a lot of work in the token space. Why don't you talk about some of the things you're working on?
Kaelig:
Yeah. So one of the main things I've been working on over the past three years outside of my day job is Design Tokens Community Group where I've assembled a tag team of amazing experts, involved the community of toolmakers and people using design tokens in their code bases. What we're building is a specification that will, hopefully, allow us to have some interoperability across tools and spaces to build a better design token-powered ecosystem down the road.
Chris:
Yeah. This is really important work. I think that it's important for us to all understand. We've had lots of different design tokens solutions floating around for a long time in the technical space. There's also a lot of different ideas philosophically about what these things mean and just trying to get one place where we all have this common shared understanding of tokens, how we think about them, how we type them, how we name them, and really have that conversation I guess in that community sphere. We've participated and it's been a joy. So thanks so much for all the effort that you put towards that. You and the team have done a really great job.
Kaelig:
No, thanks to your team as well. It's great to have the toolmakers involved because there's been initiatives in the past that we were trying to unify design tokens around a specific syntax, but they never really involved the bigger community. And that's where we come in.
So we operate under the umbrella of the WC3. That gives us a legal framework to make sure that all the companies that are participating are giving away their work in a sense. That helps us make sure that the specification we're building can be used by everyone and that this is for everyone. Because you've listened to Jina talk about her views on design systems. Design systems are for people. And so we think the same way. She's a co-chair with Val Head and me of the community group. And so that's been influencing that a lot.
Chris:
Awesome. Yeah, no, I love that voice in there and making sure that this is about the people.
So beyond the working group, there's this idea of how do you actually get tokens going? How do you get tokens off the ground? What does a practical implementation of tokens look like? And so if I'm looking at adopting this spec and I work for a big company or a medium company or even a small company and I want to try to get started with this, what does that look like in your mind?
Kaelig:
Well, at the moment, there's a decent barrier to entering this world of token nirvana. I would say that depending on the shape of your team, you might start on the design side in whatever design tool you're using, or you might, if you have more developers on your team, you are going to be ending up starting from the code side.
Because the tooling on the design side has gotten significantly better over the past two to four years, I would say that it's a totally valid way of starting the token journey and using a design tool as a source of truth. But we've seen tools like Knapsack and Zeroheight and Specify, for example, that have emerged that offer this tooling to create, manage, and ship, distribute design tokens at scale.
Not every team has access to these. We live in difficult times where buying new tools and new licenses is becoming harder and harder for teams. So where I would start today is the way I've done it over the past few years, which is a JSON file that is my source of truth, and then some sort of transformation script that helps me distribute it across my components and, hopefully, I get a plugin on the design side that can import that JSON file or whichever format I would export.
So that's me because I have experience in that field. I know how to use a command line utility. I know how to set up my continuation integration workflow so that it would regenerate the tokens every time there's a change. That said, not every single team out there understands how to set this up in a few minutes. So that's why I think the barrier of entry is still too high. And that's why we need a specification that helps those tools talk to each other better so that then we can create libraries, we can create frameworks around this concept. And sharing design data between design and code becomes just part of the workflow without having to plug in extra tools and create your own workflows, in a sense, that's out of the box baked into all of the tool chain.
Chris:
Yeah. I like what you said there about there's the expert version. I have some sort of JSON file in a Git repo and I understand how that can change and then ship and then be distributed. And that's a lot about what the tools you mentioned in Knapsack do, is our software is about talking to essentially a JSON file and modifying that based on a UI.
I think that thinking about that more practical side of it, about if I'm just getting started and I don't necessarily have the budget for a tool or I don't have the technical expertise to figure out how to create an MPM package or do a transform or do any of those other things that you really need to be able to ship those tokens, a different starting point is really necessary. And that doesn't exist yet today. What is the thing that makes that wall smaller to cross that still allows people to use and implement design tokens? And I think that the working group or the community group is a big step in that direction to try to start to get some of these things off the ground that help people work with tokens more easily.
Kaelig:
Yeah, absolutely. And so authoring design tokens if you know JSON or YAML, is doable, but it's not a very good user interface to map relationships between various design tokens and design decisions. As soon as you start aliasing tokens, and I'm just going to use some technical terms there, but as soon as you start creating relationships between various tokens, you don't have a visual representation in a JSON file. And this is where you're limited by your tooling at this point.
So what my hope is is that by having a specification in place that will have a much better visual representation of these things popping up in specialized tools as well as design tools such as Figma, Sketch, et cetera. Because playing around with tokens as a flat JSON structure has so many limitations and design decisions are rarely a key value pair way of thinking about the world. And so I'm hoping we'll get to that more complex and juicy way of modeling the design decision frameworks that we have in our companies.
Chris:
Yeah. If you think about what is a drop shadow? A drop shadow isn't just one token, it's a collection of four or five different tokens. And so trying to think about how to view any one of those in isolation is really complicated.
And I think that there's an opportunity for open source tooling here as well. I mean, we've talked about this at Knapsack around the idea of what does an open source solution for being able to visualize tokens look like? Because on the one hand you have things like Style Dictionary that provide that format, but it never really had that visualization component to it. Now we have this new standard that's come out that again is a really great representation of how to construct tokens, but doesn't really have that visual medium attached. And I think there is a place for open source to step in and create that visualization aspect of it that could be paired along with any token implementation that you'd want.
And it can also serve as the basis, like you said, for a wide variety of tools. Knapsack will always probably have some proprietary implementation of this standard that exists inside of our own UI. But creating something that allows people to visualize an animation token, for example, is a great thing. You could write in your JSON file 200 milliseconds or 400 milliseconds, but unless you're actually able to see what that looks like, that's a very limited value in that reflection.
And so I think there is room for some tooling in this space that isn't necessarily attached to a software subscription or license that allows us to actually work with these tokens in a way that we haven't really had the chance to before.
Kaelig:
Absolutely. So I was just talking to Sean at Storybook, who's been working on documentation, and he's built a playground to demonstrate how to leverage design tokens from a JSON file and then export them and show them, document them in Storybook. So there's promising things on the open source side there.
That said, not everyone uses Storybook. Storybook is the surface that typically is visited by developers. I want that representation to be available and to meet people wherever they are. And that means the design tool, the code editor that you live in and you work in without it necessarily having to be an external resource. So autocomplete, IntelliSense, and VS code, all these things can only be unlocked, and unlocked not just for one framework and one language, that can be unlocked if across whatever stack you're choosing thanks to a specification. But I don't see another way of doing this.
Chris:
Yeah. And it is interesting because the interoperability side of it is another wall, I guess, literally hurdle maybe is a better term for adoption of design tokens. Because when we talk about interoperability of tokens across native mobile apps or websites or various different JavaScript languages or web components or whatever, it is capable of working in that interoperable way, but you have to have a deep understanding of how it actually functions and how to transform that JSON file into a usable output.
And there's, I think, a lot of room also in the tooling space for making that step easier. For example, what does line height look like in a native application and how do you have those same things attached in a web line height to an iOS app that doesn't have that same thing conceptually? So what does that translation look like and how do we create tooling or at least have a clear representation of what you'd need to do there? Because right now, there's just a lot that is left up to the implementer, and I think that that hurdle is something there's not a lot of great resources available for to say this is how I would go about making this spacing token or color token or timing token usable across my entire ecosystem.
Kaelig:
Right. Well, the approach we've been taking at DTCG is we are thinking of the specification a bit like SVG or CSS where we don't want to bake in too many assumptions about how people are going to be naming or structuring their token architecture.
Chris:
Yeah. And you all have done a great job with that, by the way. I love the abstractness of it.
Kaelig:
Right. And it's been hard sometimes because we're wondering, well, at what level interoperability is going to even be possible if we don't provide any guidance on the structuring of an architecture? But so we're trying to refrain ourselves from giving too much guidance on that. But what I would love to see is an entire framework.
I think Style Dictionary, you have some defaults baked in. One of them is called CTI. It's an aiming convention that means Category/ Type/Item, and out of the box it comes with that. But if you want to opt out of it, you can totally use your own naming convention, et cetera. But it's been so successful at promoting this default that a lot of teams are using that now. So I wonder if that's the framework we're going to see emerge once there's a specification. Just like in CSS, there's been BEM, OOCSS, SMACSS, all these approaches. Those are great approaches. They've gone around the community and they've been very useful for different use cases. And I wonder if that's the kind of stuff we're going to see emerge.
Chris:
Well, I'm excited to see what the future holds. For people that are looking at how they get started with this and start working with this now, where would you point them?
Kaelig:
Well, for now, the specification is still very much in flux. So I would say if this is your first time working on tokens, probably don't use the specification. But if you want to start working on design tokens, if you're using Figma, use Figma Token Studio, amazing tool, fantastic at helping designers map pretty complex architectures. I think there is a paid version that helps you connect it with code bases and such.
Now, if you're using other tools, such as Knapsack and Specify, and I kind of miss the Envision days where there was the design system manager because the design token management in there was actually pretty good. But yeah, those tools are also great ways of just kick-starting your design token experience.
I know there's trial versions for some of these tools, but I'm waiting for the solo developer free version of this, a bit like on Netlify or Vercel. If you sign up as a solo dev with your GitHub account, you can deploy for free until you get too big to benefit from that free tier. But yeah, I wonder if that's something we're going to see more of. And hint, hint, talking to the CEO of a company that builds a design token tool.
Chris:
Just going to, just drop that on in there. No, I love it.
Yeah, I mean, we have ideas for where this could go with our system and our stack because we want to have a robust, healthy design system ecosystem that is well beyond the big enterprise customers that we have. So our focus is always about how do we get big, complex organizations to be really effective at using design systems. But there's a bunch of feed into that. Without that individual engineer or that individual designer that is enabled and empowered and understands how these systems work, it's pretty hard to get adoption into these big enterprises.
And so we have a pretty constant, ongoing conversation at Knapsack about how do we continue to serve the broader community? And I think that it's still early days. I want to serve it with the new spec because I think it's important for us to move towards that. From an adoption standpoint, it is so much more than what we've had ever before in terms of separating typing from naming, for example, is just one of the immediately incredible empowering things that that spec provides us. And so I'm looking forward to being able to have some of these things that we help with in the community that really enable and empower those individuals you were talking about.
Kaelig:
Love it. But yeah, I think if we take a step back, the best place to start is to do an audit of what's going on in your code base and in your design files, et cetera. And if you have, for some reason, if you have zero concept of styles or shared class names or shared CSS, shared whatever, design decisions, start with sitting down between a developer, a designer and discussing what are the common traits, what are the decisions that have been baked in that don't have a name to them.
The whole reason why design tokens are a thing is to create this shared layer of language that all stakeholders on a project can use so that then we can start thinking about more important stuff. Because to me, the tooling and the automation around it, that's just a baseline. It unlocks so much more. It's not an ends in itself. I don't wake up in the morning thinking, oh great, I'm going to do some design token tooling today. It's going to be great. What I'm thinking whenever I build those workflows is how is that going to help us build better products? And so far, the transformation I've seen is amazing in teams that use tokens effectively, document them well, and bake those design decisions when it matters, and then share them across code bases. That just unlocks so much more communication-wise. So that's what I'm really excited about.
Chris:
Awesome. Well, well said. Thanks so much for being on Kaelig. Really appreciate your take. I'll look forward to talking again soon.
Kaelig:
Thank you.
Chris:
Hey, everyone. Thanks so much for listening to the show. This is just another reminder register for the webinar on the 26th. We're going to have all four of the guests from the past two episodes on to talk about design tokens, and we have some exciting announcements for you all there. So registration link's in the show notes. I look forward to seeing you. Hope you have a great day.
