Building design system communities with Jehad Affoneh and Scott Mathis

The Design Systems 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.

Our guests

Jehad Affoneh is Chief Design Officer at Splunk. He’s an experienced design and business leader who writes frequently about user experience, leadership, management, and business. You can find Jehad at mynameisjehad.com, on Twitter as @jaffoneh, and on LinkedIn.

Scott Mathis is the Technical Lead, Clarity Design System Web Components at VMware. He has 10+ years of specialization in user experience and front-end development and co-founded a design system that is being used by thousands of developers across a half-dozen Fortune 500 companies. You can find Scott at github.com/mathisscott, on Twitter as @mathis_scott, and on LinkedIn.

The transcript

Chris Strahl:

Hey everyone, I'm here with Jehad Affoneh, the head of design at VMware, and Scott Mathis, who's the co founder of the Clarity Design System there. Welcome to the program, guys. Glad to have you on.

Jehad Affoneh:

Thanks for having us.

Scott Mathis:

Thanks a lot.

Chris Strahl:

So diving into this, when you were envisioning your guise design system, you call it Clarity, right.

Jehad Affoneh:

Yes.

Chris Strahl:

Yes. So when you were envisioning Clarity and the way that this design system was coming together, tell me a little bit about the genesis and origin story here. I know it's about three years old, it serves a bunch of different products, talk to me a little bit about what Clarity is.

Jehad Affoneh:

Yes, so Clarity started from the need of a specific product that both of us and a couple other people were working on, at the time was called [EVO:RAIL 00:01:03]. And the goal was to think about, how can we bring a bunch of different experiences from VMware together, and for a user to be able to go through these experiences successfully? And one of the first issues we faced is that these experiences don't even look and behave the same way. So we started building specific components and small visual patterns to bring that experience together within a single product. And as it grew, it was clear this problem is not specific to EVO:RAIL.

Chris Strahl:

So you guys were looking at solving the need for one particular product, and it had a lot of those little repeatable UI elements. And so, are these the traditional components that we think of, things like buttons, and cards, and that stuff?

Jehad Affoneh:

Yes, think about going through a workflow in a specific product, especially as we were trying to bring different experiences that were built by different teams in that product. But think about going that experience and realizing that step one has a different button style than step two. This is not even the biggest experience issue in that flow but hey, that's obviously terrible. And as we started bringing these things together, we realized this is a real problem that's not specific to that product, and we have the beginnings of a real solution that could be not specific to that product.

Chris Strahl:

Got you. So tell me a little bit then about that initial decision making. When you were sitting there looking at that first product and thinking, hey, you know what, this is actually a problem across this ecosystem, was it about the consistency, was it about the quality of the design, was it all of the above? What were some of the reasons why you were really looking at a more systems based approach to these things?

Jehad Affoneh:

It's really all the above. So it is consistency, it is quality. Consistency was a huge deal. VMware is a big company with a lot of different products coming from a lot of different teams. A lot of them are designed for the same personas that end up using these products together for similar use cases, and cohesiveness more than consistency really matters a lot. So how we ship a cohesive experience matters a lot. And visual cohesiveness is the first step in both making those cohesive experiences, but also, it's the first step of removing the visual element of inconsistency so we can find what's underneath.

Chris Strahl:

Got you. So this genesis led you to ultimately having a design system that works for hundreds of products across the whole corporate ecosystem. Talk to me a little bit about what it looks like now. So from humble beginnings, where did everything end up?

Jehad Affoneh:

So today we have a dedicated design systems team. We have over 100 different projects, and products, and services within VMware that use Clarity in addition to dozens external companies that use Clarity as well, since Clarity is open source. So what was a specific solution to a specific problem became a design system that's used by thousands of engineers and designers within and outside of VMware.

Chris Strahl:

