Deep dive on tokens with Adam Argyle from Google: How do you codify composition?

Chris Strahl:

Hey everyone. I'm here with Adam Argyle. He's a Chrome developer advocate that works at Google. He's focused on CSS. He's a member of the working group. This is our second conversation, Adam. So excited to have you back. Thanks for coming, man.

Adam Argyle:

I love it here. This is the most thrilling and deep conversations I get in the back of the front. How could I resist? It's just so much fun.

Chris Strahl:

So this is our first real deep cut conversation, where Adam and I are going to jam for a couple hours across some big topics, and try to go a little deeper than the normal surface conversation we have. And so we're probably going to get pretty into the weeds in part of this. It's going to be a little more uncut, I'd say a little less polished and put together than our normal ones. So here's that conversation, warts and all. Super stoked. We've got tokens on the menu. We've got the idea of looking at governance and how we construct things on the menu. And then we've got tools and how tools are about the creation of a synthetic experience, and how that tooling and our thought process around design systems needs to change, so that we're better able to express our design intent and see that reflected in our products.

All right. So I think that the best thing to start with when we start to think about tokens is the age old question, what the heck is a token? Is this a key value pair? Is this a function? Is this something that is just representative of a value in a system? When you hear design tokens, give me maybe a then and now. When you first heard the word, what did you think it was? And then nowadays, how has that thinking changed?

Adam Argyle:

Excellent way to phrase that, because yeah, it started innocent and small, right? Your colors were your tokens. It's almost like your Sass variables were your first forte into tokens, or maybe if you'd pulled them out of your Sass or out of your stylists and were providing them as data to your pre processors. Now you're really getting into it because you're looping over a structure in your style sheet. But yeah, in the beginning, it's just a value, I think. It was like some sort of const, it was a CSS const that you could pass around that it was reliable, that it wouldn't change and that's where it started. But we're at a position now where tokens are rich objects. They could be a list. They could be nested, and they have much more properties. And these are ways for them to integrate with other systems. There's even standards now about the shape and size and properties that are on these tokens. And we're now at a point where these are packets. They're little data packets, and they could contain a lot of different stuff.

Chris Strahl:

Taking it from that starting point, I think that the fun thing about that, too, is my first exposure was pretty much everybody's, right? Color. And the way they were expressed to me was, these are a way of representing and expressing key value pairs inside of your system. And so it is name:variable in basically every instance. And even that is relatively powerful, because the idea of a key value pairing that you then have the ability to manipulate and transform based on your particular medium was something that I immediately recognized as like, oh, okay. So this is the new XML, or the new JSON, or whatever. And I mean, not really, in that it was very simple in its construction, but also a way of essentially codifying a system for things where instead of having to have red, and a hex code, and an HSL value, and an RGB value, you actually had this idea of color primary and you could assign any of those things more dynamically as a variable, more or less assigned to a token.

"We're at a position now where tokens are rich objects. They could be a list. They could be nested, and they have much more properties. And these are ways for them to integrate with other systems. There's even standards now about the shape and size and properties that are on these tokens...They're little data packets, and they could contain a lot of different stuff."

And then I started to think about it in terms of typography, and in terms of spacing, and in terms of shadows. But then you start to get into the really interesting ones, which are animation, and how you have then multi-token things, that those tokens interact with each other and feed off of each other. And that was my first real exposure to the idea of this multi-variate set. That if you just have a token that has a timing, but you don't have a token that has an animation type, that timing token is worthless. Likewise, if you have an animation type token that you don't feed timing to, that token is worthless. And so that was my first binary construction idea of hey, these things need to be in pairs, or need to be collections. And then you start to-

Adam Argyle:

There's a dependency. You have a dependency happening between your graph of tokens, right? And yeah, how do you articulate that and how do you manage it? Because you're right. This is pretty much ineffective without its siblings, associated tokens. Pretty cool.

Chris Strahl:

Precisely. And then you start to think about all right, so if I need to have pairs of tokens, why couldn't I have parent tokens, and children tokens, and-

Adam Argyle:

Higher-level tokens.

Chris Strahl:

Exactly. Then all of a sudden you're in this world where you're like, well, why aren't tokens layouts? And the leap from colors to layout is as ridiculous as it seems, but also absolutely in my opinion, the direction where all this is headed.

Adam Argyle:

I like to think of tokens now as, we're trying to get rid of all the compute and all the... How much can we know ahead of time, and then distribute to CSS, so that CSS isn't originating this stuff? A lot of this was born out of abstraction, right? You're tired of repeating the same color. So you make a color variable, and now you have a key value pair and anyone can reference it. And now you can change it from one place, but naturally you build upon this stuff, and it gets more complex in to where we are today. Yeah. We're going to talk about content tokens, layout tokens, tokens with dependencies. These are really intense ways that we're trying to move more and more of this, who owns the responsibility of these values, to somewhere more higher level. Yeah. We're pushing things higher and higher and higher, out of our style sheets and more into a system.

Chris Strahl:

Yeah, I mean do you remember the old school HTML and CSS? Really, even before you had real CSS, where you were basically defining in your paragraph tag, font face, size, all of that other sorts of stuff. All those things that were basically properties of your paragraph tag, that then got abstracted up to CSS, which is absolutely the right call. You shouldn't be defining styles in your HTML tags. And then bumping that up another level now, we have this idea of, now I'm not just defining CSS for my page, or for my elements on my page. I'm defining it for my entire ecosystem, or my entire product, or some broader scale thing. Because people have realized you need to ladder up from HTML elements, to styles for a page, to styles for a system, and maybe there's styles for a product in there somewhere in between. But this layering of abstraction is important, because the things that you are defining now at the top of that pyramid are the baseline definition for everything down below.

Adam Argyle:

Yeah. And colors are a good example, because it starts so innocent, right. You have a web application and it needs a color. And then what you've articulated there, you're just like, well, now you have a native Android app. Okay. So how are you going to share your colors? It's like, well, you have to move them higher. The colors have to exist, not in the implementation, they must be raised up. And then as you add more places that your color needs to exist, which could be in print, et cetera, you need to have a system where you can have one color that then gets child colors, tokens, created for these different implementation systems, and you distribute them that way. Yeah. And your color all of a sudden went from, #CCC as a light gray to now it's defined as something... Maybe it's still #CCC at the very high level, but when it gets distributed out, it could be an XML color. It could be an objective C color. And you start to distribute the value in a more specific way to each ecosystem.

And yeah, it's just so funny how we move from this simple desire, and now we're into a web, right? We went from key value, straightforward one-to-one match, you could read it. And now we're in a web, and a dependency system, and a distribution mechanism, until we eventually get to our coverage stage towards the end here about Federation, and how do you manage who can change that value, right? It becomes really dangerous. Someone changed the brand color at the highest level, and distributed it to different child apps, whatever. Anyway, yeah, that's funny.

Chris Strahl:

Yeah, I mean that single source of truth also being a single point of failure. I think that as it relates to specifically color, I think the reason why we use color is because it is so attention-grabbing. When you sit there and you show people, but don't have a systematic way of approaching this via tokens, or via design systems. And you say, all right, let's take a very large social networking app that uses a lot of the color gray. When we were talking with them, they had something like 250 different shades of their core sets of gray, which is probably about 220 too many. And so when you think about that, that's not born out of somebody's willful ignorance, or malice, to go create yet another shade of gray. It's because there is no higher order system that's in place that helps define the rules of that abstraction, then filters out to all the other parts of the ecosystem.

And I think it's only really been recent that people have actually gave a damn about this sort of stuff, right? Because the service area of apps is expanding so rapidly, right? We've all watched, especially with the past year with COVID and everything like that. So much of our life is digital, and it's ever more so becoming digital. And that surface area, that all of a sudden these teams that these enterprises have to manage, has grown so rapidly, but those teams haven't grown in size to match. And so, whereas it might not have been that big of a deal to go refactor 270 shades of gray four years ago, that's now a big problem. Because that's across ecosystems of millions or billions of users, that have a huge amount of localization, a huge amount of diversity, a huge amount of just implications for that change. And without managing it centrally, I don't know how people get their arms around it.

Adam Argyle:

Yeah. It's definitely one of those things that folks get reactive about. Being at a consultancy, often we'd have clients come, they're like, "Well, my brand grew, and we made stationary, and now we have 40 websites. We have no idea what our colors are doing because we grew into this digital world reactively. And so we haven't been proactive and we have to go get a hold of our brand. Our brand is diluted, and so we want a single source of truth it, and distribute it, and how do we do that?" And I think it's just really common that these things get away from you because they feel so tiny and innocent in the moment, and they build so slowly, it's almost like a frog in lukewarm or water or whatever, right? It just doesn't know until it's boiling.

Chris Strahl:

Yeah. There's a fun conference talk there, called The Danger of the Eyedropper Tool, or something like that. And just specifically talk about it related to color tokens. Because the thing I want to move this towards is thinking about, so I think that we can all agree that tokens have moved beyond just key value pairs, and they're now into functions, and objects, and these multi-variate structures. That's an exciting landscape. Because like I said, tokens is loud as a possible thing, right? You can basically say when you go to find regions on a page, let me go to find content, let me go to find localization. All of these things are enabled by this idea of this network view of this abstraction. And I really want to hear from you what you've seen come out of this, because this is as backend of the front end as it gets, is this idea that we're defining a bunch of different base level functions for how we think about the visual layout of our site. And I mean, even beyond the visual side. Where do you see this going?

Adam Argyle:

Yeah. Nice question. I mean, I think of it a lot like state management libraries always wanted to focus on normalizing all their pasts, and having a single source of truth. And the goal with tokens is the same thing here. We want to change something centrally, and have it propagate through the rest. Let's see, what... I got lost in the question thinking about my answer, and-

Chris Strahl:

Yeah, no. So basically, all right, so we've got this idea of tokens as functions, tokens as as these multi-variate objects. What gets enabled by this? I mean, this is the back end of the front end. So where does this all go?

Adam Argyle:

Got it. Yes, okay. So this is the most hardcore back of the front, right? It's so back of the front, it has no front.

Chris Strahl:

Right.

Adam Argyle:

Right. And you are supporting all of the fronts. And I think that's what this future is trying to do here, is it's, we started by moving to the back of the front of the front, or at the front of the front and the back of the front. And we were doing a lot of the same work of-

Chris Strahl:

Whoa, whoa, whoa. You're going to have to slow down through that part, because you lost me on that one.

Adam Argyle:

Right. Okay. So we've got the front of the front, which is someone that might not... They're going to be grabbing the values. Maybe not even grabbing the values from this token system. So, let's say someone wants to build a new login page, and they need to know the colors of the backgrounds of the various services, like the card and stuff. The front of the front user is going to go consume, or the front of the front developer is going to consume these values. And the back of the front developer is going to go make sure that those values are easy to consume by the front end developer. And so that's the front of the front or the back of the front. And what I mean is that was where we started. It was the relationship was very much at runtime in the browser, and we're moving this work into a service, into an API.

And by again, going higher level, what we're now able to support is multiple platforms sharing these tokens in their own contextual ways that they need to. And I think of it like we're moving all of the compute stuff, which is computing, colors computing. It's all your consts. You're moving all your consts into an API, into a data mesh. And then you're just allowing N number of views to grab those values and compose. And so it's like what functional programming is trying to do, where they take a lot of the compute functions and they try to just make these small compute functions that are pure. I think that's what a design system is trying to do.

