Are components a necessary part of a design system? In this episode of The Design Systems Podcast, Alice Preisler, the Product Owner of Design System at ADP challenges the idea that all design systems start with a component library. Alice and host, Chris Strahl discuss what starting with documentation and design tokens instead of components might do for a design system and product teams. Alice shares her vision of using a linting tool to enforce design consistency to create a cohesive user experience. Tune in for fun thought experiments and pragmatic insights on fostering creativity within constraints, and the role of documentation and tooling for faster, consistent product development.
Guest
Alice Preisler leads the development of ADP's enterprise design system to cover all technical platforms (web, iOS, Android, ATM) across unique customer-facing brands. Alice leads highly visible, complex and customer driven products, projects, programs, and portfolios. She excels managing stakeholders, bringing the right resources into complex global projects to ensure successful execution.
Transcript
Chris Stroll [00:00:00]:
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 they relate 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 at thedspod. We'd love to hear from you.
Chris Strahl [00:00:19]:
Hey, everyone, welcome to the Design Systems Podcast. I'm your host, Chris Strahl. Today I'm here with Alice Preisler from ADP. Alice is the product owner of the design system there. Welcome to the program.
Alice Preisler [00:00:31]:
Thank you so much, Chris. I'm excited to be here.
Chris Strahl [00:00:33]:
So for those that have maybe never gotten a paycheck before, can you talk about what ADP is real quick?
Alice Preisler [00:00:39]:
I can. So, ADP started out as a company who helped smaller companies to make sure that they can run paychecks. That was the old branding of ADP, was automatic data processing. So as the company has then evolved, it's much more into the HCM or the human resource aspect of it. So it's no longer only focused on making sure people get paid correctly, but it's also about hiring, managing people's careers, making sure that all the benefits aren't okay. How do you manage as a company, your staff?
Chris Strahl [00:01:17]:
So when you think about a design system relative to ADP, it's maybe not the first thing you would think about in terms of where a design system fits, but your design system is pretty intimately tied to the way you all build products. Can you talk about how a design system fits into ADP's ecosystem?
Alice Preisler [00:01:33]:
If you think about ADP, ADP is a company who sells software. As a service, this is what we do. And as a customer of ADP, and I am one myself, I expect not only to be paid on time, but I also expect that I can see my paycheck, I can see how much taxes I'm paying, I can see how much my retirement funds are. You know, I can see all this, and I can go back in time, I can go forward in time, and I can anticipate what my earnings will be. And all this I have as a customer an expectation that this is available both on the website, but also in an app and then as a manager. Right. I also have an expectation that I can pay my people. So if I have people that are locking time, for instance, that they're not necessarily full time employees that I can manage my people.
So in terms of how many hours have they worked, how much should they get paid, have they gotten any overtime, et cetera, et cetera. And I also expect that all of this can be managed on a mobile device or on a website.
Chris Strahl [00:02:36]:
Gotcha. So you have a pretty multifaceted system where you're talking about native apps, you're talking about websites, you're talking about two different products, one for employees, another for managers. And so the ecosystem is pretty diverse in terms of the variety of applications that you're taking on.
Alice Preisler [00:02:54]:
Yes. And then we have to add the fun aspect of not only globalization and accessibility, but also that we are rolling out in different countries that have not only different cultures, but they also read differently. Like they read right to left, or they have different ways of translating. Like if roll out a system in Germany, it has to be in German. If you roll it out in Israel, you have to do it in Hebrew and so forth. So not only is it diverse in terms of the products that ADP offer, but it's also really diverse in terms of size of the customer. So we have the mom and pop shops, we also have the large enterprises, and we have the diversity in the countries where we offer the product. So Iceland, for instance, is one of the new countries that was added onto the long list of countries. Yeah. And just this fiscal year
Chris Strahl [00:03:49]:
I can't even imagine having to deal with that level of, like, localization. And so there's a lot that goes on with the design system. I think that one of the fun parts about our first, like, face to face conversation, we met up at an event in New York. And one of the things that you said that I think Washington, really fascinating is you talked about the idea of how a library of components doesn't make a design system. And in fact, you said, I would prefer to have no components at all. And I thought that that was a really interesting hot take. And so talk to me about this idea of running an ecosystem with all these accessibility needs, this huge amount of localization, a big multinational organization that also has a big array of products without the idea of components.
Alice Preisler [00:04:39]:
So I think if I look back of what I've done as a product owner for design system, before ADP, I was with Mailchimp, as a product owner of the design system, and before Mailchimp, I was with JP Morgan Chase, also as the product owner of the design system. And in all three cases, I was hired in to make sure that all the products adopt the design system. And it all started out with this component library and the metrics that we were measured on was how many components and how many products and how many instances. And the whole team was like go, go, go on that. And I think if I look back and I kind of, you know, on a retro, on what went wrong, I think what really went wrong and why we left, I'm sure we did leave value on the table is because we focused so much on the components and not really what would mature design system or what else is necessary to have a successful design system. We were just focused on making a new enhancements to button or treasury button or you know, oh my select doesn't work on this instance. So can you make it do this and so forth? That is my hypothesis in all of this is what if you do a design system with no components, can you actually gain the same?
Chris Strahl [00:06:00]:
Yeah. And what do you mean by that exactly? I think that everybody that just listened to what you said is probably like, oh yeah, I've done that. The idea of like, oh hey, we need a new button variant that has an icon on the right instead of the icon on the left. And the idea of this constant like need to support an ecosystem that has infinity much work around how they want to create small variations of things.
Alice Preisler [00:06:22]:
Yes. So I think we need to take a step back on the whole idea of components and say, well, the whole goal of the design system is a cohesiveness of the customer experience. So regardless of which product you're in, your experience should be the same. That's at least for me, one of the two main things for a design system. And the other thing is that how can we make the products deliver new features faster? Then you can then argue, well, what does faster mean? Does it mean time, does it mean quality, does it mean accessibility, does it mean right to left? Or what does faster mean? And for me that doesn't really matter that much in this whole conversation. But again, those are the two, like the cohesiveness and the speed, that value.
Chris Strahl [00:07:07]:
Of consistency is sort of ever present, right? That idea that like users don't have to learn a new interface model as they traverse your application ecosystem. I'm fine with putting a pin in speed for right now. I personally really like that one. But at the same time, like I hear what you're saying. So you have this value that is like give me consistent experiences and make it really quick to build them.
Alice Preisler [00:07:30]:
Yes, this is what I'm challenging is that can you achieve the same cohesiveness if you have a really strong design principle or design philosophy, or if your guidance to your designers are really strong in the foundations, can that then be obtained? Right? So if they all design the same way, can you then just transfer everything over to the developers? And the outcome would then be a cohesiveness or the idea that the customer experience is the same across multiple products, across multiple countries, etcetera, etcetera.
Chris Strahl [00:08:08]:
That's interesting, right? Because my initial reaction to that, which I'm sure I'm not necessarily alone in, is the idea of like, okay, but what would I copy paste from to design something, right? And I mean, like, look like design systems are more than copy paste. Like, I founded a company that's a design system platform. I understand that it's more complicated than that, but the fundamental thing is it's like, what do I grab hold of to use as a part of that creative process?
Alice Preisler [00:08:38]:
So maybe we need to focus more on tooling, right? So maybe we need a tool to help the designers make sure that when they design, they design the right things, make sure that they follow the same guidelines. And I think this is where, for me, the foundational product to the design system is their documentation platform. The documentation platform is my product. As the product owner, this is my core thing. It's like the bank and their app. Well, the app is not the bank's core business, but without the app, how are the customer then going to figure out how to use the bank? So I think that a design system without a really strong documentation platform, you don't have a true design system. You just have a component library and, you know, in various places and some tooling here and there. So if I were to do these design systems again, I would focus much more on building a core platform where the, the guidance and the tooling to the designers is clear and so forth.
Chris Strahl [00:09:45]:
I think part of what you're advocating for here that is really interesting is this foundational idea that this isn't as much about the necessary bits and bobs to assemble an experience from, but rather the guidelines and the way of working that leads to those outcomes. And the interesting thing, when you talk about tooling that says, hey, how do we have some set of rules? Or maybe rules is not the right word, some set of strongly adhered to guidelines. It almost reminds me of the conversation I had one time about linting for designers. How do you think about this idea of when you commit code as an engineer to get that code into a repo? It goes through a series and systems of checks that is honestly incredibly complicated. And design doesn't really have quite that same thing. Or at least I have not seen anything that operates really at that level. And so where you look at a design system tooling gap in the industry isn't necessarily the ability to create docs or create components or manage those components. It's the ability to say, hey, as a designer, if I want to say this design is done, there's a series of checks that it has to go through, that it has to pass, and that set of checks should be on par with the complexity of what happens inside of an engineering workflow.
Alice Preisler [00:11:09]:
Exactly. And I think that the skillset of a designer is not as structured as an engineer. I think that's just the name of the game and the different work requirements for those two roles. And I think it is so funny that we haven't figured out how to keep the designers organized in their way of designing and thinking, so that when they pass over the code to the engineers that it is following the rules of the role, the design principles, philosophy, whatever we want to call it. Figma had an event last month that I was just talking with Figma because this is one of the things that I really want to do, is that I want to try to implement a process in one of my products where we run a linting tool on the designs before they go to the developers, before the product owner actually signs off. And I would like the linting tool not only to say, this is 80% within the rules of the design system, but I would like to add that, okay, this is now 60% within the rules of the design system and therefore it will take twelve weeks or longer.
Chris Strahl [00:12:18]:
To build, you actually want to be able to say like there's some measure or some objective benchmark of quality of that design. And in that design quality state, there's a delta in implementation based on any gap that exists in quality.
Alice Preisler [00:12:34]:
That is exactly what I want to do when the product owner says, yeah, but I like that you can do this on my design, because a lot of product owners, they also say that, right, and they have these requirements to do a new variation of button or slider, whatever it is that they have, because they like the new variation. But that variation comes with a cost and it's much easier to put on time because time is what is really key to the product owner. Right. How fast can I get this out of the door? Well, if you want this new variation, you can add twelve weeks. If you can do without this, right, then you can have it twelve weeks earlier.
Chris Strahl [00:13:14]:
So that's interesting. Right. So you're basically using a time bound metric as a way of enforcing consistency. And I think that's kind of interesting, right? This idea that, like, hey, you know that thing that we put the pin in a minute ago, we just pulled that pin right back out and basically said, like, the actual value here is the speed to market and the ability to build these features more quickly. And you only get that through consistency. But that consistency set doesn't necessarily need to be a bunch of components. It can be a set of rules and structures and a production model for how you would think about the creation of product.
Alice Preisler [00:13:44]:
Yes, and this is where my theory comes a little short, because I do know, at least from my experience in the design system, that. But I don't think it's really possible not to have components. But I think focusing on the components makes it difficult. I think it is much more important to have tokens around the right things. Right. Because once you have the tokens in there, and everybody knows these are the tokens that must be used, the look and feel will be the same for the customer.
Chris Strahl [00:14:13]:
So this is really cool, because I think this is where it goes from thought experiment to practicality, right? I mean, look, I think that what you're talking about is really interesting, right? I also think that getting designers to use a linter is really hard. But at the same time, like, there's merit to this idea that maybe the starting point for every design system doesn't need to be a component library, that there's so many more practical ideas of how you actually get to what you want, which is that speed that are more meaningful than, like, let me create a button with an icon on the left and an icon on the right.
Alice Preisler [00:14:51]:
Yes. And I tried this out last year. We had to do a new theming, and I said, okay, so how few components or how few tokens can be changed to obtain the new theme? So let's try and figure out, can we do with eight? Five? It might be a little too liddy. Okay, can we do with eight? I think we ended up around 25, which for me is totally key. So you can change the feel and look, and you can match from one company, like ADP, to another company to match the feel and look. So when we integrate the HCM product into a big enterprise, we can actually match the feel and look. So the customer, which is now the employee of the big enterprise, don't feel that they move away from their design and feel and look. You can do that with 25, maybe 30 tokens.
So what we really talk about is these foundational things of the design system. So if we go into the practicality, so what do we really need? Well, color is really important, right? Typography is really important. Spacing, voice and tone, all these things are really important for us to create the cohesiveness. And can we, with the right tooling, help designers and engineers to get those automatically or easier with the reusability?
Chris Strahl [00:16:16]:
This is where you and I have a ton of overlap, right. I think that the ability to have well structured, well managed sets of tokens to understand how they fit into theming, to make those themes not so complex that you end up with 25,000 design tokens. I think that all of that is a much more valuable starting point than a button. And the biggest reason why is because once you have the basics and those fundamentals, it's like the same XKCD diagram about where you should automate. And if you repeat a task like a thousand times a day, it's a very good candidate for automation. You're doing theming and styling and basically brand choices in your app with every single button click and keystroke. You're not necessarily doing that with a button every single time. And so where that real value comes into play and where it happens all the time are those basic brand level decisions or product level decisions about how that brand gets implemented.
And I think that's a brilliant starting point for design systems. And if I could like unwind this industry a decade, I would basically say like, components are not the way, like we should be thinking about tokens first and maybe getting a little further with them before we start to think about componentry. I think that like how we get so caught up in componentry is, it feels tangible, right? I can't click on a foreground color and a background color. I maybe can see it, but I can click on a button. And I think that tangibility is something that is still a really hard thing in the area of design systems to really move past. Right. Because people want to be able to see the work that you're doing. And if you're talking about like, let me see my animation timing or let me see my spacing, that's a lot more difficult and a lot more abstract than like here's a card or here's a hero.
Alice Preisler [00:18:09]:
Yeah. I also think it's really difficult to sell. Right? Let's say you have to go to the XCOM and say, hey, by the way, this is what I want to do.
Chris Strahl [00:18:17]:
I'm going to fix spacing, guys.
Alice Preisler [00:18:20]:
It's going to be a really hot sell.
Chris Strahl [00:18:22]:
Yeah.
Alice Preisler [00:18:23]:
And I also think that for many of the companies, they are tech driven. They're not necessarily design driven. Right. And I hate to say this this way, but you don't really make money on the design. You make money on the code, because that is what you are selling. You don't make money on a fluffy design. So this is where it becomes much more tangible to say to XCOM and to say to your engineer organization, hey, I have button. You don't have to build button ever again.
So I think it's a much easier sell. And I do think that for many design systems starting out there, I think it is this necessary evil that you can't really do anything without the components. But it's also the components that can kill you. If you're so focused on the components, you kind of forget the other things that will mature you over time.
Chris Strahl [00:19:17]:
Unwinding that for a second, because there was a lot there, and you kind of said the quiet part out loud for a second is that most organizations don't value design. Not everybody's Apple. When you look at the value of design inside of those companies, design has long since advocated for a seat at the table. There's the consumerization of enterprise tech that was driven by the iPhone and the app store. People are demanding better and better experiences from companies that are these legacy behemoths, be it a payroll company or be it an insurer or a healthcare organization. And so design is becoming more and more important. But there is still this mantra that the code is the gold. It's the thing that makes the interface that shows up, that people click on to get their problem solved or to get that value.
Chris Strahl [00:20:07]:
I think that that's hard to hear.
Alice Preisler [00:20:10]:
I it's very hard to hear. And I think that that is the reason that it makes the design system so focused on the components. Because the design system comes from a component library that is typically done in the tech world of the organization.
Chris Strahl [00:20:27]:
I think it's rare to say, like, hey, this original iteration of this button came from Figma. The vast majority of the time, there was an engineer that was like, writing. Some react that was like, yeah, I'm never writing this button again. And they made it.
Alice Preisler [00:20:39]:
Yes. And I think that is the challenge. Right. That is really the challenge. My point, again is that in order to obtain the speed of your product, you need to shorten the way between engineer and design. That's another way you can shorten the way. And how does the design system help you do that? Because you can't have a developer sitting there saying, oh, I need a new variation button. And the designer designing a fourth variation of button.
Chris Strahl [00:21:10]:
I think that it is an interesting opportunity for designers as well, though, right? Because if you think about this idea of, like, design within constraints, right? Every designer that I've ever talked to always has that immediate, like, reaction to the word constraint. But the reality is, like, we've all been working with the constraints, like the constraints of our medium, you know, the constraints of a system. And having a more systematic approach to those constraints gives design more opportunity to have an impact in product, especially in organizations that don't innately say, like, our design is the thing that makes our customers keep coming back.
Alice Preisler [00:21:43]:
But that is also a huge change for the design organization because they now have to not design button, but they have to design an experience, right? So we are not just in the UI, we are now. Dear designer, I know that we asked you before to do the UI. Now we're going to ask you to design an experience using these Lego bricks. So go figure that out when it comes to the design system as well. And we haven't really touched about this because we've touched a lot about the dark side and the one truth and the tokens. But there's this whole other piece that I think, at least from my point of view, that I could have done better in all three cases, and I wish that I had done better.
Chris Strahl [00:22:23]:
It's very, very vulnerable of you. Thank you.
Alice Preisler [00:22:25]:
Yeah. And I think this whole education of what does it take from a designer to design using the design system? And how can the designer not feel this constraint using the Lego bricks that I have and that I give them and still feel, you know, the creativity of creating new, awesome experiences?
Chris Strahl [00:22:46]:
There's a really interesting parallel here, right? Wherever. When I was still an engineer, gosh, like 14 years ago at this point, which is weird to say out loud, when I still wrote code in the code mines for a living. Right. One of the things that was always really frustrating is that I always felt relegated to being a bricklayer by the design teams that I worked with. It was like, hey, go make this thing right? And it was all pushing pixels. It was all like, you know, that pixel perfect sort of mantra associated with it, and it made you feel like you didn't have any choice or any agency in the way that things got built. And I can definitely feel the sense of that inside of design when they think about the approach to systems and what you just talked about. And so how you can have creativity with constraints is something that is still like an ongoing conversation.
Chris Strahl [00:23:34]:
I feel like in the landscape of design systems, but one way or another, it feels like this is somewhat of an inevitability, right. The march of systems, because they are so valuable and they are about, like, shipping product faster. How do you think that we go about trying to face that?
Alice Preisler [00:23:51]:
So I think that this is where the whole education comes in play, because the skillset of the designers needs to swift a little bit. And the same for the engineers. You can't just have a back engineer trying to do a front end design without tokens or anything.
Chris Strahl [00:24:06]:
I mean, they're full stack now. Like, let's.
Alice Preisler [00:24:10]:
You won't have a chance. Right? So this is where the shifting of the knowledge and understanding what both the designers and the engineers, what the new roles they are, and how do you, as a design system product owner, support them in those roles? And this is an area that I think is so overseen in the whole success of the design system.
Chris Strahl [00:24:32]:
What do you think about that role? I mean, this is the role that you're playing right now, right? Where you have a team of designers and engineers that have to go build a lot of product or build the foundations of a lot of product. And so when you're coaching the folks that are using the system, implementing the system, talking about the system, what are the levers you reach for the tools in your toolbox to instill that, like, different idea? Because, like, this isn't being taught in design schools. It's not really, like, in code academies or like, even formal college education for web design. Like, this stuff doesn't exist. So how are you starting to lay some of those foundations?
Alice Preisler [00:25:12]:
So some of these foundations, it's very difficult. And in companies where the skill sets are less front end, obviously this becomes much more tricky. And we can't avoid the whole topic of components because you will need some kind of ten components, 15 components, or how many components you think is reasonable. But in those components, I think it's really valuable to have a tool where you can drag and drop easily to create new layouts of how it looks like. It's also really important from a design system point of view that you have layouts that can just be picked up by products so that they don't start from a white piece of paper every single time.
Chris Strahl [00:25:51]:
Right. What are the templates? What are the predefined structures that people can grab hold of that help them start? It's not totally unusual, right? There's very few people that, like, open up figma and genuinely have a white canvas in front of them. Almost always there's like some kit that they're grabbing or that they have themselves. That is their starting point.
Alice Preisler [00:26:11]:
Yeah. So a lot of the products teams, they have their own figma libraries that they then pull in and then they, you know, make their shenanigans and figure things and then they make the changes.
Chris Strahl [00:26:23]:
Wait, what was that word? I love that word.
Alice Preisler [00:26:25]:
Shenaniggles.
Chris Strahl [00:26:26]:
Yeah, shenagles. I'm gonna use that in a sentence today.
Alice Preisler [00:26:29]:
So they make all that shenaniggles, and then if we are lucky, they run some kind of tooling to make sure that they're accessible or that everything works. If we're even further lucky, they also used some kind of tokens so that when it goes over to the developers, the developers actually knows, oh, these are the tokens I have to use. Oh, it's not black, it's peppercorn, for instance, because the tokens are within that file of Figma. But it would be even better if we could have some kind of prototyping in there so that the designer can say, hey, this is what I think it should look like. What do you think, engineer? Do you think this will work? And the engineer can then say, well, I think this will work better, or, well, if we can tweak it this way, it's easier for us. Or we don't have a test case that run this, so we can't really test this. So there is this back and forth communication between those two.
Chris Strahl [00:27:21]:
It's funny, right? Because there's a lot of places this conversation has gone to, a lot of corners of the design system ecosystem. But the fun thing about it has, is there has been this sort of fundamental that has been reinforced throughout this conversation that it's about this communication gap that exists between design and engineering. So the idea of how do we get those things closer together and how do we get those things to move faster where one understands the other better?
Alice Preisler [00:27:47]:
And then you have this third party. The third party. That's the annoying part, the product.
Chris Strahl [00:27:51]:
Oh, yeah. I mean, that's your job, right?
Alice Preisler [00:27:54]:
Those are the annoying people that will come and say, no, no, I don't like that. No, no, I want it faster than. Right. One of the things that I really try to, in the design system team that I'm on, I really try and connect those people together from the get go. So when I say, hey, I would like this, I bring in a team of design and engineer and most often test the QA guys and say, hey, this is what I would like. What do you think? How can we do? And there is this communication between all of these parties to make sure that everything can be done. So when we hit development, it's almost done right. It takes so little for it to actually get over the line.
Chris Strahl [00:28:35]:
The gap is a lot smaller.
Alice Preisler [00:28:36]:
Yes. The tricky part in this, and this is where the annoying product owner needs to really be aware, at least from my point of view, is that if you increase scope halfway through, it takes much longer. You have to be really clear on what it is that you ask these guys to deliver. I think often, especially with the component library, that makes it even more difficult because it just takes time to figure out the scope of an enhancement to button, for instance.
Chris Strahl [00:29:12]:
So when you talk about these ideas of how you support this process with design, with engineering, with products, when you think about the tooling and the platforms that are being built around this space, what are the key things that people really need to have to be able to support this process inside of a company like yours?
Alice Preisler [00:29:29]:
From my point of view, it doesn't matter whether you are a company like Mailchimp or you're a company like JPMorgan Chase or ADP. I think that if you want to succeed as a design system product owner, you must have a documentation platform that is second to none. You cannot have something where it takes five clicks to do something or where the search only works half the time. It has to be easy to use. It has to answer the question you have without that documentation platform, you can't scale. So it's very difficult. If you are supporting 35 products and you have a team of five developers, then how are you going to scale? You need to have a product or design system platform, your product that is absolutely second to none of. I think that is totally key.
Alice Preisler [00:30:18]:
And in the documentation you need theming documentation, you need obviously the design documentation, the patterns, the patterns are key, the do's and don'ts, the layouts, and you need to be able to prototype of some sort.
Chris Strahl [00:30:31]:
That's an interesting one, right? Because this is actually something that we just recently added to knapsack was the ability to basically say like, all right, I've connected to my Figma sources, I've connected to my code sources. Let me be able to make something in Figma and let me see what a prototype of that would look like in code. That's become something that has lit up a lot of folks in our customer set. Is this idea of I want to be able to originate something in Figma and see what that looks like in code. I want to be able to originate something in code and see what that looks like in Figma and have anybody, regardless of their technical ability, be able to actually manipulate that and see how it works?
Alice Preisler [00:31:03]:
Yeah, I think that is key to the design system, and it will help the speed and the cohesiveness of the experience. As I said again, the tooling and the documentation platform is key, and if it's not second to none, you don't stand a chance.
Chris Strahl [00:31:17]:
Well, Alice, I really appreciate you being on the show today. This has been a super fun conversation. I've learned all sorts of new words, and I look forward to having you back again sometime. Thank you so much for your time and for being so open about this chat. It's been wonderful.
Alice Preisler [00:31:31]:
Oh, you're welcome. It's been lovely to be here.
Chris Strahl [00:31:34]:
This has been the design system podcast. I'm your host, Chris Strahl. Have a great day, everybody. That's all for today.
Chris Stroll [00:31:39]:
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. Have a great day.