So as a part of this early conversation you had said something that I thought was a little bit, I guess, spicy in terms of a take and that is, when you have this tool that you've built, that is open source, that is serving a broad constituency, one of the big things that you were focused on is not building it from scratch. So tell me a little bit more about that thinking around, why wouldn't you basically say, let me build my custom design system for VMware? What did you use as a basis and why did you choose it?

Jehad Affoneh:

We usually say, in the Clarity team, that basically, we really tried not to build Clarity as it stands today, or we really tried to not build Clarity from scratch the way we did it. And we looked around and we tried to figure out, what can we use or reuse to do this? A lot of what's in the design system is very hard engineering problems, systems problems that need to be solved for so many people and so many teams in so many different environments. Some of these problems have been solved and resolved now. So it's really about, how much do you want to face these problems independently so you have the label of an independent system from scratch? Versus how much is it about the reason you're building the design system, which is making these products successful, bringing consistency to visual design, and so on, so forth. I think Scott might have a couple thoughts on this especially since he's been in the trenches throughout.

Scott Mathis:

Sure, yes. So in the early days, not building it from scratch, there was a lot about adoption, right. So introducing something that was completely unknown to people and completely unfamiliar, was going to negatively impact how quickly we can be adopted across the company. So we stuck with some tried and true formats there. As we've moved towards framework independence, we find ourselves actually building a lot of things from scratch. But that's because the Web Component Landscape is still forming, so are solving a lot of problems that nobody has solved yet. So, I think that's the line in the sand, are you solving something that no one has solved yet? Versus, are you just reinventing the wheel just to do it?

Chris Strahl:

Yes, I mean, we like to pick on the button in this show, and so if you think about a solved problem, buttons are pretty solved problem in the world. And so it might be worthwhile to just grab somebody else's button and use that as the basis for your design system. Whereas something that is some function based design token system or something like that, or adaptive color palettes or something, might be an area of exploration that there isn't a lot of precedent for, and there isn't a lot of solutions out there, and that might be something that you want to build.

Scott Mathis:

Absolutely, yes.

Chris Strahl:

So when you think about that decision to make Clarity open source, what really drove some of that decision making and how has that led to benefits, either from the ability to access Clarity, the ability to contribute to it? What are some of the dividends that, that's paid for you guys?

Jehad Affoneh:

Yes, so the decision to open source Clarity was driven by a couple of different things. One was our ability to ensure Clarity remains independent. In a large company, the pull and push of different forces that influence a platform, especially an internal platform, make it difficult to remain truly independent versus listening to the top product, or the top product that adopts your platform first, or all of these different forces on a platform in the company. Having it open source allows us to say, Clarity is an open source project, Clarity has its open source backlog and community, and whether you're inside or outside of VMware, you're consuming it the same way. This enabled us to truly spend the time in building a platform versus necessarily being too reactive in how we sponsor or support specific products. There are good reasons obviously to doing this anyway, participating in the community that we use a lot was a big deal for us. So being true open source citizens matters a lot. But the independence was a really big deal.

Chris Strahl:

Interesting. So thinking about how you pitch something like that of, okay, so I have this really awesome project, it serves a whole lot of products inside the company or maybe at the time it only served a handful. I want to make this an open source project and I want my job at VMware to largely be building, curating, managing, upgrading this open source community. Give me a perspective on what that looked like when you were having that conversation with your boss or other people at the company that we're setting up this whole system?

Jehad Affoneh:

Yes, I think the interesting thing is when we open-sourced Clarity, I think we were six months or less than 12 months, which meant that it wasn't as popular, even internally, as it is today. That's a good thing in retrospect because it enabled us to say, there is this small project that we're working on, there is really no IP in it, there's a lot of engineering work but there is really no VMware IP in it. So we'd like to put it out there and build a community around it. That's a good story. I think it would have been a different way to think about if we open source Clarity today, like if Clarity wasn't open sourced today. So having it be small yet there's something there, something that that can benefit the community, that we can put VMware's name on, was a good story that we were able to sell pretty quickly actually.