It's trying to move all that stuff higher level, make it pure, so that it's just a computation, and then let all the orchestration, and all the composition, all the really complex stuff, actually, goes back into the front end system more purely. So you're separating them out and allowing them to move more quickly and to scale better, by just, again, moving that into a higher level space into an API. Yeah, it does get a little mixed up, but I think I answered the question there.

Chris Strahl:

No, totally. I think that my favorite cringey dev joke is, two front end developers walk into a bar, and they have nothing to talk about.

Adam Argyle:

Right? It is.

Chris Strahl:

The idea that we're defining all of these very low level functions that are very pure, as you say, that are then used as constructors for much bigger and better things at an implementation level. I think that that's really fascinating. Because now what you're talking about is you're talking about things that you can also develop more lower level capability around, like adaptive color comes to mind. Right? And so do I really need that front of the front end person, if my back of the front end is using adaptive color to automatically understand based on color context what color rule should apply to any one element on my page?

It becomes a really interesting frontier where... And look, we're pushing a couple of years out here, right? I know exactly two people really using adaptive color. But if you think about that, that's a really interesting, powerful ecosystem, right? If what's sending my colors is a very backend, API driven process, could I apply machine learning to that? Could I apply any number of other things to that, to basically start to have it make a lot of these decisions for me?

Adam Argyle:

Nice. That would be really fun to see. Especially since it's centralized, you could see the compute patterns. There's probably patterns in your dependency graph you could go learn from, and yeah there's analysis that you could do and all sorts of stuff. Yeah.

Chris Strahl:

I love your analogy also, to all the wonderful stuff that X state gives us around the graphs, and the flow charts, and all of this other things like that. I would love to see that similarly expressed for design tokens in more advanced situations, because I think it would look relatively similar to how you track a state machine. Because you are talking about, not state per se, but in essence, with a bunch of these lower level tokens.

Adam Argyle:

Yeah, absolutely. And I think what lends itself nice too, is that a lot of the brands or businesses that have design system issues, it's because they're really big. When you're small, you don't tend to have the need to distribute a bunch of colors amongst a whole bunch of people, and centralize it. And we have these really big teams and big products. You've already mentioned, design systems are best when they need to fulfill multiple front ends, front ends or multiple environments. It's like there's a multiplier effect here. There's multiple interested things. And I think that's important to think about that with the graph, there is always going to be, at least the goal is to centralize everything to the top, and start to distribute things down to all the children products. And those child products... and this is why I like the graph... could definitely fork the color and be like, okay, we are a sub brand, right. This is again like inheritance, right. You could call super under the color system.

Chris Strahl:

I would say it's imperative. It's an imperative that they be able to fork it.

Adam Argyle:

Yeah. It is imperative. Right. Because that's really what every child brand is, or child product is going to want to do is, "Hey, yes, we want to look like we're in the family, but we don't want to look like we're all wearing khakis and t-shirts. We want to have some uniqueness to us when you look at the family," right? So yeah, you've got to be able to fork. And I think eventually we need a system that shows us this, where it's almost like a... You need a visual representation of all these different child design systems that are inheriting you, and who are you going to impact when you make a change. It's just a big graph, man. Anyway, the graphs are fun.

Chris Strahl:

The PajamaGram style of mapping out design systems. I love it. You want to look like you're in the family, but you want to have your own unique pajamas.

Adam Argyle:

Yep.

Chris Strahl:

So if you think about where that comes from, you're absolutely right. These systems thrive when there's a lot of complexity to manage. Because that's what this is all about, is trying to figure out how to abstract away some of that complexity that can then get managed at that lowest level. And we have, I think, for better or for worse, our audience, we predominantly target the people that are actually managing those design systems. But if you think about what this relates to for your developer, just consuming the design system on any old app that is in that design system ecosystem, it's important for them to understand how they're able to affect change inside of their own products, right?

Sure, there's this system space view that's out there, but if I'm a part of ABC Corp and my app is one of many, how, as that developer in that app, do I make sure that that color override goes through that right chain in that dependency graph, to give me an effective change for the color I want to have in my app? And that's a place that design systems have not been great yet. And I feel like it's very important to understand that we're designing tools for ourselves predominantly right now. As a design systems team, we're designing tools that help us manage that abstraction. But when you actually go and consume that abstraction, either that as a localization or that as an individual app, or, possibly that as in another device, we need to start creating tools for those people, too, to understand how the changes that they're trying to get into their own application flow through a system like this.

Adam Argyle:

Absolutely. You know what I really love about this observation is just a couple of things. Abstraction is always so attractive and feels so good, and I'm just going to run you through an abstraction that happened in our kitchen recently and how it negatively affected everyone.

Chris Strahl:

Okay. I love this. Let's do it.

Adam Argyle:

Okay. One person gets an idea that everything's messy and needs to be centralized and get moved, or everything needs a new location. Okay. So some person goes and thinks about it really deeply and thoughtfully, and maybe even labels everything, and puts it all away into a new place. Okay. Now all the other people come in to make something in the kitchen, and sure. Maybe it's all in a new spot. But they don't know where it is. And there's a new learning, okay? Every time you abstract, you actually make the distance from the desire and the way you get there one step further. So the more that you abstract, the further you actually take someone away from the thing. And so, yeah, I love what you're saying here, which is, okay let's say we had a sick design system. Developer A sits down, needs to pick a color for the input. Oh, snap, what do they have to do? Open up a design document on a website somewhere, scroll through 20 pages just to find the color that ended up being XKY1T, I don't know, something funky.

But I know that Knapsack has conveniences here for this. There's auto-complete as you're typing. So what I'm getting at is, abstracting, really fun, really meaningful, has a downside. There's a new learning curve. Now, every time you go into the kitchen or you open up this folder, there's new folders to understand. Why do I have new folders? What's going... I swear, every new folder is a mental amount of baggage, even though it adds-

Chris Strahl:

Oh, the cognitive load is crazy.

Adam Argyle:

The cognitive load of just a folder is nuts, right? So yeah. Thank you for being really considerate to the developer sitting down, that needs to go find this now remote color that's no longer somewhere near them like it used to be. It used to be just right around the corner.

Chris Strahl:

But back to your kitchen analogy, they used to walk into a kitchen and just make an egg. And now that they have to walk into a kitchen and go to drawer six slot three, to find the spatula to flip the egg, that's not relevant to them, that it lives in drawer three, slot six. They just want to make a fricking egg. And the more you have people open drawers and sort through pockets, the more challenging it becomes for them to get the thing done that they're trying to do.

Adam Argyle:

Yeah. TypeScript reminds me of in the kitchen all the time, it's like someone who's ambitious about containers, and they label every container. Right. And so it's like, okay, cool. I want a spatula, where are the spatulas? The spatulas are in the container labeled flatware. Right. And you're like, okay. So I opened up flatware, it's got 10 more containers. I'm like, oh man, I'm going to have to like deduce my way... And anyway, I like these things. They're fun. Both of these have complimentary mentalities. And I think grouping and organizing and abstracting is healthy. I don't think, as much as I criticize it, that design systems are doing anything wrong. I think it's really healthy to continue moving higher level, because the problem space is super real. That, at the end of the day, maybe it is now a little bit different to choose a color for a developer, that they're not just going to go into a design file and they're not going to use a picker.

They need to find something from the system, from the data mesh, that's being distributed for the application. But what they're not going to do is use the wrong color, or add complexity to the scale of all the colors in there. So anyway, I think the value that you get back is important enough to do all this work and to put the time in. I think the payoff is there. And I don't always say that about stuff like abstractions, but I think design systems are very much worth it.

Chris Strahl:

Absolutely. And I think that you have to balance that desire to do the right thing with that path of least resistance, because there's only going to be so much that someone is going to be willing to suffer, to do the right thing.

Adam Argyle:

Yeah.

Chris Strahl:

And so the ability to basically still make the right thing the path of least resistance is the most powerful solution for that. And I think that what we're doing as a community, that's maybe not quite perfect, is we're still trying to figure all this design system stuff out, right? These are still pretty new, conceptually. And so we haven't figured out all of our own ways of thinking and tooling, and all this other stuff like that, to be able to then focus on our consumer. And it's like any other broader product concept. I mean, you remember it's like responsive web design, right?

When that first came out, everyone's like, oh, you need to have a mobile site, and nobody could figure out what that was for a really long time. We had m.mydomain.com. We had media queries that were basically making it an entirely different site. And then we finally were like, okay, it's these handful of things, with grids and fluidity that we care about, that really represents what we should actually be thinking about. And then responsive tools finally caught up to actually being able to help people build this way. I think that we're still in that place with design systems, where we are designing for ourselves. And I think we're on the cusp of starting to think more about that consumer.

Adam Argyle:

Yeah, definitely.

Chris Strahl:

One last thing on the token front, I did want to talk about this idea of tokens as content, and as tokens as localization, because I think this is a really interesting place where there's another blind spot in design systems. I've only really talked to a handful of people that really think about the content role inside of their design system implementation, where you think about that as it relates to microcopy, you think about that as it relates to headline text, and a few other key things. I mean, assets, sometimes. But I really do view this as a pretty underserved part of the design system landscape. And it also is weird, because it very quickly starts to step on the toes of traditional CMS roles. And I wanted to understand more about your experience with this, because you run into a lot of places that are looking at stretching the boundaries of how all this stuff works in a browser. And I think it's interesting to talk about that from a content perspective for a minute.

Adam Argyle:

Nice. Yeah. I like the content perspective as well, because it does. Localization almost felt like an abstraction into a design system. Every time we would convert an app, essentially every string became an abstracted value that you requested, almost as if it was a color from a token. And yeah, the way that that competes with a CMS, I guess a lot of our implementations, at least that I've been working on, are hand done. We'll hire someone to go write all the alternative strings, and then just trust them that it's all good.

And then the other thing I wanted to add too, is the UX writing is a role, and this is mission critical. The way that you talk about how to build the UI, and that your UI has a consistent voice, this is the same purpose of colors and spacing, is you want a consistent thing. You want a consistent vibe, or there's an emotional result that comes from your colors, your spacing, and your voice. I think it makes sense to put voice into this, but yeah. How would that compete with the CMS? That is something that sounds like the technology teams would have to work out.

Chris Strahl:

Right. And design systems are largely tied to CMS platforms anyway. I mean, whether you're using Gatsby or you're using WordPress, it doesn't really matter. You still need something that ultimately serves as that content store, and serves as that destination for that HTML and CSS. And there's all sorts of bizarre and wonderful implementations of those abstractions in your end points like that. But when it comes to content specifically, the design system has been traditionally... I mean, if we have traditions, being a younger concept... has usually been pretty hands-off, right? Like, oh, yo, if that's text on a page, you all manage that. It's not my role. My role is tokens and components. And-

Adam Argyle:

Most of my go-tos, like your brand slogan is somewhere found in there. Yeah.

Chris Strahl:

So when you think about that application of voice and tone, and all of these other ways of thinking about how tokens apply to values, apply to principles, apply to all of these things that, at a pretty low level inside of the content structure, I wonder what an implementation looks like.

Adam Argyle:

