From Nebula to Supernova: Design System Maturity Models

I'm a bit nervous on this stage because if you went to the pre-party you know that this is actually the karaoke stage. So I hope I can give at least a good enough show for you to not walk away crying. He was mentioning pictures, if you take pictures of me, feel free to tag me because my wife knows I'm in Amsterdam. I explained that I'm at a tech conference. I think she believes me, but it's okay if you tag me so I can provide some proof.

We're going to talk not about karaoke, not about the central of Amsterdam, we're going to talk about design systems. Hopefully we can get a bit more clarity in the design system maturity model. Before we get started with that, of course, a little introduction.

Hello, I'm Joran. Hello. Great. It's nice, it's the afternoon, so I have to keep the energy a bit high. I'll keep the introduction short because I already said a lot of stuff. Feel free to find me on the internet if you want to connect because I'm also looking for feedback and that serves as the basis of this talk. I was last year in this venue at the JS Nation giving a talk about the component library and I was talking about how we were shaping our component library from a developer point of view and that led me to having chats with a lot of other developers and designers who also attended the conference and they told me their story. I started to recognize patterns and that's basically what this talk is about as well because I have a suspicion, and that's where you come in, that these patterns are not unique to our organization.

That leads me to the next slide. My organization, so I work for a Jumbo supermarket, they have a store nearby. Feel free to buy snacks there. The key characteristic or why this is interesting is because we are not a tech company, right. We use tech to fulfill our goals which is selling groceries, getting that lettuce on your shelf. But it's not our main concern so this is a supportive technology and that sort of has implications I think in the way that we do things related to tech. So this is an important feature and if that goes for your company as well I think we are on the same page. If you are a primary tech company there's a different path. I will highlight that later on.

So why are you here? I hope you know why you're here. At least I know why I'm here. So we all know that design systems are accelerators for development, right. They benefit us. They make us go faster and sooner or later everybody who works in web development or app development, they will sooner or later get in close contact with the design system whether you like it or not.

So it's good to be prepared. And the other part is models. So models, what do they do? They help us in simplifying complex concepts or ideas and they help us understand how we can use them and I hope to see that we can also learn where we can improve as developers. So that's why I hope you're here. If you need some time to at this point walk out the door, it's fine, but this is why we're here. So we're going to try and fulfill those goals. I'm highlighting them for extra emphasis.

Before we dive into all of that, so what the heck is a design system? Let's see if we can find a very descriptive definition of a design system. Get ready for this because I'm going to read it out loud. There we go. I'll try to use my reading voice. So a design system is a structured collection of reusable design elements and guidelines that help maintain visual and functional consistency across digital products and services. Now I take a deep breath here. And then we move on to it serves as a centralized resource for design and development teams providing a set of standards. So I hope you can. Yeah. Okay. Yeah. Thank you. I was going to say I hope you can read this and then the TV fell off. We're going to continue. So this is what we use as a definition for a design system for the sake of this talk. If you want to shorten the definition, this also works. So this is by Brad Frost. He's a much better expert on design system and patterns and whatnot. So this is also a very good definition, much more usable. But for the sake of this talk, I think that longer description also serves a purpose because it highlights some of the key characteristics of a design system, which are that it is structured, centralized and contains a set of standardized patterns. It's also about the stakeholder. So we're doing this by designers and by developers, also for designers and for developers, and then also for the end users. There's another characteristic.

We want to do this with minimal cost. That last one is for project managers. I'm not sure if they're in here today. There you go. So let's get started now.

So I came up with this model for design system maturity, and it's a work in progress, right? If you have any feedback, then come find me, do the Q&A thingy, and let me know what your thoughts are and if there are parts that resonate with you as well.