Scott Mathis:

We were also able to build a business case around open sourcing it because a lot of our products have partners, third party vendors and whatnot, that build plugins for our applications. And to have a coherent and cohesive design that was shared between our products and our third party vendors and partners, gave us a pretty strong business rationale for doing it, which I think helped as well as being small and slightly under the radar at that point in time.

Chris Strahl:

Got you. So you could be this organization that was small, scrappy, nascent, and you already had a built in ecosystem because you already had a bunch of partners of the business that were looking for a solution like this.

Jehad Affoneh:

Yes, exactly. And I think that's a really good point. I think the partner angle gave it a very good business case for the business irrespective of Clarity's view of the world, Clarity independently as a team or as a design system.

Chris Strahl:

So when you were thinking about that business case, what kind of ROI were you pitching there? Were you talking about things like accessibility, were you talking about things like speed of development, we're talking about things like consistency, and really, what did you put forward as the main value that you guys were delivering with Clarity?

Jehad Affoneh:

I think the two values that we still talk about internally, which have not really changed since the beginning, one is the consistency and cohesiveness we can drive for the end user. So if you think of user experience of VMware, four or five years ago versus today, there is a huge difference in looking at a product or a UI, understanding it's coming from VMware and actually being able to use the different products the same way. The other one is the internal view of Clarity, which is, we are helping the company do something once and use it 100 different times. The ROI on this internally alone, even if we take out the external piece, is huge. We did not talk about accessibility at the time, although that might be a really good topic to talk about how we're bringing Clarity and accessibility together.

Chris Strahl:

Yes. And so, what would you say is that key metric that gets looked at when you or other people inside of the company are sitting there evaluating the success of Clarity? Is it about that speed of innovation, that ability to basically say, hey, we captured some product innovation wants and now we get it in 100 different products for a very low cost? Is it about the speed? Is it about that consistency? And how did you really measure those in more concrete terms?

Jehad Affoneh:

Yes, I think internally, one of the things that we talk about is how we enable other teams to innovate by focusing their time on their users and their use cases versus focusing on time and building and rebuilding components. So how do we get teams to simply move from, I need to build a product so I have the whole beginnings of a UI ready within minutes, versus I have to start from scratch? And then while I build the product I worry about, what's the best user experience for my customer? Not how do I design a button or how do I build the onboarding experience? All of these things are ready for you to go. The way I think about it is, it's probably a lot of fun to design Lego pieces, but it's a lot more fun to design the Star Wars kit. And it's that what teams want to do versus redesigning, and re-implementing, and rebuilding each Lego piece independently.

Chris Strahl:

I for one cannot wait until I can start playing with Legos with my son and building like a millennium falcon or something like that.

Jehad Affoneh:

That would be awesome. Yes.

Chris Strahl:

So when you think about that macro problem that you touched on there of your all about enabling all of these different product teams with a core kit that they then go make their X wing, or their Death star, or whatever with. When you look at that, that ability to upgrade, maintain, curate, manage, give new tools and new building blocks to these constituents, how do you view that problem and how has that taken shape as the system's matured?

Scott Mathis:

That's a great question. I see why Jehad wanted me to answer that one. All right. Upgrading is frankly a harder problem for us to solve than adoption. Adoption is largely grassroots and organic, which is fantastic. But product teams, consumers of the design system generally want to build their thing and they never want to think or touch the design system ever again. But when you've built it on top of a framework, like we did with Angular initially, they have to, because Angular is introducing breaking changes into that dependency tree there, and you wind up upgrading Angular and needing to upgrade Clarity, or wanting to upgrade Clarity with the new components or new designs and whatnot, and also having to upgrade Angular. So that was one of several reasons and rationales behind our move to become framework independent. To go to a world where the atomic pieces of the Legos that are inside the design system can be upgraded fairly quickly, fairly easily. If you were breaking changes, less dependency on factors outside of the design system, I guess the best way to put it.