Yeah. And this reminds me of again, functional programming. What happens when all of your pure functions are done? All the computation of your application is ready to go. What's next? And that's where you start to create these. You compose and orchestrate, and you start to create the relationships between these that are unique for that user goal. So I think what would happen is you would start to go, okay, so what are the user tasks that we need to handle? And you start looking at your list of tools, and your list of like colors and things that are coming from your system, and you go to town. And you start to create all the layouts and the glue that put these things and make them into a meaningful representation. And I always start from a user journey, but maybe that's not where everyone's starting. And yeah, I think it looks like a composition scenario, where you might think of it like Legos, but there's still a lot of, you're going to have to bring little Lego piece...

Adam Argyle:

... but there's still a lot of... You're going to have to bring little Lego pieces to connect to the big ones together so I assume it's somewhere in between, in that little realm there.

Chris Strahl:

If you were to stretch it a little bit, I think that the way I envision it is you think about a multinational global products, and you think about the things that they say that are core to their brand and core to who they are as text. Sure, slogans in there, I think that baseline product description, like some microcopy is in there, but all of that ultimately adds up to dozens and dozens of things that are the way that we use words or use imagery or use audio or video to deliver our message.

All the different content mediums, when you have those baseline ideas of what those are, and then what you can do is you can put them into a localization context where... Websites in Vietnam or websites in Japan or websites in Saudi Arabia look very different than websites in the United States and so would it be possible to have some higher order token that was governing the way that the website appeared in Japan relative to the way that the website appeared in the United States, that still includes that same copy and that same microcopy localized in Japanese, but also then applies a different aesthetic to the overall brand.

Adam Argyle:

I think what that does is it makes the front end developers, or just the team that's building interfaces need to know less. It's been annoying for many years. It's like, "Okay, marketing team, I need keywords for my page. I also need a description and the metadata. Oh, by the way, you forgot this." As a front end developer, I was bombarded with implementation details that I really shouldn't have to deal with, like little text edits in the intro paragraph or, "Oh, everyone wants to [inaudible 00:33:03] over the heading copy."

In this world where everything's a token, the front end developer references a value and walks away. They're like, "I don't care what the color is. I also don't care what we say here. I care that whatever it says can have a nice layout, so I'll make sure I pick the right layout. It can handle a variation of copy." Right. They get to make these higher level decisions because they've taken all the really low level values and pushed them so far up the chain and even into a place where the right person can go make the change and it just trickles down. I think that's the future.

Chris Strahl:

That's a really interesting idea, right, because front end developers spend so much time with product managers or marketing managers , or depending on if you're on product-

Adam Argyle:

Zeplin files, just copying and pasting just random stuff out of there.

Chris Strahl:

Exactly. Let's stop doing that and let's create tokens for that content.

Adam Argyle:

The whole power is you take it, make it into a token and now you have a place that everyone should go talk about it and facilitate the conversation now, here. Again, higher levels, so I push it higher level and bring more people in. I think that's one of the other goals that can be lost in a design system is, bringing more folks into the fold but, that's another topic we can get on that one later.

Chris Strahl:

No, but I do like the idea of giving a marketing user or giving a product owner a log into your design system and let them edit it. I think that that, that editorial experience is, again, another user need that I don't think is necessarily well served by the majority of design systems that are out there right now. We have to think as, "This is a place where as design system practitioners, we have to think about our own tools again." But, if we can provide a great experience for those people that they can understand how they affect change through the systems process by adding copy or adding content, that suddenly becomes a huge value add for that team as well.

Adam Argyle:

Yep. I think the one downside of this future is that being weird is harder, and that's a downside to me. I like it when things are weird, but this whole goal of a design system is to not be weird. That's a natural battle that happens as you normalize, is that people will want to still be weird in it and then that becomes much harder, which is fine though.

Chris Strahl:

But, that becomes then this weird organizational challenge. I don't know, we'll dive into that in a little bit but I totally-

Adam Argyle:

[crosstalk 00:35:26] I agree.

Chris Strahl:

Let's definitely come back to that though, because there is this whole idea of creative constraint that exists within design systems that I think is worthwhile to actually spend a little time talking about.

Adam Argyle:

Cool. I think so too.

Chris Strahl:

The last thing on this token front, tokens is layout, talk to me about slots. Talk to me about the way that we think about, about not just color systems and semantic pallets and typography systems and stuff like that, let's actually talk about like layout here. When we actually talk about this idea of how we construct a component, do we actually need this idea of a component or are we just talking about a collection of design tokens?

Adam Argyle:

This is such a hot one and a really hard one. Layout, I'm still trying to find patterns in what I build using flex and grid. I'm looking for these things that I could tokenize or I could abstract, because most of the layout work that I've seen get put into a design system becomes very, well, and naturally, very opinionated and you have to... Okay, so one strategy is to use CSS grid where a parent grid creates boxes with names and then it polices children inside so children have no decision in this. They get put in there by developer and they say, "Here's a header, here's a footer and here's this thing inside of this layout." The layout goes, "I see children that I'm aware of and they go here." It's all contained in the parent layout, the apparently out owns the names of these slots and sections and puts things inside.

There's another mentality here, which is like, "What if a child wants to claim a space because you want their component to own all of its own stuff, so what about the child component owning its space in that parent component, shouldn't know about those names?" I think that's one scenario of a very defined layout, but there's other ones that are very repeat oriented where you're just like, "I'm going to have N number of things in here. I don't really know and I don't really want to care." I call it spacing and flow. I'm like, "I want to go this direction with this spacing." I find I use those all the time, but I don't know how you would abstract that into a layout component because it's two things of CSS... It's not like I don't know how to put the CSS in there, but it's more like, "How do you give these things names?" Naming layout seems to be a huge problem in design systems, everyone's like, "There's these four and they look like this." You're like, "How do we talk about them?"

Chris Strahl:

Right.

Adam Argyle:

I don't know.

Chris Strahl:

I think it is back to names are hard and I think it also is back to... One of the things that you said that I think that is really interesting is this idea that some of the stuff that you see absolutely could be included in the design system. It's not that I want to lower our bar for what goes into a design system, right, I think that maybe 30% of layout is designed system lab. I don't think it needs to necessarily be an all or nothing scenario and you maybe just have a lot more snowflakes. The flow idea that you had, right, of, "Couldn't you just define flow as a token, wouldn't that work, flow right?" Have that automatically build that ad nauseam repeating in a [inaudible 00:38:48] layout forever.

You could attack it from both angles, right, in that flow right becomes a much more lower level, again, pure functional idea behind what a token would be. I think that if we try to basically say, "We're going to draw the boxes ahead of time and then just fit stuff into the boxes." I think that there's a very constrained set of things that that's going to work for.

Adam Argyle:

Yes. That's what I was going to get to next is that I feel like whenever you look at a website or you look at design or a layout, you're like, "There's only like three layouts in here. Look, there's one column there and that one's next to that one." Then, you go build it, you're like, "No, there's 40 different layouts in here. There's 40." The only reason that it looks simple is because, well, that's the whole point of design is to take something naturally complex and make it simple. There's a-

Chris Strahl:

Exactly as simple as it needs to be a no more.

Adam Argyle:

Yep. I like that you brought up the constraint focus of this because we're going to get into some more of that stuff later. There's an intrinsic value that your content brings that if you go pick a layout first and you put stuff in it, you're going to get the CSS has awesome result and then you're going to tell yourself that CSS is not awesome because your word awesome is busting out of your box, right. This is a really hard thing the web is still struggling with is, "Do I create the box and drop stuff in it or do I intrinsically look at the boxes value and just corral it?"

When I do layout, I'm often thinking of it like I'm a shepherd and these are just a bunch of sheep and they're sheep that could change size at any time. I'm just like, "I'm going to give you generically good constraints to handle this thing."

Chris Strahl:

Right.

Adam Argyle:

I'm still struggling at how to codify layouts into design systems without losing a lot of the fluidity and intrinsic, safe layout nature of the web. The layout of the web is all naturally safe and a lot of these design system layouts, in order to facilitate control and give type feedback as they're typing in an editor, they lose that and they go into a more constricted. It's just so hard, there's so much tension between some of these things sometimes.

Chris Strahl:

Yeah, absolutely. I think that there is a frontier here and I think that whoever solves this problem is going to make a huge boon to the entire low-code no-code movement, because I view this as like one of the major constraints on those applications as well, right. This is where a lot of the craftsmanship of the web comes in, right. I think that performance is one area, like why AI generated code still is not ready for a major production website is because milliseconds matter. I think that the second side of it is that, layout still matters and layout it's actually really hard and there's a very difficult hierarchical system to break down that craft into something that is more repeatable. I think that beyond defining those high level of constraints, it's very difficult to have like some AI driven system draw the boxes on the page for you.

Adam Argyle:

Yeah. It's almost like the more you abstract your layouts into and to provide... Let's say you have 20 different layouts and they have 15 different sub tokens that can tweak it and customize it, what you've done is moved all of the work into understanding the system that you've created and out of being able to be empowered with whatever CSS had available. We have to talk about these layouts, normally with a token we're creating a token and making it higher level so that it can be distributed across ecosystems healthily like-

Chris Strahl:

Kaboom, with-

Adam Argyle:

Kaboom. Okay, so great. You made a Flexbox layout and a grid layout in your design system, how does Android consume that? Are you auto laying out? You totally could and that would be super rad, but wow. The complexity starts to skyrocket as you're like, "Do I share these across ecosystems?" This is almost, it's just like a side tangent, I've heard things go into product primitives. Instead of you have a token, you actually have a whole chunk of UI. It's like a finished little micro experience and that's what you distributed. It's already got everything built in and you basically take even less customization from the developer out and you just give them this whole chunk.

Chris Strahl:

No, let's talk about that for a second, because I actually think this is a really interesting pattern based approach that is starting to really resonate with lots of people. Where we've just decided as an industry to put micro in front of everything for some reason. These micro front ends.

Adam Argyle:

Sounds fun.

Chris Strahl:

Right? Exactly. Micro machines, everybody grew up in the eighties, we all had micro machines race cars, and we've just carried that into our journey in the web. When you think about these encapsulated, reusable whole experiences... First time I ran into this I was talking to this guy, Steven, that works at a big media company. They have lots of different networks that all exist within the same media umbrella and each one of them had independently developed a way of doing a showreel.

The reality is having dozens of different showreel applications as these micro apps, micro front ends inside of these different channel applications, didn't make any sense. It made sense for them as a company to build this front end that could then be reusable across any experience that actually delivers the whole thing, right. It is not just like, "Here's some components that you can remix and mixed together, this is your show real experience, go drop this where you want to in your app experience.

Adam Argyle:

Yep. What's really crucial about that is acknowledging what is your app's value, what is your product good at? In this case, apparently it's good at creating a showreel and so go make that a thing, that's a product component. Is like, "This is very custom for us. This is what makes us unique, is this thing." You can go hand that around and let that distribute and it's always the same. I think those are really healthy outlooks and implementation details.

Chris Strahl:

I think that it's going to be something that continues to be a major trend is, people don't want to think about a lot of the low level experiences and they also want to control those really higher level experiences, right. People probably don't need to rebuild a reset password flow.

Adam Argyle:

