Season 3, Ep. 5 – Why design systems are important, with Michael Carrick, XDS

(THE FRONTIER THEME MUSIC PLAYS)

Faith (00:05):

I hear you’re based in Canada. Are you in Toronto, or are you just a Toronto Blue Jays fan?

Michael (00:10):

I am outside of Toronto, about two and a half hours.

Faith (00:13):

I grew up in Buffalo, so I spent a lot of time schlepping back and forth to the Toronto airport, ‘cause it’s just way easier to fly international out of there. So lots of time stuck in traffic on the Peace Bridge <laugh>.

Michael (00:28):

<Laugh>. It can take quite a while, that’s for sure.

Faith (00:30):

Yeah. Is that snow behind you?

Michael (00:32):

A little bit, yeah.

Faith (00:35):

Okay. Just a dusting.

Michael (00:35):

Yeah, about a foot and a half, maybe, so not too bad. Nothing in comparison to like, Buffalo or anything like that.

Faith (00:43):

Yeah. Yeah. I was home for Christmas, and we just got pounded. I know, I’m in Nashville now, and it’s funny when you say a little bit, foot and a half. In Nashville, a foot and a half would be a state of emergency. We got a, we had like, a dusting last week, and schools were closed for three days.

Michael (01:04):

I bet.

Faith (01:04):

I know. In their defense, we don’t have any salt trucks or infrastructure to deal with it, but it’s still, it’s always funny for the <laugh> northerner to live through that.

Michael (01:15):

<Laugh>. I was on a cruise with a guy who sells cars, and we probably spent about 45 minutes of me explaining winter tires and how important winter tires are <laugh>.

Faith (01:24):

And how you need to swap ’em out, change ’em in the summer, because they’re more expensive. So if you’re not driving on ’em all year, they’ll last you longer.

Michael (01:32):

Absolutely. But yeah, I laughed. I think Texas had snow like, three months after that, and I was like, I betcha he knows what snow tires are now <laugh>.

Faith (01:42):

<Laugh>. Mike, I’m so excited to meet you. I feel like I’ve heard all about you from everyone else on the team who’s been able to work with XDS, so this is really exciting for me. Also, welcome to the Frontier podcast. (Michael: <Laugh>.) This is our, pretty much my excuse to just talk to folks all day instead of writing Google ads, so it’s a nice respite <laugh>.

Michael (02:02):

No, I think it’s fantastic. Yeah.

Faith (02:03):

Awesome.

Michael (02:05):

No, happy to be here.

Faith (02:05):

Well, we’re gonna talk about design systems today, obviously, because that’s what XDS is all about. But let’s kick off with just a quick intro. If you wanna introduce yourself for folks listening, what do you do? What’s your role at XDS? Maybe a little bit about XDS to prime us, and then we’ll jump right into it.

Michael (02:24):

So, Michael Carrick, I’m co-founder of XDS. So my experience is working in large companies, building design teams, design processes operations. And one of the things we learned by going through that was, in evolving designers from at the point they were pixel pushers to strategic partners, it took us about six to seven years to do that. And one of the cruxes in doing that was a design system, because there was so much work being held up by making sure that all the buttons are the right color, and the corner radiuses were consistent. And then, in realizing a design system, the team was able to evolve. They were able to do more UX work, provide more value to people, and we saw that came from, really, the institution of a design system. So, started XDS in hopes to help other companies build their design systems faster, whether that’s using our platform or doing consultation work, but basically getting them up and running, so that designers and developers can do higher value work than building buttons.

Faith (03:24):

That’s a really good tagline. Did you come up with that <laugh>?

Michael (03:28):

Probably not. But it is our “why.” Like, when people are like, “Why are you doing this?” I’m like, “‘Cause you should not be making buttons, unless you have the best button, and you can make a better button.”

Faith (03:36):

Yeah, exactly.

Michael (03:37):

It’s just not the most valuable work for designers or front end developers, to be honest. So letting them focus on solving problems and enabling business partners, that’s really what we’re here to do. So we take care of the grunt work.

