Today on the podcast, we talk to Meredith Van Lier, the director of product management at ServiceNow. Chris and Meredith discuss the unique evolution of ServiceNow's design system and its shift towards a more flexible and user-centric design approach, emphasizing collaboration, automation, and accessibility. Learn about the strategic vision, collaborative efforts, and meticulous attention to quality defining ServiceNow's design system.
Check out our upcoming events.
Guest
Meredith Van Lier is the Director of Product Management, leading a team of product managers responsible for the Horizon Design System and UX foundations at ServiceNow. She provides product direction and strategy, focusing on driving modern experiences by enabling customers to design and build great experiences through the use of the design system. Meredith has more than 15 years of experience across enterprise, finance and consumer spaces.
Transcript
Chris Strahl [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 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 at thedspod. We'd love to hear from you.
Hey, everyone. Welcome to the design Systems podcast. I'm your host, Chris Strahl. Today I'm here with Meredith van Lier, the director of product management at ServiceNow. Meredith, welcome to the program.
Meredith [00:00:30]:
Thank you. Very happy to be here.
Chris Strahl [00:00:32]:
So this conversation is got a pretty fun twist on it. First of all, you're in product, and I think that that's an interesting thing for a design system. I think we've only ever had two, maybe three other people on products ever on this show, which is super cool. And then secondly, ServiceNow has a pretty interesting use case for design systems, which is somewhere between, like, how do you have a design system to build your product? And somewhere between how you expose your design system so other people can build on top of your product. So why don't we kick this off with trying to understand a little bit about the history of ServiceNow and what this design system is really intended to do.
Meredith [00:01:12]:
So the design system came about when we built our product workspace. It was purpose built for this application, and it is an internal part of our software where we were doing a design system to create consistency within our product and make it easy for both our internal builders to build as well as our customers. So we started there. We've had it around now for about four years. But as times have changed, we have been looking to expand our design system into other product areas. And in doing so, we need to make it more flexible for our customers. So we need to pull back a little bit from a purpose built design system to make it more open and available to our customers so that it can be something where they can customize and build upon it.
Chris Strahl [00:01:57]:
For those that maybe aren't totally familiar with what ServiceNow does, what does that experience look like for you all internally and in the hands of your customers? And what of that is actually powered by the design system?
Meredith [00:02:09]:
Yeah. So we have a product workspace, like I mentioned, that is built through a low code builder, and the design system is actually incorporated in the builder. So as our teams internally build and as our customers build with it, they are using the design system whether they know it or not. A lot of the components just come in from us as well as they have theme hooks built into them. So it's already connected into theming. So when they start building these pages and applications for their workspace, it is there and it is a part of it.
Chris Strahl [00:02:40]:
So what does the end result of that look like when you are going through that process and you're building something with components and theme hooks? What comes out the other side?
Meredith [00:02:49]:
Yeah. So the end result of that is that you end up with first a set of pages, but those pages ultimately build applications for some of your back office workers to be able to go through and complete their tasks. It could be very easy it ticket tasks or very complex workflows that maybe your customer service agents do in the back office. So they build full applications that allow their internal teams to actually deliver the value of customer service. It hr on our platform.
Chris Strahl [00:03:23]:
Yeah. So if you were say, a tech company and somebody had a service ticket where they needed something out of your application or something was breaking or they had something to report, ultimately what we're talking about, that experience looking like that is powered by the design system, is when that ticket comes in and there's somebody that is working in support that is moving through that resolution, how they would track, manage, understand, look at that ticket, is what you're talking about.
Meredith [00:03:48]:
Exactly.
Chris Strahl [00:03:49]:
So that experience of saying, let's give you a platform that we're going to expose to you, that is effectively our design system that also allows you to brand and manage as if it were your own experience. That's really ambitious. There's not that many organizations that I can think of that really think about their design system as so integral to that product experience that ultimately is served external to the organization. You think about a design system most often you think about like, hey, I have this thing that powers some product that either like some consumer experience that users are going to come from the public Internet into, or it's some product experience where people are going to have signed up for an account or something like that. And then that experience is more or less wholly owned. What you're talking about is something that's a lot more like Shopify and Polaris or Salesforce and Lightning, where you're actually empowering your customers and your users to do a heck of a lot with the design system, correct?
Meredith [00:04:49]:
Yeah, we're really giving them a lot of controls through the design system to take that experience and make it what they need it to be, whether it be the workflow, whether it be the UI, all of those things we're putting in their hands.
Chris Strahl [00:05:01]:
When the organization was looking at like, how do we expose all this stuff? The intention was, we're going to build a design system that does this. And that's what you mean when you say that it's purpose built. When you think about that, it feels to me like the design system is core to a lot of the value and the deep strategy of how your product ultimately ends up in the hand of customers.
Meredith [00:05:24]:
Yeah, I'd say we're absolutely the foundation of what is being built. Right? We are the foundation of the technology and of the actual software applications that are going out. So it is imperative to have a strong foundation in core that they can build upon and that really powers all of it.
Chris Strahl [00:05:42]:
So how does that then relate to how the internal product itself is built? Because the design system is very closely tied to the product, but it's not necessarily the product itself. When you think about that, what is the relationship between you and the team that is developing the workflows and the screens inside of the actual servicenow application?
Meredith [00:06:02]:
We have internal teams that actually build upon it first. They are actually going into the slow code builder and they are using our building blocks to create these pages and these applications. We are very closely linked to them. Those are our first customers, if you will. These internal teams, we work closely to understand what do they need? How are these workflows going to go, how can we help better service them and provide the tools that they need and the interactions and the components, the UI, really all of those layers. So they're our first layer. Then of course after that, when they release it out to their customers, those customers then can take it and also customize on top of it and do the exact same types of things. So they're really our second layer customer.
Chris Strahl [00:06:46]:
Gotcha. So when you think then about this expansion, like what you all want to do next, you're talking about like another order of customer here. And like you talked about, like the idea of how do I achieve new value from this system? What does that look like? Where is that headed?
Meredith [00:07:02]:
So right now I would say it's a little bit more locked down towards more of a governed design system. So since it was purpose built, we really started it in a way that we wanted to maintain the consistency and look and feel. Since this was a product we were bringing within our product suite. Now, as we look forward, we're providing more of an end user application. Think of it more like a website where our customers could actually have their customers coming in and let's say, reporting issues, things like that. So when they come in, they expect it to be a branded experience that looks and feels like the company and is really a seamless thing. They don't know it's service now that they're going in and there may be reporting an issue. So if we think about that, we really need to change from something that's a little bit more closed off in our approach to maintain consistency and instead move down that pendulum to be more flexible and open and really allow them to take our design system, build upon it, really configure it, make sure it's really meeting all their needs, as well as the look and feel and branding is extremely important.
It has to be pixel perfect and really match their brand.
Chris Strahl [00:08:10]:
Yeah. So, for example, if Knapsack were to be a Servicenow customer, which we aren't, but I hope to someday be, if somebody was reporting an issue with our application. And of course, there are never ever any of those, but if somebody were to stumble upon one somehow, you would ultimately have an experience that would be part of the Servicenow product ecosystem. But we would be able to make, look and feel fully integrated into the knapsack experience.
Meredith [00:08:37]:
Correct. And so to them, they would have no idea servicenow is behind it, empowering it. They would think it was just a knapsack interface to report that issue.
Chris Strahl [00:08:46]:
And the way that I would construct that interface is actually using your design system almost as a core feature set of the product value that you're delivering.
Meredith [00:08:54]:
Exactly.
Chris Strahl [00:08:55]:
And this is why product is the owner of the design system at ServiceNow. It's because this is so core to your product experience. And I think that's fascinating because very often we talk about how a design system powers the experience, but it's rare that the design system is the experience. And I think that's a really cool distinction.
Meredith [00:09:13]:
Yeah. And I think it is very unique, too, that in this case, you know, this sits under product within our organization, and that gives us a lot of alignment across our other teams. Right. This is a core part of the offering. And so we need to make sure that product is there to represent what we can do, where we need to go, and to be aligned across these other teams. So we're lockstep and hopefully even a step ahead because we're so foundational, we need to really know the direction and then be there so that when the other teams need this, we're ready.
Chris Strahl [00:09:45]:
That's awesome. So when you think about ownership of the design system existing within products, was that a conscious choice or was that always kind of like where it originated? And what are some of the reasons behind that decision making?
Meredith [00:09:56]:
You know, it sits very closely with our UX department as well. Of course, it's a key part of, you know, our visual language and how we build things. But it was started within the product organization and it has always been considered as such here, which is, again, pretty unique. And I think a lot of the reasons for that was just that we needed to treat this as a product, plan ahead, have roadmaps, have vision, be thinking of where this can go and how this can really serve our customers. Not just reacting and order taking with, you know, some of the other teams and what they might need today or tomorrow, but instead have a vision and a long term and really know what we want to get to. Just like any other product, we think that's really important to do. And then again, to align across the other product strategies so we really get the full value out of it.
Chris Strahl [00:10:43]:
So if you think about a takeaway from the ownership of this experience, the design system within product, what would be your advice to other organizations? Because I think one of the powers, maybe even a superpower that you all have is the idea is you're not trying to do this thing where you tell you, all right, we have design over here and engineering over here. We're trying to figure out how to unite the clans. You've got this idea of, hey, this is core to our experience. We have a relationship with engineering. We have a relationship with Brandon Ux. And that bridge that you're able to create between the two of them is represented as product, being that common stakeholder. That's awesome. And secondly, how did you do that?
Meredith [00:11:27]:
Yeah, it is awesome. It is great relationships that we have across all of these teams and very powerful to have everyone at the table. One thing to know is my background is traditional product management. So to me, this is normal. This is how things usually function in product. And so you do. You have that trifecta between the different groups and close partnership. So that's a very natural thing for me and for my team.
We have always functioned in that way. And it does require having very good communications across the group, everyone having a seat at the table, bringing ideas, suggestions. But ultimately, it's just like any other product is how we treat it. You know, where do we need to go? What are the needs? What are the problems? How is this going to help the customer, the business and so on? And so we do bring that aspect but it's not just us. It's all of us across those functions coming together to come up with those ideas and then to stay very closely aligned and work together on this. You know, it wouldn't be possible just product doing this for this area. And I think it just makes it better and elevates it to have all three groups really represented there and working together.
Chris Strahl [00:12:33]:
How do you share that stake? I think that that's cool when you start, then say, hey, look, there's an ownership of this in product, but we don't exist without these other disciplines being a part of it. And I firmly believe this myself. It's funny, it's actually a qualifying question for customers of knapsack is like, is this cross functional? And how is cross functional ownership defined? If there's not people from at least engineering and design and very, very likely product in that conversation, you're probably not actually going to be successful. And so when you think about that sharing of responsibility and that sharing of stake inside of that system, how do you account for that and how do you foster that? Because I think that that's not without work.
Meredith [00:13:13]:
Yeah, I would say there are some areas that do fall within some of the functions a little bit more heavily. For example, when we talk about our design tokens, that is really within our UX group actually defining those coming up with the strategy, owning a lot of that. We are there as product to really understand what are the outcomes we're going to get from that, what are we going to enable for our customers, how do we sell that internally, externally? So we're there to help, but they're the ones coming up with a lot of the strategy there. I think you could say the same for engineering. There are certain aspects of the design system that engineering really owns and runs with, whether it be kind of the technical architecture and the approach there, the connection with the other teams, et cetera. They really own pieces there that they bring to the table and they help to drive. So I think everyone has a little bit different focus, but at the end, we all act as a team. And when we go through and we think about what's our next phase of the design system or what's our next initiative, we always run it with a small group of people that involves a pm, it involves a ux, and it involves an engineer.
Meredith [00:14:16]:
And as we define it from the get go, all three of those are involved and they all are invested in what the outcome is, how to get there, and all of the details that go with that. So from the very beginning, conversation all the way through till when we deliver it. Those people are part of that and really helping to come together and elevate that idea.
Chris Strahl [00:14:35]:
Yeah, it's interesting. I was originally kind of running down this rabbit hole because I was curious what specific product insight you had. I think that the really interesting thing about this is it's like, it's largely an organizational insight and that by having a small cross functional team be involved very early on in that decision making, that's how you share ownership. And that shared ownership comes down to some formal, some informal definition. It's not like you have some great racy chart in some Excel documents somewhere that everybody has to open up once a week and understand what it is that they're supposed to be doing. It's a lot more organic and that you're like, hey, you all are best suited for this particular part of the system or role, and because you're very tightly coupled, it works.
Meredith [00:15:19]:
Yes, that is correct. That is a good way to put it.
Chris Strahl [00:15:22]:
I think that it is interesting, right. Because I find a lot of folks, especially people that don't have, I guess, a traditional product management background that are trying to formally define the swim lanes for how different teams work, operate, contribute to the design system. And I think that a lot of that has to do with the culture of the organization that they're in. But another part of it is there's this idea that in a 300 person team, everybody has to be involved in all of the decisions relative to the design system. I love the idea of taking some small cross functional section of people and saying, you are all the decision makers that are empowered to do this thing. It seems like that's really helped you drive new product value and new innovation. Do you have some examples of where that's really worked?
Meredith [00:16:11]:
Well, yeah, absolutely. We use it in a couple of ways, too. So sometimes we're looking at it in more of a longer term visionary view. And so we have some initiatives that we're working on that are one, two years out that we have designated some leads to go look at now and start defining the value and how we might do that, because we know they're so big and foundational pieces. And so they start early and they're going through and they're meeting twice a week. We're doing ux explorations. We're talking to customers to get feedback. We're working on some technical spikes to figure out what we could be doing.
And this might take us something like six months or a year if it's a really large impactful initiative. Most of ours are a little more short term, meaning looking at the next product release. And with those, when we're looking at the next product release at the beginning, we say, what are our priorities for this product release? And then we define the top initiatives that relate to those. And then those are divided into those smaller, cross functional teams, and they go through a whole discussion process. And that discovery process really gives them the time and space to define what we need to actually do, how we accomplish that, and get to a much clearer definition before we go in and actually build it. So at any time, our product managers could have three or four of those going on and kind of working through with that team getting through to completion, and then they might be looking at one longer term, one that will help really impact the roadmap in the future.
Chris Strahl [00:17:35]:
Yeah. You know, what's fun is what you're describing is a lot of the promise of design systems that we talk a lot about. Right? Like, free yourself up to do the research, to spend the time doing the exploration and how that derives business value in terms of better product. So I think it's cool you're living in the future a little bit where having a design system now for a while, that's fairly mature, you are able to structure the work around, being able to do those highly valuable things that few teams feel like they really, truly have time for.
Meredith [00:18:10]:
Yes, I feel very fortunate, actually, with where we are and how we've evolved this. It has taken time and work. I will say. I know when I started with the design system, it was a little bit more towards the order taking side and reactionary, and it took a lot of work to try to figure out how do we get ahead? How do we shift left, how do we think bigger, not just in the moment, but of the future? And that took kind of a mindset change both for the product team and then, of course, for the rest of the team and bringing them along for that and really getting them to see the value in it. And I think once they did, it's not even a question anymore. Like, this is so much easier and better and better outcomes that it just makes a lot of sense and the team is excited to do this type of work.
Chris Strahl [00:18:52]:
So what did that shift look like when you go from this place where you're feeling more like order taking into more of a proactive idea of what this could be and where do you feel the inflection point?
Meredith [00:19:06]:
For us, it was really looking ahead at where does the business need to go and be in the next two three years starting to look up and say, what is our product going to look like and what are we going to want to do to support that and really understanding then from there, how can we break that down into the work that will be meaningful with that foundational piece of the design system? How do we make sure that we're going to be ready for that? And at what points in time will we need to do that? So a lot of that's just looking kind of at the vision and breaking down the work and understanding kind of what it'll take to get there and looking up and being aligned across the other business areas and looking at where the customers will be and what our goals are as a company. All of those things matter as we look at this. And so I think we bring that aspect is, you know, let's look up, figure out what the business needs, what the customer needs in the long run, and then let's bring that down to how do we help deliver it? What do we need to have in place for that? And then we get into the more tangible pieces of, okay, how do we actually build whatever that might be, or expand our token library, if that's what's needed, or add a low code theme builder, if that's what's going to help our customers? All these things are things that we realize that that's where we're going to need to be at that time. So how do we now start that and get to those points?
Chris Strahl [00:20:24]:
Yes, it's amazing. I love this conversation because once upon a time, I was a product manager, product owner, and I never got as far in my career as you are, largely because I made a change. But, like, one of the things that was always difficult to encourage people to was do like, the lookup thing. Like, spend some time thinking about how you answer those big questions more systematically than deal with necessarily, like, the pain that's right in front of your face. And I think that there's so much of that that is an encapsulation of the value of design systems that, I mean, a lot of the company that I co founded was based on that lived experience that I wanted to be able to see other people live in a better world. And it's awesome to hear that it works. I think that that gets me really excited to hear like, hey, here's somebody that has done this and is feeling that glide associated with when you're able to really systematically solve a lot of the challenges an organization faces.
Meredith [00:21:19]:
Yeah, I think another piece of that, too, is that the design system is included with all the other products in terms of same expectations. So if we're doing a review of the roadmaps a year out or strategy three years, the design system also has to have that. We are not just waiting to hear everyone else's ideas and then understand how to implement it. That's certainly a part of it is working with them. But we have to be in lockstep and we need to be actually presenting these ideas, coming up with these big impactful pieces. And again, it just comes down to having it being treated like a product versus a piece that's maybe tucked under design or ux. It's actually elevated to the same level as everything else.
Chris Strahl [00:22:03]:
That's awesome. When you think about what that roadmap and what that looks like, when you think about some of these initiatives that are two years out that are explorations of value and everything like that, where do you see this headed? Where are those new explorations of value leading you, especially as it relates to the design system? I think it's interesting to talk about ServiceNow as the product company, but specific to the design system. Where do you see these huge value unlocks that you're working yourself towards?
Meredith [00:22:31]:
Yeah, it's very exciting. We are looking to figure out how to better open up the design system and to do that. What we're thinking of doing is creating more of a base foundational design system that'll be kind of the building block going to more of a systems of systems approach. And what that's going to do is it's going to unlock the ability to have different systems for different ecosystems. So one will be our workspace one, like we already have. We're also going to look to have a design system for builders, some of the internal tooling the customers see. And then as we look at things like some of the more web applications, like I mentioned earlier, with the ones that customers really need to customize, we're going to be unlocking those components greatly and putting a lot of configuration options in there so they can still stay in the box and not have to actually take our code and own it. They could still work with our code, with our design system, and they can configure and save it in the way they want to get the functionality and layouts they need.
And then on top of that, we're looking to see how do we really allow them to fully style everything. And this will be things like through more of the design tokens, through greater flexibility in the builder and in our theming capabilities. And so really pulling all that together to open it up, let them build upon it and configure it and stay in the box, and then get to a point where they really can impact the visuals so it looks, feels and acts exactly how they want. So it'll be a big endeavor that's going to take us probably two or three years to get through and actually see through.
Chris Strahl [00:24:05]:
I think if I were to describe the zeitgeist of how enterprise thinks about the future of design systems, that's like the top three things. Better theming systems of systems, more ways of exposing this to allow others to compose and change patterns and experiences. And that's really awesome that this is stuff that you're actively working on creating.
Meredith [00:24:27]:
Yeah, it is exciting. And then I think the other missing link we have right now is in some ways we're like the best kept secret. People don't know we have a design system because we don't usually publicize it. It's just been built in and is a part of the value we provide. And it hasn't been its own thing externally. So now we're also looking at how do we better provide the guidance, best practices to our end users, so that they have the experience and the tools to help them to build the best ux, to have the best patterns, you know, to really make these great applications. So we're going to be doing things like actually releasing a public design system website, just like most design systems have to help provide that value and that guidance so that our customers will really be able to benefit from the knowledge that the design system brings.
Chris Strahl [00:25:17]:
Yeah, there's this interesting pattern that has sort of developed in the conversations I have with lots of folks that are deeply in the design systems. Right. And it's funny how it expresses itself because you talk to people that have fairly advanced, fairly mature design systems, but also really ambitious ideas of what the design system can do. And almost everyone that is in that camp has talked about the design system more as the way of working instead of necessarily its own distinct thing. And some people have gone so far as to say, like, our design system intentionally doesn't have a name because we want it so deeply integrated into just the way that we do things, that it feels natural or it feels like to be a part of the team, you have to do it this way because it's the right way to do it. And I think that it's interesting to talk about it in terms of a design system that's also represented as a product, because, yes, it's a distinct thing. It is also very intimately tied to the way that you all build everything.
Meredith [00:26:14]:
Yes, it is just a part of how everyone builds here. It is integrated into all of the systems that they use and it's absolutely an expectation that teams will use it. And in that way, I think we're very lucky. We don't have to go through the kind of battle of asking people to adopt it and to use it and really push on that. It's just there, people use it, they see the value. It's more of a question of why wouldn't you? And of course, there are times where there are limitations and people do need to go around it, but, you know, that's absolutely an exception for us versus, you know, what would be a norm at some places.
Chris Strahl [00:26:50]:
So when I talk to product management people, I always like to bring up the idea of what is the value from a product standpoint. Right. And for a very long time, our product metrics have been about how much surface area can we create inside of applications. And I would say that recent economics and industry trends have created a refocusing away from proliferation and surface area and more into value creation and quality. As we start to move towards new ideas of what product metrics are, I think that you all are well suited to say this isn't about how much we can ship and it's not about necessarily how fast we can ship it. There's a lot of the things that you talked about that are about baking in quality. When you think about the idea of does a design system make you build better products? My assumption is that your answer would be an unequivocal yes. But I'm really curious to see how it does that.
What are the things that a design system does that people internally, or you could encourage other people externally to look at that represent a better product?
Meredith [00:28:03]:
And the answer is definitely yes to that one.
Chris Strahl [00:28:07]:
Good. I guessed right.
Meredith [00:28:09]:
Absolutely. I think that that's the direction it should be going in for a design system is high quality componentry, all the code, we ship everything. And I will say our team is the highest quality team out of all of platform and servicenow, which is amazing. But what that means to me is it's because our standards are so high and we have baked in so many ways to do all of these checks to make sure that we are providing things like accessible components that we're doing through all the 2.1 aa checks that it meets all of the other quality bars that we have, we have a full definition of done that has, I think, twelve different criteria that every single piece of code has to go through before we ship it. And so that is just ingrained into our design system, into our engineering, into our quality assurance team, and they do a great job with all of that. So part of it is that it's just built in and it's a standard and we believe in it. And we are also, we are a sister team to an accessibility team at Servicenow. And so that actually is really helpful too, because that accessibility team constantly helps to raise the bar on what we're doing and provide best practices.
And whenever we're going to make a change, let's say, to an existing component, we go and we check with them and say, hey, what are the implications of this? How is it going to change things with accessibility? What about tabbing? How would that work? And you have to run down the whole list and just make sure that we're really thinking it through. So we do that early in the design phase and we talk about those things before we even build them. Then when we build them and we queue them, we actually check that and verify that that's in. So that's absolutely built into our practices.
Chris Strahl [00:29:45]:
Yeah. And when I think about quality, like accessibility is one of the first things that comes to mind and the ability to say, like, we have a focus here because we believe it reflects on the quality of our product and that is enabled by the design system. I've had the great fortune to be able to see a little bit under the hood of how you all operate and being able to see the automation and the care that is put towards the craft, especially around accessibility. It speaks to the commitment to quality.
Meredith [00:30:15]:
Yes, absolutely. And I think our team also builds a lot of automation in a lot of ways, including things like a lot of our test coverage. We're very thorough in all of that and making sure we really have, again, the highest of standards since if we have any issues, it goes throughout all the software and our customers products and we don't want that. So we try to be proactive. Another area too, to know about is that we have a product that helps our customers to theme their products when they go in there and they can make choices around things like colors. They have controls where they can change colors even within components and down to very granular levels. So that's great in terms of flexibility, but it can be very dangerous for something like accessibility. So we have built in things like accessibility checkers, where when you go in and you're changing your colors, we know what the background color is, we know what's going to lay on top of it.
We can do the contrast checks for you, provide you alerts, and then if you want to change it, which we hope you do, we actually provide a list of accessible options for you. So we make it really easy that you don't have to guess. You don't have to wonder if you're meeting these things. What happened when you adjusted it? We want you to have that control, but then we also want your end experience to still meet the same high standards that we have.
Chris Strahl [00:31:28]:
Yeah, this is one of the things I was talking about that, like, I got to get a little peek at, and it's really cool to see how much care and thoughtfulness goes into it. I would say it's a level of care and thoughtfulness that is on par with any other major enterprise product experience. And what's cool about that is that's the design system at work, providing customer value. It warms my system's loving heart to see that in such a preeminent featured way as a part of product capabilities.
Meredith [00:31:58]:
Absolutely. And our customers love it, too. I think they're so happy to have an easy way to achieve their goals and to meet the standards that they would expect.
Chris Strahl [00:32:07]:
Awesome. Well, Meredith, this has been a fantastic conversation. Thank you for coming on. Really excited to keep talking to you as we watch these next steps over the next couple of years.
Meredith [00:32:15]:
Great. Thank you so much for having me.
Chris Strahl [00:32:17]:
This has been the design system podcast. My name is Chris Strahl. Have a great day, everyone. That's all for today.
This has been another episode of the Design Systems Podcast. Thanks for listening.
If you have any questions or a topic you'd like to know more about. Find us on Twitter thedspod. We'd love to hear from you. Show ideas, recommendations, questions, or comments. As always, this pod is brought to you by knapsack. You can check us out at knapsack.cloud. Have a great day.