I was just going to say, auth is a perfect one. No one wants it, "Okay. Hey, I've got the design system. I have inputs and colors and cards." You're like, "Oh yeah. Well, thanks so a week later I'll have a login form." Great. As opposed to, "Let's just go get the login component and it will pop over in a modal. Does everything it needs to and writes a cookie or a session and it's out of your way." Right. It's like a service, it makes the component into a service. It's really cool.

Chris Strahl:

Exactly. No, this is actually a really interesting place because I think log-in office is absolutely... Because, nobody in their right mind ever really wants to write another login system.

Adam Argyle:

How many unique bespoke log-in pages have you been to it? You're just like, "Ah, some developer did it again."

Chris Strahl:

I'm convinced that that people only like writing 404 pages because they like to be weird in a context that not many users should ever see.

Adam Argyle:

Nice.

Chris Strahl:

Any of these types of really wrote experiences that aren't particularly dynamic, aren't particularly interesting and you're never going to change somebody's mind about your app by having a really awesome logging experience, you can change if I [inaudible 00:46:40] a really bad one, I don't see that as a differentiator. People are building these as patterns into their design systems and they're basically saying like, "Here's the whole thing. Here's the here's login, don't worry about logging anymore. Here's showreel." Showreel is a very interesting counterexample on the opposite end of that continuum.

Where you actually have something that is now a higher order function inside of the app that like you said, it's like well-known for, and that needs to work and that requires a very high degree of control inside of an application, as opposed to compliance experience like CCPA, or we're collecting your data or GDPR, do you authorize us to use cookies experience?

Adam Argyle:

Yep. It comes down to... Man, this is like another one of the... Here's one of my favorite personal thoughts about design systems and this is playing into it because I think there's a range of design systems that you're oriented towards. Again, if you think it's Legos, what we've just described as having this product primitive, this experience that is created and can be carried around and just placed somewhere. This is like a Lego that you went in and got, that's like a castle it's pre-built, it's all one piece. Now, the bottom of it can connect into any other Lego pieces, but really there's no changing this castle. That castle is good for a super duper beginner that doesn't know anything about Legos, as well as someone who wants to build a kingdom, they can go start with your castle.

That's essentially the range that we have here is, you can either give someone bricks like, "Hey, this is the bricks of our kingdom, enjoy building a castle or here's a castle with a carriage." The question is always, "How much do you allow someone to customize the castle?" You become somewhere in this scale in your design system like, "Did you make really opinionated easy to move around components or did you try to empower everyone and make a system with so many small atomic design system pieces that they could go build anything and look like in their family, but they're now in a choice overload scenario and they feel numbed and can't build anything?"

Or, it takes so much expertise about Legos to actually build a castle that you're like, "I'm not a Lego professional and I don't have 10 hours to build a castle so where was the one in between for me?" It's always really important to know who your design system's for, who's consuming it and where on a scale do you want to be. I don't know what the right spot is on this yet.

Chris Strahl:

I don't think anybody does and I think it is somewhat unique to the implementation. One of the things I love about this whole thread of communication is where we started was around this idea of, "What are tokens at the lowest level?" Is like these key value pairs moving into these more complex things. Moving into some future looking things about what stuff like back into the front end type things we can do. Moving into stuff that maybe, maybe not, this is good for layout and all that. I love like how we basically took this really basic concept and showed how powerful it is, and also gave it a marker as to where this community is at on that continuum.

I think that marker is really indicative of your, your castle, kingdom bricks, a metaphor of... We're somewhere in between bricks and castles right now and we're having a really hard time deciding if we need more bricks or more castles. There are people that really want the bricks and there are people that really want the kingdom. I think that it is incumbent upon us to keep in mind that where we're at in a design system landscape, is we've built all these really incredible tools for design system practitioners. Thinking about the people that have to then go make something out of those, we need to basically have that conversation with them of, "Do you need bricks or do you need castles and how do these things all line up together?"

Adam Argyle:

Yep. I love that it's all coming down to services, right. You're turning all of your tokens into a service and just the service mentality is I think really healthy. I wanted to briefly talk about content that I don't think is a good token at all and that's alt text. If you try to alt text an image, happens in a CMS too, what did you alt it for? You don't know its usage yet. If it's a picture of a car on a road, your alt text would be car on a road, but someone uses it because they wanted the alert to say, "Car is appearing to drive off into the horizon onto new endeavors." You're like, "That's why I used the image, was to support this quest of new endeavors on this page but the alt came from the design system and wow, just really missed the mark." I don't know how to solve this.

Chris Strahl:

Thinking about XKCD, right, half the fun of XKCD is reading the alt text for the silly little comic because that's where the real jokes are.

Adam Argyle:

I did not know those are in there and now I'm going to have to go read them all.

Chris Strahl:

Dude, you're going to have to go read like 2000 comics again now because alt text is brilliant every single time. The idea of that expression of intent and how that intent actually ends up showing up and being aligned with the use, that's a hard problem, right. I think that there are some things that still... This gets back to me like we live in a land of tokens and components and users live in a land of pages and those pages have context and we cannot be aware of every possible context on every single page. What are the things that we still need to do at that page level because we're taking those away, right.We're trying to erode that individual implementation problem.

Adam Argyle:

Taking a lot of the human out of it.

Chris Strahl:

Are there any things that stick to that?

Adam Argyle:

Nope, really good call. I don't really know where the right place is to land. All I know is that it's a good indicator that abstraction... We see this in application development anyway, it's like as much as we want to abstract things away, there's still work to get done and still complex work to get done and thoughtful work. Not just doing the work, but a human needed to use it and then use it again and go, "Oh, this is the right solution."

Chris Strahl:

Exactly.

Adam Argyle:

There's still a human that builds with the design system, but sometimes it seems we want to make design systems for AI that can then just make all these decisions. To me, that means people are going to be making houses that look like they came from a factory. You're like, "Ah." You're driving down the street right now and like there's all this construction happening and they build those cookie cutter houses are going to be like, "Oh, look, that house was built with a design system and AI, it just looks like it because there's not enough human there." I don't know, this is just a fun part that I like thinking [crosstalk 00:53:41]

Chris Strahl:

I think this is great because we're going to take a quick break. And then when we come back, we'll talk about why design systems equate to fascism? I think that that's a perfect segue into where we go from here.

We ended on a note of fascism, which I think is somewhat appropriate because there is this reflexive idea of what a design system is. A design system is control, a design system is rules. A design system is boxes of ticky-tacky. I think that it can be but I think that that's if you think about this Anne Randian universe of how a design system actually gets applied to a group of people. I think that there is like the Star Trek application of this as well, where we all get along wonderfully and are peaceful and all of the base needs of humanity are met and so we ought to spend time gardening to making art.

I want to live in that design system world, not in the Anne Randian one so how do we get there, Adam. Tell me about how do we make this not about fascist control and more about empowerment of the people that consume it?

Adam Argyle:

Good call, because the way that the design system is giving you power is through its rules so how do you navigate the tension of this desire to create more rules in order to create more empowerment? I think it comes down to a couple of things, the first one is going to be, there's just new types of programming coming, right. We've already talked about what does this future where... Well, it's like the text values inside of a dom node just aren't owned by you anymore as a front end developer, the text is going to come from somewhere else.

As we move into this future where everything's abstracted and everything is... Let's see, I keep like losing sight of original questions as I try to weave and come back.

Chris Strahl:

How do we push back against fascism and make it so that design systems are empowering? How do we all live in Star Trek and not Mad Max?

Adam Argyle:

Right. This is like, "How do I write within TypeScript but not feel like my arms are tied behind my back?" It comes down to... There's a new type of programming and there's going to be a mentality shift, I think you had just have to be open-minded. I think some of the best artists in the world find massively impressive creative ways to express within sight of constraint systems. For example, there's phenomenal art where someone has drawn on Starbucks cups and then they stack them together and they make something beautiful.

You ask a thousand different artists and you say, "Hey, here's my little design system. It's Starbucks cups and a black Sharpie." They go, "I can make nothing with that." Then, you have some other person that goes, "Look at what I made with it." You go, "Mind blown, this is gorgeous. How did you create something gorgeous with that?" I think what we're going to get to is the constraints themselves in this case are empowering and they are limiting, but that expression and the place that you find inside of there, I think is going to be new. I'm going to just kind of throw that down there on the table, at least it's like the initial starter thought.

Chris Strahl:

No, I think it's great. I think that design systems can be about one person or one small subset of people pushing constraints on a much broader set of people or it can feel a lot more collaborative I feel like also, right. I think that the initial gut reaction, that reflects idea that comes to mind, if you own a piece of that rule set that's being pushed on you, it's somehow easier to accept. I also think that because things are different than the way that you've done them before does not necessarily make them worse or better, it just makes them different. People do need to about what a new canvas looks like, what didn't you set a tooling looks like, what any way of thinking about design looks like?

I think for the most part, this is a good thing, right, because you're taking a lot of stuff that designers do and developers do like, "Let me go code a table layout, or let me design a sticker sheet of buttons." You basically saying, "Maybe, that's not the work that is the most valuable to you. Maybe, that work would be better represented by just a set of constraints and let people that are actually doing implementation work within those set of colors."

Adam Argyle:

That was one of my questions I was going to ask is, what did you want to do as a front end developer anyway? Did you want to juggle hex codes and copy strings that... To me, that's one of my least favorite things to do is go change copy again, because the person was unhappy with the text and then it's like, "Wow, this is not really what I wanted my life as a front-end developer to be. I didn't want to go make incisions of texts nodes in the dom, I liked this other side of things." I think what a lot of this can do with the right mentality is open up to the role that you want it the whole time or help you move into the next phase of your role, because if your product is new, you're not going to go jump straight into a design system, likely, you're going to want to discover that over time or start to abstract as things get crazy.

A designer should start with a sticker sheet if everything's in a rough draft state and then there is no product, but as the product becomes more stable, you all should start to align on the thing that is closer to reality as the world that in the project that you're working on is now real. There's a lot of having to do with phases here and then which phase is your product in and which phase is your role in because maybe your front of the front and now you want to be back at the front or maybe you were back to the front, but the whole data mesh has done and it's just in maintenance mode and you want to go back into the front end. I think your role is just changing with the product as the product is evolving and becoming more mature. There's like a maturity and a phase relationship here that impacts whether or not this stuff feels constraining or not.

Chris Strahl:

I think also what sparked a thought in my head when you were talking through that is this idea of the people that are able to build these systems most appropriately are going to be the ones that watch this massive launch and evolution in their own career, right. If you're able to get on board with this thinking, to take advantage of it, to shape it for the organization and to make it better. That's just not a better way of working, that's also like a really great career move. I think where people are at is, they're just trying to understand exactly how they get there. I think there's some trepidation and some nervousness about what a design system implementation looks like.

Lots of these things fail, lots of them fail publicly and that is a scary thing to think about but there is this idea of, "If I'm able to make this work for my organization and make it work for my team, what's good for me in terms of my day-to-day, what's good for the company in terms of its overall ROI of this system, is going to be a great move for my career and how I go about thinking about being a creative director, being head of front end engineering or any number of other things that you would want in an organization.

Adam Argyle:

Yeah, definitely.

Chris Strahl:

