The Next Leap in Tokenization  ## Metadata - Author: [[YouTube]] - Full Title: The Next Leap in Tokenization - Category: #articles - Document Note: --- tags: [design-systems, design-tokens, token-script, open-source, penpot] author: Mike (Token Studio CEO) source: YouTube/Conference Talk reference: https://www.youtube.com/watch?v=4AEa3OCiyf0 date created: 2025-01-03 12:45 --- # 🏷️ Title: Token Script: From Static Design Data to Dynamic Executable Logic ## 🧰 Action Inbox - [H1] Evaluate Token Script for design system automation — demo at 15:30 #design-systems - [H2] Review DTCG W3C spec Issue 210 for theming approach — mentioned at 08:45 #standards - [H3] Assess color space conversion capabilities for brand consistency — shown at 18:22 #color-management ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Token Studio](https://tokens.studio/) - [DTCG W3C Spec](https://design-tokens.github.io/community-group/) ## 📝 Summary - Token Studio CEO Mike presents Token Script, a programming language for design systems that embeds executable logic directly in design tokens - Addresses "implementation drift" problem where different tools process design token extensions inconsistently - Token Script will be open source and runs the same interpreter across all platforms (Figma, Penpot, Style Dictionary, browsers) - Partnership with Penpot positions them as first design tool with fully interoperable scalable design data - Maintains backward compatibility with DTCG standards while extending capabilities ## 📖 Main Content Token Studio, supporting 250,000+ designers and developers since 2019, identified a fundamental bottleneck: static key-value design tokens can't keep up with ambitious design system requirements. Users consistently request features like color manipulation functions, custom token types, and dynamic relationships between design properties. The core problem is "implementation drift" - while the DTCG W3C standard wisely includes a $extension property for tool-specific features, each tool must implement its own processing engine. This creates inconsistent results across platforms, returning teams to the siloed approach design tokens were meant to solve. Token Script addresses this by embedding executable logic directly with design data. Rather than multiple competing compilers, a single lightweight interpreter runs everywhere - in design tools, build systems, and browsers - guaranteeing consistent execution of custom functions like color darkening or contrast calculations. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=0) — [H1] Introduction and Problem Context - Key idea: Design systems reality often out of sync and hard to manage across tools - Evidence: "250,000 designers developers and other product people building design systems across different tools" #### ⏱️ [02:30](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=150) — [H2] User Pain Points Drive Innovation - Key idea: Ambition of design systems has outgrown capabilities of static tools - Evidence: "How can I add functions to my design tokens to lighten or darken a color" #### ⏱️ [03:45](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=225) — [H3] Original Design Token Problem - Key idea: Designer handoff resulted in chaos by thousand hex codes scattered everywhere - Evidence: "Marketing guy calls up says we got to tweak that brand blue and now there's a hunt" #### ⏱️ [05:20](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=320) — [H2] Design Tokens Solution - Key idea: Tokens created single source of truth bridging design and development - Evidence: "Color brand primary - conversation no longer about what's the correct hex code but are we using the right design token" #### ⏱️ [07:15](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=435) — [H1] W3C DTCG Standards Work - Key idea: Mike serves as editor focusing on theming and multi-file systems - Evidence: "Issue 210 has been one of the longest most debated threads on the entire history of design tokens community group" #### ⏱️ [08:45](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=525) — [H2] Extension Paradox - Key idea: Dollar extension property created sanctioned space but required every tool to invent own engine - Evidence: "Built-in escape hatch called dollar extension - green light for tools to add new features" #### ⏱️ [10:30](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=630) — [H1] Implementation Drift Problem - Key idea: Same function executes differently across tools creating inconsistent results - Evidence: "Tool X runs slightly different algorithm, Tool Y doesn't have darken function at all" #### ⏱️ [12:15](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=735) — [H3] Cost of Competing Dialects - Key idea: Innovation grinds to halt when every feature needs implementation across entire ecosystem - Evidence: "Every idea, every request gets stuck in the mud because it needs to be implemented everywhere" #### ⏱️ [13:00](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=780) — [H1] Token Script Vision - Key idea: What if logic traveled with design data instead of separate implementations - Evidence: "Single engine that could run everywhere understanding not just structure but intent" #### ⏱️ [14:20](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=860) — [H2] Open Source Commitment - Key idea: Token Script will be completely open source specialized programming language - Evidence: "Not another proprietary lockin - token script language and interpreter will be open source" #### ⏱️ [15:30](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=930) — [H1] Live Demo Begins - Key idea: Token Script playground shows real-time execution of design logic - Evidence: "On left side token script, on right side output - focus is the outputs" #### ⏱️ [17:45](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=1065) — [H2] Color Space Transformations - Key idea: Design in optimal color space, export to compatible formats automatically - Evidence: "Design in OKCH color space, get hex values for tools that need them" #### ⏱️ [19:30](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=1170) — [H2] Contrast Calculation Example - Key idea: Automatic contrast-compliant color selection based on background - Evidence: "For given foreground color, contrasting background color according to WCAG algorithm" #### ⏱️ [21:00](https://www.youtube.com/watch?v=4AEa3OCiyf0?t=1260) — [H1] Penpot Partnership - Key idea: Penpot will be first design tool running fully interoperable scalable design data - Evidence: "Penpot closely working together will be one of first design tools powered by token script" ## 📚 References - [Token Studio Platform](https://tokens.studio/) - [DTCG W3C Community Group](https://design-tokens.github.io/community-group/) - [Style Dictionary](https://amzn.github.io/style-dictionary/) - [Penpot Design Tool](https://penpot.app/) ## 🗣️ Paraphrase - Static design tokens as simple key-value pairs have become a bottleneck for advanced design system requirements, leading to fragmented tool-specific implementations - Token Script introduces executable logic that travels with design data, ensuring consistent processing across all platforms through a single portable interpreter - The open source approach maintains DTCG standard compatibility while eliminating implementation drift that currently forces teams back into design-development silos ## 📰 Newsletter 🎨 **Design Systems Evolution: From Static Tokens to Executable Logic** The design token revolution solved the "thousand hex codes" problem, but we've hit a new bottleneck. Token Studio's Mike reveals how ambitious design systems are outgrowing static key-value pairs, leading to inconsistent - Summary: Mike Kamminga, co-founder and CEO at Hyma, shares the main reasoning behind Design Tokens existence, what pains they deal with and what are their current limitations. But, most importantly, Mike introduces Hyma's new take on tokens management: Token Script, a real language for design systems, readable by humans, machines, and even AI. *Penpot Fest 2025 | Better, together: Refining the designer-developer workflow.* -- Penpot is the free open-source design tool for Design & Code collaboration. https://design.penpot.app​​ Penpot is ideal for product design: UI designs, prototypes, wireframes, mockups, webs, apps, and much more. Penpot allows a true collaboration and no handoff drama between designers and developers thanks to features like CSS Grid Layout, Flex Layout and Code Inspect. Designers get a professional, intuitive, powerful design tool with ground-breaking responsive layouts, design systems at scale. While developers get a design tool that expresses as code and provides ready-to-use code to develop faster. Penpot is the only one that can be web-based or self-hosted. The app works with open standards (SVG and CSS) avoiding vendor lock-in. Also, it enables teams the flexibility and control in their designs, thanks to the API and webhooks available. Penpot Community: https://community.penpot.app App: https://design.penpot.app​​ Help: https://help.penpot.app​ Contribute: https://github.com/penpot Penpot Fest: https://penpotfest.org Follow us: *Mastodon: https://fosstodon.org/@penpot/​ *Bluesky: https://bsky.app/profile/penpot.app *X: https://x.com/penpotapp *LinkedIn: https://www.linkedin.com/company/penpotdesign *Instagram: https://www.instagram.com/penpot.app/ *Github: https://github.com/penpot Penpot: Design as code. - URL: https://www.youtube.com/watch?v=4AEa3OCiyf0 So, my name is Mike, I'm the CEO, one of the co-founders at Hyma, where we're building token studios, style dictionary, and a bunch of other cool technologies that some of you may be already using today. And of course, we are the proud partners of Penpot with whom we are together building the future of design systems and design tokens, and of course many other things that are being done in Penpot . Today I want to share a story, one that's really close to my heart and our heart at Token Studio, and that's a story about the evolution of design data. So yeah, first we'll look back a little bit at where we've come from, some of the hidden pains that maybe, or probably all of us have been feeling, and then we'll dive into where we're going next. So, from static data to dynamic executable logic, how do we get there, and how do we build truly intelligent design systems? Our journey at Token Studio really started with some real pain points. We were practitioners, we were building design systems, complex design systems for all kinds of brands, large organizations, and we really saw some really serious gaps in what we were doing. So from those really beautiful, consistent design systems that we had envisioned, the reality was often something that was out of sync and quite hard to manage across different tools and platforms. So yeah, we really thought there has to be a better way to structure and manage the data. So since we launched our plugin in 2019, we have grown to support almost over 250,000 designers, developers, and other product people in building the design systems across different tools like Penpot, Figma, design-to-code tools like Style Dictionary, and we've been listening for all these years to countless of support requests and points from teams who are building these complex systems. Things like how can I add functions to my design tokens to lighten or darken a color, or how do I add custom color types to my design tokens, or what if I want to connect the padding in my design to, let's say, the x height of my font? All very realistic questions if you're building a design system. And of course, there are hundreds more, but there's just so many requests here, I can't go through all of them. But these conversations really revealed some fundamental problem or fundamental truth that we had to embrace, and that's that the ambition of our design systems had actually outgrown the capabilities of the static tools that serve us today. So the very foundation of design tokens, these simple static key-value pairs, they were actually becoming a bottleneck for us, and this realization didn't just inspire new features, it actually inspired us to rethink the foundations itself. So to understand where we are coming from and where we're going, let's first rewind a bit to the problem that it all started with, and I'm going to go a bit faster over this. You probably all know this, but for context, right? So we've all lived this nightmare, right? A designer hands off beautiful mock-up, it goes to the developer, developer inspects it, we find a whole bunch of hex codes that say 0033FF or whatever, a nice color blue, and that goes into CSS, and not in one place, but in hundreds of places. One week later, marketing guy calls up and he says, hey, we've got to tweak the brand blue a little bit, and now there's a hunt, because we have to go back to the developer, he has to become the detective, find all those hex codes, and fix it. All right, but yeah, and then the question is, okay, what about the iOS team? What about the Android team and the marketing side and all those other digital properties that we have? So what was the reality? The reality that we really had was we were living in a chaos by a thousand hex codes. So design tokens, they changed that entire workflow. Instead of abstracting design decisions into static mock-up, we abstracted them into structured data. So that blue is no longer just a hex code, but it actually became an entity, like for example, color brand primary. So this simple shift created a single source of truth, and the token became the ultimate authority, which was really bridging the gap between design and development. So the conversation was no longer about what's the correct hex code, but the conversation is really about are we using the right design token? All right. Oh, sorry, that's my bad. Nice animations, though, but we have to wait for them. Yeah, okay. So this concept, of course, was too powerful to just remain a best practice, and it really needed to be something that was community-driven. So that's where the DTCG, W3C DTCG, or Design Tokens Community Group really comes in. And at Token Studio, of course, we've been really proud supporters and contributors to this effort from the very beginning, because we really believe that open standards are the only way forward to build truly scalable systems. For me personally, of course, this is a topic that I'm deeply passionate about for the last two years. I've had the privilege to serve as one of the editors for the Design Tokens Community Group as an editor on the spec. And my focus has been on pushing standards forward on the topic of theming and multi-file editing, like compact systems where we need to, you know, the design tokens format currently is a single file, and we need theming, we need multi -file, we need more complexity. So I've been focusing on that. Maybe we all know the issue 2.10 that's there in the DTCG spec. If you're following along, this has been one of the longest, most debated threads on the entire probably history of Design Tokens Community Group, and that's about how do we do theming. So that's what I've been working on for the last two years, and I'm really, really proud to say that in the next days, weeks, we will be launching an additional spec which is called the Resolver that will make huge progress in this area. All right. Thank you. Thank you. However, we're not done. This brings us to a paradox. Because the DTCG obviously very wisely decided that we had to limit the scope, and we couldn't imagine possibly every feature and everything that we would ever need in this spec. So what happened here is that there was built in, there's a built in escape hatch, maybe how we want to call it, and there's a property that's called dollar extension. So that means that now we can extend design tokens. So it was kind of a sanctioned space for integration. It was a green light for tools like Token Studio, Style Dictionary, and many other tools out there to actually add new features that the users were asking for. It gave us a way to store that data somewhere in the design tokens. But the reality of that is that every tool now had to invent their own engine. How do we process that additional data? All right. So now let's see what happens when we try to actually do something, right? So we'll take a look at a simple darken function, for example. So let's say you want to create a hoover state for your primary button. And in this case, we're going to use a custom function to darken the primary color of the button hoover color by 30%, something that's quite common, right? I want to hoover, and I want my color to go a little darker. So because the darken function that you use, this is not a standard, darken 30%, there's no standard above that, right? So that's a custom proprietary function, a little algorithm that you have developed in your design system. But yeah, it's just a piece of logic. And it needs to be defined in each of those engines that I just mentioned. So when our token studio plugin, for example, gets the darken function, it executes that perfectly because it knows what to do with it. But let's say when we now hit compiler X, it runs maybe a slightly different algorithm to darken it by 30%. And if you look at tool Y, who doesn't have a darken function at all, we just get the base color, and it fails. So this is a problem. And yeah, so there we come to another piece, which I would say this is what we call kind of the implementation drift. It's a direct result of a very, very well-intentioned extension space that we have in the spec. But it's really a hidden text that every design system team pays because it's really about all the hours wasted in trying to find out, for example, why the color in this app, native app, or in this website is just a slightly different hex color than the actual brand color that's there in our definitions. So however, this isn't a failure of the standard. It's just a natural consequence of the design of this standard within a really vast and diverse ecosystem. But nevertheless, we are back to building silos, the very problem that design tokens were meant to solve. We now, again, have this sort of isolation going on. Okay, so what's the ultimate cost of drift? The ultimate cost of drift is that we have now a bunch of competing dialects, and the every idea, every request for a new feature, a custom function, a custom type, it just gets stuck in the mud because, yeah, imagine across the entire ecosystem that needs to be implemented every time, and it's just really hard. So, yeah, we're again left in a world where the tools really can't keep up with the ambitions that we have. So after, you know, going through this pain a lot ourselves at Token Studio, we really had to ask ourselves one fundamental question. And that question was, what if all this logic traveled with the design data? Yeah? So what if instead of having ten different compilers, we had a single engine that could run everywhere? An engine that understood not just the structure of the data, but also the intent behind them. So, yeah, this is really the core idea that led us to rethink everything. And the result of that exploration is what we call TokenScript. And to be clear, just to preempt that, this isn't another build tool or any proprietary layer on top of the design tokens JSON. It's a really specialized interpreter programming language which is designed from the ground up, completely focused on the world of design systems. And we knew for this to succeed, this couldn't be another proprietary lock-in of data. And that's why we're really, really proud to announce that TokenScript, like most of our other tools, will be completely open source. The TokenScript language and the interpreter. Yeah, and like I said, it's not a proprietary layer on top of JSON. Also, this is not a new technology that is in any way competing with the DTCG standard. In fact, this is, I think, the natural evolution or extension on top of that. It's fully backward compatible. It's designed to supercharge the amazing work the community is already doing. Absolutely not to replace it. And yeah. Give me one second. Yeah. So that's the key of what I wanted to explain here. The logic you write, your darken function, your spacing calculations, they live in TokenScript itself. So the interpreter is a very lightweight portable engine. So you can kind of think of it as a library. For example, a JavaScript library that can be embedded everywhere, whether that is natively inside Penpot, whether that's in a plugin, in Figma, or in a build tool like Style Dictionary, or even real time in the browser. You can run it everywhere. The same engine runs the code everywhere, which means it guarantees that the darken function, if you want to darken by 10%, for example, will be executed everywhere in the same way. No more drifts, no more dialects. Okay. So I'm going to rush a little bit because I see I'm running out of time. So what does this let you do? It lets you move from describing your design system to programming your design system. And oh, so I think I'm going to skip to the demo now because enough talk. Yeah. So this is another experiment Marco is going to take over here because I don't have a laptop. So we're going to do this together and we're going to make this look, hopefully, seamless. So let's go. Oh, yeah. I have to look there now. That's interesting. Yeah. So okay. So we're now looking at a token script playground. And this is where it gets a little nerdy, but I hope that's all right here. And I'm going to run through it a little bit, but I think that's okay. So on the left side, what you can see over here is actually an example of token script, which is really simple right now. And on the right side, you see the output. That's all you need to understand right now. The focus is the outputs. Okay. So on the left side, we see a simple variable declaration. You can see yellow. It's of the type color and it has a hex value. Nothing new. We all know that. And we're returning that yellow. On the right side, you can see it. So as we move on, I want to just like quickly show this. Of course, we all work with different color spaces, right? So that's something we would like to have natively available. So what I just want to show you here is that we can just move to HSL. And now we have the color over there in the HSL color space. So moving on from there, yeah. So as you can see, I just want to build this up a little bit, right? So we have the variable, which is called yellow. And we want to make that to brand yellow. So this happens all the time, right? Your brand guide comes in and from the marketing department, it's full of hex codes. We need to keep those hex codes, but we want to work in HSL. So we want to move that there. So that's what we're doing here. And now we're returning brand yellow as HSL. And this all seems pretty simple, but we'll go up really quick. So let's look at the color ramp. Okay, so we start with the brand yellow again. We moved it to HSL. And now we want to generate 10 steps. So we want to create a dictionary out of that. I'm not going to go into the loops, but you see we're using a little loop over here. And on the right, you can see there's a color ramp. All right, let's keep moving. Yeah, so yeah, I was talking about that darken earlier, right? So of course, we want to lighten and darken colors. So I'm going to show you a bit more how that works here. But look at that. We have a simple color function here that's called relative darken. And what that really does is, yeah, let's return the yellow first. See, this is all running in real time. There we have our yellow. And we run a darken function. So let's return the darken version. And we can see it just darkens this color, right? So really simple stuff. But keep in mind, right now you can send this exact algorithm along with your design token. So no more unexpected results. All right, going to the next one. Yeah, okay. So now you can see, right, we have an HSL ramp here. So first we had some manual code to create a HSL ramp. And now you can see we're just using a simple function. Maybe this is a really good time to quickly dive into functions. So how does this work? Well, of course, we don't want to write a whole piece of code everywhere. But you probably have some smart people on your team who are building these algorithms, how you build a color ramp. And now you want to store that piece of logic as a custom function that you can now use everywhere. So that's what's happening here. We have a function, HSL ramp. All right, let's move to the next one. Because I can already see some of you guys thinking, hey, HSL is horrible to generate a color ramp that is looking yellow because it gets really dirty. So maybe we want to use a color space like OKLCH. Now, the problem with OKLCH, of course, we know is we cannot use it in every tool. But as you can see over here, we have an OKLCH color ramp. And it looks already way better. So now let's go to the next one. Yeah, so again, I don't expect you to look at this code and say, hey, this is clear to me. What I really want to show you here on the right now, we have hex values. And what this means is I can design my design system in a color space that works for me. And I can also, in real time or in export, get it in any color format that I want that actually works in the tools that I'm using while still having the benefits of a beautiful color ramp in this color space. Yeah, and how does this all tie together? Here, one more example of scripting that is maybe a common use case. What we see over here is that actually we want to know for a given foreground color, what would be the contrasting background color according to, let's say, your WCAG algorithm that you want to use, whether it's APCA or WCAG 2.1 or whatever. So you can see now that maybe we've changed the color from once to maybe we can already see that, right? Okay, yeah. And okay, this one in this case is still white, but you can see on this color, white would be the contrasting color. And now on red, black would be the right contrasting color. Okay, so how does this all tie back to design tokens and how can we make this a bit more tangible? So I will jump to the JSON format. So like I promised, this is backward compatible or in no way competing. So these are your design tokens. Many users are already using all kinds of functions or additions, math, and you name it. This is already complex. And you can now actually do this. You now can define your own function, for example, a contrasting color, and tell for a color that I should have my color.white or color.black on it to reach contrast. And if you see the right side, these are real-time rendered tokens. And at the bottom, we just put them in a simple preview for you to see it. But you can see these tokens are rendering and they're rendering an output of a black or a white on top of this background color. And some of this seems maybe like really simple stuff, but I'm running out of time and I'll look at metadata if we can get two more minutes. I guess so, yeah, I'm just taking it. Okay, yeah, so I want to talk a little bit about why this is actually really interesting. And that's where I'm coming here to the schemas and to the function. So when we talk about converting colors, I don't know, who of you are working quite intensely on colors? Maybe I can see some hands, color spaces. Oh, yeah, there's quite a few people here. So for the rest, if you want to convert between colors from HSL to OKLCH, for example, to actually do that, you have to step through five different color spaces to actually get there from an algorithm point of view. And what we see at the bottom here is that we are not only able to register custom functions as schemas, but you're also able to register color spaces as schemas. So I don't have time to go into the details, but of course, we are all here. So if you're interested in this, come have a chat with us and we can show you a lot of stuff. But we are bundling color schemas and functions, the entire logic along with your tokens, which means that whenever you need to do a transformation, whenever you have a build pipeline, you will be able to do that reliably every time, the same time, no surprises. Okay, then I have one last slide over here. Of course, we're not doing this alone. And I'm really excited to say that Penpot, with whom we are closely working together, will be one of the first design tools on the planet to actually be running on fully interoperable and scalable design data and soon powered by TokenScript. With Penpot together, we are at the forefront, we are building the future of design systems in an open, collaborative way, impossible to lock down, and a future where teams work in sync, brands stay connected everywhere, and also AI tools will be able to understand how to use and process this data. That's our commitment, open standards, real interoperability, and a shared movement with Penpot at the heart of it. Thank you, everyone., The Next Leap in Tokenization, YouTube, 01k8teedmng6cnjkaa51xyr1qb.