Faith (03:49):

Well, let’s start with the basics for folks listening who are not in the design world or in the front end development world. Just real basic. What’s a design system?

Michael (03:58):

The best definition I can come up with, and I’ve seen it used a couple times, is Lego. (Faith: That’s good.) It’s really digital Lego blocks that help executives, kind of, understand. So you’re pre-building Lego blocks, you’re pre-theming them. So if you look at the variety of themes that Lego has, you’re theming a bunch of Lego pieces, and curating them, and maybe building a couple of custom pieces. But from there, they can build anything. They can build cars, and houses, and all sorts of wonderful things, but it all follows the same theme, the same ideas, the same principles. So it all looks like it’s part of a family. So a design system is really pre-built Lego blocks and the documentation you get with Lego is really the documentation with design system: how to build it, why to build it, and yeah, help teams to run a lot faster.

Faith (04:41):

Yeah, so we work with a lot of startups, right? And, I think, for folks who are, kind of, building from the ground up, the thought of implementing a design system is very far off of their radar, because they’re like, okay, what’s the minimum viable thing that I can do today, (Michael: Yeah.) you know, so we look, at least, somewhat legit? And oh, I’ll just bring in a designer to do this, like one-off thing, and that’ll be that. What are your thoughts for folks kind of in those early stages around starting with a design system early? What’s the value of starting early, rather than circling back a few years down the line and trying to rebuild everything?

Michael (05:23):

Well, I think you’ve gotta look at it as a phased approach. There’s lots of levels of design systems, and certain levels make sense at certain times. So you may say, you know, we’ll start with a UI kit version of a design system, so that’s designers creating common components that are gonna be used throughout the design. So I always tell, you know, startups and stuff, look at your brand, start building out common components, and it could just be a button, it could be an input field, it could be a card. But by building those common components, other designers can reuse them over and over again, and that way, when you do pivot your brand, as startups often have to do, you know, know they might join and have a venture project that they might have to pivot their overall look and feel, because they’ve evolved or they’re looking to be purchased.

Michael (06:04):

So having that control at a granular label…level, sorry…to be able to make those changes, easily, is kind of key. So I look at it as saying, look, start with what you can. If it’s just a UI kit, great. If you can add some documentation so that designers or freelancers that you hire after that can review it and say, “Oh, this is how they use their color. This is how they use their typography. This is when I should use this button and not that button.” So a little bit of documentation is really letting future designers or future developers on the code side to pick up from where you’re left off, which heavily reduces onboarding and really helps you pivot a lot as a company. ‘Cause you may say, “Hey, we’re in a huge push. We need 50 more developers and five more designers,” and then you might pull back a little bit. But making sure that everybody’s contributing to this kind of core center of truth helps that truth evolve over time, and then anyone who comes in afterwards has a starting point and they’re not just, again, building another button that’s going to create a divergent experience.

Faith (06:59):

Right. To me, it feels like good hygiene in the same way that when we build back ends, we need to have the right practices in place so that folks who come in after us aren’t having to start from zero. Right? It’s the same with anything. So…

Michael (07:19):

It’s just building that up over time, and you can choose. There’s lots of open source versions of design libraries that you can use, and coded libraries you can use, and that might be the best starting point for some companies. I think, when you look at the design side of things, it’s really understanding your scale. Like, how big is this product going to be? Where should you really start? Where’s your brand at? And just creating that library, and I think, you know, considering things like light and dark mode. (Faith: Right.) Are you going to need to enable those things? Well, that’s color tokens. How do you build out a color token architecture that supports multiple modes? If you are really strong in accessibility, you might have a high contrast mode. If you are one of those white label SaaS products, you might want to be able to say, “Okay, wow. How do we theme ourselves to look like our other partners? And how do we make our colors change, so that we can look like our partners’ products to make a more seamless client experience on their side?” So just asking a lot of those fundamental questions to say, “Well, how big should this be, and therefore, how valuable is it?” And that kind of gives you an idea of whether you should grab something quick and easy off the shelf, or whether you need to spend some time really building out a foundation to grow on.

