Kevin Broich, Design Systems Architect at Cisco
Transcript:
Chris Strahl: 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 @TheDSPod. We'd love to hear from you.
Hey everyone, this is Chris with the Design Systems Podcast. Today I'm here with Kevin Broich, the design system architect over at Cisco. Kevin, welcome to the program.
Kevin Broich: Hey, thanks Chris for having me.
Chris Strahl: So you've had a really interesting journey at Cisco. You've been there a pretty long time for somebody in tech. I think you said 24 years, is that right?
Kevin Broich: 24 years, yes.
Chris Strahl: That's uncommon these days, is a nice way of putting it. With the musical chairs that we all sort of play in the industry, that's longevity that is unusual. But I think that there's an interesting sort of perspective that gives you on the evolution of design and engineering inside of the organization. Why don't you talk about some of the things you've experienced there?
Kevin Broich: Yeah, so I started as a backend software developer a long time ago, before .com buzz days. And back then, C++, C. Then every five years I sort of moved to either a different role or a different group at Cisco. And moving to different groups, it allowed me to grow where I didn't feel like my learning curve was kind of leveling off. And so I spent some time in voice, I spent some time doing Android and Java. And then I spent a few years doing a tech lead position at Cisco, which is very much a deep dive into us, like a single product. You're the subject matter expert, the technical go-to person, but you never get to see the canopy or above the canopy in the forest, you're always looking at the tree. And so I felt like at some point I was ready to move on to a new thing, and then I did move to the dark side, the design side of the house for five years, and that was an eyeopener.
Chris Strahl: Yeah, I mean that's a jump to go from Java and C, which by the way, when I was in college, I was a software engineer that was literally learning those languages, and then jumped over to the web and front end code. That's quite a pathway. What did that feel like jumping over into the design world?
Kevin Broich: I had always been interested in design. It'd always been sort of like a siren song for me calling me. I was always interested in design, I've got a background in architecture, and so the design, even on my team, when we didn't have design resources, I was always the designer. So I would always do the mockups for our group. But when I moved over to design, it really allowed me to learn the underpinnings, the psychological underpinnings of design, the vertical rhythm, progressive disclosure, golden ratio, things that designers had been telling me and I didn't understand. And so it really helped me to be paired up and mentored by somebody that had worked at Apple for 20 years. And that was the eye-opening part for me, was to really understand how design fit into a product and what that was all about.
Chris Strahl: Yeah, that's interesting. If you think about the early origins of design systems, I think we mentioned this before, but the whole Alexandrian pattern idea and the Christopher Alexander pattern language all comes out of architecture. That's kind of where this started was like, how do we build structures for people to live in or work in? And those patterns have then since been sort of adopted by the design system movement.
Kevin Broich: That's right. Yeah. There's even terms like design systems have been named after elements in architecture like keystone and become a foundation stone and things like that. So there is a lot of synergy between those two disciplines. And I think to be an architect, you also have to have not only the logical mathematical side, but the design side, the design sensitivity. That's a hard thing to have both of those skill sets, but to do them both well is equally hard.
Chris Strahl: Yeah, I hear you. I think that some low level APIs of knapsack are still called bedrock as sort of a nod to the foundation's idea. So tell me what happened in 2014? Before the show, you were talking about your first touch with design systems, and it happened around that time, which is I think reasonably common. That was when the San Francisco SaaS meetup was happening and everybody was talking about it. It was around the time that I first touched anything that could resemble a design system, but what did that look like for you?
Kevin Broich: Yeah, I always say necessity is the mother of all invention, but in our case, we had a couple dozen applications that we were sort of managing and making bug fixes on and maintaining and pushing out to AWS out to the cloud. And in terms of managing those, we had a small team. We were forced into figuring out how to scale and how to maintain these. And one of the biggest issues really was keeping them all consistent because a lot of the users of these applications were the same people that were coming in to leverage those tools. And so trying to maintain, keep that consistency became sort of a nightmare for us without having some sort of consistency on the UI.
And so I really got into CSS at that point, really focusing on that presentation layer, learned a lot about CSS. And eventually realized, let's just have a single CSS for all these apps, why have multiples? And so then we started using our CSS and sticking in as CDN. So we had sort of a single place where we had all the apps eventually point to. And that "Aha" moment came when we were able to flip on the switch to this next version of the CSS. And all of our apps were updated together in a consistent manner. And we just were like, "This is how you do it. We're on the right track here. We're onto something."
Chris Strahl: Yeah, I mean, I remember that light bulb moment also. That's really funny. The guy that ended becoming my co-founder, and we were working on a project for a big cosmetics company. And we ended up having a very similar sort of thing. We were always blocked on backend development. So we were waiting to have something to style, waiting to have something that you could apply CSS to in some interesting way. And when we heard as a part of that project that we weren't going to get the ability to have anything from our CMS team stood up until just a couple of weeks before the scheduled end of the project, we basically said, "Well, what if we made our own thing to style and then we were just able to copy that styling data?" And without knowing it, we built our first design system, where we had an abstraction of that brand or CSS implementation that you could then apply anywhere. And that was definitely this moment where both Evan and I were like, "Wow, this is really powerful."
Kevin Broich: And about the same time, Cisco brand was pushing a new design across as much as Cisco as they could get their hands on. And the problem was that they didn't have a design system at that time. Design systems didn't exist, but they did stumble across our UI kit and realized, "Wow, this is a great way for us. It's sort of a vehicle for us to drive that consistency." And it's already in the language of the developers, right? It's CSS, something they understand besides just having some set of Adobe or something, mockups, this is something developers can use today. And so we worked with them after that. So they sort of adopted it with us and we ran with it. It was great.
Chris Strahl: How did that go from there? I mean, that's been like God, 10 years ago? Holy cow. So going from there, what does that look like now?
Kevin Broich: So this is an internal open source project, which I found myself doing a lot of the internal open source support. And I think over time, eventually it kind of got passed by. Because there were other parts of Cisco that were looking at building fully formed design systems. And this kit was really just the CSS, so it didn't have all of the other stuff that goes into a design system. It didn't really have an iconography guidelines, icons, illustrations. It was missing the do's and don'ts, the guides. It has sort of over time been deprecated at Cisco in favor of some of these other fully formed design systems.
Chris Strahl: So when Cisco was looking at how design and in particular systematic design gets applied to products, I think that there's obviously a sense of scale because it's Cisco, and it's a big global company that has heaps and heaps and heaps of products, probably thousands if not more. And you also have this thing where those products are sold in very interesting ways. Go ahead and talk a little bit about that. I think this is a sort of hidden value here that I haven't heard of before.
Kevin Broich: Yeah. So we have different parts of Cisco. We have cisco.com, they have their own design system. We have parts of Cisco that are still focused on end consumer products like Webex and they have their own design system. But the groups that I'm in now, we have a need for a design system that allows our products to be sold both a la carte and in bundles. And the customers, they're demanding that our products work together seamlessly. And so we need a consistent sort of user interface, something that sort of brings them all together. And it was something that was actually noted at the executive level that, "We really, if we're going to sell this like this and bundle this, it needs to be consistent, it needs to be familiar to our users, it needs to be something they can jump from application to application and not have to learn a whole new interface."
Chris Strahl: So you have product A, product B, and product C. If you're a a la carte buyer, you may just buy one of those products. But lots of people buy all three of those products together. If you're an a la carte consumer, it maybe doesn't matter that much that product B and product C are a little bit different. But if you're buying all those products together, you're thinking about that one thing that you're buying and you want A, B and C to all feel, look, act similarly.
Kevin Broich: That's right. It needs to feel familiar, it needs to have shared DNA of some sort. And I think having multiple products, over time, Cisco does purchase companies and then we sort of bring them in, we onboard them into our system. We at some point have to get them into a design system. So we have that uniformity, that consistency. We're just now starting to realize this at the upper levels that this is important, that uniformity that consistency, that's really important. That's part of how we can sell the product. It's not just an afterthought.
Chris Strahl: There's two questions I have that come from that. The first is, Cisco didn't build all these products probably. And so when you acquire a company or you acquire a product line from a company, what does that look like in terms of adoption into your existing design system? And secondly, when you think about the business case for this, obviously there's a technology case, we want to support less software. Our surface area needs to be smaller, but the business case for this is an interesting thing where you're basically talking about executives buying into strategy. So stack one of these at a time. First, how do you adopt something that wasn't yours to begin with?
Kevin Broich: Right. Cisco is a lot other big companies, we do purchase [inaudible] companies over time. And so we are sort of a collection of smaller companies in a sense. And to be honest, a lot of them come in and they don't want to give up the way that they do things. And so there's a time period, an adjustment period, which takes them from, "Okay, look, we just bought by Cisco." And into eventually, "Hey, we're part of their portfolio now and we need to look like the rest of their portfolio." And for some brands or some products that we purchase, some companies it takes longer than others, others to sort of figure that out.
But one of the things I have always felt strongly about is when we do purchase a company, there should be sort of a checklist that they go through of how will they get integrated into our company. And I feel like in the future, design system should be one of those things. We should talk about that consistency, about adopting a design system. It should be just part of that checklist so that that company is aware, look, we already have an existing UI and existing design language, let's figure out and plan for how we can actually adopt that.
Chris Strahl: I think that what you were talking about though is effectively needing, I don't know, not a mandate, a checklist, an onboarding item, I'm not exactly sure what you call it, but as a part of the process of becoming a part of Cisco, that idea that a design system and cohesion is important, that seems to be also valued now at a very senior level inside of the organization. What's made the difference there?
Kevin Broich: For years, we were pushing to do this type of consistency and design system sort of from the ground up grassroots efforts, and we'd always been looking for somebody at that executive level to sort of be our advocate, somebody that agrees with us and feel strongly about design systems. I think part of it here is maybe Cisco in terms of buying these other products, they start to see that the products and companies that we purchase, they already have existing design systems and they're very mature and they're very well thought out, and their products look fantastic. And it's like they start to see what our product suite looks like versus theirs. And I think part of it is, "Hey, we need to up our game. We need to get better at this." And so that assimilation, it does take time, but I think just that part of purchasing companies and procuring them, we realize at the executive level that, look, they have really great design systems and great design, so let's see if we can continue that.
Chris Strahl: So you were sort of in the search for finding this executive sponsorship, leadership. I don't know, what would you call it? Would you say just an executive that values this sort of thing?
Kevin Broich: Yeah, I'll be frank. Honestly, some of the groups at Cisco, the executives don't even know what a design system is. And part of what our job seems to be was to sort of educate them on just starting from scratch, what is a design system? What does it do for you? What's the ROI? How do you measure that? What's the KPIs? And I think it feels a little bit like every time I would move to a new group, it's like I was starting over, explaining the benefits of this. But it is now at a point where I feel like there is a critical mass that has been reached at Cisco where people do value design systems. There seems to be enough advocates out there now that they realize it does have value. Now they don't maybe value it as much as like, "Oh, we need these new features." But it's at a level now where it's noticeable and it's starting to get the attention of the executives to the point where they're starting to announce things like out at Cisco Live and it's scary and exciting at the same time.
Chris Strahl: Yeah, I mean it's the thing we always dream about. And then also the thing that is also really terrifying because it puts you in a area of more discomfort. I think that the interesting thing here to hear you talk is, there's sort of this trend that's happening where you're seeing design systems as a way of working, kind of percolate around your ecosystem in your orbit. And then there are other folks that are taking notice of that and basically saying, this is strategic for us. It's actually something that represents competitive value.
Kevin Broich: Yeah. If we can just, I think that's the part is, we can get to the point where it becomes foundational, where a design system is just something where you start at. That's where you start because it scales, it's going to drive consistency. It's that contract between product management, design and engineering that once they all agree upon it, it just makes it so much easier to build product and build it fast.
Chris Strahl: Yeah, actually, it's interesting you mentioned it that way. Our mission as a company is to change the way people think about building products. And the idea of that reaching into a C-suite or VP suite inside of Cisco is really exciting, because that does represent a recognition of the value of systems inside of an organization that operates at a global scale. And so the brilliant part here is that it's more than just tools. It's more than just like, "Oh, hey, there's this way of working that, like you said, is at that feature level of complexity." Because most of the time, people that are highly paced organizations, they don't really care about features. What they care about is what is the value that this creates for the business? And being able to represent that business value very publicly at a conference or very openly as a way of working inside of an organization, that's really cool.
Kevin Broich: Yeah, it's refreshing and it does feel like it validates what we've been working on for so long. You mentioned 2014 is already almost 10 years, and it does feel like it's been a bit of a long slog to get to this point. And maybe other companies have reached this point much sooner, but for the size and scale and culture of Cisco, it has always been more of a hardware company moving towards being a software company. It just took us, I think, a little bit longer.
Chris Strahl: Well, you have all these things that are out there that are of strategic value, but they've been thought of as more like an asset, like lightning or material or carbon. Yeah, there are ways of working, yeah, they represent significant buy-in from an organization, but I oftentimes wonder how much those are viewed as strategic in terms of we build better products or we build products faster than our competitors because we use systems that help us scale. And there's maybe a maturity thing there because material was built in what, like 2015, something like that? I don't know if anybody ever really actually thought about design systems as the cornerstone of how you go rep design at scale. But I do think that there is an interesting idea of what you're talking about at Cisco, where you have an organization that caress about this very foundationally. And I'm not sure that's necessarily reflected in lots of companies that have public design systems.
Kevin Broich: Right. And you mentioned strategic, and I think it probably is that level of maturity at Cisco. We need to get it to a level of maturity where it is considered strategic. Right now, many teams are doing design systems and it feels a little more tactical, because they understand at that level what it does for them. But in terms of really driving the benefits of having a design system across an org, all the deduplication, the consistency, it's a maturity thing. I think once we get beyond this tactical point, we'll be able to get to that strategic point where we get that executive sponsorship to really drive it across, not just some parts of Cisco, but all of Cisco.
Chris Strahl: Yeah, it's interesting you talk about it like that. I think that the tactical piece is really easy to see because that's where a lot of the pain is. The pain exists for design and engineering very much at that last mile. How do I unite what's going on in Figma with what's going on in code and actually make it so my product looks anything like the thing that I designed? And that's a really present problem. But I think when you think about it at that strategic level, what does a systematic application of brand look like in a way that applies design at scale?
That's a lot headier, right? There's a lot of there that is philosophy and not necessarily concreteness. But I think that what you're starting to see is all of these proof points at that tactical level rolling up to something greater than the sum of its parts. And you talked about being able to see above the canopy. The above the canopy for design systems feels like this idea of what you talked about with bundling. It's not just about the experience of one product, it's the experience of this collection of products inside of an ecosystem. And that's what's driving a lot of value.
Kevin Broich: Yeah. And interestingly, Cisco, as they build out, they purchase more companies and build out portfolios, this is going to become the norm. As they build out their portfolio, they'll realize, "Wow, as we pull in each of these new products, we have to have sort of a seamless way, a plan for how we actually integrate them into our existing design system." So that will become sort of the norm. That'll be part of hopefully that checklist that I talked about when we onboard new companies that we have purchased.
Chris Strahl: What do you need that helps this? There's this idea, standards come to mind. What's happening with design tokens and the working crew for the W3C, that comes to mind. There's a lot of things that come to mind in terms of best practices or case studies for this. Because there's not a lot of companies that are out there touting the strategic value of their design systems. I've run into a few, but how do we help foster this idea?
Kevin Broich: I think once that dam was broke at Cisco, where we actually had an executive C-suite talking about a design system at a Cisco Live forum, it felt like then you started to see the entire organization kind of get behind it. Before that you could talk about it and explain the benefits and it didn't matter. It's like it never got on the product managers, off their backlog. It never got prioritized properly. But as soon as that C-suite person comes in and says something, it's like magically a lot of these backlogs now all of a sudden this stuff was becoming front and center and everybody was focusing on the next quarter, "Hey, we're going to focus on adopting this design system." And they all sort of got behind that. And now we're looking at ways to measure the level of adoption that some of those products are at.
Chris Strahl: Yeah, it is interesting how the power structures in an organization work when it comes to something like this. Because it can be clambered for at that implementation IC level all over the place. There's very few people that are designers and engineers in their day-to-day workflow that don't say, "A design system is a major change to my quality of life." But that rolling up to a power structure that values that cross-functionally, that values that across an organization, that's a lot harder to realize. And I think that there maybe is something to that. You talked about metrics. I think about the vanity metrics of velocity and lines of code written and stuff like that. But isn't there something to this idea that everybody's life is made better by these systems? Isn't there some sort of subjective metric made objective eventually there?
Kevin Broich: Yeah. And I think part of that to me feels like a cultural shift to where the front end is valued at the same level as the backend. Years ago, I remember thinking about becoming a front end architect at Cisco, and I remember someone telling me that Cisco doesn't hire front end architects, we only hire backend architects. But then a few years later, they did end up hiring their first front end architect. And I felt like, wow, it's happening. It just seems like it needs to hit a critical mass a certain point before we cross that threshold and then the dam breaks, and here we are. And I'm hoping that the same happens here, that it's not just a design system that sort of is across one business unit or product group, but eventually sort of gets spread across all of Cisco. Because honestly, there's parts of Cisco that could really use it and it would really be a game changer.
Chris Strahl: Yeah, I think that there is this interesting thing you could relate it to that's a broader macro trend with that consumerization of business technology. The most interesting article I've ever read about the iPhone was talking about how it wasn't the iPhone itself that was all that valuable, it's what the iPhone did for business technology. The idea that everything should feel like a consumer experience in every aspect of our consumer lives and our working lives. And that value placed on design showed that design, even in enterprise resource planning applications, or server switch technology or whatever, actually has a place where people like to use user interfaces that are enjoyable. Shocker. But that hasn't really been something that is even 20 years old necessarily inside of most large enterprises, is the idea that your experience for your physical hardware technology should feel consumery to a point that people actually want to use it.
Kevin Broich: Right. And the other part too, that Cisco, maybe they were a hardware company historically, but becoming a software company, a lot of engineering teams at Cisco were building front ends, but they had no designers, zero designers. And I was on several of these teams where I was the designer, although not trained as a designer, but just somebody that had design sensitivity-
Chris Strahl: The Java guy who likes architecture.
Kevin Broich: Yeah. So like, hey, everybody stepped back and I stayed in the same spot and I became the designer. But that has changed. And so at Cisco over the last five to seven years, I've really seen an effort across multiple orgs to actually hire really good designers, world-class designers and build out design teams. But we still do have a bit of a deficit on some teams that still have no design resources at all. It's a bit of a feast or famine in some parts of Cisco.
Chris Strahl: Yeah. And it's also hard, because think about all of the 40, 50 year history of the company that has been applied to how you all work through code. And then all of a sudden we value design. Well, how do you scale that design practice? Which is equally as complex as a code practice, but oh by the way, you've had less than a quarter of the time to actually do that and value it. And I think that that process of getting people to work well with one another is actually harder than just saying, "We're going to care about design." Okay, you can make lots of great statements out there like, "Cisco is a software company that cares about design." Whether or not you've made that statement, I don't know. But presuming that that's out there in the world somewhere, how do you actually get there? And how you actually get there is very complex and you're trying to do it really, really rapidly.
Kevin Broich: Yeah. And we've had our fair share of ups and downs with hiring designers and scaling that out because as you know, if you've never built at scale a large design team, and I mean greater than 50, greater than a hundred, there is a set of processes and tools and things that you need to do to sort of accommodate all of that. Because that's a large group of designers producing a lot of design.
And you have to figure out a way to not just create the design, but to actually get it at productized. Because in the end, that's what we're trying to do, is productize and make money. That's what we do. We're a company, we're trying to make money. And the design, I think needs to focus sometimes on not just creating a boutique one-off unique snowflake design, but to also think about, "Hey, we have to productize at some point. That's how we make money." So sometimes there has to be a bit of compromise back and forth between them and engineering. And that part is still very new to Cisco. That negotiation, that compromise is very new.
Chris Strahl: Well, and it's often fraught, I think about the design to code process and how it exists now. And what's interesting about most organizations that we end up talking to at Knapsack is, they're fundamentally unaware of how much pain exists in that design decode process. And almost all of it exists for product people. I mean designers, they feel it, engineers, yeah they feel it, but product people, they live it. They live this idea of, how do I connect design and code into a product that is going to have users that ultimately I'm accountable to? But holy crap, is that a really hard problem. And if you're able to tell somebody, "Hey, systems is a way of solving this design to code pain." People's eyes kind of light up and they're like, "I didn't know that there was ever something that could do that, that could take that away."
Kevin Broich: And I think in the past, there's maybe been different parts that people have adopted over time of a design system to try to drive some of that consistency. But it was never done maybe holistically where it's not just all about an illustration or an icon library or even a component library. It's all of the above. And when you put it all together, it's greater than the sum of its parts. And I think that's the part where if we can get to a point where we do have a fully mature built out design system at Cisco, and we can show the value of that, I think that's where it can explode. And eventually, all of Cisco will sort of get onto that design system. I hate to say the word bandwagon, but.
Chris Strahl: Right. So you're in an interesting place because you've lived this pain very personally on both sides of the fence. You've had time as an engineer, a lot of times as an engineer. You've also had time as a designer. Tell me kind of about your journey over the past couple of years as you went back and forth between these different disciplines?
Kevin Broich: Yeah, I mean, like I mentioned, I've always been interested in design. And design was kind of a black box to me when I was on the engineering side. So I felt, "This is great. I need to learn more about design." So I really jumped at the chance when I could move. We were coming into an organization that was looking to build out a couple of very large web-based, cloud-based flagship products, very complicated, very large, but they wanted to also move fast. And so instead of going that MVP route, they kind of were like, "Let's just build it all." And they rushed it out the door with no design system, no component library.
And so as part of that process of coming in and evaluating, "Okay, where are we at?" I came in, they asked me to lead the common components design system team, build that team out. And part of us, we struggled with, "Do we just start over?" The app's already in such poor condition, the quality was so low. "Do we just start over?" I've had this in the past where that starting over came up, and there was always this thing of if you start over, you have to have two teams, one team to maintain the existing product and the other team to build the new one and try to keep up with all the features. And it's always a nightmare.
Chris Strahl: That parallelism never really works.
Kevin Broich: No, I think you have to really think about retrofitting and doing brownfield, even though it's harder, it's still, I think in the end it's going to be easier, if that makes sense.
Chris Strahl: Well, I think it's the only thing that's really viable. I mean, pulling off really truly parallel products is extremely difficult, because then even the transition is an area of pain. All of it is very fraught. Whereas, at least in a brownfield situation, you have a pretty clear idea of this is where one thing starts and the other thing ends.
Kevin Broich: Yeah. And we started this. We were like, "Okay, let's roll up our sleeves and fix this. We can make this work." We knew what we were up against, but we were very optimistic thinking about it and how we were going to tackle it. But I'm always a very big believer in starting small, establish some trust with the engineering, with designers. And we were going to focus on the low hanging fruit. So we were going to tackle the things, get some quick wins to really show, "Hey, this is what we can do with the design system and get people on board." Because at this point, we still had detractors on the design side and the engineering side that, "What are you building? What is your team doing? I don't understand what you're doing."
Chris Strahl: So in that snowball effect, when did the avalanche come? When did that proverbial dam really burst for you in that project?
Kevin Broich: It was so fun to see, because we felt like we were in this slog for a long time just working so hard. But I think the point at which we really saw it happen was when, I mean we were building out a common component library, we were building the design documentation, interaction, specs, visual specs. We were doing all the right things. But when we started to actually see the common components get adopted in the two flagship products. And it started to turn the corner because the developers of course, at first were like, "I don't know." But then when they saw these were production ready components, we had really put some thought into these. They were fully accessible, localizable, everything, and they could just pull out some of that old technical debt, drop in these new components, they ended up really liking it and they were supported. So they knew that they would get support with these components. And so that became the avalanche point for us when we started to see enough of these components get out there in our two flagship products.
Chris Strahl: Boy, that is so validating to hear. I have to tell you, the idea of it has to ship to production, it has to be production ready. That's one of the things that we believe really strongly in, is that the path to value, especially with engineers, is showing them that the thing that you've built is ready to go live at scale. And that is so critical to the trust that people place in these sorts of systems, is you get lots of stuff that is either generated or created or built in such a way that the considerations of scale around performance, accessibility, localization, theming, they haven't been thought of. And then when an engineer touches that thing for the first time, that's well versioned, that they can see the evolution of, that they can understand the craft that went into it, there's this light bulb moment that happens, and I love those moments.
Kevin Broich: Yeah. And as they started to use more and more of the components, then they started coming back to us and saying, "Hey, when is this going to be ready? When is this going to be ready?" Because before they were sort of ignoring us and only doing this, what I call forklift and replace thing only happening when they were forced to. There was a certain amount of sprint time that they were given to actually do some of this replacement work, this retrofit. But eventually they really enjoyed it. They really started to see we're reducing technical debt, we're making things better. Actually the product's getting easier to maintain over time. The quality's going up, there's less tickets being written against it. It was really like we had turned the corner with that.
Chris Strahl: And I think that that's what I get back to with that idea of subjective metrics ultimately aggregated into objective metrics. This idea that everybody was more stoked, they were more excited about the work they were doing, and that adoption is the thing that shows sort of, it's maybe the best metric we have right now of showing people's level of stoke, is that they're actually willing to use it. But there's probably something there about generally feeling like the work that they're doing is valuable to the product, that feels like maybe a better way of representing it.
Kevin Broich: Yeah. And it wasn't just the engineers that we were focused on with the design system, it was also the designers. So at the same time, we were building this component library out. We were also building a companion Figma-based component library that was a one for one match. And then building these components and making them available to the designers, they love that. That saves them time, it creates a deduplication and it allows for dynamic updates. Where in the past, I think a lot of the design, they were actually just copy pasting from each other. It became sort of a maintenance nightmare. It was impossible. So having a Figma component library that goes with your tooling base, JavaScript base component library, that was a game changer too.
Chris Strahl: Awesome. So in all this, it sounds like there was a lot of learnings that were gathered both on the design and engineering side. What would you say were the big takeaways? If you had to summarize it into a couple of bullet points, what are the things that you would leave our listeners with in terms of advice or learning?
Kevin Broich: If you are retrofitting into an existing code base, I think the number one thing that we learned, and we didn't do it right away, but eventually we sort of started doing it, was collecting what I call design system telemetry. Collecting metrics from the code base. So our engineers were using a monorepo and we were able to write scripts that would go through the code base and detect on a per view, per product basis, sort of the adoption level using our components. And then we were also able to detect older components. And over time, we were able to build sort of these charts with trend lines showing how we were doing. This was something that we were able then to show upwards to our executives, "Hey, we're making a difference. And look where we're at. Now we're at 80% adoption of the new components." That was great for us because it allowed us also to identify the components that maybe needed more attention.
We were collecting also the top five, the top five components that were being used in our system. So we started with that, and then we started replacing some of the big hitters, like the table component, the header, the left nav. And that's when we really started to see quality improvements. And people started to look at our applications and going, "Wow, this is great. This looks good, and it's consistent."
One last thing too is, I think design and engineering, as you know, it's so important that that relationship that needs to be a bi-directional bridge. And I think so often there's that natural tension between those two groups and it can really go bad if you don't curate that, you don't keep up with that. It's one of those things, especially the way big companies silo design and engineering it into their own separate groups. It just becomes this we versus they kind of thing. And I've always been a proponent of you've got to build a bridge with them. You've got to pull engineering in early and often because they'll spot things. They can see the blind spots that designers sometimes don't see. So that's important.
Chris Strahl: Wonderful advice. Thank you so much for sharing your time. Awesome journey. A really incredible sort of look at a very, from the beginning to modern times, journey inside of Cisco. So thank you so much for sharing. It's been wonderful.
Kevin Broich: Thank you, Chris. Appreciate it.
Chris Strahl: Thanks again, Kevin. This has been the Design Systems Podcast. I'm your host, Chris, signing off. Have a great day, everybody.
That's all for today. This has been another episode of the Design Systems Podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter @TheDSPod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by Knapsack. You can check us out at knapsack.cloud. Have a great day.