First, this picture. Does anybody recognize this picture? Cool. Yeah, a couple of space enthusiasts. Not that many. That's a bit of a shame. So allow me to elaborate. This is called Pale Blue Dot, and it was shot by a Voyager space probe. So I have space as a theme, right? I think space is really cool. We live in space, so it's very important to us as well. But this was shot by the Voyager space probe six billion kilometers from Earth. So the engineers who worked on that space probe, they send it a message, have it turn around, shoot a photo of what it was seeing. And that little dot there, that's Earth. So that's where we are at that point in time. The reason I included this picture is not just because I think it's one of the coolest pictures in the history of mankind, but this is showing Voyager where it came from. And our model is also going to help us in identifying where we came from. And it also shows, you can't see, they are waving. Those are the engineers who sent the Voyager on their journey. So they made sure that it also had a goal, and we're also going to investigate that. So that's why this picture is in here.

So the stages of maturity. I've identified a couple of stages. And obviously sometimes you can be in the middle. This is sort of a gray area, right? It's not a black and white situation. You can be at a certain stage where you have fulfilled characteristics of a more mature stage, but it's a model, so it should help you in simplifying things.

And again, I want to stress that this model is aimed particularly at non-tech, non-primary tech companies. Let's go over them. I promised with my title that we're going from Nebula to Supernova. So star types, I think they are a good analogy, because they too start very nearly invisible, very nebulous. And over time, star types, they start to build up in mass, and they start to influence their surroundings. So that's why I think it works.

We have a couple of them. I've identified five so far. I'm not sure if there are six, seven, 20. I doubt there are 20 to be honest. But these are the ones, and we'll go over them one by one. So from a non-primary tech point of view, you probably start here. If you are more tech orientated, you probably start here. And that's fine. There is no straight path of fulfilling all of these maturities. It's fine to enter at a certain stage and just continue developing.

Stage one. I hope you're ready. So this is, at this point, you can't really speak of a design system yet. But it is, at this point, is an attempt by designers and developers to reuse a couple of bits of technology or pattern. So as developers or as designers, you are inclined to not repeat your work, or repeat your work so you don't have to, like, we like copy pasting, actually. And this helps in providing a bit more consistency. This also helps you in building faster. And this also helps you in the end with sharing patterns, maybe with other teams or with other developers. And this is the seed of what a design system can become. It doesn't necessarily have to end that way, but this is the staging area, basically. A couple of characteristics here is that usually it starts with handcrafted elements that people do very diligently by hand. It's built in isolation. So there's a little usage that is being shared across teams or across individuals. It might grow into that.

And also adoption is very low. It's hard to identify this as a design system already. So we'll move on to the next one, because it gets more interesting the more we progress.

This is the next stage of these names. Blue Dwarf. Here we're seeing a more structured way of working. So if we took the previous stage, which was very nebulous and incoherent, at this point, we see that designers and developers, they are tailored more to digital products. They were actually considering what you're building for. It might be a cross-platform as well at this point. And those patterns that you see between designers and developers, or between developers and developers or designers and designers, they become a bit more coupled together.

So the designers and developers also start to communicate together, which is awesome if you can achieve that. It doesn't always work that way. But if it does, that's very treasurable. But you still see a split probably between development patterns and UI patterns. At this point still, the driver of what the design system can become is driven by necessity. Because people want to work faster. That also has some implications, but we'll try to solve that in the next stage. I was mentioning third-party libraries. If you get started with a digital product, it's very common to use a toolkit. That's perfectly fine. There are also different stages of toolkits you can use, and we can also start to map them on design systems.

No, we're not going to do that. Don't have time. But that's a different discussion altogether. But what you will see is that you run into the limits of using a standard component library. So you need to take action here.

Key characteristics, but we'll move on to the next one. So, I think at this point, the soul star is not... It's actually a coincidence that it refers to our own star. But this is a comfy spot. This is where you can actually start to think of it as a design system. So, you now have your communication between designers and developers is good. So, they are talking together. They're working together, and they're trying to identify patterns and components that they can use and reuse. You also start to see documentation, which is fun to work on. But it's very useful, because it provides consistency and it helps other people to move faster as well.