Faith (08:23):

So for somebody who’s kind of weighing the options of, okay, do I just do something off the shelf, because we have all kinds of choices now for out-of-the-box design systems, or do I start with something custom? How would you guide them through that decision? How, do you know that it’s right to do custom rather than out-of-the-box?

Michael (08:43):

It depends on some strong fundamentals, in terms of looking at the open source one. So build an Excel sheet, look at all of your libraries out there, do some comparisons on performance, on scale, on the features and functions available directly in the components. Maybe interview those free libraries to see, hey, is there anybody working on this, doing active contributions? Look through some of the code, if you are, to say, okay, how often is this code being updated? Build something small on it, little prototype, do some testing on it, you know, make sure it’s fully responsive, make sure that it’s meeting performance requirements, make sure that it’s accessible. Look for documentation. Like there’s some basic criteria that you’d want to evaluate, free versions out there, before making a choice. And then you’re making an educated choice. We use this because of these reasons, and then kind of move forward from there.

Michael (09:29):

Challenges you can run into down the road, if you start with an open source platform, you might not have the level of support that you would need. Those libraries can get pretty dense and pretty confusing when you get down to the component level and trying to customize those components. So you can run into some support issues or some deep learning holes where you’re like, “I need to add a new function to a date picker,” and you spend the next two weeks trying to fix or add a function or a prop to a date picker. (Faith: Mmm.) Whereas, if you built it from scratch, it probably would’ve taken longer, but you would know how to build from there. So there’s some advantages of building clean from scratch and then being able to add on top of those functions and features. Honestly, building from scratch is not for the faint of heart.

Michael (10:08):

It is hard. You need experts in the languages that you’re building in. It’s an incredible amount of performance testing, accessibility testing, unit testing. Like, it’s a lot of work to build something from scratch. So it’s a strong consideration when looking at the two. The other thing that we tell clients to look at is what does your future scale need to be? Do you need to support multiple brands? Okay, well a lot of design systems that are out there, they’re theme-able. You can make a theme quite quickly with them using their tokens, but it’s really hard to fully abstract the CSS from those components, so that you can support multiple themes or brands simultaneously. Right? So then, you may end up saying, “Oh, well we’ve got two companies and two products. Well, now we have two design systems.” (Faith: Mm.) “And now, we’re supporting two systems, and they’re no longer aligned because Brand A is Brand A, or Product A is Product A and the other one is Product B.” And all of a sudden your maintenance is becoming that much bigger, right? And then you realize, oh wow, we need to get this other product off the ground, and it’s in React, and our core library is in Angular. So just having that sense of where you might be going really gives you an idea on the scale that you need to build out on. And that can really change your strategy on the design system.

Faith (11:17):

Yeah, I mean that’s an interesting thread to pull on is scale, right? Because starting small with one product is one thing, but having a clear vision of where you’re going and being able to adapt as you scale is another. So I’m curious to hear about how XDS supports clients as they scale, right? And thus, their design systems have to scale. What have been your, kind of, key learnings there?

Michael (11:43):

It was core for us to, kind of, come from a more corporate background. (Faith: Mmm <affirmative>.) We dealt with large companies that had sister companies and children companies, so we started understanding that enterprise problem from the beginning. So when we developed XDS, first thing we did was we fully abstracted the CSS, so that we knew we could maintain multiple brands simultaneously. We actually started with Vue JS, because it was really close to like, a core JavaScript, and HTML, and CSS semantically. It was really clean and easy to build from, so we built what we call our scaffolding or structure. And then from there we realized we could build multiple languages, so then we could build React, we could build Angular, and by using common scaffolding across those components, we could share the prompts and functions across those components. So we were able to then stylize multiple frameworks, easily; we are able to manage multiple frameworks a lot easier. And often, when you found a bug in one JS framework, you would find it, or the solution would be the same for both frameworks, because they followed very similar structures at a component level. So we looked at multiple brands as the first problem, then we looked at multiple technologies, ‘cause we want to be technology agnostic (Faith: Oh, interesting.) so that we could support Vue, React, Angular, Kotlin, Swift, Flutter, you name it. Like, we’re heading in that direction, so that we create a base that can be…support large enterprises. So we started with the hard problem and are working our way to simplify it a little bit more <laugh>.