I think that also one of the things that we talk about when we talk about design systems is, what tools do you throw away, right. If I'm a company or a dev team or whatever, and I'm investing in this design system, what does it replace? I think that there's a lot of interesting conversation around this because there's also this rush to tools, right. I'm the first to admit, we're one of them. Where we're trying to find this place that is between design and development that represents a more practical, scalable, efficient way of building really great applications. You see folks like Figma doing that on very much the design side of things and you see folks like Storybook doing that very much on the developer side of things. Are we talking about the end to canvas tools, are we talking about the end to hand...

Chris Strahl:

... end to canvas tools? Are we talking about the end to handoff tools? Are we talking about the end of prototyping?

I think that all of those are obviously intentionally kind of provocative things to say, but if you're building something new, typically that means that something else is getting replaced. What do you see that as in this ecosystem?

Adam Argyle:

That's a fun content setup. I'm reflecting to, my son is learning how to just draw right now. And there's so many similarities I see to being a designer.

There's these sticker books, and we have sticker sheets that designers use. I'm watching my son basically use the simplest way that he could to design, which is with stickers and putting them on a page. And the page already has layouts done. He's basically putting eyes on the eyes, and stuff like that.

He's still doing it wrong. I'm watching him do it wrong, and I'm like, "This is just like adults. Adults do the same thing." Just because you had a sticker sheet with a bunch of pre-made stuff, does not make the next task that much easier, honestly.

If you're not a good designer, and you don't know how to create an experience, then having all these really nice stickers doesn't actually do you much good. So yeah, we could [crosstalk 01:03:09] rush to tooling. Oh, go ahead. Yeah.

Chris Strahl:

Yeah, now all of a sudden there's an eyeball sticker on a toad leg, and you're just like, "Wait a minute. It's supposed to go onto the toad eye."

Adam Argyle:

Right. And yeah, supposed to. What is supposed to, and how's the design stuff... Right. So a Figma file can't decide supposed to. All Figma files can do is have a sticker. And I don't mean to downsize it. Because I think it's really powerful still what it can do.

But yeah, we have a lot of things competing for this optimization of this future flow, where I think what people have in their mind is a vision of building applications that's much simpler than reality.

Sorry, another metaphor. Working with wood. If you have ever like used something made of wood, you're like, "This is simple. Do you see it? It's just a couple of screws here, and they put it into there, and now it's a bench over here."

And then you're like, "Okay, I'm going to go make my own bench." And 10 hours later, you're like, "Wow. Little decisions became really important. I haven't even considered... "

I think that design systems and tooling have this mentality where like, "It's so easy to write a marketing page that's like... And much better. Look at this workflow." And it has one kind of key thing, but it creates new jobs, and new trade-offs, and new things. All of this stuff is new and doesn't necessarily always make your work less.

Okay, so here's something about a design system. I think design systems, in a lot of ways, create more work in an effort to reduce work. Which is a natural tension. So again, lots of tensions. I like looking at tensions. I think they're fun.

Chris Strahl:

I remember when we first met, that was, that was basically your opener to me. And I was like, "Ah, I'm going to talk to this guy for two hours about..."

Adam Argyle:

And then it into Kubernetes.

Chris Strahl:

Yup. So anyway, I mean, I think that it's a good point, right? And I don't think that the role of any one of these tools goes away, so much as it changes.

I don't think, for example, that design systems are going to replace canvas tools. You are always going to need that space where you take that idea cloud and you give it some first form. Even if it's still just a bunch of clouds in a box. It's still the first expression of intention.

I particularly love the words expression of intention. Because I think that that's fundamentally what design is all about. And the medium that that takes, I think is going to change. I think that there's going to be less expression of intention inside of synthetic tools, and more expression of intention in actual code.

Now, whether or not that ends up being production code, I think that that remains to be seen. But I think that what you're going to see is, you're going to see stuff come out of a Figma-style landscape or a canvas tool-style landscape into a medium that is destined for much more rapidly. Because that's where you're actually going to be able to take advantage of the work that you've done in a design system to then assemble an application.

Adam Argyle:

Yup. As much as we want to think that the expressive box, canvas art layout is going to go away or that prototyping has gone, I think that it's, again, rooted in this assumption that things are easy. I've been thinking about this recently. Kind of the example with the wood is, things are only as complex as the amount of layers you've taught yourself to see.

So you have to bounce out into the high level, looking at the design system and what its goals are, and then all the way down into using it and see that it's always going to have these decision points, where, yeah, we can go express our intent, which I think is a really healthy thing to do, and that that should be freedom of expression, is very different than the system's implementation.

I like expression as a sort of forefront, and it's almost like design-led product companies because they're expression-led instead of systems-led. To me that just makes them more human-oriented.

And I like that we continue to know that this stuff is all for humans. We could abstract ourselves away into something unusable, but as long as we have... We have to have tools that allow expression that's devoid of the implementation details, that basically go tell the implementation details how to behave.

There's, again, another tension there, right? Somebody has to be pushing the bounds or else nothing ever progresses and it only just becomes more secure, and a firmer application or whatever.

Chris Strahl:

Well, I think there's even tension there. You're totally right. There's lots of places for this, right? The tension between design and development, and who owns the source of truth. The tension between, I guess, the authenticity of expression versus the systematized nature of it, the systematized application of it.

I think that even at some of the more low levels. The idea of what is an expression tool versus what is a component tool. And thinking about the constraints in browsers, the constraints in how those are reflective...

I'm sure you deal with this very frequently given your role. Canvas tools express websites in a certain way that may not actually align to how a web browser interprets HTML and CSS.

Adam Argyle:

Yup. That's what we mean when we say synthetic, is it's sort of something trying to bridge a gap. And by bridging a gap, it has now become uncanny. It's not either the vertical stack, like you thought it was in your design tool, and in the end environment there's something off.

Those are really hard moments for me to see too. Because I look at a lot of these component-based design tools, which have really strong goals. They want designers and folks to come in and orchestrate, and tie these things together.

Because it sounds like fun. Who doesn't want to be like, "Oh, I'll drop that in there and drop that in there and connect the wires up." But that design task is so dramatically different than the one with stickers.

And so I empathize with both sides of this. I'm like, "Who are component design tools really for?" Because I see a lot of React developers, or just developers that like building components, want to go build a component design tool.

Then they're like, "I understand every little bit of it." And we're like, "Yo, you made it. They're all your components. You know every property on them by heart, pretty much, before you even got into the tool that creates new paradigms."

And so, yeah, I'm really trying to just be an observer here. Where are designers moving towards? Because they jumped on the Sketch and Figma component tree really fast, right? There was this strong desire to sort of dry up their work inside of their design tools.

But the more that they do systems work... It's like the most systems work I've seen anyone do is in Axure, in terms of designers. Designers would spend so much time building Axure prototypes or Framer prototypes, original Framer, but not since then. I've almost seen an incline in component tools that could do all this stuff, and a decline in designers caring.

And I'm just trying to soak it up. What did we do wrong? Because the goal was to give designers more stuff to work with, and yet they're not there. They're like pushed out. I don't know.

Chris Strahl:

Yeah. I think there's, again, back to that tension, and that wrestling for control. It was funny when we were first, before we were Knapsack, when we were still an agency, one of the early conversations I had with my co-founder was like, "Okay, so we're a company that builds big custom design systems for large enterprises. What are the things that we're going to face that are going to be the hardest challenges?"

And he said, "Point blank, the thing that I see being super, super difficult here is explaining to the organization who controls your dom. Is that wrestling of control between design and development something that is ultimately going to lead to better collaboration? Or is it just going to lead to this resistance and conflict?"

And whenever you talk about design systems, the implication is synonymous. It is now both design and development. I think that that's a pretty established science at this point. But who ultimately controls the changes to that design system is, I think, still this dichotomy that hasn't quite reached a state of harmony around organizations.

We're bleeding into the governance conversation a little bit here, but the idea of, if I'm a designer, am I the one that controls our palette for our application? Or do the developers control that? That's a very simple, but very pointed question that drives at exactly this tension.

Because I think that if you asked a head of design, they would say, "Absolutely I do." But I think if you asked a senior front-end engineer, they would be like, "Absolutely I do."

Adam Argyle:

Yeah.

Chris Strahl:

And the real answer is kind of a bit of both. But I don't think that organizations are well-equipped to draw those lines, and it doesn't fit neatly into a RACI chart.

Adam Argyle:

It definitely doesn't. Yeah, I love the way you painted that, because the answer isn't clear. It's just so fuzzy of who owns it.

Yeah, you have folks who talk about it, and this is almost like org trees in general. All the people talk about it, and then one person puts the bolt into the plane. Who owned... Yeah, I don't know. And does it really matter?

I guess the story is that you all worked together, so how do you facilitate and keep a history of that? I guess, yeah, how do you keep track of where the decision really came from? And that's just a whole other topic, isn't it?

Chris Strahl:

Yeah. I mean, I think it is and it isn't. I think that this is also kind of related to tooling, right? And it's related to, for example, what Abstract was trying to solve with design, right? So Abstract was like, "Yo, we need to have real version control," and [crosstalk 01:13:22]

Adam Argyle:

It's key for designers, yeah. I made [inaudible 01:13:23] do it. I was like, "We're on Abstract now."

Chris Strahl:

No, and it's a great idea, right? Because I think that then you start to think about a lot of the things that I think that design teams haven't, for whatever reason, have not chosen to value as a part of the creative process. That forces collaboration on the developer side of things.

Force may be too strong of a word. There is this collective need to have better collaboration between these cross-functional teams. And it's not just developers and designers. There's content, there's marketing, there's product. There's all these other audiences that we talked about beforehand.

And that giant bucket of other is potentially more important than the designer/developer collaboration. It's just that's what's in focus.

Adam Argyle:

Yup.

Chris Strahl:

So when we think about that, and we think about the tools and the ways that that tooling supports that, I think that code tools for design systems are going to have some gravity to them. And it is going to start to pull things into that medium, where non-technical contributors can manipulate production code to see what the results of that are.

Whether or not they're able to publish an app out of that is kind of irrelevant. What matters is that they're able to touch the thing. And it's not just like an approximation of the thing, it is the thing. [crosstalk 01:14:49].

Adam Argyle:

It's why Storybook has been really successful, is you're touching the thing. This isn't a synthetic version of the thing, it's the thing in isolation, right?

With all of its sort of... Well, if someone's defined it right, it has all the levers and buttons that you can push to go see how it does when things do this. Yeah.

Chris Strahl:

Yeah, but I think that even Storybook suffers from a fairly serious drawback of being an artifact of a build process, right? And so, yeah, you're looking at what exists in your build, but it's not the place where new experimentation really happens.

Adam Argyle:

Yes. Yes, nice.

Chris Strahl:

I think that that creative process, and moving some of that creative process into the design system is a pretty essential moment in our tooling and our maturity. And I do think that that maybe takes away from some of the prototyping tools, but honestly, those have been a really hard nut to crack, I think for design and dev teams for a very long time.

I don't know if design systems replace prototyping, but I think that it's definitely a place where a lot of the basic experimentation for UI can, and likely will, happen.

Adam Argyle:

I think that's a nice way to position it, because that's where I've seen them be the strongest. There's a lot of component-based tools that will consume a design system, and you're right. They're pitching, we'll create production code. And that's always where I'm like, "Why?"

I mean, sure, I know why, but when I go look at it, I'm like, "No developer's going to want to inherit that. You had to Abstract four times to get that outputted right, and it shows, and now I don't want it." So why not [crosstalk 01:16:25].