Chris Strahl:

Yes, I think that this is, I guess, the best way to put it is a problem that doesn't get quite enough attention. I think that because most design systems are somewhere between one and five years old, with I'd say the average being probably about two years, people haven't really gone through a lot of framework changes. There's been sure upgrades in Angular versions, or React versions, or whatever, but React isn't going to be around forever, Angular isn't going to be around forever, so what's next? And how do people start to plan that transition into something like web components or whatever next JavaScript framework becomes the hot thing, right? So you guys have taken a pretty smart approach to that with this framework agnosticism, tell me a little bit more about how you've done that and how you're thinking about things like building web components into your system.

Scott Mathis:

Yes, so the Web Component library, well it just made a lot of sense. It was driven by a business need initially because we were acquiring a lot of companies. And many of those companies coming in we're using React and our Design System Components, our library, was written in Angular. That puts some pressure on us to consider, how are we going to support these React teams? How are we going to bring that design coherence and consistency across the framework layer? And the more we thought about it, and the more we investigated it, we saw that it made more sense to get the design system out of the framework conversation entirely. Even now, Svelte is becoming very popular and it's had probably the biggest jump since view. So teams that are acquired that use Svelte, what are they going to do? So getting out of that framework conversation was really helpful. And it goes back to how to water faucet analogy, where you talk about the water not working and whatnot. Well, if you build your design system on top of a framework, you're basically putting your water pipes on your kitchen floor, right. So if you want to tile your kitchen floor or change the tile in your kitchen floor, you got to pull up all your water piping. There was this inversion of layers there that the framework independence really helped with.

Chris Strahl:

Jehad, why don't you explain the water faucet analogy real quick, because I love this, it's a great way of thinking about how people view a design system when they're in a downstream product team.

Jehad Affoneh:

If anybody listening works on a platform team, it's probably true not just for the design systems team, but any platform team or operations teams too actually. And the example we always share internally is, nobody walks home, opens their water faucet, and then admires the amount of work it takes to take water, purify it, make sure it's actually ready to drink, running through pipes that go for miles across a city or a town, get it to your water faucet immediately, possibly even heated if you wanted to, and then you grab a cup of water and walk away. Most people open the faucet, use it, and move on. The only time you care about the water faucet is when it doesn't work. Is when you open it and nothing comes out, or dirty water comes out, or whatever it is that you need to worry about. But even when that happens, you're frustrated because something that you take for granted didn't work, versus you're thinking about all of the challenges that could have happened in the piping and systems put together to make it happen. I see design systems the same way. If you work on a product team, a design system either works, and of course it does or it doesn't and we have a problem. And that's the relationship you need to figure out how to deal with especially as you do upgrades or change management.

Chris Strahl:

That's a great way of thinking about it. The idea of infrastructure, plumbing, all of these are such common analogies, but I love the visual idea of walking into my kitchen and flipping on the faucet, and having nothing happen. And just that shock and amazement in that moment. And maybe you wiggle the handle a couple of times and eventually you give up and walk away in disgust. I love that idea because I've definitely watched that play out at a product level inside of companies before.

Jehad Affoneh:

I don't even know who to call if that happens. I know when power goes out because that sometimes happens. But if the water doesn't come out, I'll have to go Google, who runs water in my city, to make it happen. So it's that level of expectation of consistency, which by the way, means it's really good infrastructure. But it also means when it breaks, it breaks.

Chris Strahl:

I got a touchless water faucet for my kitchen sink, and it's wonderful to watch how confused my friends are when they go to wash their hands and move the tap and nothing happens. And I'm like, hey, you have to wave your hand under it. And then they get it, and there's this realization that there's this new technology and new way of thinking things so they don't have to expose themselves to COVID or whatever that's hanging out on my faucet tap, you can just wave your hand. But it's interesting to see that learning that has to take place to even use something as simple as turning on the tap.