Faith (13:08):

That’s such an interesting way to build, and I think it doesn’t work for everybody, right? Like, most folks, the smartest decision is to start small and scale from there, but I think when you’re dealing with something as complex as a design system, the problem you’re solving is the problem of the large enterprise, right? (Michael: Yeah.) So working backwards really makes sense. I’m also curious, as I hear you talk, it seems like you are the definition of a T-shaped professional. It seems like you are just, you’ve got a lot of, a huge breadth of knowledge in different areas. So I’m curious about your background. How did you find yourself in the position of co-founding XDS?

Michael (13:51):

It’s an odd trail, but (Faith: <Laugh>.) I started with general graphic design, of course, and then I graduated, went to work for a sporting goods company. We built snowboards and hockey equipment, so I learned industrial design, to a certain degree, and learned how to deal with manufacturing in different countries, and how to get products out, and then how to build those into print catalogs, and then built digital websites. So we really got into building products all the way through to digital and print. Did that for a while, then worked for an agency that worked for lots of different clients, did a lot of print work for governments, and really started to understand accessibility, and its requirements, and scale of print, then realized that nobody was spending money on print, or at least not a lot, <laugh> so I really got into digital.

Michael (14:38):

I kind of doubled down and started learning code, just basic jQuery, JavaScript, CSS, and HTML, building insights for governments to be accessible, so we had to learn how to scale designs using REMs and building really strong experiences. And then from there, kind of, grew up through the agency and started leading their design and development department, building products for really great brands. Then got really stressed, as people often do in agency size, (Faith: <Laugh>. Yes.) went from working 60, 70 hours a week and decided I needed a switch, so I went to an enterprise company and, kind of, started as a senior designer just to take the pressure off for a while <laugh>. (Faith: Mm-Hmm <affirmative>.) Worked my way up building design teams and then realized how much I really enjoyed the operations of design teams, building and evolving designers from juniors, and helping them pick paths, whether they should be, you know, general designers or specialties, led us to a much larger design team structures of where you went from generalists to specialists.

Michael (15:36):

So we were like, okay, we have product designers, they can do a little bit of everything, but now we need really deep expertise on research, which is very different than our UX designers. We’re like, no, we need fundamental people who understand quantitative versus qualitative methods. We need people who really can’t even design their way out of a paper bag, but can do research and do it really, really well. So we started hiring and building up that practice, building up methods, building up design operations, and transitioning visual designers to UX, and hiring a lot of engineers, actually, who are really good UX designers, and industrial designers who make really good UX designers, and building up a specialty group where each designer had a very specific career path in terms of their skillset. So as you manage that team, you have to get a decent level of knowledge of all of them.

Michael (16:20):

And then I’ve always been partnered with technology whether it was from early in my career, learning technology, to building agency teams with technologist and designer side by side. It’s a really important role, which made design systems a really easy evolution (Faith: Mmm.) for us where we’re just like, of course you should sit beside your designer and your developer. They should be hand in hand. And then realizing that’s not normal. A lot of companies truly segregate technology from design, and the design system became that much more important, because it helps to bridge that gap, but it also helps to tear down that wall, because it shouldn’t be that different, right? You shouldn’t have designers building design tokens that should be applied to digital without sitting down with developers and figuring out how are they consuming those tokens? How are they building their experiences?

Michael (17:06):

