Evan Lovely, Chris Bloom, Jake Love, and Brittany Smart from Knapsack
Chris:
Hi, and welcome to the Design Systems Podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design, code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at knapsack.cloud. If you want to get in touch with the show, ask some questions or generally tell us what you think, go ahead and tweet us, @TheDSPod. We'd love to hear from you.
Chris:
Hey, everybody, and welcome to the Design Systems Podcast. This is your host Chris Strahl. Today, we're doing something a little bit different. We're going to do some hot takes with some of the folks that I work with. And so we're all in Hood River, Oregon. I wish I could say it's a beautiful day. It's actually a little bit cloudy, but at least the gorge is gorgeous. And we're going to be having some voices from inside of Knapsack talk about some of the cool stuff they're working on. So hey, Chris, why don't you introduce yourself?
Chris Bloom:
Hey. My name is Chris Bloom, and I'm a developer here on the Knapsack team. It is very humid outside, and I am moist.
Chris:
That's the perfect word for it, really. Everyone loves that word. That word trends really well with our podcast audience.
Chris Bloom:
It's great right now.
Chris:
Yeah. So anyway, the thing I think you wanted to jam on was design tokens, hot topic, as always, in design systems. We spent a lot of time working on design tokens conceptually within Knapsack largely because we think about design tokens as a way of expressing your organization's brand or brands.
Chris Bloom:
And tokens themselves are a relatively new concept in the design system seen from just the last couple of years. We've really only been talking about design systems as a way of building software within the last six or seven years, and we've refined and we've refactored our approach to thinking about that stuff. And tokens are a big topic, especially because tokens has a spec. Do you want to talk about that spec real quick?
Chris:
Yeah, so I believe the W3C has created a working specification for design tokens, how they work, how they function, how you inherit them, how they transform, all these different things. And so at a fundamental level, a token is basically a key value.
Chris Bloom:
That's it. Tokens are data. Tokens are just raw data that can then become something else, become something that we use inside of our applications, like CSS or JavaScript variables. And this is a pretty dramatic change from the way that we used to store these kind of variables. We used to have big SaaS files full of variables, top to bottoms. We even have files right now full of CSS variables, but what tokens do a little bit differently is they say we're not going to lock that concept of a color to a specific technology. We're going to give you this data or this framework agnostic way of storing them, and then you can convert them into whatever you want.
Chris:
And that conversion either takes the form of a transform, or it actually just works directly by something reading from say a JSON file.
Chris Bloom:
From a JSON file, the universal language of data on the internet right now.
Chris:
So the hot take, then, is that rather than thinking about a brand as a bunch of styles and a Figma file or a bunch of variables in a SWIFT iOS application, or thinking about them as a bunch of different CSS classes in the web, you think about a common data format that everything flows from.
Chris Bloom:
That's it. My first adventure into tokens came from my exposure to Tailwind, Adam Wathan's CSS framework. Now, at Knapsack, we support all sorts of token formats. We support all sorts of UI frameworks, but I really got into Tailwind a couple of years ago, and the big aha moment for me was that all of these colors and spacings and paddings and font sizes were not stored as the technology that was going to display those things on the internet. It was just stored as JSON, which was a big JavaScript variable. And then it became the stuff that we needed during a pre-processing step. It was a big light bulb moment of wow, we've been storing stuff wrong this whole time because, and I'm guilty of this, years ago, if we had a big SaaS file full of variables, we realized, wait a minute, we needed those variables somewhere else. I need JavaScript to understand this stuff. So we built these hilarious duct tape and bubble gum systems to parse a SaaS file, turn the SaaS file into JSON, then take that JSON and go feed it into JavaScript. It's very Rube Goldberg-esque to just say, listen, these are a bunch of key value pairs that we should be consuming into other formats.
Chris:
Got you. So that's in contrast to the new way of doing it, where you have this common format that everything's stored in. And then what makes that belong in a design system? Why do we care about this existing inside of the actual code and functions and design, and how does that help us, really?
Chris Bloom:
So one of the advantages of storing a lot of this information in tokens is that a big part of a design system is providing your components to consuming applications. Design systems are more than just components for sure, but a big part of it is being able to say something that needs to use these pieces, we make it available. Being able to make those smallest parts available... And that's what a token is. It is something that is at the lowest level in your system. If you're familiar with atomic design, we've always had things like atoms and molecules and organisms to explain the complexity of a component, but what a design token does is it says there is something lower than an atom. If you think of an atom like a button, for instance, well, that button is made out of a dozen small decisions. What's the line width? What's the border color? What's the rounded radius? What is the background color for the button? So the design token being small at that level means that we can also provide that to the consuming systems that use our design system.
Chris:
Right. Also, I love the idea that tokens are what make a component more than just a bunch of boxes, and so that is all of the visual treatment associated component. Of course, you can hard code this stuff. You can make it so that every single button is blue or whatever, but it's more interesting when you're actually passing that token to that button and saying, all right, button, read from this potential set of tokens to ultimately represent what color it should be. And that may be blue.
Chris Bloom:
That's it. And the best part of it is it is truly technology agnostic. That's why there can be a W3C spec for it, because as long as you are meeting the shape of a token object, and I think it's an object that has a key as dollar sign value at this point, then we've got the ability for all sorts of things to just say, oh, I understand that and consume that just like everything consumes JSON these days and understands that format. And this is going to be something that's going to let us describe our brand colors across a lot of different sites, systems, frameworks and even run times, like iOS, Android, whatever.
Chris:
Yeah, so it actually frees us from a lot of constraints. We often talk about the constraint of going from design tools to products. This also frees us from, like you said, entirely different types of products. You could do something that was a touchscreen kiosk. You could do something that was a website. You could do something that was, heck, an Alexa app. Or skill, I guess, is what they're called.
Chris Bloom:
Having a design token for volume.
Chris:
Yeah, exactly. Why couldn't you have that? Anything you can express as a variable, you can essentially use as a design token.
Chris Bloom:
That's it. I cannot explain the terror in the past of being provided a set of design elements to go build something like a website and being given a really specific technology like SaaS, for instance. If you didn't have it preconfigured, suddenly you've locked in an entire project to a really specific run time for your styles plus node environments and dependencies and pre-processing steps. And we always felt there has to be a better way to do this. And really, it's just about storing these rules as just raw data.
Chris:
Awesome. Well, thanks so much for talking to us about just what these things are, why they matter. Any final thoughts?
Chris Bloom:
Just really having written a big part of the tokens engine inside of Knapsack, it's given me a lot of insight into what people want to be doing with these things. They want the ability to edit them easily. They want the ability to share them. By the way, included in the spec is the ability for a token to reference another token. If you have a base red and it's got a base blue, when you have the brand red 500 token, it can just reference the one you've already defined. A lot of the power of design systems is removing the possible permutations of things like variables and font sizes, and design tokens allow us to keep this really tight, constrained set of values that can just reference each other to make what we build a whole lot more knowable and a whole lot more simpler to use and simpler to understand.
Chris:
More elegant.
Chris Bloom:
More elegant. Exactly.
Chris:
Yeah. So how do we think about these inside of Knapsack? Because I know we use the W3C token standard, but we also extend it in a lot of ways.
Chris Bloom:
That's right. We've really extended it to provide concepts of custom groupings where we want folks to be able to organize and customize the way that they display and the way that they talk about their tokens and the way they document that stuff. So we've extended the spec to provide custom groups, and we put a lot of effort into what's coming up with our UI around organizing and defining these in the browser and being able to hit a butt and save that as JSON. So I think that's really, really important, and I think that once tokens have a really good web interface for stakeholders, for the designers and the developers in a design system to be able to mess with them on the fly and being able to consume these rules from things like Figma, it suddenly just blows open the door what you can do with the design system and how easy it is to reuse those pieces.
Chris:
So here's an interesting hot take. There's lots of people to think about how styling is owned in design. You have layer styles, textiles, all those different types of styling that exist inside of a Figma or whatever design tool it is you're using. What would you say to those people that says that my design systems just inherit my styling from my design tool?
Chris Bloom:
I think with the advances that we have in tools like Figma where, honestly, Figma has one of the best ways of defining these low level pieces, it can go both ways. Figma can import rules like this, but Figma can also export rules like this. So however your team wants to work, at the end of the day, it's just a little blob of JSON that you're passing around. Whoever you want to have own that or be the arbiters of the truth of that, you can, and you can have it fit to the best needs of your team. That's a great part about all this stuff just being data.
Chris:
Awesome. Well, hey, thanks so much, Chris. Appreciate you being on.
Chris Bloom:
Rock on. Thanks for having me.
Chris:
Cheers. I'm here with Jake Love doing a hot take about tools inside of design systems. Jake, why don't you say-
Jake Love:
Hello, everybody.
Chris:
What do you do?
Jake Love:
I'm a senior solutions engineer here. I've been working in the cross-functional space pretty much my whole career, whether that is working with design teams or working with cross-functional engineering teams at different levels and trying to solve the problem of how you can create consistent designs and build those into code. [inaudible 00:11:50] solutions has been something that's been on my focus for a very, very long time.
Chris:
Yeah, and you're a bit of a Swiss Army knife of a person because you know a little bit about design, you know a little bit about code, you know a lot about product. But really, I think the core of this conversation is that you set up the vast majority of the design systems that use Knapsack. And so you get to see dozens of these things, and you get to see lots of different variations about how companies big and small use design systems on a day-to-day level. And you also get deep into the sausage, so to speak. And so how everything is made, all the ugly bits, all the great bits. So without calling anybody out, one of the things that I was curious about is, what stuff goes in a design system that is beyond just tokens, docs, components, Figma files? What are the things that are a little lesser known that still show up there?
Jake Love:
Totally. And those are probably all the unsung heroes. Those are the scripts that are doing all the things in the background. It's the same idea behind a design system where if you've spent time doing something, you shouldn't have to spend additional time doing that over and over again. And so when we talk about whether that's a build process, whether we talk about the creation of artifacts or the acquisition of those artifacts, placement in the right place for file structured, all that stuff, if you solve that problem one time, you should also deliver that inside of the system. And so yeah, share the things that you've learned on the engineering side with the production side.
Chris:
Got you. So this represents content that isn't necessarily UI content. This is content that actually helps you build that UI. And so it can be scripts. It can be [inaudible 00:13:31]. It can be all sorts of other things that are within the system. What are some really great examples that you've seen of this where you're like, wow, oh, that's a great idea to have, is this a repeatable, reasonable thing?
Jake Love:
Yeah, totally. Rollup configurations, webpack configurations, any configuration that essentially is something that you would need to do either during a CI/CD build process or something that would need to happen in order to get a application to a state that it could run, and so any script like that.
Chris:
Yeah. And so these aren't the things that are actually the UI themselves. It's not the toy, but it's the batteries that go in the toy. It's more of a batteries included situation.
Jake Love:
Yeah. Some assembly is required. Right. And that some assembly is not any complex mechanism or anything. That comes out of the box. You just have to bolt some screws and tighten them in, and there you go.
Chris:
Got you. So how does this help people? When you have all these things and you're consuming the design system for the first time, presumably if I am a product owner or an engineer inside of an app team and I'm looking to consuming this design system, I either have to think about how I create my own tools, my own builds to able to consume that, or I can actually just look at the system and it provides that for me. Is it as simple as that?
Jake Love:
Yeah. It also depends on how you curate that. It's a choose your own adventure game. That can take various formats from a README file to a Notion doc or whatever the tool is that you're using. But once you have that list of scripts and essentially tools in your toolkit that are available for other engineers to use, it just creates a lot more of a safe environment, a consistent environment. And again, you solve a problem for an engineer that might be a future engineer. It helps to preserve the longevity of your system and the maintainability of the system as well.
Chris:
Awesome. So how does Knapsack do this? Is it just stored as content inside of our system? Yeah.
Jake Love:
Well, actually, one of the things that I have always really loved about our system is that we try to get out of the way of good old fashioned engineering techniques and best practices. And so we ship with monorepo. And so there's a package JSON that is at the root of every single workspace. And then out of the box, we also have separate packages that we're releasing for each one of our renderers or design token and styles, but it's highly configurable. And so while it ships with some opinions because we have a long experience building and delivering design systems, all of the things are very configurable, and that is things on the smallest level, like what format of the tokens building into, all the way to the granular level, like what assets are included inside of our MBM packages. So it's all very configurable, and any config that you would need to pass in, even to one of our renderers, like a custom web pack config, that's something that you can also add to your MPM packages, ship that out and then pull that into your production applications down the line.
Chris:
Awesome. So if you're an engineer that's then trying to consume a design system that's built on Knapsack, you already have this included in your repo. It already exists there.
Jake Love:
Exactly. Yep. Yep. That's how it comes.
Chris:
Cool, man. Hey, thanks for coming on.
Jake Love:
Absolutely. Thanks.
Chris:
Today, I'm here with Brittany Smart. Brittany, what do you do at Knapsack?
Brittany Smart:
So at Knapsack, I'm a solutions engineer, and I work with customers. I get them excited and up and running with Knapsack and answer any of the questions that happen along the way.
Chris:
So your hot take is about a customer conversation, and in this customer conversation, you were chatting with somebody that works at this big company. And what specifically were they trying to understand?
Brittany Smart:
So this particular customer, they're struggling with this huge problem that's not necessarily fallen on their shoulders, but they're the only one at the company that's really concerned about how they're going to provide consistency across all of their brands and products, especially since part of their company works in different countries. So there's that and the whole time zone thing, and it's like, how do we get everyone on the same page? So we started out the conversation, and he was a bit nervous to say the wrong thing. There's a right thing to say, which, of course, it all depends on situational and relative. But the more and more we talked, I felt like we were able to come to a solution that he felt comfortable with. And as we went on, I think just the fear started to dissipate, which made me feel really good because I could tell that he was getting the answers he was looking for, obviously, so that was good. And having someone there to hold your hand as you go through this process can be really daunting without someone there to lean on for expertise or guidance because it feels like there's a tidal wave coming at you.
Chris:
Totally. It's interesting. There's a lot of vulnerability with design systems, and the reason why there's so much vulnerability is because there's not a lot of prior art. This is still all pretty new, and so because this is all still pretty new, we're all figuring this out together. And I think that's one of the awesome things about your job and what you get to do, is you get to see those vulnerable parts of our customers because it's not really something you do in business when you're in charge of an initiative like a design system at a company, especially a global company with a big team. It's international, and you're trying to achieve these lofty goals that you maybe set not entirely knowing what you were getting yourself into. And now to say I don't actually know how we're going to get there, that's a scary moment if you're an executive or a manager or even an IC working on a design system because it's very hard to admit that either, hey, the plan that I thought and the expectations I had maybe aren't meeting up with the reality of what it takes to get this thing done, or secondly, I just fundamentally don't know what the right way forward is. And to say I don't know in a business context that is often really scary.
Brittany Smart:
Yeah. And anytime that happens, when a customer says they don't know, my immediate response is that that's okay. It's okay to not know. And together, we'll figure out the steps forward, and you can drop that fear and take control. Fear is just stalling you out, so unless you take those steps and make these hard decisions, you're never going to find out anything. That's how you move forward.
Chris:
So what are some of your strategies for this? Because obviously you took this complicated problem and this person that was having a moment where they were really struggling with some of their expectations, their decision making. How do you guide a customer through that faces that anxiety and that apprehension and is willing to open up to you about it?
Brittany Smart:
It's a fine line, and it's very personal place. And like you said, people are vulnerable. I definitely think, and this is something I learned from Andrew, that comedy is amazing. It totally disarms people, and I think it's a great way to just set the stage for a real conversation versus these fake conversations we usually have in the business world.
Chris:
What do you mean by that? So when you think about a fake conversation, does that mean people being overly guarded or not being transparent about what's really going on?
Brittany Smart:
Yeah, I guess my past experience, you go to a meeting, and there's a PowerPoint. And at the end, there's goals and bullet points, and everyone just had nods. And it's business as usual. There's not critical assessment of the real problems, and that's because the real problems are hard. It's harder to face, which is scarier, so it's easier just to go along with whatever's supposedly working at the time.
Chris:
And so in your job, you're oftentimes taking that person who's responsible for building that PowerPoint and sitting in that room with those people and really helping them address those very real and present problems for them because ultimately, people invest millions of dollars in these systems. And they have to have real outcomes, and the pathway is often really uncertain about how you get there.
Brittany Smart:
And it's like, what is it that we do that they feel comfortable placing their trust within our capabilities and within our product? And I think it's just being genuine and honest in the conversation and telling people we don't know sometimes the answer, but we'll find out. It's not something we're just going to leave people hanging, and we're supportive, which I think is rare these days, especially given working online more. I think it's harder to make that connection, but I just think that honesty and being vulnerable as well.
Chris:
So you're going on a journey with these customers, and you're trying to also provide them that sense of there's a broader community out there that you can connect to. And we're part of the same community together.
Brittany Smart:
Yeah. We're all struggling. We're all just paving the path and just learning together, which is scary but also awesome at the same time because being able to network with your peers and take their good ideas and fold that into what you're doing and sharing your ideas with that community and building that up is just something amazing to be part of.
Chris:
So what was the outcome? Did this person have a panic attack? Did they quit their job in disgust? Were all of a sudden everything rainbows and sparkles?
Brittany Smart:
It was actually rainbows and sparkles at the end. He was just super excited. I showed him things that our product can do as far as customization and things. He was just like, "That's awesome. I'm going to loop my boss back in," so it was amazing. I think he felt validated, but we were also very realistic as far as there's no perfect solution. So it's all about incremental steps and figuring out what value we can deliver that these customers will benefit from.
Chris:
Awesome. Well, I know I feel great knowing that our customers are in your hands, and I really appreciate you taking the time to have this wonderful, vulnerable, empathetic moment with me as well. So thanks for coming on.
Brittany Smart:
Thanks, Chris.
Chris:
Cheers. I'm here with my co-founder and dear your friend, Evan Lovely. Thanks for joining.
Evan Lovely:
Thanks for having me. Hello, everyone. Hope you're all having a good day.
Chris:
So this is a hot take about branding your design system or really customizing it to make it your own in some interesting way, even if it's ugly or horrible.
Evan Lovely:
Something like that. Yeah.
Chris:
Got you. So it turns out that people really care about the look and feel of their design system. And it makes sense because the system that houses your brand should probably look like it was made by your company and not made by a small startup that called their product Knapsack. And so in doing that, we have to enable lots of different people with lots of different opinions to change the way our core application looks, so talk a little bit about how that happens.
Evan Lovely:
Yeah. So our application showcases people's design systems, and shocker, the site that showcases a brand should be on brand. So there's no surprise that we had a lot of users requesting the ability to customize the look and feel of the Knapsack application since it was showcasing their brand, so being able to customize the colors, customize the typography was, of course, the things that we have just shipped for it. I feel like there's a lot of parallels for a design system as well because if you're making a design system that has a button that is type primary using the primary brand color and you want that button to get used in a lot of different brands, a lot of different brands have a different definition of primary. So being able to change it from a blue to an orange to a green in different scenarios is what we basically did for ourselves and what I know a lot of people who built in design systems need to do as well.
Chris:
Yeah. Even if you have a single product there's always core inverse for dark mode or high contrast mode or colorblind mode or any number of other things that you incorporate that are derivations of your brand that are maybe not the same as the original thing you built.
Evan Lovely:
Absolutely. And I think that everybody, when they first make design tokens, they learned that they shouldn't be using color blue in all of the places because eventually that changes. That's basically why you with design tokens go, hey, this is the blue, this is the green, and then we're going to say that color primary references another one of those tokens. So you're able to swap it out, so that way, when you have a button that uses color primary, you can vary what color primary is instead of having a button use color blue. And then color blue is now green because your button that has the primary background color, well, that changes if you're on light mode or dark mode. And I think that's basically the most famous themeing that most UIs see. And pretty much most everything has got a light mode in a dark mode anyway these days, so really, it's not that much different if you're using it in a lot of different brand sites because it's just a lot more than two of them.
Chris:
So back to how we did this in Knapsack, we're now in this place where you can change a lot about our app's core UI. And this is hard because we spend a lot of time and a lot of work and a lot of thoughtfulness in creating a UI that we feel like represents our app and our brand, and now it needs to be able to inherit and represent a customer's brand. How do you think about that problem?
Evan Lovely:
Well, it's about constraining choices at first. We had some people suggest, well, why don't you just let us add whatever CSS we want? And we're like, that's a bad idea because it would eventually change.
Chris:
Yeah. Why is that about idea? What can happen when you do that?
Evan Lovely:
Again, a design system is about constraining choices. So you could have fonts that are basically everywhere from size one up to, really, infinity, but think about it 150 pixel font size. You have 150 choices there. And so you're going to have a lot of fragmentation. It's going to look like crap. And so you use design tokens to define, hey, we have 12 point, 16 point, 18 point, 22, 32, yada, yada. It's about constraining choices, and so you don't want to let anybody add any CSS that is technically possible. You want to open up you can customize these couple things because then you have only so many spots that things can change because if there's an infinite amount of things that get changed, that's a lot of places for bugs to hide. And it also makes it really hard as the original authors to update it because, as we all know, it's a living, breathing thing that always gets updated.
Chris:
So your surface area is huge and it's also really complex, and so because of that size of service area and complexity, the reality is it limits our own ability to change our own app. And by constraining what you can change as a customer, it still affords a customer the flexibility to represent their brand, but it also allows us to actually stand a reasonable chance of updating our application at some point in the future, which we basically do every day.
Evan Lovely:
Absolutely. You want to stay nimble. You want to be able to move quickly and iterate quickly. And, of course, you don't want to break the preexisting things for anybody else. I think there's a lot of parallels to any people making design systems out there because you have people using your stuff in unexpected ways. And it can be delightful to see people using stuff in ways that you never dreamed possible, but it can also be equally horrifying to find out what's being done. And I think that it requires a little bit of letting go because it is really hard to prevent every single edge case.
Chris:
Yeah. And next thing you know, have white text on a white paisley background.
Evan Lovely:
Absolutely. We spend a lot of time talking about, should we throw an error there? How do we do color contrast checking there? And we believe that our users are smart, and what we do there is showcase them the results of their change right in front of them. And we believe that they would instantly see that white text on a white background is probably a bad idea, and then they would not hit the same button. So by showing them the results of what would happen as opposed to letting them do it and then eventually maybe they stumbled across it was basically the way that we worked around that a little bit. So in our area where you customize the theme, you can basically see all the ramifications there.
Chris:
So from a technology perspective, how is this possible? Are we implementing our own set of design tokens and then those design tokens are being buried? Are we just allowing people to change values in our apps somewhere in a UI? What does this actually look like?
Evan Lovely:
Yeah, it's all design tokens, of course. That's the thing that is awesome about it. And so a little bit more specifically, it's CSS variables, also known as CSS custom properties. And so that lets you change color primary on the fly to another value.
Chris:
So we've actually implemented design tokens inside our own app, and then by changing those token values, that's how you develop an app theme that can represent your brand.
Evan Lovely:
Exactly.
Chris:
Got you. And, of course, there's rules about how those design tokens interact with each other. And this is especially important in things like typography where it's way more complicated than it looks like it should be.
Evan Lovely:
Yep. Absolutely. And so you can think of it also like in Gmail, how there's cozy, compact and... What's the other one?
Chris:
Spacious or something like that.
Evan Lovely:
Spacious. Yeah. So it's like three sizes of how much breathing room it is. As a user, that's so much nicer to use as opposed to going and manually changing all of the margins and paddings and font sizes and things like that. So you have that as your input, and then that still lets the Gmail team basically know where it needs to get applied. Also, they've constrained the choices. They're like, okay, it's one of three sizes.
Chris:
Yeah. You can't do cozy plus two pixels.
Evan Lovely:
Yeah, exactly. Or 22 pixels or 12, whatever that even means. So the constraining of choices I think is key to letting people override your look and feel.
Chris:
Awesome, Evan. Well, hey, thanks for being on. Always a good pleasure chatting in front of a microphone with a beer, and yeah, looking forward to trying it out.
Evan Lovely:
Always good at being on the pod, Chris. Thank you.
Chris:
See you.
Chris:
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, @TheDSPod. We'd love to hear from you show ideas, recommendations, questions or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