Chris Strahl:

No, wait a minute. I want to hit that really... Because that I think is an absolutely essential point, right? It needs to be the code you wrote. It can't be somebody else's code. The moment that it's someone else's code, you're introducing a burden onto that developer team.

Now, if you have no developer team, who cares, right? You might as well have something.

Adam Argyle:

Take what you get, yup.

Chris Strahl:

Yeah, exactly. But if you have a dev team, and you're all of a sudden telling them to go take this pre-built set of components, or go take this AI generated code, it's the same problem as organizations implementing Material.

Material is great. I love Material. I think it's awesome, and super badass. But almost within a couple of months of an organization adopting Material, they usually are like, "Oh, man, there's some constraint about Material that I don't like, or that I wouldn't do," because it's not their code.

And they now have this upstream dependency for their design system that is actually really hard for them to untangle inside of their organization. Ultimately, that's not saying that Material's a bad choice. That's saying that, if that is going to be the direction you go, you have to understand that that constraint exists.

Adam Argyle:

Yup. Yes, the constraint exists. And one of the first constraints I immediately think of is, in these prototyping places with reality components, I'm like, "There's no session. And if I can have an authed session, what am I doing in here? It's still synthetic and full of junk."

Chris Strahl:

Yeah.

Adam Argyle:

And then you go, "Okay, well I'll make a design tool where you have to sign in your user to go design in a..." No one's going to do that.

I mean, but you could. But then it's like, "Why don't you just go to your actual application and log in as a test user and just go mess around on there?" But yeah, oh, there's so many fun things you touched on.

I had a thought recently, and I think I've mentioned this phrase before, but a, component's always want you to think that they come around and are just totally contained. Like a cereal bar, like a protein bar, and you're just, "Yeah, it's just all contained. I'll just go pick one up off the table and I'll go put it over there."

But the reality is, it's like you asked for a banana, but you got a gorilla holding a banana. That's the object-oriented programming classic phrase. You wanted the one class, but it was sub-classed and super-classed or whatever. And all of a sudden you've got this whole nest.

I've been thinking that components recently, because you said they were all tied up together, I think components are all strings. And that is actually kind of just an okay way to think about it. That way you're not as surprised when it has strings attached to it.

That's something that these design tools can't, or shouldn't, expose. And that's what the implementation details are for. The implementation details are to go codify all the strings, because there's so many, and they're really annoying. They're really annoying strings to manage and you shouldn't [crosstalk 01:19:14]

Chris Strahl:

I think this is a huge shortcoming, right? It was the same people bitched and moaned about this with Twitter Bootstrap as they do with Tailwind today.

You have this idea of, I want to have a framework for a thing. I grab that framework, and I get the good with the bad. I get that banana, but there's that gorilla standing there, right? And what am I going to do with the gorilla now?

And unless you're willing to go through the complexity of ever more advanced dependency management, ever crazier webpack configs, ever crazier per component version management, you start to create a new kind of fragmentation that is potentially just as bad or worse as the old kind of fragmentation you were trying to solve.

Adam Argyle:

Yup. Yup. Yeah, design tools, I think you're right. They're best leaning more into prototyping and just be, get it closer to the metal. Use what your developers have built, instead of what y'all have built internally in your design tool.

That way it's sort of more innocent, and it also comes back to what I think designers like to do, which is be expressive. Developers like building systems, and designers like being expressive.

I think that's why a lot of these component-based tools fail is because they're so systems-oriented, you just lock up a designer so fast. And they're like, "I just wanted to go express my taste. I have a taste, and I want to go see if I can do it in your tool." And they're like, "I've spent 20 minutes, I got none of my taste out. So I'm just not going to come back to your tool."

Yeah, focusing on it and just dropping it down is a really good idea. I wish more tools would just be like, "We're a prototyping component tool. We're not going to output code and claim all this other extraordinary stuff." And keeping it simple could be really nice. Anyway, good call.

Chris Strahl:

Yeah. I mean, there's a little bit of an elegance to it, I think, where the upstream of your design system... I feel like we're starting to develop this notion of, the things that are upstream of a design system, should be stuff like design tools, like content, like marketing copy.

All of those sorts of things should be the inputs into your design system. And that data should reside in a place that can populate your components. Even if it's just sample data. That becomes the basis for how you ultimately construct those experiences in the design system.

Then the output of that system is either a package, which I think has its own set of shortcomings that are similar to that banana/gorilla analogy. Or it becomes an API call that you make at build time.

And that API is returning to a much more specific thing. Like I could get my banana, I could get my banana peel. I could get a banana split. I could get a banana smoothie. I could get a banana smoothie delivered by a gorilla.

Adam Argyle:

Right. I think you're touching on kind of where this future could be then, is because we were kind of confused... Well, I was confused earlier. How do you facilitate delivering a castle and bricks?

And maybe this is how it is, is your castles are being in a prototyping state. You have a prototyping tool for designers. Your design system is consuming the API there, so all of the little bricks are getting built ahead of time for a certain set of users. And then another set of users get to consume those to build the end application.

So it's almost like, by making this design system, and you're putting these higher level, you're empowering many different types of users to use these in many different ways. It's like, yeah, your design system should be your consts.

Anything that's a constant that isn't going to change, or that you can easily compute, should get tucked up into there. And it starts to empower these different expressive environments. One is a systems expression, and one is just to sort of like...

Okay, so how do we go next step then is, what if a designer is in one of these tools, they're building a prototype because they know that it's just sort of that way, but they find a flaw in a color. Could that tool push that up somehow and make that easy so that there could be like...

Chris Strahl:

I mean, why couldn't it right? If you have this idea of what a color is as a token, and that's something that is a revisionable, versionable piece of code, you can build a GUI that allows you to edit or change that in some simple way, and then push that through whatever review and governance process you want in the background to make that change go live.

Adam Argyle:

Yeah. It's just an API hunt. Well, and then you have Knapsack, so you could just have designers login to Knapsack and go nip it at the source, right?

Chris Strahl:

Yeah. That's kind of the idea. And I mean also, we integrate with Figma, right? So if you even wanted your designer to be the one that you've empowered to do that. Go change your brand colors in Figma, and then import those into Knapsack, and that creates a new version of your design tokens, and you're off to the races.

Adam Argyle:

Nice.

Chris Strahl:

I think that that sort of structured tiering system for where change happens, the biggest thing that I want to get to, is I want to get to the point that the consumer of the design system, that front end developer that is down working with the package or the API that gets produced, is able to make a change and have that alter their app. And have that change flow through all those design system machinations.

Adam Argyle:

Yup.

Chris Strahl:

And this is, when we were first envisioning a lot of this Knapsack app side of things, we're like, "Well, okay, what are we kind of like? Are we more like infrastructure or are we more like a design tool or are we more like a collaboration platform like GitHub Pages or [inaudible 01:25:08] or whatever.

And what we settled on in our initial iterations, is we're a lot like GitHub, where we are a landing pad. We have inputs and outputs. Ultimately you build something out of GitHub, and that goes somewhere else. And also you have a lot of things that come in to GitHub from someplace else. And GitHub is the [crosstalk 01:25:31].

Adam Argyle:

Converging space. Yeah.

Chris Strahl:

Exactly. It's collecting all this stuff and controlling it. And that's kind of how we thought about our software in the early days.

That viewpoint has changed and expanded a little bit. I think that some of this collaboration tool, especially as it relates to non-technical users, is insanely valuable and that's an important part of getting designers and developers into the same space.

And I think that there's a little bit of infrastructure here as well, because you need to think about this in terms of APIs, because you don't want everything to come out of a build process. You want a lot of stuff to happen in real time.

But I think that that collective nature is all to say, that what you want is you want people to be able to use the tools that they're most familiar with, that they're able to best express themselves with.

Adam Argyle:

Yeah. Yeah.

Chris Strahl:

And you want to have a meeting place for all of those tools where people can agree on what the output of that is going to flow down to your consumer applicants.

Adam Argyle:

Yup. Nice. Okay, so yes, we could say the sum of the goal of a design system is to liberate and create a multiple amount of expressions that can all push and pull from the same sort of source.

The goal is to empower expression, not to limit it. It can feel that way at first, but it has a multiplying effect that is outside of yourself. So yeah, maybe in the moment when it's new, it can feel frustrating, but over time it would disappear and enable a multitude of different groups.

Yeah. That's a really healthy goal for it to be. An expression enabler.

Chris Strahl:

Goodbye Ayn Rand, hello Star Trek.

Adam Argyle:

Yup. Very nice. I guess the trick is, not over-engineering your design system so that it is so rule-focused that it actually is shackles.

So it's that delicate balance of an easy-to-use API or whatever. And that's a whole other conversation about API designs and stuff.

Chris Strahl:

Right, well I view a lot of this as like a really big UX problem.

Adam Argyle:

Oh, yeah.

Chris Strahl:

What is the experiential nature of this collector tool, that has this collaborative space, that has all of these other different aspects of it, that also is real time, that also works for developers, works for... All these other different audiences.

It's a multi-faceted and very complicated UI and UX problem, that ultimately becomes about trust and about humans and about how we work together.

Adam Argyle:

Yup. Aw, I love that. Yes, it does. Because at the end of the day, that is the hardest part about this whole thing, is going to be that moment where someone wants to change a color. They want to change some of the copy, and this becomes a human conversation.

So yeah, the whole system is there to support the facilitation of that conversation, keep track of the decision that was made, and then distribute the value down to all interested clients.

Chris Strahl:

Yup. Yeah, and I think that this is why design systems fail if there's not service design attached to it. My talk with Dave [inaudible 01:28:34] about service design and why a service design matters, somewhere between 20 and 40% of a design system's success is in tooling. Basically the whole rest of that is how well a team is able to adopt and utilize and work together around it.

And that I think always will be so. No matter how wonderful we design these really incredible tools, it's all still going to be about how people use them.

Adam Argyle:

Very nice. So, Knapsack's focus has been, first to solve the API layer, this sort of core experience of stashing and managing so that it can then build and empower other tools. It becomes a foundational dependency of other things so that they can... Nice. Very nice.

I don't think I'd actually positioned it that way in my mind. I mean, I knew that it was an API, but I like that it started so low-level, and that it can empower so many more things because of that strategy. So very nice. Cool.

Chris Strahl:

Yeah. And I mean, it's reflective in the way that we think about the ecosystem. We want Figma files in our system. We have a Figma plugin. We want XD files in our system. We did a big project with the Adobe team to make that a reality.

I mean, hey, if you're using Storybook, you should be able to embed Storybook inside our application so that you can understand how that fits into the broader ecosystem. And likewise, we support GitHub and will very soon support GitLab and Bitbucket and all of the other places where you would want that code integration to live.

And so the idea isn't to try to supplant these tools, the idea is, try to figure out, what is the control point between all of these different disparate systems that all add up to a design system?

Adam Argyle:

Yup. Nice.

Chris Strahl:

Well, anyway, I think that that's great in terms of the chatting about, is a design system innately a fascist, microcosm in our lives, shackling us to a way of thinking. I did want [crosstalk 01:30:40]

Adam Argyle:

Here's your five Legos. Go build me 100 experiences.

Chris Strahl:

Right. You only get Starbucks cups and Sharpies. Go to town.