What challenges are they running into? If a designer was building a UI kit and asked the developers, “What library are you using? Using material or material UI?” then that would help them maybe make components more functional, based on that library rather than building without any context. (Faith: Right?) And then, all of a sudden, the developer’s looking at a component where they’re like, “I have no idea what that’s supposed to do,” and then has to, you know, hack away and build custom capabilities. So going through life, kind of bridging that gap, and then being someone who can help bridge that gap, it really made sense that design systems was a really nice evolution with that role.

Faith (17:40):

Yeah. Yeah. To me, design systems almost feels like the common language between designers and developers, right? Like, it’s the space on which we can all agree, right? (Michael: Yeah.) You know, as you were, kind of, walking through your career trajectory, I was really struck by how you really took on new challenges and likely were often the most junior person in the room in a given, kind of, skill set, right? <Laugh>. And a willingness to, kind of, to do that even when you’re like, mid-career, I think is a superpower that not everybody has, but it strikes me as kind of similar to one of the value propositions I I see in XDS, which is, you know, we create design systems that can be implemented by junior level folks, right? It almost arms junior level designers with that same superpower, (Michael: Yeah.) and so I’m curious about your thoughts on how low-code and no-code solutions like XDS are, kind of, career door openers for junior developers, and how you work that value prop into your product.

Michael (18:52):

It’s a great question and one that we get asked quite a bit. You know, a lot of designers are terrified that design systems are taking their jobs, right? (Faith: Yeah <laugh>.) I’m actually doing a series on this right now, which is all around the value proposition of designers and developers outside of building a button. And we, kind of, go back to what our core is and looking at designers and saying, “Okay, yes, here are some pre-built components and some pre-design components. Use them, please, and break them and let us know when you break them.” And I think the first challenge you have when adopting design systems and working with new designers and developers is you gotta create that two-way communication. You’re gonna use the design system, you gotta help us make it better, otherwise it’s never gonna get better, and you’re just gonna be frustrated with that.

Michael (19:34):

So as a designer, you get to play, and you get to break things, and then you get to work with experts on how to fix them, how to make them better. It’s a really good way to dive deep into certain areas of technology and design without actually having to be responsible for the ones necessarily building them and solutioning for them. (Faith: Mmm <affirmative>.) So, I think the first thing that designers can do when working with the design system is use it, break it, and then provide that feedback, and then follow up like, how are we fixing this? What is the fix? And could I have done that myself? Like, be ambitious, be supportive. If you can break it and offer a fix, now you’re contributing to the design system, now you’re making that core better and that becomes part of your portfolio as you grow to say, “Hey, I didn’t build the design system, but I used it, and I was able to contribute to it, and I built a better button, I built a better input field.”

Michael (20:20):

“I was able to elevate that when I did that. It helped, you know, 15, 20 products throughout the company all be better, because I built a core piece, you know, added to that core.” So I think looking at that kind of contribution is a huge part of it. The next is taking the time and efficiency that a design system gives, and there’s lots of different statistics on this. Some will say it’s 30% or 25, some go as high as 50. And the chart that drives me crazy is they keep showing reductions in time and, you know, increased efficiency. And then, usually, they’ll spike up a little bit on the UX in those charts and say, “Hey, this is more time for UX,” and it should be. (Faith: Mm-Hmm <affirmative>.) But I argue that it should be more time for all the practices to do more, to experiment more, to learn more.

Michael (21:02):

So, but it does make sense that designers then focus more on doing UX work, prototyping, doing user testing, validating those designs. That’s a huge contribution to design and also the business. I think designers often forget that part of our role is de-risking and working with the business on how to de-risk. And whether that’s preliminary research that you’re doing, whether that’s validating concepts and ideas early in that prototype stage, or whether it’s that last stage of unit testing and, and building out those last usability tests for your product, were always de-risking. And providing more time towards that is a huge value proposition to the business and a great evolution for designers to say, “Hey, I went from designing to now de-risking for your business.” So you can quantify that really well in terms of data and analytics.

Faith (21:50):

Yeah.

Michael (21:51):