And this also means that it takes a lot more, or a bit more effort at least, to work on the design system. And you will see a culture change, where there is a bit more effort that's being put into maintaining and growing the design system. And adoption rate for that reason is pretty high, I would say. And this is the advantage of building this from the bottom up. If you follow this route, then you will organically lead to a high adoption rate, which is something to consider. Key characteristics here. So, a high level of communication. You try to foster consistency by providing the right tools. And you encourage people to work together with you, because the design system has grown at this point, right?

So, it takes a bit more effort and time to work on it. Which is fine, because it also accelerates you. Or at least it should. So, I was talking about, this is more the top down approach, right? The red giant. This is where you come in if you want to, from the get go, start on a design system. And what you then will do, and I don't think this is the best example. So, I'll continue my story from the bottom up approach.

Because I think that is more interesting. That's at least my journey, so I know a bit more about that journey. But what you see is that you are seeing very close collaboration between designers and developers. They are trying to figure out patterns between them and between teams maybe, and also trying to figure out how to apply them in digital products.

And what you also see at this point is a development for a vision and a long term strategy for the design system. The extensive documentation is nice, but I think the long term strategy is the most valuable here. Because it also means that it takes a bit more effort to guard the design system. And from an organizational perspective, it also means that you need to allocate resources to work on the design system. Which then leads to adding goals and KPIs.

At this point you need to involve management and you need to make it a product, make it a portfolio. This is the last one, and there might be stages beyond this one. I don't know, maybe black holes, quasars. Maybe next time I'll talk a bit about this. But at this point we've arrived at a full fledged design system. This is something that you could put open to the public. I'm not saying that you should, but you could. At this point you have your clear vision, you have your clear strategy. Everybody is on board. Everybody knows what the design system is and what it stands for. It's also considered a strategic asset in the organization. So that also means that you need to protect it even more. And you need to have a way of ensuring strong governance on the quality that makes up the design system and its parts. I'm going to skip over to the next one.

It's also considered a strategic asset in the organization. So that also means that you need to protect it even more. And you need to have a way of ensuring strong governance on the quality that makes up the design system and its parts.

If you think about design systems, you might think about a couple of properties and capabilities that also fall into the design system category. I made a list and this list is definitely not extensive enough. There may be more, there are probably more. But these are things that are also part of a design system, right?

My assumption is, and I think it's pretty reasonable, that you don't need every one of these properties in order to reach stage 5. You can get away perfectly well without teaming, for instance. Accessibility is an important one, I would recommend you to put that in as early as possible. But you don't need everything. What is also a reasonable assumption, I think, is that you will need a couple of capabilities before you can progress to a next stage. So typically you would see more and more capabilities being part of more and more mature design systems.

And before we near the end, I want to share a couple of practical tips from at least my experience and from what I've heard from other designers and developers. This is something that you can take away and try to apply if you run into similar issues. So what we've seen is that with the initial innovation being driven by necessity, so people just doing this because they want to solve immediate problems, it also means that because you're not following a direct vision, it also means that you sometimes have to circle back because you run into a dead end. And that's fine because you learn a lot about all of those opportunities and as long as you share them with your peers, you can make use of the learnings at least.

What we also learned is that a design, so systems reflect culture, I think that's a given that also goes for design systems. So if you are working on this, make sure that you have cultural compatibility. You need to have a system and you need to have a contribution system that matches the culture of the organization that it applies to. And there are, so you can facilitate a culture change, but it needs to be compatible. That's, that's, otherwise it will not work. You can't force people to do things that they're not used to.

We also noticed that not every change is equally important, so we were thinking about adding a design token at a very early stage in our organization, but we put that in the freezer because it didn't add that much value over time. We were more happy with adding other pieces of capabilities to our design system rather than doing something specific as design tokens. If you have a clear vision and strategy, then it's easy to make those decisions.

And the last bit, and that's the most important one in these types of organizations, is that you are constantly surrounded by people who are using this, right? You have your developers, your designers, UXers, everybody who is using this and who is a stakeholder is in your organization. And you can use them. You can use them to train them how to use the design system, that's facilitating culture change, but you can also use them to get valuable insights in how they are using this, how they want to use it, and what works and what doesn't work.

