In this episode, Chris talks with Daniel Ley and Jonas Ulrich from KickstartDS, a framework designed to simplify design system creation and drive meaningful adoption. They dive deep into what adoption really means, moving beyond metrics like component coverage to focus on efficiency, team morale, and an iterative approach. Drawing on real-world examples like UNICEF Germany, they share how effective adoption strategies can reduce complexity, speed up delivery, and maximize impact. Tune in to learn how to measure and represent adoption in ways that truly reflect your design system's value!
Guests
Jonas Ulrich and Daniel Ley are the founders of kickstartDS and owners of ruhmesmeile, a consultancy specializing in design systems and headless CMS. After over 15 years of experience developing websites and UIs as a traditional online agency, they sought to improve how teams work on web frontends. This vision led them to establish kickstartDS as a corporate venture in 2021, providing an open source meta framework for design system creation.
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.
Hey, everybody. Welcome to the Design Systems Podcast. I'm your host, Chris Strahl. Today I'm here with Jonas and Daniel from KickstartDS. Before we get started, I just want to let you guys know we have our leadership summit coming in Atlanta, Georgia on January 30th. Check out Knapsack Cloud events. Welcome to the show.
Hey, y'all. It's really great to have you. Thanks for jumping on early morning US time, late in the evening Germany time. So thanks for being here.
Jonas Ulrich [00:00:52]:
Yeah, a pleasure.
Daniel Ley [00:00:53]:
Thank you very much for having us.
Chris Strahl [00:00:55]:
Why don't you tell the audience a little bit about who you are, what you do, and we'll go from there.
Daniel Ley [00:00:59]:
I'm Daniel Ley, together with Jonas, we are leading the Rummesmaile, which is the agency behind KickstartDS. With Rummesmaile. We specialize on design, systems consulting and headless cms. So basically we are just doing project business just based on KickstartDS. My background is product and UX. Before I joined Rummesmaile as managing director, this was like three years ago. I was leading UX in different stations in Amadeus, like a large software company for the travel industry. And I was also involved for years in that Global Galactic Design system program we were running.
Jonas Ulrich [00:01:38]:
I'm Jonas from Germany too, so I've been building websites for money, so to speak, starting 2004. So quite some years, I'd not say it was professionally in the start maybe, but starting 2008, we founded Rummesmaile, the agency we are still working off today. And that was when we really started building websites and did that since three years ago, where we decided to maybe give this whole thing another spin to find maybe a product that can fit the market. And that's where we started KickstartDS, a small framework basically to create your own design system and to ease the pain of a lot of development needed initially, a lot of investment being really upfront heavy to implement something like a design system. That's where we thought maybe we can make a difference here.
Chris Strahl [00:02:30]:
Awesome. Yeah, I love that. I was trying to think about when I first made websites for money and I was like, man, I'm old. Anyway, tell me a little bit more about KickstartDS and what it does.
Jonas Ulrich [00:02:41]:
Yeah, so basically I tried to outline it super briefly in saying it's a framework to create your own design system. So basically it means you may have a need for a design system. That can already be a pretty deep topic if you actually have a need for design system. But say you have one and you want to build one. We always try to compare it to one year of development time that you would probably at the least have to invest. And that's where we try to make it easier by giving you a toolbox with some nice tools and best practices in there that make it easier to find your correct first decisions when building a design system. To have some base components in there, some token setup in there, some semantic tokens.
So basically everything. Best practice to boot, and then you can grow from there. So I'd say it's a meta framework. That can be quite a hard word to grasp, but it's a framework to create your own design system, which is also a framework, which. That's why we call it metaframer.
Chris Strahl [00:03:40]:
Nice. Yeah, we live in the meta. I like to. I like to always say that.
Daniel Ley [00:03:43]:
And it's open source, so you can just hit our website and from there dive deep into our docs or GitHub to load it as. Like, we know that companies want to own their design system, so it's not like a software as a service approach. It's just open source. You can download, install it, and go from there.
Chris Strahl [00:04:04]:
So before the show, we were talking about adoption. That's what you all really wanted to hit on today. And this is like super triggering for me because adoption is my favorite metric to hate on. But also, you all brought up some really great points about some of the ways that we should think about adoption. So when somebody says, like, hey, I want to measure adoption, what comes to mind? Or what do you all look at when you're talking to a client or a customer about adoption?
Jonas Ulrich [00:04:31]:
I mean, my immediate reaction would be I'd be wary and questioning where that question is coming from, because there can be quite a few different reasons to ask such a question. I think adoption is super important, but I'm not really a believer in having simple metrics encoding your adoption rate. I think that's just not encompassing enough as a viewpoint. You need to look at how quick can new projects be done with having a design system? How much faster are existing projects projects done? How can you try new stuff that you wouldn't have been able to try without having a design system? So I think all those are parts that should factor into what you call adoption. Because sometimes people like to write simple metrics like 70% of my components are fed from the design system. And at least to me, that's not telling me anything. Those could be the simplest components. Thoughts could be relevant, complex components.
I think you have to qualify it a lot more to have a real number attached to it. But I think adoption as a topic in general is super underrepresented in some design system discussions in that aspect. Like how do I actually use my design system now? So a lot of people build a nice design system, nice documentation. They have a Figma file, they have a component library. But starting from there, there's not much further as help for people actually implementing the design system. Then, for example, when building the new marketing website, or when building a new dashboard or interface view, then you pretty much are on your own in a lot of cases. And that's where we think you can do even better when talking about adoption, having more than just some basic components in there.
Chris Strahl [00:06:16]:
So folks go and they stand up a system. So there's a system of some kind at some level of maturity. And then they talk about things like coverage, or they talk about things like number of downloads for the system or utilization of that system. And what you're really looking toward is this idea of what is the value that that represents. And the value that represents being support for the people that are building the system or using the system. And so that sounds a lot like usage metrics, but with an eye towards value. So how do you really get at that value? What is useful to you?
Jonas Ulrich [00:06:55]:
I think it really depends on the context. In some contexts, we've seen time to market being super important. So that was more the focus. How quickly can we create a new, for example, page? We did a project with unicef, for example, in Germany, a big ngo, and they built help pages. So if there's an emergent situation or something urgent, they quickly need to spin up a new pledge page for that reason and have people give money like that. And to be quick on that, they really had to rethink their approach. They were having agencies do those single pages before, and now they can do it themselves. So they have a turnaround of, I think two days now for a new Page, whereas it was like four weeks before that, not even talking about investment needed and the time invested by those agencies.
So for them, adoption was mainly about how can we quickly create new pages without having the external dependency in there. So time to market was super important to them, for example. So I think it really depends on those metrics. If you're building dozens of dashboards, you probably want to save on efficiency, because building the 12th dashboard shouldn't take the same time as the 11 before that. So, as often, I think in our business, the answer is it depends. Which is not what you like to hear normally, but unfortunately, it's often true.
Daniel Ley [00:08:24]:
Especially when you go around and present large adoption rates and coverage rates, and most of the teams just do not say how long it did until they had that rate. Right. If it was like in a couple of months, great. If it was like in a couple of years, well, it was not that great achievement. Right. Time to product must not necessarily mean time to market, but it's part of that.
Chris Strahl [00:08:50]:
Yeah. One of the things that I've always thought was really interesting about the adoption metric, especially as it relates to coverage. Right. Is like, okay, so 80% of my experiences are built using design system components, but I only get like a 15, 20% efficiency bump, which is like, a lot, right? Like 15 or 20% is a lot. But what happened to my other 55%? Right. Where did the rest of that 55, 65% go between the ability to reuse everything and then how that actually shows up in my products? And so I've always been kind of curious about that. Right. Where there's always these, like, coverage targets or adoption targets, where like 90% of our apps are built with the design system and they all have 80% coverage, but we're only targeting a 15% efficiency gain. And so the metric there seems to be the efficiency gain.
And the thing that I would focus on would be like, well, how do I reduce that gap between coverage and efficiency? Because that seems to be where there's some missing part of value. Do you all think about it in that vein? When you look at people that are talking about coverage and adoption, do you look at that as, like, where's the real value coming from?
Jonas Ulrich [00:10:07]:
I mean, I'm still having a hard time with those values because I always question where they come from and how scientifically valid they actually are. Because I see a lot of approaches just doing some static analysis of components in their code base, which doesn't tell you anything about dynamic contexts. For example, where the page that will get Rendered for the user in the end will be determined dynamically. You won't see that in your code base. So those will always be wrong on that assumption already when looking at those values. And I think one interesting aspect is where do you see the savings? Do you really have the timekeeping to differentiate where people have worked on? Because in my experience the efficiency gain is used up by doing more relevant stuff. So it frees up time in your projects that gets invested to make things better, to bring out a better product in the end for maybe the individual parts that are not covered by the design system. So I guess there's always enough to do.
Even if you have 80% coverage, you have a lot more time to invest on the remaining 20% to make them really great. I think that would also be something to have in mind when just comparing times invested.
Chris Strahl [00:11:19]:
Yeah, I agree. I think that there's this interesting concept of like we want design systems to help us grow faster or to build better quality software. And there's kind of these two things that people tend to aim at. They aim at this like efficiency savings. So like how much money do I save? Which is an interesting thing to put out there. And it's usually couched in like two ways. There's the one way which is like fewer defects, right? You're going to save some percentage of your QA time because your software is already going to have your accessibility decision making baked into it. And it's going to take us a lot less time to remediate accessibility gaps.
Likewise, that consistency of brand like VQA is shorter. But then there's this whole other idea, like we just build faster, right? So we have this efficiency gain. But it's not like all of a sudden, hey, it cost me a million dollars to make a product multiply a million times. Some percentage of QA savings and some UX in engineering efficiency. And now that product only costs 750,000. Because that's not really how it works, right? It still costs a million dollars. But what were you able to do that you weren't able to do otherwise? And that gap seems to be where a lot of people get lost in adoption statistics and metrics. Because it's a really hard thing to measure, first of all is like how many things did I do that I wouldn't have been able to do without a design system? And secondly, it's a little bit fluffy in that people really like hard roi.
Chris Strahl [00:12:48]:
They really like hard savings, like I saved a quarter million dollars. But that's not necessarily the presence. And I think you know, Daniel, you would probably say it's not even really the point.
Daniel Ley [00:12:59]:
Yeah, not necessarily so. Well, I think there's components from a design system that can so much other things which on that greater scale needs to be considered as well. So it's mostly much more performant we could approach to like larger topics. Accessibility, usability, everything is much more consistent. So it's not only the reusage, but it's also the better quality of all the things involved.
Jonas Ulrich [00:13:29]:
Yeah, and maybe I'd add that even the focus just on components, because I see that a lot too in especially adoption metrics, that there is a fetishization almost of components. Because I think a design system is much more than just components. It's also the rules and the best practices, how you build new components. So even if you're building a wholly new use case for your page, a great design system will benefit you in being more efficient in doing that by having great tokens, great semantic structure that makes it easy to know the right design decisions for your new interface elements. So I think just reducing it to components is also one of the errors in just looking at it like that. Because the disaster should be way more than just components, in my view at least.
Chris Strahl [00:14:17]:
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.
Chris Strahl [00:14:38]:
I think there's this idea of what is useful. Right. One of the things that I see in really mature design systems that are super useful is things like linting rules or CI configurations or a lot of artboards or mood boards that help set a theme or a tone for the design work that's happening. And all of that is useful, but it's not necessarily reflected in a metric of component coverage or components component adoption. And I think there's also like kind of thinking about that bigger picture like Daniel, you were alluding to is, you know, how does this integrate with my content? How does this integrate and actually get shipped? Right. I think that that's the thing that often I get frustrated about with pure adoption as a metric is it's not really about shipping. And for me, like metrics that are really Valuable in product are the ones that are about like, how much or what did we ship? And I think that it's really challenging because these are hard to pin down.
And so if you were sitting there talking to a director of product at a big company and they're like, what is the value I get from my design system and what do I put on my KPI dashboard? What would you tell them?
Jonas Ulrich [00:15:54]:
Probably, I mean, that's a bit flippant, but probably the mood of the team because I think really what benefits the most is a good design ops team having the backing from their stakeholders to implement a design system and to really mean it. It really makes their work much, much better. At least that's what I've seen pretty much in every case where a design system was being done in good faith. At least that's one of the main things. It's not super tangible and it's not expressible in euro or dollar, so it's probably not what you would like to see there. But I think it's a super important part and it very much has an effect on the quality you will produce in the end.
Daniel Ley [00:16:37]:
I think super important is that everything should not be over engineered from the scratch. So it should be really an iterative, lean approach towards everything. So of course it could take a year to settle down. Just like the semantic structure of my component API and my token taxonomy. I can't involve everyone and do my own research inside the company, talking to other teams, get the data together and I should do that, but I should keep it lean and just start and learn from there because it's like a learning journey anyways. And maybe think more about the structure of things and how to interfere that structure with adapting systems instead of digging too deep into hundreds of component props for each component and taking only the most complex things. As John said, it depends, of course, it depends on the organization, on the products you serve and deliver. But I think really empower the team to let them think systematically and that design system approach will not only serve into a better mood, but also foster to that iterative approach.
Chris Strahl [00:17:53]:
Gotcha. So you're advocating for this idea that let teams explore, let teams build in an iterative way that they can discover that value along the way. And so if I'm that director of product that is sitting there saying like, what do I put on my dashboard? To Jonas point, maybe there's some sort of like NPS metric for design systems, right? And that NPS metric for design systems is like two things. It's how often do you Use the design system in your daily workflow. And if all of a sudden the design system went away, how much would it impact the work that you were doing? So when you think about the very specific thing you're trying to measure, you're trying to put on there, that equates to a dollar value or a specific measure of roi, maybe that's really more subjective in the happiness and the effectiveness of the team that you're working on. And you could transform that into a more objective measure by understanding exactly how people view the design system as a tool for creating value in their daily work.
Daniel Ley [00:18:54]:
Yeah.
Jonas Ulrich [00:18:55]:
And I think in the end, it should increase your time to market and it should increase your efficiency. I just think it's really hard to quantitatively measure that, really measure that from start of a project to having it in production. There are so many variables and so many different things influencing that that it will be hard to just pinpoint specifics about the design system in there, I think.
Chris Strahl [00:19:20]:
Yeah, but like, haven't we spent three decades of software development now trying to figure out how team velocity works? Isn't there some way we can tie this to, like, a team velocity metric?
Jonas Ulrich [00:19:31]:
Absolutely. Yeah. And I think that would be the sensible thing to see overall, how your team velocities improve, because you probably have multiple teams working with the design system. When you have a design system, because you probably don't really need one. If you just have one team implementing one software, it can be overkill. But if you have multiple teams having those team velocities in mind and having the team feedback in mind, maybe measuring how much questions you actually get for your design system in your design ops team, how much feedback there is, how fast your iteration cycles are when taking that feedback and implementing it. So I think those can be really great metrics to also show growing adoption, to see how it spreads like a fire. Maybe in the best case.
Chris Strahl [00:20:20]:
It's interesting, right? Because this idea of, you know, the value of a design system is definitely tied to the number of products or the complexity of the system that you're trying to work within. Right. Like, design systems love complexity because we sort out all that mess. And, like, the highest value design systems are the ones that land in the most complex places where they can provide the most value and most benefit. And so when we think about that, how do we represent that value? And Daniel, maybe you could dive in here with your expertise when you think about, like, that idea of, okay, so a design system is most valuable when it's in a place with lots of brands or lots of products or lots of people that are doing different things on the team because that system helps all of that complexity get managed. I think that talking about how happy the team is or how stoked they are or how much they would suffer if you ripped something away from them is one interesting way of thinking about it. But I don't think that really speaks to the complexity side of it. And so I'm curious when you think about that, what measures come to mind when you say, okay, a design system that's working for one product, one team with maybe half a dozen people building it, is not as valuable as something that is working for 10 teams with 10 people and 10 products.
Daniel Ley [00:21:43]:
Yeah, I think we should also strongly think about the whole onboarding process towards larger organizations and organizations in different teams. So also design system folks like to think in details and then there's documentation everywhere. Lots of the systems I've seen they somehow lack about a holistic approach. So there's super sophisticated dev documentation, super sophisticated figma or design documentation. But also at my time in Amadeus, often wise a team wanted to adapt to the design system and they were asking for examples which could help them to adapt quicker also from the dev team perspective. And I think that's something where lots of systems still lack. So we see like ready made templates somewhere. The Gov UK design system is pretty good in onboarding dev teams, new dev teams providing lots of detailed code, therefore like also thinking or taking a look onto the projects and customers we mostly serve like larger content driven websites and there we could really benefit from that systematic approach and completely deliver ready made starters for a CMS solution, for example.
So you just do not maybe need to dig too deep into that design system over details but rather focus on okay, everything's set up so just like take the quick start and start with the backend so while my front end is there already and then maybe think about what might be missing.
Jonas Ulrich [00:23:28]:
Yeah, I mean maybe we're a bit biased in our thinking like that because we always try to think of those design ops teams as just a unit out there proposing how things could be done. So it's not something that's dictated from the top down, but it's more like a self service thing, a nice place where your job gets easier when you use it. And looking from that perspective, there are quite a few things you can do to drive adoption. Like Daniel said, for example, having templates in there, maybe having some recycles showing common usage of your components, having ready pages in there, maybe even connectors to different systems where you can easily try the system in a headless cms, for example. I think those can all be things that make it easier for people to approach the design system and to then also adopt the design system. So, for example, we have a big university here in Germany, and they can't even tell people what they need to do because it's set up differently politically. They are just one department that makes an offering and people can but don't have to use it. So they really have to focus on their communication, on the examples they provide to drive the adoption.
Jonas Ulrich [00:24:44]:
So that's also something to reflect on how your organization actually can do that, because it will be widely different in different contexts.
Chris Strahl [00:24:54]:
Yeah. So I guess if you were to just summarize, like take one big step back from this. If you're a company that's looking at a design system, or you're somebody that's a design ops or product leader that's evaluating a design system, we tend to represent that value as speed, efficiency, quality. But like, how do we then think about representing that value within the organization? Do we think about that as adoption, which is like this nice, handy, simple thing we can grab off the shelf that is very observable, or do we think about it deeper than that? And if you were talking to a customer or in that position yourself, how would you advocate they represent the value of the design system?
Jonas Ulrich [00:25:38]:
Yeah, and I mean, that will pretty much be efficiency. Not as much adoption rate, but efficiency. And we try to do that by having a lean process, by starting with a small design system, finding a pilot project that really works, and then really seeing the value there. You should see the value inside the pilot project, the specific value that the design system generates for your organization. And that's also one of the steps we try to make sure when selecting the pilot project with our customers to find such a representative one. Maybe not your main.com page, maybe not the smallest, most niche type of interface you're building, but something in between that already gives you some nice insights about how much faster was it, how good did it work, how qualitative is the result, and then just growing from there. And I think that's one of the big things a design system can do for you because they are made to break down complex scenarios. You can go iteratively at it.
Jonas Ulrich [00:26:40]:
You can solve one problem at a time and grow one problem at a time and build complexity like that. And I think that's almost always the right way to go about when building software. Not just building one big super complex thing, but breaking it down and starting small. And I think that is one thing that Design Systems can help with, being incremental and still having a process attached to it, not just doing throwaway stuff.
Chris Strahl [00:27:05]:
Well, hey, I want to thank you guys so much for being on the show. I really appreciate you being here, sharing your wisdom. Make sure that you're able to check out Kickstarts. We'll put a link in the show notes. And I just want to say appreciate you staying up late and jamming with me.
Jonas Ulrich [00:27:18]:
Yeah, no worries. And if anyone has questions, feel free to drop into our discord too. We are always happy to chat.
Daniel Ley [00:27:24]:
Yeah, thank you very much.
Chris Strahl [00:27:26]:
This has been the Design System podcast. I'm your host, Chris Strahl. Again, there's a Knapsack event likely coming to a city near you sometime soon. Unless you're in Europe, we don't have those going quite yet, but come check us out Knapsack.cloud/events. Otherwise, hope you all have a great day. Everyone. Take care.
Chris Strahl [00:27:42]:
Hey everyone, thanks for listening to another episode of the Design Systems Podcast. If you have any questions, topics, suggestions, or want to share feedback, go ahead and reach out to us on 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.