Jehad Affoneh:

By the way, that might be a really good analogy to carry on and change management of the visual design and design systems, which is also a challenge in addition to just the technical changes. One of the things we struggle with thinking about is, how do we not make Clarity the reason for inconsistency?

Chris Strahl:

Mm-hmm (affirmative).

Jehad Affoneh:

So if we change the style of a button tomorrow, different teams will upgrade at different cycles, possibly up to 12 months not upgrading. How do we not make it to where Clarity is the reason we have inconsistency between products that Clarity made consistent just a few years ago?

Chris Strahl:

Right, you have your own upstream problem because you're in so many different products.

Jehad Affoneh:

Exactly, yes.

Chris Strahl:

So when you think about that model, and getting back to Scott's comment earlier about tile floors and pipes on top of them, you guys have a pretty established maturity model for the way that you think about the actual content that goes into Clarity, where there's this component, pattern, platform sequence that you guys have thought about. Can you talk to me a little bit more about that and how that might relate to this water in your home metaphor we're running with?

Jehad Affoneh:

Yes, all I can imagine is water pipes on top of the floor right now, so thanks Scott.

Chris Strahl:

I also just remodeled my kitchen, half the world did in COVID. So you're hitting home with those, Scott.

Jehad Affoneh:

Yes. I think the thinking on the maturity model was that, really it's a combination of, how can we drive adoption and what matters most? When you look at visual consistency of products and services that VMware publishes, 80% of the visual consistency is really in four or five components. If you get the fonts, the colors, the header, the buttons, the input fields the same way, you look similar. I can tell this is coming from VMware, especially if it's unique enough color wise or font wise to recognize it.

Jehad Affoneh:

So starting with components made a lot of sense because it allowed us to move the needle on what we wanted at the time, which is visual consistency. From there, you just have to continue to complete the set of critical components, especially difficult ones like data grid, that you have to ship and make happen. Once you have these sets of components, you can then start thinking about, okay, we need to build patterns that will use these components, one or more of these components together, and put these patterns together in ways that are usable on day one. And from there, obviously, you can build a UI platform that can build micro front ends or whatever the direction you want to go.

Chris Strahl:

When we think about that maturity model, one of the things that stands out to me is right now, so much of the focus in design systems is around components. Let me build up a component library, let me get those baseline pieces of the UI out there, that like you said, I can recognize immediately as being a part of my product ecosystem. I think where people are a little less familiar is when you start to think about things in terms of patterns. And then ultimately, I think that very few people are thinking about a UI platform. Help bring us all in on this. So when I'm thinking about a component library, and the buttons, and the headers, and the cards, and the form fields and everything like that, that's in there, when you talk about constructing those into a pattern, what are you really talking about there?

Jehad Affoneh:

Yes, I think the thing that might help in the mental model of how this works is a lot of the time design systems starts in a company that's trying to say, we're building different products in different teams, and after we build them, we're going to make a solution out of them that connects these products together, and now we have a solution. When you think the other way around, when you think actually we're going to think in terms of solutions, into end solutions, and then break them down into executable chunks that different teams are going to pick up, the whole concept of what you're building is different. It sounds very simple, we're building simple products and putting them into solutions, solutions into different sets of pieces. But the reality is, if you're starting with a solution, you have to build certain sets of patterns and experiences that are consistent for that solution to work, and then you have to figure out, how do I break them in a way when two teams are working on these solution, they're not building these two parents differently?

Chris Strahl:

Right.

Jehad Affoneh:

It's a mental shift in the mental model of this, which brings with it, do I give that team the chance to use a bunch of components and put them together, or am I going to give them a pattern, so at the end of the day when we go back to the solution, we have these patterns work together?

Chris Strahl:

Yes, I think that's great. And so a concrete example of a pattern for you guys, what does that look like?