Now, get ready for some non-spicy takeaways.

Now, get ready for some non-spicy takeaways. Let's see what we got here. This is also something that's a given, right? But software always changes, and it takes effort to guard that change, and it takes effort to maintain something that's always changing. So you need to accommodate this in your organizational structure, make sure that you have the resources to facilitate this, and just make sure that you can guide everything that you're doing in the right direction. And what helps is clearly communicating your vision and strategy. That helps in multiple ways because having a clear vision and strategy and having a clear roadmap with practical points helps you with all of your stakeholders in your organization who immediately know where and how they can contribute to the design system and make it grow into an even, like, maybe a better stage or make it even better in terms of quality or adding new capabilities. So I would very much suggest making use of them.

Lower maturity is not necessarily a bad thing. So I was talking about these stages. If you are on stage zero or stage one, that's perfectly fine as long as it matches the needs of your organization and also the resources of the organization. It doesn't make sense to go for a level, a stage five maturity system if you're just a startup and you're just testing the waters with one new POC. That doesn't really scale well because you're putting too much effort in your design system.

I'm ending with a lovely picture of Voyager. So I hope that what happened here is Voyager 1 and 2, they both left our solar system, right? They were interstellar space. And that happened because people combined their knowledge and put those on the right path. And my hope is that by all of the feedback that I hope to get from you as well, we can also reach beyond the stars, as they say. It's been a pleasure yapping about design systems for all of you. There's no time for karaoke, which is sad. So if you want to get in touch with me, find me on, I think I'm posting the slides, not using AI to do that, but they will be online. So if you want to know more about this, please get in touch with me. Because I'm looking for feedback. I'm very curious about your thoughts. And that was it. Thank you so much. So let's see what's popping up here. In the meantime, oh no, it's already showing up, so that's cool. Let's get some of them popping up. So the one that's on top right now, and I didn't select it, sorry, it's the first time I'm doing this, it's this one.

So what do we say is the best approach to continue to develop and improve the design system that has reached a mature status? So I would say that this, again, falls back to having a clear strategy and a clear vision, right? And as long as whatever you do fits within that vision and strategy, there's always work to be done, there's always improvements to be made. And having that clear vision helps you making decisions that help in shaping the design system, but I also think that the design system itself is not necessarily the goal of an organization. So it can happen, I haven't seen any practical use cases here, but it can happen that if it fulfills all of the needs, then you're done. But in practice, there's always something that you need to do, right? So there's always room for improvement. But having that vision and strategy really helps in that regard. Okay. Let me check where we're at right now. For some reason, Slido just decided to do a quick refresh. In the meantime, yeah, you can still join 14.15.

Let's go to the next question. So the next upvoted question that we have here is, what was your experience in regards to convincing other stakeholders in a non-tech company? So also the non-tech stakeholders? No, just all stakeholders. Let's see, what we did is, this is the stage three part, where we are setting goals and KPIs. So those goals and KPIs, they help in communicating the value that we're bringing with all of the changes that we think we need to bring to the design system. So from a business perspective, it is a reasonable request to ask, why do we need to put all of this time into a design system? Well, there are numerous research reports where they state that a design system, well, we all know it helps with consistency, and consistency helps with driving sales. So if that's your bottom line, then having a design system is actually contributing to business goals. And that's, I think, the key to the answer is, as long as whatever you do, it doesn't necessarily is limited to the design system, but as long as what you do contributes to business goals, or if you can link it to business goals, then you can build a case. And then you can use that case to convince managers or non-tech stakeholders, or stakeholders within the company as well, that it actually contributes to core business. That's, I think, the answer.

Okay. And so, let's, oh, this one is interesting. So where on the scale would you say that Tailwind lands? Tailwind? Well, I don't consider Tailwind a design system per se. It's sort of a helper tool, right? And you can incorporate it in your design system, you can use it to build a design system. But a design system is more than just a tech. It's also more of a philosophy, and it's also the invisible patterns or the agreements, it's a tone of voice, it's coloring. So Tailwind doesn't really encapsulate what a design system should be, in my opinion.

