Episode 292: Using Tokens in Design Systems with Jan Six
32:30 Share

Hello, ladies and gentlemen, and welcome to the UI Breakfast podcast. I'm your host, Jane Portman. And today, our awesome guest is Jan Six, staff product designer at GitHub and co-creator of Token Studio. And we're going to talk about using tokens in design systems today.

This episode is brought to you by Wix Studio, the new web platform for agencies and enterprises. The magic of Wix Studio is its advanced design capabilities which makes website creation efficient and intuitive. Here are a few things you can do: Work in sync with your team on one canvas, reuse templates, widgets, and sections across sites,

create a client kit for seamless handovers, and leverage best-in-class SEO defaults across all your Wix sites. Step into Wix Studio to see more at wix.com slash studio. Hi, Jan. Hey, nice to meet you. Thank you for having me.

We're super thrilled to discuss this technical and also progressive groundbreaking topic with you today. But before we do that, let's talk about your background and also a little bit of your founding story at Token Studio, which also I find pretty fascinating. Yeah, sure. So my background that led me to design was, I guess...

I started out in agencies. So I was working, I think, around six years in various agencies and moved places a few times. I always, like I worked in print, but also in digital design back then. And I always had this

Feeling that I wanted to do more, to basically work on designs that are having an impact and that are affecting users' lives for the better and to always optimize what I can, which at the time wasn't really something that aligned well with the agency kind of approach. So it was always ship a product, ship a project, and then move on to the next. And I always felt that I wanted to optimize a single product or project and then keep optimizing that as we go.

And eventually that led me to work as a product designer. So I kind of shifted gears there a little and I moved to a startup, which was a very small startup bootstrapped. And that allowed me to not just work on UI and UX design, but also get my fingers dirty with code. So I learned to develop myself and basically build sites on my own, because as I mentioned, it was a small startup. So we had to

work very scrappy when it comes to resources and time management. So a lot of times I would be faster than the engineering capacity that we would have. So I felt like I could just learn this myself and see if I could help them out in any way.

which was one of the best decisions, I think that helped me grow to an understanding of the designs that you are proposing. Are they buildable? Can you build them? Is that something that you can change maybe or make better? So I think that was a very good move. And eventually that then led me to join GitHub four years ago now almost as a product designer where I am

working on pull requests, but also on co-pilot. So I've been around a few times on different projects. And I do that from my home in Salzburg, which is in Austria. And yeah, I think that's what got me into where I am today. And that, I think also along those times, was also the inspiration to create the Token Studio plugin back then.

If I had a parallel life trajectory, I'd love to leave your trajectory there because you outlined exactly the problems I can see so much is, you know, design capacity really being less than or more. Basically design work much faster than engineering, going the front end, implementing design systems sounds pretty awesome. So excited for your trajectory.

Yeah, it's also fun, I think, to be able to build the designs that you are designing in Figma and then go on and build them in actual code. Sometimes it's something where I would just jump into code sooner than I would normally because you are able to explore and discover so many different ways of how you can do something if you're working on the actual product. Exactly. Now, the founding story of Token Studio, pretty fascinating how

You and Mike were working on different things and then United. Tell us more about that.

Yeah, so the initial, or for me at least, the initial inspiration to work on the plugin was just that I was working in this startup, which was basically about a platform as a service, which you can customize. And depending on the platform, you would get a different look and feel. You could get a different color as a background, different fonts, all of that. And that was something that I did in Figma to kind of reskin the whole experience and

but then also in code later on. And around that time, I learned about design tokens and what they could do there. But I found it quite not empowering to not be able to do that within my design tool. So I knew that I could use design tokens in code, and there were all of these transforming tools to get that to CSS variables. But if I wanted to use design tokens in my design tool, I just couldn't. There was no way. And I

Decided to just build that small plugin that basically would do that for me, which then took a JSON string, like a coded version of your design tokens, and let me apply that to my designs. And I could swap that out with a different version, maybe a different brand, maybe a background blue and all that. Like depending on the platform, it would show up differently. And that was starting out very, very simple. But at the same time, it was one of those things that I always kept having ideas for.

which is different to some of the other projects that I've done before, where I at some point felt that now is the end. I completed what I wanted to do and now I move on. But in this case, it kept on giving. I always felt there is one more thing we need to do, one more thing here, one more thing there. And there we are a couple of years later where the product has grown so much that there is a dedicated team building this and driving this forward. And I think that was...

A couple months after the initial release, when I did already make this open source, I got in touch with Mike, who was creating a bunch of feature requests already, and we were bouncing ideas back and forth.

And then at some point, we just decided to join efforts and take this forward with more people to be able to maintain this from an open source standpoint, because the issues kept growing. Basically, work needed to be done and more feature requests from other people as well. And as you can imagine, that just gets a lot for a single person maintaining this or just two people. So that's where we decided to have some people manage this entirely. And that's been growing ever since.

There is quite an intriguing product story happening. On one hand, Figma is evolving. So they added variables not so long ago, which kind of duplicated some of your core functionality. But on the other hand, Token Studio is evolving and you're building much more exciting things there. Tell us more about this.

Yeah, so when we came out or when the plugin was built, it was the only way to style your designs in different themes, I would say. There were some other plugins, but it was, I think, one of the more scalable options. And we were always feeling that ideally this would be a native solution or be something that could be enhanced with native functionality to be faster because a lot of the efforts were done by the plugin itself, which

hits its limits at some point, or at least back then did. And I would say once Figma introduced variables, we kind of noticed that more of the simpler reasons for using the plugin, such as a company starting to use light and dark theme, or a company deciding to use maybe switching between two different brands or so, those were things that were tackled by Figma's variables itself.

While the plugin itself evolved into something that was catering more towards the more complex needs or towards the design system maintainers who have more requirements around managing their design systems and their design tokens than what Figma's variables offer. And so around the time when that came out, we decided to grow the offering that we have into something that would go beyond Figma.

And that's kind of when the work towards a dedicated platform started, where teams could go and manage their design decisions as design tokens or more in a dedicated platform that is kind of agnostic and sitting between different design tools that you would be able to use between different design tools, but have that space that gives maintainers and those creating, but also consuming design systems space

everything they need so that they can work effectively. And I think around that time was also when we started our collaboration with Penpot, which is an open source design tool and where we are basically building in an open source collaboration, the native integration of design tokens for Penpot already with the idea in mind that we would be able to offer a bridge between those different tools and

Yeah, I think that will only grow from there. Being able to offer functionality like ours in the plugin and Figma to maybe Sketch or Framer or if we think further, tools like InDesign or Illustrator or some other industries that we don't really cover yet with design tokens.

to really complete that vision and goal of having a single format, design tokens, drive all of those design decisions and all of our tools without any manual effort. So that would be the long-term idea that we have this tooling that allows us to go from design tool A to design tool B without all of the sacrifice and friction that it comes with today.

You're following, you know, they start with why kind of approach when you have a global overarching mission and then you're following there with products. It's pretty awesome. Yeah. And I guess it also comes from my own wishes when I was working on systems like that. I didn't want to do all of this manually to go from this one brand to this other in the platform.

but be able to do that with the clicker button and have that effect, not just my Figma designs, but also the code that it produces. So we could just save time and be more efficient as a team. Let's give our listeners a primer on design systems if they're new to the concept and what a design system is. And more interestingly, what are the practical assets that you're producing and how you're implementing a design system when you're starting one?

So, and I think there's many different definitions, but I think what to me comes down to being a good design system is just an encapsulation of all the decisions that we as a team make on how we are using our products and our internal products when it comes to finding consistency, cohesion, be it a color palette that you are all defining or be it the typography that you're choosing, like all of these different design decisions that go into you as a system.

Those would be encapsulated and you combine that with a component library, which stores all of your various components and also encodes such as buttons or cards or alerts or whatever. And you combine that again with all of the patterns and decisions and rules almost that make up your system to form the larger design system that you have there. And I think that can just be something that you start very, very simple.