Jehad Affoneh:

A good example would be onboarding. If you're onboarding to VMware service, there are certain sets of things that you need, and ways you can configure these things. And even though onboarding will use a stack view, possibly buttons, possibly a progress bar at the top to tell you where ... so different types of components, you can put these together in many, many different ways that for a user, not only would they look different in terms of visually different, they would actually be confusing, especially if I'm onboarding in two different services back to back. So building onboarding as a pattern becomes essential if we're going to say, hey, we have a cohesive set of services as VMware as a company, and if you learn how to use it once, you've learned how to use it forever. It's the faucet thing. All facets should operate the same way, if it's in the same house, otherwise I don't know, is this touch or I'm going to have to open it or is it both?

Chris Strahl:

Right. No, I love it. I also really like the idea of moving beyond the idea of components, right, because one of the hard parts that people have conceptually with design systems is, like you said, there's no solution innately there, right. Great, I can see a button, or I can see a car, or I can see a hero, or a carousel, or something like that, but innately that's not providing any direct user value because people don't consume those components in isolation, they consume those collections of components. And oftentimes, those collections of components attach to a state, or a sequence, or something else that is a part of actually delivering that solution in user land. And I think your guise idea of, how do I focus on that solution set and build patterns around that? Is a really powerful way of thinking about a practical way for components to be valuable to users. Now when I think about that next step into this UI platform side of things, this is where things get really fun and crazy. And this brings together a whole bunch of ideas around design tokens and the way that they interact with patterns, and the way that these all come together to really build applications, for lack of a better word, but really more of a service design for a design system. So I really love your guise take on this. Go ahead and just explain that, in your own words, how you go from a pattern to a UI platform.

Jehad Affoneh:

So I can start to with the UI platform piece but I think Scott has a lot of interesting stuff to share about how we think of design tokens and web components as a framework independent way to get there. I think the UI platform, I would quickly say, we're heading towards a world where really the focus is into an experiences of what the user wants to do versus where we had, at least in enterprise software, where we had different sets of products that you stitch together as a user. To get to that world, you're really building experiences that should be possible to use and reuse in different ways, depending on the vertical, are we selling it to healthcare or government? Depending on the product. You need to configure networking before you start the cloud environment, but one is built by the network team, one by the cloud team. There are all of these matrix of things we can put together, the question a UI platform needs to answer, and we haven't really cracked it, but how do you build these things as experiences, and then still be able to put them together as workflows without having to always start at button, carousel, Stack View, whatever it is, versus starting at, I need onboarding, then I need network configuration, then I need something else? That's a really difficult problem to do. And Scott can share a little bit of our thinking on how we're building the infrastructure through design tokens, framework independence, and all these things that are going to allow us to bring these UIs together.

Chris Strahl:

No, and this is where I get really excited too, because I fundamentally believe that this is where this is all headed, right. If we stop the components, we're only really realizing maybe 5-10% of what we really could be doing with these systems based approaches. So I love this concept of it's not just about delivering components, it's not just about delivering stitching together components, it's collections or more robust components. It's about actually these huge hunks of user value that ultimately is represented in some action that they would take inside of a product.

Scott Mathis:

Yes. And in terms of how we built this all up, a good conceptual model for me, that I've returned to, the idea of atomic design. You have the atoms, which are almost all entirely in the design system. You have the molecules, most of which are in the design system. You have the organisms, which are these patterns which can be both micro and macro, especially when you start talking about web components, and web components can be infinitely big, right. You can have web components with web components and web components. And your entire UI can be just a single web component if you want. And with a little bit of massaging and React, it'll work in all frameworks no matter what the product team chooses to use.

Scott Mathis:

And that's one of the directions that the framework independence has led us towards. It makes it easier for us to embrace this atomic design principle. But it also highlights community, right. So if you're in the open source, it's your community. But even if you're not open source, as a design system, you're going to wind up in the community anyway. So the design system community, those are the people that are going to be building these larger patterns because no design system team is big enough to build all the patterns that a product is going to need.