The next value proposition we always push is modules and templates. Like, build new things that other designers, if you see a common problem like signup or forget password, and it’s still a common problem, <laugh> but then go do the research. What are the common paths for users to do this? What are the best practices? Do some usability testing, understand your business’ approach to that common pattern, and then design it, and then add it to the design system, document it, so they don’t ask the same question a year down the road, or why are we doing this?

Faith (22:20):

Yeah, I haven’t thought about that, but it’s reminding me of a theme that we’ve been talking about a lot here, especially in our newsletter, is this idea that expertise can actually be a dead weight on your career. And what I mean by that is, you know, folks who are generalists, like you, who can do a plethora of different things and do them well, are the ones who tend to rise. And sometimes, we feel like, in any given role, let’s say as a junior designer, our job is to become a deep expert in that one thing. Doing that can actually tie us to that role for longer, because we’re not giving ourselves the space to develop a breadth of skills. And so, as you’re talking, I’m thinking like, man, XDS is really, or a design system in general allows designers to build that breadth of skill and experience beyond just creating buttons, which is how we started this conversation. So that’s really cool.

Michael (23:24):

I think it’s important. I do some coaching and mentoring with designers, and I often will ask their career path, like, what is the job you want in three years? What’s the job you want in five years? What’s the job you want to do in 10 years? And they’re instantly, it’s amazing how confused, and they really don’t understand. I’m like, okay, then start researching. Like, go on LinkedIn, look at these jobs, interview these people, understand the rules, and understand where you want to go. ‘Cause there’s two paths. One is that generalist, in which case you become a manager. But managing isn’t for the faint of heart. It is hard to do to manage teams, keep morale, build culture, hire great designers. It is not easy <laugh> to build that up. (Faith: Mm-Hmm <affirmative>.) And being an expert at something I still think has a lot of value, but I feel like a lot of companies don’t understand that value well enough.

Michael (24:08):

They see it as a ceiling to that career path, where I look at it and say, you should have an expert in that, and that should be their job is just to be the best. They should be doing TED talks on that expertise that they have, if that’s the role they want to do. But now, their contribution is different. They should be writing blogs, they should be curating training material, they should be supporting the organization as an expert in what they do and be the expert. But now, you become a trainer and an educator and that’s a different career path. But understanding the two is kind of core to realizing where to put your effort in and where to grow. (Faith: Right.) So we look at it in both ways are great, ‘cause we hire experts. So I hope some continue to be experts, (Faith: <Laugh>.) because we sit down and do a ton to realize like, who is the best Angular front end developer that we can either create or hire or help us, because they’re the ones who are gonna help those companies? And when they sit down with the company, they’re sitting down with a team of 15, 20 developers, and they’re gonna get berated with questions. So they have to be an expert. They don’t have to know everything, but they have to be really good, because our clients come to us for help, and support, and guidance. So we need those experts <laugh>.

Faith (25:13):

Right, right. For sure.

Michael (25:15):

Yeah, no, I think there’s two paths for a lot of these careers.

Faith (25:20):

Yeah, absolutely. And I think giving folks the space to find the thing that they want to go deep in is such a critical piece of that early phase of a career, so that’s awesome. Mike, where can people find you? If folks are listening, and XDS sounds awesome, or they wanna connect with you, where’s the best place to go?

Michael (25:39):

Honestly, our website, xdsystems.co, is the best place. We’re on LinkedIn. I’ve got a Twitter account at @michaelcarrick, if you want to. Often confused with the football player, or soccer player, (Faith: <Laugh>.) from Manchester. When he makes a mistake, I get yelled at on Twitter.

Faith (25:55):

Oh noooo! <Laugh>.

Michael (25:56):