So, oh, this is the one we already went to. So what would you say is the best approach to continue to develop and improve the design system that has reached a mature status? Because for instance, I remember you dropped something about, oh, maybe there's a black hole, something that could show up. Where would you say are the next steps? Yeah. So, now, I'm looking for feedback on that one. So you could consider maybe we see some new platform that you want to support. That could be in addition to the design system. You could try to dive into new markets. What we are doing, for instance, is also investigating how we can service emails, how we can service a print, even. Because it doesn't necessarily have to be limited to just digital products. It can be any type of product that should reflect how the brand presents itself. So there are those capabilities. But you could also make the design system itself, might make it more advanced by adding more capabilities to it.

So there are those capabilities. But you could also make the design system itself, might make it more advanced by adding more capabilities to it. I think after that stage 5, there is very few room for improvement. But if people see opportunities, then reach out to me, because I would be happy to learn about them as well.

Okay. And hopefully, then we'll get another talk with a continuation of the next one. Exactly. Yeah. Then we'll take on stage 6 and I don't know where we'll end. Okay. So we're already looking for it for the next years event.

So someone here is asking if you could share some tips when talking about design system documentation. So did you have this experience? What can you tell us about it? Yeah. So documentation is always a sensitive topic, right? I think we all know that once the documentation is there, it's very beneficial to us. But there are very... I heard it in the previous talk as well, I think. But there are very few people who get excited about writing documentation. It could work to use AI probably to help you in writing documentation. But it's also really good to realize that if you want to onboard people on using the design system or using your technology, you need to do some sort of documentation anyway. And that can be in words. But if you are doing that, then please write those words down. Because that's your documentation for the next onboarding session that you're going to be giving. And that saves you a lot of time. And that's what we developers, designers like to do as well, right? We like to save as much time as possible. The goal is to be as lazy as possible. Do as much as possible with as few actions as possible. That's my goal personally. I'm not sure how that translates to any of you.

So would you say that it makes sense to invest in building your own design system from scratch? Or is it okay to use an open source one? So, yeah. So, the developer answer is it depends.

I think it does actually make a lot of sense to use some of the kits that are out there. Because they are very good. If we would have known about them when we started our journey, we would have been already a bit further, I think, in our development. There are very good toolkits that give you a lot of freedom in styling it the way you want it. So, they're not limiting you, but they are supporting you by providing all of the basics that you need anyway. There is no right or wrong here. It's about having the right resources and pick the right tool that fits within the resources and the goals.

Someone here is wondering if you could explain what you mean by culture compatibility. Maybe if you have an example, it would be great. So, the way we set up our design system is very close to how teams are already working. We have a culture in our organization where teams are already very open to collaboration. And they also had different domains, and the domains would try to find each other more easily than people from outside domains. So, what we also did is to set up the design system to allow people from certain domains to find each other and collaborate within those domains. Because we already knew that that would be a win. But not force them to do anything that's very much outside of what they were already doing. We asked people to contribute while working on features and not necessarily working on specific design system stories because that didn't make any sense for them. We had teams working on sprint goals, and their sprint goals rarely involve design system goals. So, what we did in our case, and that's our compatibility match, so to speak, is to have our teams working on the design system while they were working on business features. So, small steps, small increments, where we improved the design system gradually. And we did that because that's the way we were already working. And that's different for every organization, probably, but if you can set something up that's very close to how you're working, you set yourself up for success.

Everyone, thank you for joining, and thank you for coming here to speak to us, Johan. I'm sorry if I mispronounced your name. Could you teach me how to pronounce it properly? So, I heard a trick. If you were in English, think your run, then you got it. If in English you say your run. Your run? Yeah, then you're there. Okay. So, that's how you pronounce it. Okay. So, everyone, give it up for Johan. There you have it.