Chris Strahl:

Right. There's almost too much that you could build in these systems. So it's a lot more about deciding what to build. And then also, back to your point around not starting from scratch every time, what can you go borrow, right? I think that probably the login experience is one of those things that's probably been done a few million times. And so maybe there's a way that you could grab a login experience pattern from elsewhere that means you wouldn't have to build it yourself.

Scott Mathis:

True. And that contribution, even in a closed system, not in open source design system, that contribution may come from outside the design system team, to be honest. That's why it's important to be able to groom a community within your company, so that way you can all trust each other's judgment, and you're all innately on the same page. We're most of the way there. I wouldn't say we're 100% there, but that's, I think, part of the real work of a design system that a lot of people don't consider.

Chris Strahl:

Yes. And I think a lot of these concepts are still pretty new, right. There's a lot of greenfield here to decide what this approach really looks like. I don't think that there's a system that I'm aware of any way today that is fully based around micro front ends or these really pattern based approaches. I think that people are trying to build that and are working really hard towards it. And it's honestly something that we're really working very hard on at Knapsack as well is to try to figure out what these actual constructs look like. It's pretty easy to say, there's this piece of UI, there's this bit of design, this bit of code, you link those things together with some documentation in a common workspace and you have a component. It's a lot harder to say, what does a login pattern look like inside of a system or inside of a tool? I think we're all stampeding in the same direction and I'm very excited for when we start to see these things in practice in a lot of different places.

Jehad Affoneh:

And I think a lot of these patterns test every part of the system. It tests the technical ability to build these experiences and patterns together, it tests the visual design abilities to predict how these things that are going to look in different environments, and it also tests your change management as it relates to how teams work together. Who builds a login experience? Is it the design systems team? Is it most important product in the company? Even onboarding, who builds onboarding? Or more interestingly, who builds the configuration settings experience? So there are all of these questions around who builds what that start to get really interesting. And most of these are questions you actually don't have to ask with components. Components are built by the design system, the product is built by the product team, done, it's easy. With patterns it's, who builds what piece of what pattern? Who maintains it? Who keeps it moving when the design systems change? It gets a lot more interesting, which means a lot more opportunities.

Chris Strahl:

Yes, and this appending to the way that we think about building our apps today, I think that's what I'm most excited for is, for a long time, when I've been building applications to the web, I've always wondered at the bespoke nature of the way that we build product. And that's just an innate thing that has existed out of necessity, less than intention. And I think the thing that I'm most excited about with these pattern based approaches, is being able to zero in on the intention of how we build these applications, to base it in research, to base it in accessibility, to base it in a set of best practices for what that ideal onboarding experience should be, and then to be able to share that very broadly across an ecosystem of applications to ultimately the benefit of users. So shifting gears for a quick second, I mentioned design tokens a minute ago. I know you guys have been thinking really hard on this topic and we actually just spent a lot of time ourselves getting together a group of industry experts to specifically discuss this. I'd love to hear you guys take on how you're using tokens to help manage things either at the component level or the pattern level inside of your system.

Scott Mathis:

So the design tokens are a glue between the component and the pattern level, right? So, going back to the atomic design, you have the atoms, molecules, organisms, blah, blah, blah. There's actually a layer smaller than an atom, you can call it a particle layer, or a cork layer, whatever you want to call it, and that's where design tokens live.

Chris Strahl:

Schrodinger's token.

Scott Mathis:

Schrodinger's token, yes. Does it exist? Only if you look. Anyway, I'm not going to nerd out. So our design tokens are a shared almost design language. So you hear people talk about design language and it's, this is how big our borders are, and these are the colors that for a hover state or whatnot. And really the design tokens are the implementation of that information into something that's consumable outside of the design system team. The design tokens, they ensure that no matter what people are building, if they use the tokens, it's going to look consistent. The coherence is going to be built in, which is pretty huge.