Could just be that you decide to define various colors, but you grow that to a complex system that is able to cater to many, many teams. But you can always start small. I myself was a single designer working in that startup that I mentioned before, and I wanted to get that off the ground and

I did so by just starting somewhere. It, of course, wasn't on the same level that many of the larger design systems would be, but it helped my team to understand what is there, what should we use, how do we not always reinvent the wheel? And I think that's, if I had to give one advice, is to just start with what scale makes sense to you, and then you can always grow more complex in your systems. And design tokens itself would be the

the atomic decisions that make up your system, as I mentioned, colors or typography. But that can also grow into spacing and padding and various other decisions, such as what border radius do you offer? Or do you always pick from random values? So by defining these as design tokens, you kind of take away the guesswork when having to apply

any decisions on any layers and make it easier and faster for your product designers to choose from values. But the main takeaway and the main advantage you get is this consistency that your users will also feel. I think that to me would be a shorter summary of a design system. But there is, of course, as I mentioned, different levels. You can grow more complex. You can keep this very simple. I think it depends always what you need and what's useful in your situation with your current goals.

Specifically, what is the correlation between components and tokens on the technical level? So there is the idea of a component design token. So maybe taking one step back, with design tokens, we have different levels. So imagine you have a color that is red and you give that a name. Let's say it's called red 500. Maybe you put it on a scale like red 100 to red 900 and 500 would be the middle value there.

You give that the name cutoff.red.500. That would be the core token that you have there. And you can then reference this color in some other token. So you say my button background is a reference to the cutoff.red.500 token. You can imagine going even wider than that or deeper than that and not just defining these two levels, but many different levels.

And when it comes to components, what I just did by having a button primary background token, I'm actually declaring a component level token. So this is only to be used in the button component. But as an engineer, I would already know, okay, what value or what color should I apply for the background of the button, which is a variant primary? I would likely choose the button background token there. But you don't have to go that specific. You can usually just start with A.

another layer which would just be, maybe you give it a name of foreground default and background default, and maybe another color called accent.default. So depending on how deep you want to go, you can create systems that are reflecting that. And then you can always go deeper and more complex. When it comes to components, you would have, as I mentioned, you could go quite deep and quite complex for each component, its own token.

But what usually helps teams as they're starting out their design system efforts is to maybe not include and maybe not think too much about these component level tokens and rather

stick to what we call semantic tokens, which would be what I just mentioned, the accent default or the foreground default, the background defaults for without having this component specific naming in place, which you could later on always add. If you have knowledge of CSS, that's a concept that likely already exists.

resonates as you have CSS variables where you are basically defining the values of certain variables and are attaching them to certain properties like color or background. You can also create these nestings of references such as a variable references another variable. And by doing that, you're creating a system that is more forgiving and it's easier to change things without breaking things on the side, to have these side effects that cause mayhem.

So there is advantage in growing to more component-based decisions on your design tokens, but it's also creating a lot of overhead. So it's usually something that should be well thought through before diving in too soon with those. Are there any articles or guides online that can explain the concept you described using examples and visual show-no-tell stories?

There are some really good articles out there. Nathan Curtis always produces really good ones. He has this article out there about naming design tokens. That's a few years old now, but it still holds true, I would say, and includes a lot of this talk. The other one that I think is always helpful, or at least helped me gain an understanding, is one from Brad Frost. I don't know the exact name of it, but

something along the lines of multidimensional theming, which also helps understand why we even need to do this. So if you are changing from light to dark theme, you are actually gaining by following a pattern like that, by following a consistent naming pattern. And there is a couple out there. I think maybe we can add some to the notes after this. Exactly. That's why I'm asking. We're going to link to those in the show notes for the listeners.

yourself are in a pretty unique position where you are co-creator of a token platform for design systems, but also you're a consumer of design systems being a product designer at GitHub. So I'd love to hear now that part of your identity, which is using existing design systems and what are the problems, what are the challenges, what are the benefits and just overall your impressions.

So at GitHub, I'm a product designer, not actively working on Primer, the design system of GitHub, but I am a consumer. So I'm usually consuming that in Figma, but also in code as designers there, usually code as well. But one thing that I think helps me a lot is with my work on Token Studio is this knowledge of being a consumer and what's important.

So I always value speed, efficiency, and not having too many choices because I need to work on ideas and get those off the ground without being forced to think about systemizing too soon. And another thing that I learned as a consumer, I truly value there is that you can trust the system a lot to do its job. And that, I think, is one of the most important pieces of a design system, to have this trust in your consumers that

Whatever they do, the system will take care of it as long as you're staying within the system. So when it comes to color modes, which GitHub has quite a few, I can trust that as long as I choose the right colors part of the system, I won't face any surprises when it comes to changing this to a dark mode or to a dark high contrast or to a high contrast mode. And that was, I think, one of the key learnings there or one of the key important things for me

But also then thinking back on the person who's creating a product for design system maintainers, it kind of also shows that missing link that you should always think of the end user instead of just the immediate next user. So I think that's one of the things that we always need to make sure when creating complex systems to keep it in a way that's usable and user-friendly for the actual consumer, because that's the users that you are creating it for, your systems.

and finding and creating tools that help those consumers in turn already help those maintainers by making it easier to adopt a design system. Since we're touching on consumers and maintainers, let's talk about company roles and what are the typical job titles of people who are developing design systems, using them, and how this all blends into organizational structure.

Sure. So I think that is probably really depending on the team that is hiring for that role. One role that I could see emerge more often is the one of a design system architect, in a way, who's kind of overseeing all the logic that goes into the system. I'm not sure if I know of any specific design system role titles that would be special in that way, but...

Content is quite important, like you separating those roles or those professions that are able to bring meaning to your system in a way that's enabling it for your consumers in the realm of docs pages or so.

Token knowledge itself is something that I see come up more and more where you have dedicated people who are able to build the logic in design tokens, which I think is quite close to design system architects in a way, which control logic itself. And then you kind of always need someone who's more on the technical side of things to make sure that those processes that you are creating are processes that you are able to translate into code.

So you create your complex systems, but actually it should end up in the hands of your engineers just as much. It's only useful if it's used not just by designers, but also by engineers. So this concept of adoption to give everyone in the company a chance to use the design system is something that I think is always the most important part. So finding roles around that probably makes the most sense to me.

I'd love to hear your advice for companies who have gone far ahead on, you know, no designer, low designer kind of situation, or have like just a diverse set of components and are willing to invest into a design system. So what is the process of auditing everything and like streamlining a large existing product to apply a new design system to develop and apply one?

Yeah, I think any company that had to change things on an existing product without a design system in place knows the pain of how much you have to go through to be able to get that changed. So while the design system in the beginning might seem like a large investment, as soon as you hit a few of these instances where you need to make changes and it's slowing you down a lot that you don't have the system in place, that's where you kind of see the value of it.

But the other value I think is just that with a proper design system in place, you are not just speeding things up as you need to change stuff because it's changed in one place, but rather that product designers and engineers don't have to guess. And if I don't have to guess, then I can create the solution with not a lot of time spent on thinking of what's the right approach, what's the right component or all of that, or not component, but what would I use here?

And it's already also making the experience for your engineers much simpler as in the code base. It's becoming more of just playing with really well-designed Lego blocks that you are able to just build on top of each other.

And that can speed up the feature development lifecycle and process by quite a big factor. So I think the biggest advice if you don't have this is to maybe start looking at your existing system. How many different buttons do you have? How many different implementations of something do you have? And talk to your team about these pieces, like how much time is spent on actually trying to use the right one.

versus just picking from one example or from one defined component, that should speed things up a lot. And having this inventory of what your design looks like today, like even if you have no system, you kind of have a system, will help you just understand where you need to invest the most, but also where you might need to do some more alignment first before you can actually define the system because maybe each team had its own way of doing things and maybe each team had different requirements.

So communication, I think, is of essence there to bring everyone at the table, different teams, different professions, and make sure everyone's aligned with what they need. And that doesn't have to be a huge project. It could just start very simple, maybe a few people coming together to say they finally need this or they want to make this an effort.

And just starting small and implementing incrementally would already help everyone because you don't have to swap out the entire thing in one go, I think. But you could just do that one by one and make progress like that. You've mentioned before that adoption is probably the biggest challenge that organizations face when developing a system.

And implementing it. Tell us more about this and what's your take? Yeah, I think adoption of design systems is quite crucial when you want to make that a huge success across the entire company. Because it starts to be a problem when you have different teams trying to do different things or trying to do things a little different.

which would normally require them to rebuild it. But if you have created a system like that, but you maybe didn't talk to your teams or didn't talk to every team as much as you should have, then you might end up with a system that is only useful for a certain part of the company, but another part is not able to use it and is not able to implement it like that. And those will then basically be left behind and are going to be using your

are not going to be using your system at all. Meaning the effectiveness that you as a design systems team or you as the person implementing the design system has is cut down by a number of percentage points. So I think as much as possible, you should try that the entire company is able to use your design system because that way any small change has a huge effect in your effectiveness on any future change that you make basically.

I think you've already sprinkled great bits of advice throughout our episode today. But if you were to sum up your recommendations to companies who are not doing design systems, how to get started, that'd be great. Yeah, I think an initial thing that everyone should probably start with is just do a part of the design system. If you don't have anything so far...

Maybe just start with defining your color palette. Maybe try to look at what you have out there and reduce what you can. Make it so that people don't have to choose as much. And the other thing is, once you've done that, maybe go on with typography, the spacing, and all that to define your core values.

and then move on to make those available to your users, which you could then also start to introduce as a component library or so. But I think once you do have your design tokens in place,

make sure to document those properly. That's something that many teams forget to do and just expose CSS variables or so. But documentation and finding out how you can use these or are supposed to use these can already be a big step. And that could already mean that you are just defining the rules without having all the specifics implemented already.

But that way, there is one central source of truth for your team to go look things up. But then once you've done that, I would always recommend to start using automated processes to make sure that your design systems are in sync with your code through the Figma plugin that we offer, for example, or through the platform to have a single source of truth for anything you do. But that would then be something that you can transform easily to your entire team.

I think you should try to automate as much as possible in that phase without overwhelming everyone. So I think it's always a balance. But starting with these small incremental steps should at least get you started. I'm glad you touched upon documentation. So what does good documentation look like? Where does it live? Is it Teams Wiki? Is it a dedicated, I don't know, pretty website? What have you seen?

So I think what usually works best is a dedicated website, but I think it depends. Anywhere where your team knows they can go to, if you have a dedicated website, you probably need to make sure that that is something that is well discoverable.

If your Teams wiki is enough and you maybe just have a small system, that's fine too, I would guess. But think about your consumer and how they would want to approach this. If that's just yet another bookmark that they would have to open or save,

which they don't find use for as much because the content is still too small, then implementing that directly where they are makes more sense. Finding ways to bookmark stuff is probably great. I think the Kedapa Primer docs are really good when it comes to what you can find there and what components are to be used. So I think that's a really good example, but it's also one that is quite comprehensive. And maybe that's not the scale that you need so far.

Thank you so much for sharing your wisdom on this complex subject today. Where can people learn more about you, about Token Studio, and where can they find you all online? So if you were to go to tokens.studio, you would find out some more about the stuff that we are building out in the open. So anything that we build is open source. And we have this Figma plugin that you can discover. We are also working on this Studio platform.

That allows teams of all sizes to manage their design decisions in a way that is scalable and then be that bridge to different design tools, to Figma, to read and write there, but also to Framer or InDesign or all these different tools that I mentioned before. That would be a really good next place to go and look for some information. We do have the studio platform.

Currently a waitlist, but you can sign up for that on the tokens.zudo site. And then there is a studio button at the top. And if people want to find out more about me, I do have a domain at jan6.at, which is also my BlueSky username if people want to follow along, even though I'm not as active as I should. Awesome. Thanks so much, Jan, for being our guest today and wishing you good luck in building and growing Token Studio. Thank you so much for having me.