Standardizing Design Tokens
This week we sail into port at the W3C to talk to Kaelig Deloumeau-Prigent, developer and design advocate, and co-chair of the Design Tokens W3C Community Group. We talk about how tokens came about, the challenges in standardizing something so young and the future of where DesignOps is going. I'm also pretty sure that I heard a Frenchman extolling the virtues of Californian wine, but my ears may have deceived me...
- Kaelig on Twitter
- Design Tokens W3C Community Group
- Pink Floyd, The Wall
- Tough Guides: How to Stay Alive on A Desert Island
Luke: So Kaelig, it's great to have you here and I suppose the best place to start, which is usually the place that we start with most people is, how did your path lead you here? How did you get into design systems? And, well, I suppose now you're a design and developer advocate.
Kaelig: Thanks for having me glad to be here as well. And, yeah, so I'm a design, Developer advocate and, well, developer design advocate.
Luke: You're an advocate for building things.
Kaelig: Yeah, essentially I'm looking at how people build the best product they can and remove that friction along the way that comes between this concept and the user.
Luke: Cause you've been at Shopify for quite a while now right?
Kaelig: Four and a half years.
Luke: Jeez. And so I'm really interested in design tokens specifically because when it comes down to Salesforce and Shopify are the two ones, basically, you and Jina Anne are the two Grandfather and grandmother of design tokens. How did that come about? How did you folks actually get to a point where you're like, oh, I suppose this is a thing, and this is what tokens are. What was the origin story of that?
Kaelig: Yeah, so Jina and Jon Levine, Salesforce back in the day, it actually traces back to when Jina was working in Sass and Ruby with middleman as a static site generator back in the day. And she wanted to use CSS variables, but not just for one platform. And so she ended up encoding her CSS variables in YAML and then I think she imported them in her style sheets and in various other platforms. And I think this is where it kind of started no burgeoning as an idea of huh, you could have a single source of truth that's not just in your CSS, but it lives somewhere else and it's consumed by other platforms. Then at Salesforce, they took it to a completely different level like this is part of the Salesforce platform theming of the entire UI is powered by tokens and customers in their Salesforce dashboards and admin settings can modify the tokens, people building apps for Salesforce can also modify tokens for their particular apps. But yeah, it started as how do you get something that works for their proprietary, CSS pre-processor their Salesforce one app as well as their CSS and then is able to scale because Salesforce is big.
Luke: Yeah. I mean, they're not a small company. Yeah.
Kaelig: Yeah and nowadays their UI is now powered by web components proprietary XML syntax called Aura I believe. And the Salesforce lightning design system, which is HTML and CSS and obviously, there's a bunch of apps they acquired at some point there was one acquisition per week or something like that. It was kind of the joke over there, that when you need to scale design to all these new properties all these new platforms, you end up feeling like, huh, what is this? What is the way we could scale at? And design tokens were the answer. So Jina and John decided on calling this, methodology design tokens back in the day. And she's, talked about this. I'm not even doing it justice, but feel free to search for that content because she does tell the whole story step-by-step
Luke: There's a really good podcast with, I think it's Smashing Mag, where she went into the history of it all. So where did you come into the picture then? cause I mean, now you're co-chair of the design tokens W3C group, right?
Kaelig: Yeah so, when I joined Salesforce, I remember seeing the tooling they had around tokens that I was super impressed. And so I participated in some of that towards the end of my tenure there. And then I moved to Shopify and I felt like it was probably the third or fourth company I had to do some version of design token tooling at. One of my frustrations there was that despite having this team that is able to build token tooling, we were struggling to get it, not just cross-platform, but also cross-design tool. And we were exploring tools for prototyping, design process, all of the gamut of things you might do as a designer, we were just exploring. And every time we had to recreate the foundations of our design system for each single design tool. And I was thinking, with the funded team, we're struggling and we're feeling like we're spending time building stuff with basically zero value because it's just this table stakes of you need colors and typography and spacing, etc. What do other teams feel like and what is the handoff between those tools looking like for other folks? So it seems like a lot of busy work and I felt like there's gotta be a better way. So like a lot of software and standards this was born in the flames of hell, feeling at the bottom of my patients and just exhausted by the fact that I feel like I'm recreating the same thing over and over again, every time I joined a company or every time we add a design tool to our palette and felt that there's gotta be a better way. So what if we created a community to think about this more closely, see if there is an interoperable way to share those foundations and having worked with design tokens, having worked on design token tooling on Theo at Salesforce, I felt like, you know what if we took that thinking and made it into a standard that all designed tools agreed upon what could we unlock? So this is where it started, then I reached out to my mentors, past bosses and people in the standards world, then I asked how do you do a standard, how to standard? Because it's not something you learn
Luke: No, it's not a simple process either. It's not a quick or simple process.
Kaelig: It's not quick. I learned that the hard way. I knew that was interest from the community. I didn't know where to start to create a new standard. And so I reached out, I was pointed in so many interesting ways to look at the fact that, Hey, there's intellectual property associated with, those kinds of things when a lot of companies start thinking about this together in a pool. so if you're going to create an open standard, you need a forum for that to exist, where there's intellectual property restrictions on those companies can claim as they're discussing those things together. And this is where the W3C is extremely useful. So I reached out to W3C, I was like, this is not really a web thing. Like it's got a web tend to it, but it's not just web, would that fit under the umbrella of the W3C and, Dominique, who at the W3C is thinking about all this community stuff, was like, yep, totally, just create a community group, that's gonna protect your IP and then you can start going through the standard of publishing specifications. So this is why W3C design tokens community group was created. Then Jina and I and Danny Banks worked together and with, Garth Brathwaite as well, to look for who are the best experts in the world that would help us build a standard, how do we set ourselves up for success? And this has been a journey, but the first six months to a year we're dedicated to setting up the structure, building the values, building the team, recruiting a diverse set of folks. Then after that, finally, we could start writing. I'm happy that a couple of months ago we released the first version, the first editors draft, and that was after months of writing, consulting with all the design tools out there, making sure they're on board with having a standard and that they will apply themselves to adopting that standard. And so now we're asking for community feedback and as soon as the community feedback is sufficient, we're going to get back to the design tool vendors. So the design tool vendors include Figma, Sketch, Framer, Invision, Adobe, just the biggest ones out there. So hopefully we get something in our design tools in 2022 that is pretty close to interoperability. But yeah, we're starting small and we'll see where this goes later.
Luke: Well, I mean, cause that's the thing, right? It's like, with something like tokens, especially something that is born out of a need within big enterprise and it feels like it was something that was happening in parallel in a few different places, or the same idea at least was happening in parallel in a few different places. You already get to the point where people are starting to implement it in their own way, right. And you start to then get people going, oh, I'm going to build a tool that's going to do this. And we've already got some design token management tools out there that are going, we're going to push this to the limits of what we can absolutely do, which is then a bit of a worry because you start to get into those old days IE6 craziness of the web where you're kind of locked into one tool and building for one way of doing things, so it's great by the way. So thank you for doing this standardization process, cause I think it is something that is going to be sorely needed, and I suppose you just talked a bit about how the process has been so far, but what do you see as the biggest challenge so far that's come out of this of trying to create that single standard that's going to hopefully be adopted across the industry?
Kaelig: Yeah. The hardest part is to know how to scope this first version because there's a lot of needs out there for, how do you encode your design foundations? And some people want to encode more than just the foundations. We want a foot in the door, that's my strategy right now. I'm very biased towards starting adoption early, by early I mean, we're talking about years at this point, but these are long processes, but we need something. And so in not boiling the ocean is, is hardest part. Very early on, we said we want something that's durable, that is going to be adopted. And so we're trying not to make very controversial choices in the things we're implementing. So one choice was, for example, to say, Hey, for now, we're just going to go for JSON as an interpretable designed token format for file format. It's not necessarily the best long-term and technological way of doing this there's better ways, but we also think that if we want adoption, we can't come up with our own new design kind of file system and file format that would put so much pressure on the design tool vendors to adopt it, that it would just be friction. So adoption friction is something we care a lot about. And then we're starting with colors and we restricted ourselves so much, It's kind of sad the state of the hardware for how do you encode colors? Like the DCI-P3 color gamut on newer screens and the fact modern monitors are so powerful, but the web is not necessarily there or product design tools or digital product design tools are not there either. So we kind of asked the community, like, do you really care about, you know, DCI-P3 and other color gamuts and HSLA and LCH, etc. And so we ended up being like, you know what, for now let's just stick to hexadecimal, we know all the design tools support that with an opacity layer and we'll take it from there. Basically every time you explore a certain facet of how to encode certain design foundations, so for example, colors, typography, gradients, animations it’s a fricking rabbit hole. It is so deep and there are people on the CSS Working Group who have been thinking about this for decades. So this is also one of the reasons we've limited ourselves a bit in that first iteration, it's that our mental health depends on it to be honest. The discussions can very rapidly fall into those rabbit holes and so it's fascinating, but it's also, coming in the way of productivity.
Luke: It's like when you touch a topic, it just kind of branches off into about 50 more, and then it's like, you, you touched another one of those and it just keeps going. I was having a look over one of the first editor drafts and it was even just, it must be so tempting to either try and you know, instill best practice by, say for example, limiting types with tokens and it must be so tempting to be like, well, this is what we should be doing, but actually if we start cutting off what people can do with the tokens, you're not going to get adoption. And it's like that where's that balance of, what is good practice and what is actually going to get used by people. I'm interested to hear like your thoughts on what the big challenges are coming up with like how people start using. Cause I feel like as an idea and as a tool, this is something that makes sense. It feels like that there's something around, I've had so many arguments about source of truth as a concept, things like governance, especially if we're talking about like tokens back and forth, between design tools and code and you know, how we manage that and all the rest of it. I'm just curious, like how have you tackled this in places you've been before and have you seen any really great ways of managing this or ways of approaching this.
Kaelig: Yeah. So there's two things that come to mind. One is governance, for sure, but the other one is, how design tools can stay on top of the trends when this becomes a standard because you've probably seen with CSS, how CSS has evolved massively and people have been doing crazy cool shit with CSS, that's really awesome and then you look at Dreamweaver and those tools that were kind of attempting to help people with that, these kinds of tools, lot of the time have a bit of trouble keeping up with the way things are doing in the industry and in terms of architecture and capabilities. Governance, I think is really interesting because Jerome was talking about this being the decade of DesignOps and I think operationalization of design systems and who is responsible, who owns what and the workflows around this are super interesting to me. So I know that in some design token management tools like Invision, you have admin rights for certain people over certain tokens. And I think that's pretty cool or like the way you can do an almost like GitHub workflow around design tokens, but in a design tool, I think it's super powerful. So, I know that there's other companies looking at this arcade specify, I'm sure zeroheight has a design token play. All these tools might be doing things differently and I think that's totally fine, but where are the standard comes in is this interoperability of we all have the same compile target, and we can all between design tools share this, now from one design tool to another, having some sort of source map. So between design tools having the sort of source map to trace back where the original token comes from will be also potentially interesting. So design token source maps, maybe there's a blockchain play there as well for people to mint NFT colors from their system.
Luke: Yeah. I think that's definitely a possibility. Well, it's interesting though, because it's something that I'd never really thought of. And especially if you're talking about two-way syncing, because I think at the moment it's a lot of token management or the pipeline for tokens tends to be designed tool through to code, right. There's not much that's happening that's going back the other way. Mostly because it's pretty hard for the design tools to support it at the moment because they haven't worked in any kind of standardized way of doing this. So I can totally see there is a definite need for that if we start to get that two-way sync happening,
Kaelig: Yeah, I'm not sure people will want that two-way sync, to be honest. So one of the principles in DevOps and the site reliability engineering world is that everybody should be working in the same tools and so you can imagine having some teams that pick a tool, just say this is the tool where we contribute tokens and then developers and designers alike know that this is where the source of truth is. I can imagine having two-way syncing of pushing and pulling. We're really talking about not just consuming, but really editing. And I think that complicates matters so much that I'm not sure people would want that. Imagine the mental model for people to realize, okay, if I change this, it's going to go up to the mainstream and if that person at the same time in their other design tool also changed it, what is the reconciliation going to look like? Who makes that decision. So, anyway, I feel like there's going to be a kind of a choice people are going to have to make of where their token library is going to be decided.
Luke: That does make sense, but this is where I feel like DesignOps being such a new concept. This does feel like it's an Ops problem, right? When it comes down to it.
Kaelig: And by the way, I’m totally biased by my experience in that world. So I would love to see people doing that two-way syncing and proving me wrong that, oh, it turns out it can totally work. And there's a lot of cool stuff to be invented around this. So, yeah, please do innovate, that'd be awesome.
Luke: Cause it's the thing, right? It's like, I think that we're in at least the advantageous place in that we've had a lot of DevOps tooling to deal with a lot of this. So, you were talking about before about like Git style, or GitHub style workflows, where it's looking for diffs between, basically merge conflicts, right, that's what we're talking about here. But then yeah, you'd have to build in branching. I mean, it does maybe feel like it's overkill, but I do feel like it gets into the next thing that I'm sort of interested in, is this idea of automated workflows and continuous integration that works. I don't know, maybe it is just a lofty ambition, continuous integration that could work both ways between design tool and code.
Kaelig: Yeah. I mean, it would be interesting to see what kind of pressure it puts on the testing tooling aspect. Cause you can achieve continuous integration if you have really good automation around testing and continuous deployment kind of comes for free as soon as you've got this whole thing set up properly, but in the design world, a lot of the time products don't get visual regression testing interaction, like end to end testing of how things feel, how things look like, how accessible things are. We're still at the very beginning of automation around these things, I feel like, that our suite of tools that allow you to do that in isolation, at the app level, but those are expensive bits to put in place and it's not accessible to the common design system team and product team. So I feel like we're a ways away from this. I wouldn't be surprised to see this happen maybe first in a react native or the mobile world where maybe they're tooling and the people working on these projects are typically, they have to go back and forth between some sort of client-side UI work and backend. And I've seen our mobile teams at Shopify come up with really cool tooling that front-end and hybrid teams would not necessarily have had the passion for. So I'm really looking forward to the next 10 years, I think are going to be so cool. And we're going to see so much cool stuff coming up.
Luke: Well, it is interesting actually, because I suppose that brings me on to the next question, which is what is it about the future of DesignOps, design systems, tokens, everything in that area generally, I suppose it's the design to dev pipeline. What is it about the future of that's exciting you at the moment, and I suppose, what are you hoping for, like, what are you hoping changes?
Kaelig: Yeah, for me, the DesignOps problem is a spectrum. So you've got your culture that has to promote certain practices, the practices that have to feed into what the company means by quality and then you've got all the tooling around this to make sure people have the right tools to put in action, the culture and, the process. So the time where that UI has to go in front of the user is also another step that I think DesignOps should care a lot about. And I haven't seen much of that and I think we're going to see people expand what DesignOps means to UI development way, way more. I see a lot of companies keeping UI development in their engineering departments. And I feel like this is where things start to break down because those, two need to be joined there. There needs to be something that happens between how we think about delivering design in the design world, but also it's got to go in front of a user at some point. So for me, that's where the future of DesignOps is. What are those feedback loops between I'm a designer, I have an idea, I have a concept, I want to put it in front of a user. What is that path? How do I know I'm having an impact? Is there a gatekeeper somewhere that's going to prevent me from knowing that I ever had an impact on performance, user conversion, etc.. So that's what I'm thinking about, where I feel like the field is going to go.
Luke: It's interesting actually because I was talking to Brad about this last week where he was talking about that split between the front-end, almost like UI engineer, and then there's the, what I'd never would have called a front-end developer who does a lot of the business logic and a lot of the, you know back in my day, we just did HTML and CSS. But it's become such a complicated, almost full-stack sort of engineer world and I mean, to be honest, I love the rise of this concept of like a UX engineer or a UI engineer who are working very closely with or working in the design teams. And I think you hit the nail on the head, I think it's a recognition that the design process is not just when the designers are touching things either, but it's like the DesignOps process starts when senior leadership or even just product are talking about what are the problems that we're trying to solve right through to when it exists in the hands of the user and I feel like it just stops when you've got that handoff point, which is not a thing really.
Kaelig: Yeah. I mean, sadly, it is a thing in many places, I believe that this is where things are going. Yeah. You're getting closer to your user.
Luke: Brilliant. Well, I suppose it's almost time to send you off to your island. But before we send you off we have a very important task to do, which is to decide what it is that you're going to use to spend your time there. So you have one piece of music that you get to take with you, you get one piece of literature and you get a luxury item as well. So I suppose let's start with the music. What's the music you're going to take to it as the island?
Kaelig: Yeah. The first piece I bought when I got my first paycheck, head of a web agency in France probably my first two paychecks, cause it wasn't that much. And then I bought a Hi-Fi system and a few CDs, and one of them was Pink Floyd, The Wall. It's the piece that has been following me along and I just love it so much. So I think that would have been to be it.
Luke: It is an epic piece of music.
Kaelig: Yeah. A piece of literature, I would probably go for some sort of survival guide.
Luke: It is the obvious one to go for. And how about the luxury item? What luxury item are you gonna take with you to the island?
Kaelig: Luxury item, hmm, probably a very nice bottle of wine.
Luke: Oh, I mean, I will allow a never-ending, beautiful bottle of wine.
Kaelig: Yeah, it'd be nice, tap wine that serves luxury wine.
Luke: Do you have a particular province that you go for? Or just as long as it's good.
Kaelig: Yeah. I like a good Pinot Noir from Sonoma, I'm a big fan of those big Pinos over there. And my wife converted me to, I wasn't really into it when I moved to California first, then I'm like, this is, this is good stuff.
Luke: Wait. Sorry. Did I just actually have a French man on the podcast, praising Californian wine? Is that, is that a thing?
Kaelig: I will probably have to send my passport back to the embassy for saying that.
Luke: Brilliant. Thank you so much, Kaelig.