Scott Mathis:

And it also, for us, I don't know about others, but our design tokens are platform agnostic. So we have teams that build Android apps, and we have teams that build iOS apps, and largely we've been a web focused design system. But now people can take those tokens and import them into their Android build and or import them into their swift code, and they can use them, the very foundational pieces of our design system, to create their own apps, so now we have coherence across platforms. So design tokens are pretty exciting. And I think they're a really big piece in having like an unspoken agreement between all levels of the community.

Chris Strahl:

Yes, absolutely. I love the innate portability of design tokens. And I also like the idea of beginning to broaden their adoption as the common thing, right. The first thing that you think about when you think about adopting a design system should be around that token set, because that primes everything else that follows.

Scott Mathis:

Absolutely. And changes at the token level cascade out across everything really, and that makes it really easy to try new changes, try new looks. If we wanted to make all of our buttons bright orange, it's a few lines of code, whereas before, it would be a whole lot more effort digging into the CSS and SAS variables and such.

Chris Strahl:

Awesome. Well, I've really enjoyed having this opportunity to talk with you all. It's been great to hear about the way you've set up Clarity, the way you think about the maturity models of design systems, and even touching on design tokens a little bit. We always like to end these shows with you talking about how design systems and systems thinking has invaded your personal life. So I'd love to hear, what's ended up becoming a design or systems based practice in your day to day life as a result of your work on Clarity?

Jehad Affoneh:

Still thinking about that one.

Scott Mathis:

I could throw one out there to give Jehad time to think mostly.

Jehad Affoneh:

Thank you.

Scott Mathis:

You're welcome. So, I make music for fun and not all of it's great, but it's something. And it was actually all the exploration into design tokens and stuff just got me thinking about music, and frequencies, and tone in terms of the same way a designer would look at colors and in a design token, like a color palette almost, which is kind of cool. I'm not original in that thinking at all. There are other people who probably thought this before and probably have much better approaches to it but it was interesting in taking something that I'd always acquainted with my ears and applying this design token approach to building instrumentation arrangements and all of that.

Chris Strahl:

Definitely. I played classical piano for like 10 years back in high school and everything like that. And I haven't played in a very long time but thinking about music, and music theory, and notation, and everything like that, it has a funny way of bubbling to the top of my mind whenever I'm thinking about designing or architecting the design system.

Jehad Affoneh:

I still don't have one. Actually the only thing I can think of is when the pandemic started, when COVID started and we were all working from home, I got a little bit into video editing and stop motion videos just as a way to think about passing time, which was a lot of fun. And a lot of video editing is about, or in my very short experience, a lot of video editing is about transitions and small fillers that go between different pieces of the video that most of the time are pretty similar. Like the clouds moving fast or move from a black surface to a black surface, so you're able to transition. And I started, whenever I see something, when I go on a walk or something, to take a video to think of it as a small piece of the set of components I have to put these fillers between the different videos. Now I think about all the scenes I see as I walk differently. I think of it as, is this part of the library or not or should this be part of the library or not?

Chris Strahl:

That's awesome. I love that you both pick things that were related to content. I think that it's so interesting to think about the content aspect of design systems and how these are containers for content, that's what we're designing. And these viewpoints that we all take towards the content that we're creating, be that video or be that music, thinking about the structure for how that content fits into the system is really cool daily application to the way that we think about this stuff. Well, awesome. I really appreciate you guys being on the podcast. It's been awesome to get to know you a little bit. Great to chat. We're going to put in the show notes a way that you can all check out Clarity. And I look forward to talking to you guys again soon.

Jehad Affoneh:

Same. Thanks so much for having us. This was fun.

Scott Mathis:

Yes, thank you for having us.

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 @TheDSPod. We'd love to hear from you with show ideas, recommendations, questions or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud.