If you’ve ever struggled to balance perfection with business reality, this episode is for you. In this episode of the Design Systems Podcast, Chris Strahl talks with Noelle Lansford, founder of Shep, about why chasing the “perfect system” often breaks more than it fixes. Drawing on her experience across startups and Fortune 5 companies, Noelle argues that design systems succeed when they serve people and the business—not when they chase architectural purity. She and Chris dig into the realities of relational alignment between design, engineering, and product, the shift from component factories to consulting mindsets, and what AI means for the next generation of design leadership.
Here’s what stood out:
- Perfection shouldn’t be your goal
- Design systems teams should pursue an infrastructure + enablement structure
- Systems of systems thinking works—if the cultural conditions are right
- AI makes iteration faster, which makes human oversight more essential
Guest
Noelle Lansford began her career as an engineer on design system teams before transitioning into design, where she discovered her passion for connecting the technical and human sides of digital product creation. Today, as the founder of Shep, a design systems consultancy that partners with organizations from early-stage startups to Fortune 5 companies, Noelle helps bridge the gap between design, engineering, and business strategy. Her work focuses on creating systems that balance structure with flexibility, prioritize people over process, and deliver lasting business value instead of chasing perfection.
Transcript
Chris Strahl [00:00:00]:
Hi, welcome to the Design Systems Podcast. This is the place where we explore where design development and product overlap. Hear from experts about their experiences and the lessons they've learned along the way, and get insights into the latest trends impacting digital product development and design systems from the people who pioneered the industry.
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 tell us what you think, send us a message over on LinkedIn. You can find a direct link to our page in the show Notes. We'd love to hear from you.
Chris Strahl [00:00:26]:
Hey everybody. Welcome to the Design Systems Podcast. I'm your host, Chris Strahl. Today I'm here with Noelle Lansford. Noelle is a consultant. She has her own consulting business. She's currently working with Alaska Airlines. She has a huge background in software engineering, design, design systems.
Nicole, why don't you say hey and introduce yourself.
Noelle Lansford [00:00:42]:
Hi. Thanks for having me, Chris. This is going to be super fun. I run and own a company called Shep. It's a design system consultancy. I work anywhere from stealth startups all the way to globally recognized Fortune 5 companies. Before that I was just working in design systems, doing some engineering, some design. Ended up fully flipping over onto the design train, but still get to use my engineering skill sets when I'm consulting.
Noelle Lansford [00:01:11]:
So I'm super excited to be here. I'm very excited for the topic we have today. Thanks for having me, Chris.
Chris Strahl [00:01:16]:
Absolutely. And I think there's a lot of crossover in the idea of design and engineering as a part of this conversation, in the way that you think about how you construct a system for scale. So as we were meeting before the show, we were talking about this idea of the decisions we make as they relate to systems oftentimes are made with our body of knowledge. So as a designer, I think about things in one way. As an engineer, I think about things in another way. And when you have those sort of cross pollination of ideas, very often the way that one discipline thinks about something isn't really fundamentally serving that other discipline. And I kind of wanted you to start out with a concept and that concept is all about how do I think about the perfect system. And we're starting with this because it's kind of interesting.
Chris Strahl [00:02:07]:
It's very heady topic about what that looks like with the intention of understanding a little bit more about how we would go about building towards that perfect system.
Noelle Lansford [00:02:15]:
Yeah, I love that. Where I like to start with anyone. And I'm sure You feel this way as well. Spoilers. There is no perfect system. My personal mantra when it comes to design systems is design systems is 90% people. The rest of the 10% is easy production work. Easy is generous.
Noelle Lansford [00:02:35]:
But comparatively to the other 90% of people problems that need to be organized, the 10% of production work is not hard by comparison. So when I think about what the perfect system would be, I'm not thinking about the perfect architecture, I'm not thinking about the perfect component. All of those types of things that we like to think when we're in the weeds. Like, oh, if I just had this, it would be so much better. Where I see the perfect system is a not possible but a optimized and ideal communication strategy between three primary disciplines. Of course, more disciplines would be included, but the three that are the most common being product and business, engineering and design. And if those three parties can have relational alignment, then that to me would be the goalpost for a perfect system because I think the outcomes from there would be optimized for the problems at hand at that Org.
Chris Strahl [00:03:31]:
So when you think about that, like relational alignment, that's a really loaded term. And I think that this is super interesting and it's kind of the meat of what we want to try to talk about here. Right. Is when we think about what alignment means. Give me a sense of when you think about something that is like really well aligned.
Noelle Lansford [00:03:50]:
Yeah. I think when people know what's going to happen next, that to me is like the key indicator of alignment, which sounds really obvious. And so I'll dive into what I mean by that. If a consumer says, hey, we need X feature on this component, I would love in my perfect system for every party in that system to already know what the other party's going to say and know how to work with that. Oftentimes that's not the case. And even on a design system team, which one of the primary claims of a design system team is bridging the gap between design and development on behalf of an organization so that those agreements can scale. If there's disagreement at that stage and those disagreements scale now, they are inside of the products that that company has. So that feels abstract, but walking it back to like a component.
Noelle Lansford [00:04:48]:
As an example, if three different parties want to go in three different directions and that's never resolved by the time that it launches, then that's going to be misalignment on that component versus an alignment on that component.
Chris Strahl [00:05:03]:
There's some sort of Spider man reference here. Uncle Peter with great power comes Great responsibility. I think we've actually said that on the show before, which is funny. But that idea of I can scale the good and scale the bad is absolutely true. And it's one of those things that when Knapsack thinks about implementation of a system, one of the things that we try really hard to do is not make it single sided. We don't like to have it be like design, build something and then you integrate code into it. Or we take a component library and then we layer in the design over the top of it. Largely because these pieces of misalignment exist and it's no more present than in things like naming.
Chris Strahl [00:05:37]:
Right. Just understanding, is this a tile or a card or is it a banner or film strip? All those different little agreements are very important to the success of the system at scale. I think that one of the things that you brought up that was really good about this is that we also have a product conversation that we have to have there around what does the view of product or the role of product specifically as it relates to a user also feel like? And there's almost this sort of like service model agreement that we should be tying into these things that I think is often really overlooked. Like, like, hey, we're all just building a system here. But like you said, this is intended to serve dozens or hundreds of products at scale, be implemented thousands upon thousands of times. And getting it right is really important.
Noelle Lansford [00:06:23]:
Totally. I think in my practice, one of the reasons why I even decided to go into design system consulting was I saw this massive gap of businesses feeling underserved by design systems. For a while it felt like design systems teams were really, really aligned between design and engineering. And you would get to this point where they were so aligned that they were then not serving the business, but they were making a perfect system, technically perfect system by design standards. And it was like, can I get the highest version, the most heightened version of the perfect system? Whereas now what I see is I'd rather have a imperfect system that serves the business needs really, really well.
Chris Strahl [00:07:07]:
Yeah. So from that business needs perspective, this is really fascinating to me because everybody always wants to say like, I have my specs, I have my components, I have my stuff in figma. It's exactly aligned to code. It's got all of these things that really tie super well together, but ultimately can still fail that service need. Tell me what that looks like. What happens when you see a design system team reach nirvana, yet still it can't get funded or it goes into this black hole of like, hey, this isn't a problem that we're going to address anymore or people's job roles change. What is the causality of that, in your opinion?
Noelle Lansford [00:07:44]:
One of the things that we saw in kind of 2022 through probably 2024 probably bleeds into this year as well. But there's been a shift, I would say, in 2024, but during, like, kind of when mass layoffs were at their peak, I think we saw how this played out really vividly, or at least I did. This was prior to me starting my business. I was a design system ic and I kept going from design system team to design system team that would have the funding cut. And so I felt like I had a first row seat of this playing out. We would get a perfect system. And really the pinnacle of the problem was it was so perfect that we had to keep telling the business no on key things that they needed. So obviously that means, well, we're not just paying you to have fun and make components, so we're gonna have to adjust.
Noelle Lansford [00:08:37]:
So I saw that played out. Of course, that's not what happened to everybody, but that's one iteration of it. I think design systems for a while had such a bad reputation because of that trend. I will never forget. I was looking to interview at a specific company. I had reached out to one of the employees that I knew, and she took me out to coffee and. And we were talking about design systems, and she's more of a product person, and she was saying, hey, I don't know if we have a design system opening, but tell me why you like design systems so much. And so I like dive into it.
Noelle Lansford [00:09:11]:
Total nerding out, like, oh, I love design systems. Cause of this, this and this. And then she just kind of sat there. She just looked confused and disappointed and she was like, do you just enjoy telling people no? And I was like, oh, my gosh, that's great.
Chris Strahl [00:09:26]:
Yeah.
Noelle Lansford [00:09:26]:
And that was like the aha moment for me where I was like, oh, this is how people feel about it. Like, people for a while at a lot of companies kind of got hurt by a perfect system mentality. And so, yeah, I think that's what a failure looks like is like, it's failed so hard that somebody's interpretation of a design system team is a controlling, perfectionistic team. Which, you know, it sounds really harsh, but because of that, design system teams have largely shifted in their mentality to be more business oriented out of a survival mentality. I think a lot of people are still in that survival mentality and haven't really matured that process that's coming up.
Chris Strahl [00:10:08]:
It's interesting because I tend to think about these things kind of like systems of record, right? Where you have lots of fundamental systems that run a business. And those fundamental systems are things like your accounting system or things like, you know, your CRM or JIRA I think could easily be like work tracking, right? We don't really have this concept of that system well ingrained for like what makes up your products. And I think that design systems are doing that and I think that we don't really treat them like we treat other systems of record. We treat other systems of record as these like semi sacred yet imperfect places where you go to get a bunch of data to then go like do something meaningful with it. And I think that there is all this investment through the period that you described, like 2022, 2024, where you had all these people that were trying to invest in this idea of that perfect system of record that was somehow immutable. And in that mentality, I think that there was a lot of damage done to the idea of what do these systems actually serve. And that is clearly your point. When I think about this in the relative context of do we treat this like an accounting system or do we treat this like a CRM or something like that, I think that it provides a really great backstop for how we talk about this stuff where you can say like, hey, look, you know, you can have a perfect accounting system, but you still need to do journal entries.
Chris Strahl [00:11:27]:
You can have a perfect CRM, but you're still going to have contact records that need like data enrichment. You can have all of these different aspects of the way that the business functions. But that doesn't mean you stop investing in them or that they're always in this like very perfect state. As the business needs adapt, the system has to adapt to the business. It can't be the other way around.
Noelle Lansford [00:11:45]:
I think that's spot on. You know, during this time period, the age old debate of is a design system a product or a platform? Came back into full swing. And I don't really like that juxtaposition when thinking about this particular problem because I think design systems as a product has value and design systems as a platform has value. But I think they're both still metaphors for what's really going on. And there's helpful things and unhelpful things to pull from each when I'm thinking about what's helpful from a product. Yeah, Design systems for a long time have had a hard Time tracking and reporting success frequently and often. And for that reason, it's very helpful to pitch your design system as a product that needs to have personnel and infrastructure in place to be able to storytell and socialize with people that have been hired in, have the skills to do that. Whereas a platform is really helpful to understand that it's not like other product teams, it's serving a foundational need to lots of teams and should that team be put in jeopardy.
Noelle Lansford [00:12:50]:
It's not an isolated problem, it's a organization wide problem at that point. But really what I think a lot of design system teams get overlooked like their value is really in having visibility into all of the products and stepping in to consult and help and not even always give tangible output as part of what their highest value is. I think the idea of a component factory design system is starting to go by the wayside and it's like, oh, well, what else is there? I think there's a lot of value in the consulting that can happen from a design system team and not from a place where I feel like it sometimes can feel condescending of like we have this elite force of people that know the best way to do stuff. I don't think it's that it's here's people in your organization that you know that are peers with you that have visibility into all the other products. Like why wouldn't you want to tap into that?
Chris Strahl [00:13:45]:
There's a lot of layers to that, right? Because there is this idea that like you said, was very in vogue of product or platform. And I think that everybody's kind of started to come around to the inadequacies of that conversation. I think there was another side that you brought up about like this idea of component factories. Right. And it's funny you mentioned this earlier. I'm glad we circled back to it. The idea of like, do I make a thing that is a simple abstract unit that's highly modular, that can be adapted to become a whole bunch of other things, or do I make patterns and those patterns actually have some intrinsic value, even if they're less portable, less modular? And so the third part of it being then like, how do you think about the connection point in the business with a bunch of teams that very rarely would otherwise talk to one another inside of a big company if it weren't for the fact that there was this central thing that they all used and all united around those kind of three layers are the immediate things. I see.
Chris Strahl [00:14:37]:
And so unpacking that one by one, we talked a Little about like product platform. I've kind of come around to the viewpoint of like, this is infrastructure. And when we think about systems of record and we think about like what the word system means, I always go try to draw from examples that are out there in industry. This reminds me so much of like DevOps circa 2011 or 2013 or something like that, right? Where we all had all of these people that were incredibly well paid that went around setting up infrastructure for big companies. The cloud revolution happened and now all of a sudden we had all those people setting up infrastructure in the cloud. And then you got things like kubernetes and all this other stuff like that, like all these orchestration environments that basically took that and said we don't need to hire 80 people that understand how server configurations work and how they heal themselves and stuff like that. We need to have a single centralized orchestration method. That orchestration part then goes and serves as infrastructure for every part of the business.
Chris Strahl [00:15:31]:
Just like how every business needs code to run their app, every business needs infrastructures and servers and stuff for that code to live on. And I love that because that is a very concrete parallel to what ultimately is going out of a company in terms of digital product.
Noelle Lansford [00:15:47]:
On the tangible side, I think infrastructure is a really good word for like what the delivery and output of a team is. And it's all digital, so you can't really say like the real physical thing, but as physical as the digital gets. And then on the intangible side. So I think infrastructure, yes, that's the output. And then I think the intangible output is enablement. So put those two things together, it's like an infrastructure and enablement team.
Chris Strahl [00:16:13]:
So when we think about how we convince others of the value of that system, if we couch it in this idea of infrastructure, we think about it as like, this is a critical thing with which to build your products on top of. And when your product is built on top of that, all of a sudden all those things that we talk about as traditional value props for a design system like this helps you build faster. This is more scalable, more efficient, it costs less. Yes, you invest in the infrastructure of the system, but once that infrastructure is up and running, you can reuse it thousands of times across all these different places. Those things really come to light there and they really shine in that infrastructure thing and they're very concrete and business people get it. And so I tend to really gravitate towards those representations of value in that space. When we think then about like the idea of do we build component factories or do we build patterns? That's kind of the next layer to me because now all of a sudden you're not talking about the infrastructure side of things, you're talking about content. So what is the content that goes in the design system and how do you think about the use of that content? And there is this sort of split where like, of course you still need components or maybe you don't.
Chris Strahl [00:17:19]:
If you believe in component tokens and all that other like, stuff that's out there, but presuming that you believe in the world where components exist, you need those foundational elements, but how do you represent those to users, to consumers of that design system is, I think, where a lot of this changes. And I'd love your take on that idea of like, are we trying to build components that have this like high value and modularity or are we trying to build patterns that have a high practical value?
Noelle Lansford [00:17:46]:
I think it depends on a lot of factors, obviously. But the high level take is, do you have a design system yet? And if you do have a design system, what's in it? If it's a bunch, a bunch a bunch of components? And I'm probably going to say, yeah, let's figure out the minimal amount of components that we need that people will get off the shelf when not being used in a pattern. It also depends on the maturity of the product. Like if we already know fully reusable feature flows, then there's a lot of value in my opinion, of reverse engineering it and starting with the larger patterns, working backwards and standardizing things that are smaller a lot slower and standardizing bigger things sooner. I think that take is probably similar usually for people that are just getting started as well. I think it was really popular to start with the button, like as a component, like, yeah, let's standardize a button, standardize some colors, things like that. There's actually this really great conversation hosted by Ben Callahan on the question, and it was a topic called Inside Out, Outside in. And it was do you start with the foundational elements or do you start with the biggest elements? So in this case, patterns and which direction do you work? And so kind of the outcome of that conversation was those two ideas probably shouldn't be pitted against each other, but they should be pick one area of focus and then continually work on the other one as well.
Noelle Lansford [00:19:10]:
And so for me, I tend to focus on a outside in approach just because I come from a world where people have made, you know, hundreds and hundreds and hundreds of tokens that they don't actually need, but they anticipated that they needed. And now at this very fundamental level, you have all of this cleanup to do because you don't know where those 1 tokens might have been used and where other ones wouldn't have been. And it's just a lot harder to clean up foundational elements than it is to create, for lack of a better term, a potential throwaway pattern. Like, if you're in a mode of exploration, I think that makes a ton of sense. If you're in a mode where you really do need some more stringent and rigid design practices, then maybe starting with foundations is a good idea. But those are kind of the levers that I think about when I think about kind of an outside in versus inside out approach.
Chris Strahl [00:19:56]:
I agree with most of that. One of the things that was interesting is the idea of a throwaway pattern, right? This idea that when you have a pattern that you're building it and you don't expect to use it, what value does that have? I think that there is value in the exploration of that pattern. Just like how when we're all working in Figma, we throw lots of stuff away, and the intention is that you're learning. I mean, even on the code side, the Mythical man month always talks about build one to throw away, right? And all those sort of like seminal pieces of literature around the ideas of how we build and why we build. And I think that even, like Christopher Alexander in a pattern language has lots to say about this as well. When you talk about, I forget exactly how many different components are in every building. Something 70 something, I think. And the way that you come about discovering those components is you look at that outside first.
Chris Strahl [00:20:40]:
You go around and you look at a bunch of different buildings and you decide like, oh, hey, that's a window, and hey, that's an entryway. So all of this is sort of intrinsically in this place where to develop the language that you want to have as a company, you have to kind of decide, am I starting with letters or am I starting with words, or am I starting with the story? And very often I feel like organizations, they ignore the story and focus on the letters and the words. And that to me is kind of like the backward approach, because that gets into the problem that we were describing earlier in the chat, where suddenly you're in this place where you have a system that's really perfect and really brilliantly beautiful, but the story's boring.
Noelle Lansford [00:21:21]:
That's right on. And I think just like patterns as explorations is a really interesting idea. Because it's like when I'm thinking about a throwaway pattern, I'm thinking about a pattern that's usable right now but is probably going to be thrown away later because the feature is still being developed and there's still value in reusability sometimes in that intermediary solution where it's like all these teams need an intermediary solution, what pattern can we provide that we know isn't going to be the final end all, be all, but is at least a stepping stone. We deprecate it, then we give them the full version later. I've seen that happen a lot and I've seen a lot of design systems teams get stuck there because it's like, well, we know we're going to have this other thing, so why should we make this intermediary thing now? And I think it's to your point, it's a storytelling tactic. It's, this is our story right now, this is going to be our story later. But we could still service our teams by building this thing that we know is going to be thrown out. And for that reason, in my opinion, patterns don't always have to be comprised of atomic elements.
Noelle Lansford [00:22:19]:
I think that is a good time to try out different atomic elements, especially when you're running a trial period like that for a pattern to get market research on what would happen if we did change some of those things. And I think sometimes we get so wrapped up in. Yeah, but this is the standard button. This is the standard form that we're like totally unwilling to try out something else. And I think a pattern is a really excellent way to try that out.
Chris Strahl [00:22:43]:
Absolutely. One of my favorite ones that we do a lot of experiments with is we were a lot of like big retail e commerce organizations and so like a shipping calculator block is really fascinating. And so you have things in there that are like ground two day, single day, et cetera. And it has pricing and all this other stuff like that. It's a radio button list, but it's also like a grid of cards and it's also got some selectors that are in there and stuff like that. And so oftentimes we try to think about that as like its own encapsulated pattern and that gets rebuilt all the time. And the reason why it gets rebuilt all the time is there's all these explorations of how lists function and how buttons function and how cards function that are pretty unique to how you handle shipping. And because that fairly unique need is something that when you're designing a product detail page or a shopping cart, you're just kind of like plunking in there.
Chris Strahl [00:23:30]:
From an implementation perspective, like from the idea of that person managing that shopping cart or that checkout flow, they're just like, yeah, shipping goes here. And the nuance in the design oftentimes happens in this entirely other separate place. And because of the way that E commerce is organized and how you think about different teams and stuff like that, it often doesn't really matter to the people that are managing that shopping cart or that product detail page exactly how that block gets included. And so it's a fascinating way for people to kind of experiment and play with other combinations of components that they wouldn't otherwise get to you because everything else is so like locked down or rote. And that ability to experiment, I think is something that still oftentimes leads us to better, more interesting outcomes and also gives people an opportunity to experience the system in a very creative way.
Noelle Lansford [00:24:22]:
Yeah, and also going back to that friend that I had coffee with that is like, do you just like saying no? I think that largely addresses that concern because, yeah, if you are only limited to being able to use the most atomic level stuff, you're never going to be able to experiment with patterns. Anytime you come to the design system team with a new pattern proposal, it's going to be met with, well, that's not within our standards. But then you miss out on a lot of really key interactions. And especially in the case of E commerce, buying things should be fun. And so you're going to need fun explorations. And sometimes standard inputs don't really cut that. They serve a purpose and a large purpose. But yeah, experiment with patterns like that that are industry specific or that can make your area of the industry stand out in ways that are helpful.
Chris Strahl [00:25:09]:
Hey everyone, I'd like to take a quick break and tell you about Knapsack's leadership summits. Every month we host an exclusive in person event in different cities all around the country, bringing together design, engineering and product leaders. These summits are all about sharing our learning with tailored discussions to address the challenges you're facing. The best part, it's totally free. Head over to Knapsack.cloud/events to find an upcoming summit near you and apply to join us. We'd love to see you there.
Before I dive into the whole idea of the service model behind this and getting lots of different organizations that don't talk to each other to talk to each other, one of the things I wanted to just lean into a little bit on this is I think we tried to solve this problem with systems of systems and we haven't totally given up on it, in my opinion. I think that systems of systems as a concept is still absolutely viable in the land of design systems.
Chris Strahl [00:25:58]:
And we haven't done a thorough enough exploration of that conceptually within the community here. Because the intention was you have some core foundational system and that holds some sort of immutable truth. So things like your brand palette and stuff like that. And then there's this extension of that that is a product system or departmental system or some other part of the ecosystem that has some level of diverse specific need. And then you can even go like one step further and say like, here's a very specific product based system. So all those systems inherit from one another. There's a systematic way of controlling and overriding the information that you're presenting. The hard part, I think is that these things get really, really complex.
Chris Strahl [00:26:40]:
And I don't think we've quite figured out how to cut through that complexity. And so people kind of throw up their hands and they say like, well, forget about it, we're just going to federate everything and we're going to have some core system that we publish. And then everybody kind of just implements it however they feel like implementing it. And that also comes with its own set of shortcomings because then you have all these different fragments that exist all over the place. And one of the core values that we propose or espouse in design systems is this idea that we can centralize the way that we maintain and update the things that go around our ecosystem. But if everybody implements that thing differently, what is that central thing to update? And so I'd be curious your take on this because I think that people default to federated models when they don't feel a sense of capability around systems, of systems based thinking or a single system is inadequate for them. And I see this pattern everywhere where you have heaps of consolidation across these big companies, right? We have seven design systems, but we only want one. We have 11 design systems and we maybe want three.
Chris Strahl [00:27:42]:
Like the Desire is there from a business use case. Talk to me about how you think about the implementation.
Noelle Lansford [00:27:49]:
I so far am a big fan of systems of systems for large enterprises. This goes back and why I am so passionate about that trivial conversation around is it a product, is it a platform? And I think this is where I see the big, big value of the intangible. Because once you have your core systems set up and the idea of a systems of systems, it's going to Be really, really hard to change any of that. And if I'm a business person looking at that, I might be like, what are they even doing? They're not changing anything. There's been no output from this core foundations team for I don't even know how long. But to me the role of a core foundations team, aside from getting that initial thing set up and then kind of screening requests of like the rare occasion in which something should go back that far to a change, is they're consulting with the rest of the systems that inherit from their system. And that's where that like key consultant, I have visibility into all of these different systems role becomes a really high value internal consultant if you allow it to be. So that's where I see when people go to federated, it's usually because they don't see the value in that or you know, there's a shortcoming on the foundations team that they're not operating in that way and sometimes it's both.
Noelle Lansford [00:29:10]:
So that is part of where I see like the business and design and engineering being in total alignment that like, hey, there's a lot of value in us being positioned here. And then when you get to the downstream systems then there's a lot more room for exploration. And I think that's the unlock that a lot of businesses kind of need is where can I explore and where can I standardize? And that's where I don't love selling design systems, especially systems of systems off of the sole idea of like efficiency and consistency because they're going to feel cheated later when you're like, well actually you need this other team that does the explorations and still is doing systems work and we other systems people are going to be foundations people back here and have next to 0,0 tangible output. It's like nobody wants to buy that. But if you flip that script and it's like no, we consult so that you can explore and we maintain the standards, we ensure that your standards are intact while tastefully exploring. And I think that's a really hard balance and definitely a shift. And I think systems of systems is set up really well to do that if those agreements are in place.
Chris Strahl [00:30:15]:
It's hard because like you said, a business user or a business decision maker in this case isn't buying a system, they're buying the output of the system, they're buying the speed, they're buying the reduction in cost, they're buying the efficiency. And when you tell them that they have to make lots of different investments over the course of a very Very long time. It's not surprising when people are like, okay, so when is this going to pay off? Or what am I funding again? And so when you think about the systems of systems concept, I completely agree. It's like you just described, like how do you have something that is really truly standard? And then how do you have like this more experimental place where people can feel free to make more mistakes or to do things that are a little outside of the norm. It's the same kind of argument that is ironically in front of designers a lot, right? Like, well, if you just hired me a bunch more UX people, we'd have better UX as a product. And that idea of like, well, we underfund that and it usually comes out in unfortunate things like accessibility, where the under resourcing of that means that like you're making compromises, but oftentimes those compromises aren't valuable enough for people to want to invest in.
Noelle Lansford [00:31:25]:
Yeah, I think that's a really important question that regardless of if you're doing systems of systems, you have to ask yourself really honestly, and it's a hard question, is this actually cheaper? Is this actually simpler? Is this actually more efficient? And if it isn't, it'd be better to do something imperfect that is those things.
Chris Strahl [00:31:48]:
So one last kind of meaty piece of this, right, is this idea of we're going to go interconnect a bunch of people that don't really talk to each other otherwise, right? You got product team A, product team B, product team C. All of them use some centralized system that's maintained by an entirely different team. And so just within a relatively simple ecosystem, that's four teams of people, four different management structures that probably don't even all report up to the same executive level group. And so in a situation like that, you're getting a lot of people inside of a big company of thousands and thousands of folks that don't really know each other, that operate in this place that is probably limited in terms of trust, that also operate in this place where they all have different ideas about how it should work or how things should function. And it creates a human quagmire of decision making and even oftentimes a really unclear line of authority in terms of who ultimately makes decisions inside of that organization. This is about service model design. And when you think about the service model design is by far and away within our customers, the most overlooked part of a successful implementation. People can build incredible tools, incredible infrastructure, have perfect componentry, but if they don't get the Service model.
Chris Strahl [00:33:08]:
Right. It doesn't work. And I kind of want to hear from you your experience with designing these types of models and then also some ideas about how we could maybe be better at this.
Noelle Lansford [00:33:20]:
The first thing that a lot of people jump to is leadership. Buy in is super important. I think that is important, I think, versus just saying the leadership is bought into the idea of a design system and leadership, there is leadership in place that is over. The design system is a different thing. And the second thing is what I feel like needs to happen more often. Design system teams, in my experience are often this unicorn team that has just decided that despite all odds, they're going to work together despite conflicting interests from their different parties that they report to. Sometimes people don't even do that and they're just forced to be on this team. That never goes well either.
Noelle Lansford [00:34:02]:
But what I would love to see more is multidisciplinary leaders that can take ownership of a design system and be a key stakeholder of that, who understands all of those different things. And it's almost like a buy in via that person where it's like that person, not that they necessarily have to be in the C suite, but some sort of single source direction, whether it be a director, manager, whatever it may be, versus kind of a more spread out approach of yeah, we have, you know, somebody from engineering that cares about this, we have somebody from product that cares about this. We have somebody from design that cares about it. Yeah, but who do all of those people report to? And I think that is also what makes it different than a product team. Like in a product team, it makes a lot of sense to have those negotiations, to have that push and pull. But on a system, if a negotiation between those three parties goes wrong, then that scales throughout the entire business. Versus having somebody with the multidisciplinary leadership in place to be the person negotiating with all those people. Yes, but still understanding, like, okay, we get the final say.
Noelle Lansford [00:35:06]:
There's not a final say person kind of outside of that. And I think that's a limited model, but that's one of the models that I've thought of that I think would help that service model design quite a bit.
Chris Strahl [00:35:17]:
Yeah, I think that there is this interesting balance, I guess is maybe the right word between this idea of like, look, a design system can't fail because the decisions scale everywhere and we have to also allow ourselves to make some mistakes and some compromises. And that's very challenging. Like anytime that somebody is the owner of a design system in an organization or especially A newly minted one. I'm like, ooh, you have no idea what you just signed up for. And oftentimes that is somebody that is doing a lot of pretty high level negotiation inside of the organization with marketing, with product, with technology, with design that ultimately has very far reaching impacts and that ability to understand how those impacts scale and kind of the mindfulness about where a design system goes, I think is a pretty essential skill. If you're in this place where you're the person that's leading that kind of an initiative.
Noelle Lansford [00:36:10]:
Yeah, if you're that person. I think the key question to ask that I think you baked into your explanation is where do I need to say no 90% of the time? And where is it okay and good to say yes to exploration? And I think going back to that idea of foundations versus patterns is a really good one for somebody in that position because, yeah, you should be exploring in patterns. You should be saying yes. And the good news is a lot of times requests for permission to. And I'd say permission with kind of air quotes around it. People ask permission from the design system team to do stuff. This permission to explore is like, yeah, yeah, do that. In patterns, the permission to explore usually comes through, I need a token, I need a new component.
Noelle Lansford [00:36:59]:
And that person as well, with the rest of the team, I think should have. In their mind, they're asking me for a token, but what are they really asking me for? They might be asking, hey, can I try out a new color in this pattern? And in their mind, based on the way that a design system has to work as it has over the last couple years, is you have to file in for a new token. The design system team has to go through a review process to see if the new token can exist. You know, if you're in a system of systems, where is the token going to go? Who is going to own it? All of these questions. I think that can be greatly simplified by exploring through patterns. If you have a team that's like, we just want to try out this color, we don't even know if we need it, instead of telling them no, be like, well, yeah, do you have this pattern? Can we help you build it and do it there? And then you, the design system team, get firsthand experience understanding the value of that token versus a 20 minute question in an office hour.
Chris Strahl [00:37:47]:
So I have one more sort of loaded question about this. We're in this place where our landscape is shifting dramatically under us as practitioners in design and product and engineering, where, you know, this wouldn't be a design system talk if it didn't include AI in some way. Right. Where AI is upsetting a lot of the power balance around the idea of how we think about design and engineering. And I think that a lot of what you described represent really virtuous power cycles or power structures inside of organizations. But not every organization is like that. There's oftentimes at best, siloing, at worst, like fiefdoms that occasionally war with one another for resources. And so when you're in this place where it seems like design has less and less power inside of organizations to have budget to make decisions, et cetera, how do we still feel like we're creating a service model in an age of AI coding and this explosion of the idea of how we make things with AI, how do you kind of see that service model maturing?
Noelle Lansford [00:38:51]:
Yeah, there is more of less. More underfunding of design in particular, and that is creating a power balance issue in a lot of organizations. And like you said, what I described is applicable to lots of large enterprise organizations, not even all large enterprise organizations. So it is a subset of. And yeah, then you have this elephant that is AI coming into play. On the one hand, it makes explorations like we're describing in patterns way easier and faster to do. And so to that, I would say, yeah, utilize that. If you have less designers, utilize the thing that can help you iterate and explore faster with less.
Noelle Lansford [00:39:27]:
I think that makes a lot of sense. On the other hand, you know, that might reinforce the idea of underfunding design. So, you know, we're kind of in that experimental phase of like, okay, which one is it going to be? If I was giving my friend advice that's a designer, I would say, yeah, use the AI tool because your prospects are going to be better if you know how to use that. But at an organizational level, I still think that it will come down to people and it will come down who has the influence to make critical decisions. You can iterate with AI all day long, but more than likely, we're far away from a future where AI makes the final go button decision on what goes live.
Chris Strahl [00:40:05]:
How do you think this affects who we hire, how we hire the types of people that are going to be getting these kind of jobs in the industry.
Noelle Lansford [00:40:12]:
Like, on the pessimistic side, I really feel for people that are juniors because I think it sets a really, really high bar for companies. And a lot of companies don't want to hire people that are likely to fail. And I think we're going to probably have a generation of unfortunately stunted designers that weren't given opportunities early. There's a lot of senior to principal offerings right now because people want strategists, they want people that know how to think about the problem regardless of necessarily if they're going to implement the problem. And so I think right now that makes sense for what we're seeing. But I do think from an industry perspective that's going to be a little bit shortsighted because we're not going to have more senior people after that. We're going to have like a really bizarre middle, icy level design group because of that.
Chris Strahl [00:40:58]:
Yeah, you see this sort of no man's land of all these senior folks that kind of came up in a time when product design was one way. And then this big AI transition happened. Everybody kind of got wiped out in that middle. And there's going to probably be a new crop of designers that are just like AI first, that are probably coming up now or soon. And in that middle ground, there's a lot of potential that's just not being realized. And I think that the hardest part, from a business perspective, there is like, there's a cost to training this people because they're not equipped with the skills that they need to be equipped with to actually be effective. And you have a hard time training experience, that's a long road. But at the same time, they're not innately AI native.
Chris Strahl [00:41:38]:
And boy, like I agree with you, it is really hard to think about today's grad and like, what opportunities are in front of them.
Noelle Lansford [00:41:47]:
I think that you're right. It's a unfortunate gap in the industry and it will likely be self solved by AI native designers, but not necessarily a sell for those people that find themselves caught in the middle.
Chris Strahl [00:41:58]:
Well, I do want to leave us on like more of a high note.
Noelle Lansford [00:42:01]:
I know, right? I was like, wow, what a bummer. Never listen to Noel and Chris again.
Chris Strahl [00:42:06]:
If you're 25 listening to this podcast, you're like, well, well, shoot. But the thing that I did want to kind of leave us with is when we think back to the sort of original premise of what we were talking about, about and that idea of building that ideal design system, you know, through your experience doing several of these now, I was just kind of curious, what are the things that have shifted the most in that ideal vision? You talked a lot about the trends in the way that we've thought about this stuff. I assume that mirrors a lot of your own thinking, but at the same time, like, if you had to pick one or two things. You're like, this was a major change in perception for me from the time that I first started doing this work to now. I'd be really curious what that.
Noelle Lansford [00:42:49]:
Yeah, I think you're totally right. A lot of what I've said has been informed by those mental shifts that I've had. When I first got into thinking about design systems, I was thinking about how to make something as efficient as possible and kind of in the early days, making things a lot less efficient by trying to be as efficient as possible. I think that was one of my early lessons, was just like, oh, maximum efficiency isn't actually maximum efficiency. So let's walk that back. One of my most recent understandings has been if business doesn't care, like why do it? And that sounds like dreary, but it's kind of, I don't know, it is kind of a valid question. It's like, if you're putting in so much effort to make somebody happy that doesn't want to be happy with your product, why make the product? A lot of people do like a design system evaluations to say, like, hey, what can we do better in the system? And I like to look at it a layer out from that. I like to do an evaluation of what does the business think of the design system? Where do they see systems that thinking as valuable? It may not look like the most traditional design system route, but if you start there, I think it can lead to a lot more positivity than going doc site searching and picking one out of a hat and saying, I want to build that one.
Chris Strahl [00:43:57]:
No doubt, no doubt. Well, Noel, thank you so much for your time, for your generosity and I really appreciated this conversation. This was super fun.
Noelle Lansford [00:44:05]:
Yeah, thank you so much, Chris. This was super insightful. I loved hearing your thoughts on this topic as well.
Chris Strahl [00:44:10]:
If you enjoyed this conversation and you want to hear more, we have the Design System Podcast that you can check out on the web or wherever you get podcasts. We also host Pattern Leadership Summits in major cities all around the country. If you want to go to one of these events near you, you can go to Knapsack.cloud/patterns, check it out and otherwise.
This has been your host, Chris Strahl. Have a great day everybody. Hey everyone, thanks for listening to another episode of the Design Systems Podcast. If you have any questions, topic suggestions, or want to share feedback, go ahead and reach out to us on link LinkedIn. Our profile is linked in the show Notes.
As always, the podcast is brought to you by Knapsack check us out at Knapsack.cloud. Have a great day, everyone.