Thinking about this in terms of governance, that's kind of the last piece that we really wanted to hit on hard.

Adam Argyle:

Yeah.

Chris Strahl:

You can't really talk about governance without starting at, how do we build things? You had one of the more brilliant analogies before the show about working outward in, versus content outward.

Adam Argyle:

Oh, yeah.

Chris Strahl:

I think that that's a really great thing to explain, just because I think it's a pretty solid grounding for the whole governance discussion.

Adam Argyle:

Cool. So there's an article I read recently that really supported why I think I was thinking about it. It's called The Grain of the Web, and is working with the grain of the medium that you're in.

The medium that a lot of designs come from, is not a medium of the web. It's a medium where you draw a box, and it's a freeform floating box, and it has very little rules about it. That's what's fun, is your expression is unfettered. Pretty much everything is available.

That's the way that everything starts is, the content of whatever it... We always start with the end app that we want, and not necessarily our content. This is always a thing an agency would be doing too. It's like, "Oh, you want to make a website? Do you have images and content you want to say about yourself?" "Oh, we don't." What do you think the website is going to be about?

This problem of starting with wanting something, but not knowing about what you actually bring to the table in terms of content and value, has been around for a long time. And it manifests in our design tools in that we draw boxes and then try to put paragraphs in them.

And we're still doing that. Even with a design system, I watch people start open a new project. They've got pulled in the design system. They start building with components. And they're still building outward in.

Which is not the way the web renders or the way that the web works. And it also creates a mentality that things will fit into my box, which is a problematic mentality for content.

Because content is going to show up with an individuality, with its own personal needs and requirements. And if you created a box and put it in there, you're starting off on the wrong foot. And so what I was trying-

You're starting off on the wrong foot. And so what I was trying to share in that point was that, when we were talking earlier is working that way is still prevalent and it's still like a massive part of the problem. So let's say we have designed systems figured out and we've got everywhere from bricks to castles to build kingdoms. We're still going to have people that go build a city and then try to stick people in it. And you're like, "Woah, don't you want to ask people what they want or here, or give them a space, see how it kind of comes up organically and naturally." And it's almost like organic is the same thing as intrinsic versus, and then we have extrinsic, which is where you define a box and try to put things in. So, yeah, I'm just still seeing, even though we're advancing in our technologies, in our collaboration strategies, that at the end of the day, the people that are approaching building are still doing it outward in, and I don't know how to help them not do that.

And I don't know if it's tooling that needs to sort of facilitate building up a canvas from inward outward. I don't know. I just think there's a mentality swap that needs to happen. It's focused on like, "What is my message? What's the image I want to share." And work out that way, as opposed to being like, "I want it to be a card and then it will have an image and I'll go find copy to stick in there." I swear so often we're hunting for things to put in the sticker we put. I picked a sticker, the sticker looked good and now the sticker needs to, "Ooh, this is the hard part. What's it say?"

Chris Strahl:

Right. Right now all of a sudden my headline wraps and it throws everything off alignment wise across my entire website.

Adam Argyle:

Yep. Yep. Exactly.

Chris Strahl:

My favorite thing is like I was on a project one time and they had to localize in German and we were talking about things with the design team and I was like, "Well, so the one really hard part here is we have much longer headlines in German." And we always love to pick on German words for being 40 characters long or whatever, right? And I was having to review with the designer and they're like, Well, can they just make the title shorter?" I was like, "What do you think? Soda cans in Germany are bigger. Do you think billboards are bigger? They're just to accommodate more letters than a word?"

No. The answer is that we have to be flexible about how these things get implemented and bringing this kind of background to the governance side of things, right? Like when you are kind of constructing in this way, and you think about the structure of construction is of any digital product, there's innately a change management process that has to undergo, right? And whether that is going from an outward into a content outward model or whether that is a handoff from design to development or whatever.

The grounding that we need to make there is, change has to be managed as things go through all this different machinations. And by the way, back to your first comment, I think that's a cultural thing. I think that there's still so many people, especially in the world of design, but also even in the world of dev and technology that come from like the old print media days, or the AS400 UI days where people would be able to basically have a very static, medium, the web is innately like a very fluid, very easy to change medium. And even to a large degree, native apps are.

Adam Argyle:

They are now. Yep. Yeah. You don't just have two iPhone sizes anymore like the beginning days. Oh, it's easier to do now there's... Anyway, yup.

Chris Strahl:

Right. Now you've got notches and circles. You've got to cut out all sorts of other stuff too, right? But when you think about how we construct things and how we manage that process from end to end, that construction is innately driven by a governance process, whether it's formal or informal. Every single app team has a governance process, whether they've codified it or not. And I think when you think about how you build and the constraints about what you do... I lost my train of thought there. When you think about how you build that app, that governance process can have a lot of influence about the way that everybody works inside of the team. And that also relates to design systems and design tooling, because that can be an aid to that governance process or it can be a real headache.

Adam Argyle:

Yeah. I'm thinking of like a CMS that has a character limit on a subtitle.

Chris Strahl:

Right.

Adam Argyle:

And you're just like, "Okay. So in an attempt to make layout work easier or something, someone decided that a hundred characters was the limit and a marketer just tried to paste in something 150 characters." And yeah. How does this sort of tension that's happening here now that's part of the governance model part implementation details, part that mentality of how it all started. Yeah. It's sort of all winding up into this one little moment, huh?

Chris Strahl:

Yeah. And I think that just to be clear when we talk about governance here, we're not talking about big governance processes, like how you advance an app forward in time and space. We're talking about the little constraints that you set inside of your system that control the flow of information through the work. And I think that that's actually amendment to mention at the beginning that I kind of honestly forgot, was this idea that their governance about like how to change culture inside of organizations and stuff like that. We're not talking about that. What we're talking about is trying to figure out how the constraints you establish in a design system reflect the values and the way that the team wants to work.

Adam Argyle:

And how do you share that and have a tool that facilitates communication and collaboration, convergence, divergence, all that stuff, which is very get centric, which is why I think GitHub or just Git sort of websites, is a great example for where this design system governance can head and it should be heavily influenced by that system.

Chris Strahl:

Yeah. It's definitely been a huge boon for us is the idea that Git is your backend is actually a really powerful concept, right? Because even if you have a bunch of stuff that doesn't innately use Git, like URLs to Figma files and whatnot. You can push that into a Git repository as marked down or whatever that allow you to still revision the way that things were inside of that focal point collaboration area. And so your design system content at all should be something that exists inside of a framework, like Git. And I mean, Git just happens to be the most popular one and in my opinion probably the best. And I don't think that anybody would argue with it being the most widely used in terms of managing that control of change.

Adam Argyle:

Mercurial forever.

Chris Strahl:

Right, man, I remember when we were working on the drupal.org migration and we were trying to move away from CVS and we were deciding whether or not it was going to be Mercurial or Git or whatever-

Adam Argyle:

Or SVN or whatever. Yeah.

Chris Strahl:

Yeah. Oh my gosh, that debate, you talked about bike sheds.

Adam Argyle:

Yeah. I'm glad it's over. It's in the past now.

Chris Strahl:

Yep. So anyway, thinking about where that all goes... Sorry, I keep losing my train of thought on this. So where that all goes would be a system where you can have all these different disparate parts, you can control them all in one place. And then you can also reduce the amount of constraints inside of the system, based on your ability to understand how people actually use and manipulate data inside of the design system.

So your subtitle example, the idea would be is that you would need to design for a multiline subtitle or with some set of reasonable assumptions. And I think that this is one place where I really want your opinion is, when you think about defining reasonable assumptions as constraints inside of a system, if you're a heading and you're a paragraph of text, that's probably something that is unreasonable. But if you're also a heading and you're two lines of texts, maybe not unreasonable. And so how do you think about baking that sort of decision-making into your design system?

Adam Argyle:

Yeah, this is definitely a strategy thing. So if I was to build this, this is going to expose a lot of Adamisms, I guess, is I'd rather let someone put in 2000 characters in a heading reload their app and see the mistake, then limit them and try to make a decision ahead of time. Essentially, there's so many what ifs or buts, or in this scenario, this should be fine. And so I guess I kind of like a certain amount of human judgment to be in there. And I think that's where design systems have this one feature. That's like their most popular feature and it's the dos and don'ts section of a design system. And so I think maybe what you can do is kind of, yeah, you suggest the dos and the don'ts and let someone work creatively with inside of there.

I just like people still feeling like they can be creative. I think the most successful design systems are the ones that people think they're getting away with something like Tailwind, for example. Like Tailwind, there's so many little escape hatches, and you're like, "Aha, I'm going to do this. You don't even know." Tailwind or whatever. And I think people like feeling sneaky and expressive. And so in my system, I would allow them to do that and hopefully have a model where if that hits staging and we see a headline that's just massive. We're going to be like, "So why is the headline so big? So tell us is there a good use case for this?" Because I mean, I'm down if you know the users and who's going to be looking at and go okay.

And just kind of facilitate a conversation about it, as opposed to having a tool, have a little red linter in there that said, "Eh, you can't do that." But I don't know. I'm still on this kick of human communication is really hard, but I still think we should have it. And sometimes tooling tries to push out human com and I get upset. I'm like, "No, you could still talk to people about why stuff shouldn't be that way or ask them why. Maybe you'll learn something because you hadn't thought of that use case yet." So that's where I'm at though. But I'm curious. Yeah, what would you do in this scenario?

Chris Strahl:

Yeah, I think that it's interesting to... So first of all, I love the idea that Tailwind brings out your inner toddler. Having a toddler at home, I get that all the time. My kid is all about cheating to win right now.

Adam Argyle:

Seriously, I can't get them to do anything unless I tell them I don't want it. I swear. As soon I'm just like, "Dude, don't do that." They're like, "Oh, I'm going to go do that now." I'm like, "Oh man."

Chris Strahl:

No, it's all about a race for me. I'll be like, "Hey, we need to go change your clothes." He'd be like, "No." I'll be like, "I'll race you." And he'll get this sly look on his face and then run.

Adam Argyle:

So funny.

Chris Strahl:

But in all seriousness, when it comes down to how do you control every single decision in design system. The reality is you can't. I think you marked down the dos and don'ts for the ones that really matter. And then you establish a set of purpose and principles that give people a rubric for how to evaluate the rest. Yeah. And we used to talk a lot about purpose and principles on the show. We haven't revisited that topic very recently, but I think that one of the things that is really powerful about those things is because you can't document everything. The stuff that you can document should be governed by those purpose and principles. When you come to those crossroads of what should I do, that should be your rubric for decision-making.

Adam Argyle:

I wonder if tooling can sort of help facilitate the conversation to kind of like a raising an issue on GitHub, "Hey, this might not actually be a bug. This is sort of me asking questions and maybe other people would want to see the answers and sort of having that become very public." I think a lot of what I like about the concept of it's design systems and the future of them is the more... And I don't mean public as some design systems are very public, like completely open.

I mean more like public, like it just looks transparent, it looks approachable and it has this vibe of, "I can see into it and find the things I need and ask questions and no one's going to get mad at me type of thing." Yeah. Just design is just so hard so.

Chris Strahl:

Yeah I definitely see that.

Adam Argyle:

Yeah, you got to be lenient to them for that way, because otherwise users... Again, I just think they need to feel expressive and maybe even feel like they're getting away with something sometimes or else it just loses its fun. That's just lame to say, but there's something less fun about designing with components sometimes.

Chris Strahl:

Well, there's also like, I mean, design systems are about play, I think. I think a good design systems make people feel like they're playing. And I think that that's a cool concept to latch onto. But even beyond that, the idea of how do I make something still remain fun, but still exert control over it. The human factor is obviously important in this, but also the gentle reminder, the gentle nudge, right? Like the way that you can make a comment into the design system or having an interaction design system, see your pull requests in your design system. Understand how the work is flowing through that system and getting done is a really essential way of understanding how you're a part of that bigger hole.

And it reminds me a lot about like my roots in Open-source. I spend a lot of time in the Drupal community and watching that transparent, very public, very open discussion about like, even the really devilish details like warts and all. I mean, if anybody doesn't know, like the drupal.org ecosystem is by default public. And there's only very certain specific things that are behind the curtain, most of the time related to security and other really sensitive stuff.

Adam Argyle:

Nice.

Chris Strahl:

But that fostered this sense of community. And it fostered the sense of understanding how the contributions that individual is making or how that consumption of that thing came to pass. And so that expression of intent, again, in almost like the history of a component is really important and being able to see how that component evolved into the thing that is now, I think that the ability to almost like see a timeline of an evolution of something is very helpful for people understanding intent.

Adam Argyle:

Yeah. Yeah. Because a lot of times decisions that someone else made are really frustrating. Things other people coded are frustrated or even just things I coded last year are frustrating. But being able to see the decisions that led to its current state can help you get back into the position of like, "Oh, okay, I understand why this is here and I'm not as angry anymore." And I think that can be really nice. I really am attracted to this concept of how similar. I'm just sort of noticing it now that CMSs and design systems are really similar. And I'm wondering why haven't more design systems almost just looked exactly like WordPress or something. Why isn't there one like that?

Chris Strahl:

It's a totally valid question. And I think a large part of it is, is because design systems data has still largely been unstructured. Yeah, sure, we've got schemas, but how used are those schemas is to really represent fields and data and everything like that. And lots of times where you define schema is in a very independent place from where you're actually coding your components and not everybody uses TypeScript and all sorts of other things like that, right? You keep in mind that the vast majority of design systems that have any prominence whatsoever out in the world are complete custom built, end to end. And that complete custom build comes with a lot of, I mean for lack of a better word, things that we're really great at implementation, but then you don't have budget or time to address post-implementation that ended up being shortcomings. And it's not, I would say, uncommon in today's landscape to get a couple of million dollars to build a design system. What is uncommon is to get a couple million dollars to maintain a design system?

Adam Argyle:

Ooh. Yes. And that's, I think, the excitement of most creation is creation sounds so much more fun than maintenance. But maintenance is the true value that you need to sort of be oriented towards is to make that path easier, not your creation path easier, but your maintenance path. Interesting. Yeah.

Chris Strahl:

And you are starting to see a lot more like CMSs style things show up in design systems in some of the more recent examples. I think that it's funny, we're hitting like all the high point debates of when Evan and I were first starting this whole thing about what we talked about. Here, we're just building a new CMS. We had that conversation too, where you're sitting around a campfire with a beer in our hands being like, "So is this the next CMS?" And we're basically like, "If you're able to take a bunch of components and you're able to glue them all together and then you're able to tie it to a content source, how different is that than a CMS?" I mean, you're just kind of missing the publishing and maybe some wiring up of some backend services.

Adam Argyle:

You got the draft token.

Chris Strahl:

Yeah, exactly. Right. And we ultimately decided that the domain of CMS is all about a very independent purpose than a design system. And while the two were pretty intimately intertwined, the way that you think about the creation and management of content... So let me first preface this by basically saying like the model of the stack is dead, right? We all pretty much know that. Unless you're a smaller organization that doesn't have a dev team or it's a small site or something like that, there's very few people that actually want to couple their display to their content these days. And so that's a couple of that framework, that idea of like, "I want to have reactor, I want to have some other thing that is not the thing that is packaged as my CSS rendering my or CMS rendering my CSS." That's what this is all predicated on.

So the idea of the domain of a CMS is to have a place to create that constructed content that is then tied to an API to ship, which is another leg of the stool in the same way that backend and stuff like Square and Shopify or any number of backend services exist. Content has become a service framework, with things like Contentful and other applications. I mean, [inaudible 01:52:35] people can function as a service WordPress and then front end is the last remaining piece of that. And my friend was the last remaining leg of that stool was because front-end is governed by convention. And even in a lot of modern design systems, it's still is. There isn't that rigid definition of schemas that are actually making the design system API a reality for the vast majority of people.

Adam Argyle:

Yeah. The front end is the convergence of everything, right? It's all effort convergence there. And this is why I'm still surprised people think front end is easy when it's just like, "Well, apparently you don't know what's the convergence-

Chris Strahl:

Front end is a dumpster fire.

 And it's much less of a dumpster fire than it was five years ago, which is also a really hard thing to explain to people. And I mean that in the kindest possible terms, right? I just think that if you look at just even the evolution of JavaScript from jQuery to like modern JavaScript frameworks, that is so empowering and so enabling for people to actually build real apps on top of JavaScript, and now it can also be JavaScript all the way down, right? You have React and you can have Node and you can have CSS and Chess and all this other stuff that is all working in concert to actually create a real predictable application.

Adam Argyle:

They're all craft-based, they all are just connecting the graphs, composing new graphs and enabling something to pull from those and build something new from a single source. Yep.

Chris Strahl:

Yeah. But I mean, again, look at where we were at five years ago. We're like, [Ben 01:54:08] was new. I don't know. Maybe it's a little early of that. But now into like this idea that, we have TypeScript that is doing rigid definitions of variables and allowing us to flow information back and forth and their own little tiny schema that's on top of your code. It's super powerful where we're at now on the front end and that's what's kind of enabling all this design system stuff to shine.

Adam Argyle:

Yep. I get kind of confused and even with tokens and stuff, it's like, "How do you start to codify composition?" Design systems often have this where sandwich like, "Here's a button, here's an input." I'm like, "All right, what's the best way to put these together? Or how do you know if I have to submit buttons next to each other? Do you style them different automatically? Or do I have to go do something? What's the thinking of Knapsack in terms of orchestrating to disparate tokens into a new one, if they're defined in a certain way. Is there a verbiage or a syntax for that?"

Chris Strahl:

Yeah. I mean, not without a custom implementation right now. And we want to get there. So we actually been talking about this a lot, right? How do you define arrays inside of tokens, right? And when you have arrays, there's no simple way to do this. You can design a UI for an array of strings. You can design a UI for an array of objects. You can design a UI for array of any number of things, but then all of a sudden, ness and array inside of array. Well, you just blew up your UI. And so what we've basically settled on is this idea of kind of an advanced mode editor, where you're able to define these more objects structured functional pieces of tokens and allow them to relate to other tokens, trying to figure out how to do that in an elegant way where we don't have a code editor in our app.

So how do you think about allowing people to actually paste a block of code into Knapsack that is representative of a JSON file that defines that token schema or whatever. And so the answer is like, "You can do that inside of your repo today and Knapsack will respect that result." But we are not yet empowering people to understand how to, "All right, so I've got an array of buttons or a button grid. How do I have an array of tokens that also is responsive to that button grid?" And so that's not something that... It's something that we're working on and I'm really excited about where that's headed and it's in the not too far flung future.

Adam Argyle:

I wonder if that's why layouts are so hard is that here's here. Okay. I'm sorry to bring it back to the token singers. It's just so fun is that I think that tokens that are the most effective are [Leafs 01:56:53] right through the end of the other edge of the graph here. And so what I'm asking is how does the design system represent something that's a convergence or is a overlap of two at the same time. And it's just not something that an API is very good at answering when it's really good at answering Leafs.

And yeah, layouts aren't Leafs, are they? They need and touch too much stuff. So that must be why they're struggling so hard to get into these systems is theoretically, you'd have to define your grid that has a bunch of typed slots. And then you have to have things that can type slot children that then some element says I am of this. Anyway, you have to go define a whole bunch of extra stuff just so that your system can be aware enough of their relationship together. Ah, man, it's just really exploding. [crosstalk 01:57:48].

Chris Strahl:

And then ness something and then all of a sudden, like the metal level becomes so brain breaking, it's very hard to traverse. And yeah, you're absolutely right. The higher order tokens is how this gets solved. And I literally have only ever seen one design system that has ever had actually that concept in production. And I think that it is a frontier. And I think that what's most exciting about it is, these are very hard problems now, but I don't think that they're always going to be. I think that the value is obviously here, right? Like you and I are sitting here talking about it. I have these kind of conversations with a relatively high amount of frequency. People are going to start to see having a baseline design system that connects design and code as table stakes. And now the really fun stuff is what comes after. And I think that this is definitely one of those, like what comes after ideas that I'm really excited to hear.

Adam Argyle:

Nice. Yeah. It's just the concept of design system is—I don't think it's questionable now. It's like, "No, this is good for you. If you have multiple targets that you're building towards, this is something that you should start investing in earlier than later." But it's not done. And it does have a whole lot to grow. And it is exciting to think about, I just put out a question the other day about layouts and how are people managing them in a design system. And it's just like, the options are still really wide, which makes finding the right tactic really hard. And it sounds like everyone's just kind of going to bespoke. Yeah. Finding what works for them and moving forward with it. A lot of it comes down to sales too, and having an advocate, someone who can go convince other people that it's worth reading the components and finding these tokens. But yeah. I guess competition too.

Chris Strahl:

I mean, usually somebody that's willing to be paid and beer and pizza for a little while, right? Because usually that's not sanctioned work. That's still something that's usually happening, is like an insurgency inside of an organization.

Adam Argyle:

You remind me of street teams. Do you remember street teams for bands?

Chris Strahl:

No, I don't. I'm missing out on this one, man. You and I are usually so good on these things.

Adam Argyle:

You'd have like good Charlotte or MxPx or Green Day, or I don't know, maybe it's a [Leia 01:59:59] or something and you'd have a street team that is in your local area and they're just like kids and cats that are down to go pitch the band. So they'd go, "They'd get mailed [crosstalk 02:00:11]."

Chris Strahl:

Yeah. I grew up in a small town, so we probably didn't have those.

Adam Argyle:

Oh, nice. Okay. So yeah, some friends would be like, "All right. I just got my shipment from Green Day. I'm going to go to their show tonight and hand out flowers or flyers and I'm going to get a free red bull."

Chris Strahl:

Okay. Gotcha. No, that makes sense. Early influencer marketing.

Adam Argyle:

Early influencer marketing definitely.

Chris Strahl:

All right, man. Well, Hey, this has been an awesome talk as always. It's been really great to catch up with you. You've been so generous with your time. I love talking about this stuff. I'm sure we're going to have another conversation again, but I just want to say from the bottom of my heart, thank you, thank you, thank you. This has been so much fun and I look forward to when this goes live and we can keep talking more.

Adam Argyle:

Same. Yeah. I mean, five minutes is all that's gone by it, right? So next time we'll do a 10 minute talk.

Chris Strahl:

Yeah Right. Exactly. Exactly.

Chris Strahl:

That's all for today. This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter at the DS pod, we'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack and check us out at knapsack.cloud. Have a great day.