<Laugh>. It works. So yeah, please reach out. We love to talk about design systems all the time, which is odd. It’s a niche within a niche. But yeah, I think it’s a fantastic place. And whether it’s just consulting, ‘cause it gets confusing, and it gets lonely, and there’s a lot of, there’s a ton of content on design systems out there, and you’ll realize that it’s so much as contextual to you, to your business, to the size of your design team, to your strategy. And helping to make those decisions is hard, because you can read something about a, you know, three, four, I’ve seen six tier design tokens. Okay, well that might not be right for you. (Faith: Right.) Right? Like, you gotta really consider your business, your design, your strategy, and then find content that kind of helps them support that. One area, if I may touch on with, when you talk about career growth that we talk about with design systems, is designers taking that extra time they have to create, what we love to call, “ownable moments.”

Michael (26:44):

And I think that’s the part where design systems should fail, and it’s an important part to fail on. So when you’re building out an experience, yes, 80, 85%, let a design system cover it, cover the button, cover the body of the content, cover the navigation, great. But designers should really take that extra time to find ownable moments in the experience where they can delight users. And I feel like that’s an area where, as design systems create efficiencies, we often just create more, and we don’t actually create that space to say, “Well, what is an ‘ownable moment’ and how does that work?” And it could be everything from your cart on an ecommerce system and delighting users there. It could be transitioning clients from prospects…sorry…from visitors to prospects and looking at that lead funnel and saying, “Well, how does the business make money, and how do we get a user to cross that hard bridge of signing up?” And then playing with that, and creating new patterns and new designs, and really throwing out the mold of a design system to experiment and try, and then if it works, and it tests well, great. Then build it into the design system.

Faith (27:47):

Incorporate it, yeah.

Michael (27:48):

Exactly. And then find another ownable moment. But I find when people are looking at the efficiency, they often just keep building more pages, and what I keep trying to push is finding moments that you really wanna own from an experience perspective that are gonna really contribute to users having that delightful experience we’d want them to have or contribute to the business and being able to support them and managing value better. So anyway, just food for thought, but always something that we try to educate people to focus their time on.

Faith (28:17):

That actually speaks to me and, kind of, the professional situation I’m in currently, as we think about, kind of, a redesign and restructure of our website. And so that was very relevant for me. (Michael: <Laugh>.) I hope listeners find it relevant, too. Thanks, Michael!

Michael (28:34):

Happy to sit and chat with you guys about some experiences we’ve had building ownable moments, or partners of ours and clients of ours who have. It’s fun, but it deserves time, it deserves experimentation, it deserves out-of-the-box thinking. And I think that’s where people can argue design systems have become very templated, and you can say, “Oh, I can see that that site was built with a design system,” or “That was built with material,” and you’re probably right. But then, there’s an opportunity there (Faith: Right.) to differentiate, to evolve the design system. Add animation to it, add motion to your transitions. There’s so much more you can do, and people often stop short of building out the common components. And there’s a lot. There’s a lot of stuff that design systems can do.

Faith (29:14):

Yeah. Well, I might take you up on that, then. I really appreciate the offer. Michael, this has been so cool. I feel like I spend a lot of my time, kind of, knees-deep in developer world, and it was very cool to cross the threshold into designer land. And I feel like I’ve learned just enough to elongate my T-shaped professional just a little bit into the design space. So I really appreciate it.

Michael (29:41):

No problem. Thanks, Faith, for the opportunity. This is great. (THE FRONTIER THEME FADES IN) Anytime we get to help designers or developers out. We’ve got a team of developers, if you ever want to get into some detailed podcast on, you know, integrating design systems, design systems open for developers, like, all sorts of things that can really help them out. Happy to support you guys with that, as well.

Faith (29:59):

That would be awesome.

Michael (30:01):

Our focus is more on people getting used to design systems, using as part of their operations. Whether that’s XDS’s product, great. If not, doesn’t matter. Get a system into place, create that time and that efficiency so you guys can use that time to do higher value work.

Faith (30:15):

Awesome. Thanks for listening to the Frontier podcast, powered by Gun.io. We drop two episodes per week, so if you like this episode, be sure to subscribe on your platform of choice, and come hang out with us again next week, and bring all your internet friends. If you have questions or recommendations, just shoot us a Twitter DM @thefrontierpod, and we’ll see you next week.