Enterprise Design Systems Management

Maturing a Design System

Ben Callahan

Ben Callahan

Enterprise Design Systems Management

Check out a free preview of the full Enterprise Design Systems Management course

The "Maturing a Design System" Lesson is part of the full, Enterprise Design Systems Management course featured in this preview video. Here's what you'd learn in this lesson:

Ben walks through a framework for how to mature a design system through education, engagement, and evolution for each stage of the maturity model.


Transcript from the "Maturing a Design System" Lesson

>> Let's move on. So we've covered the anatomy, we did a really high-level overview of the maturity model, and we just kind of explained origin stories. Now what I'd like to do is kinda walk you through a very simple framework for how to mature your system. So in order to mature through the stages in a healthy way, no matter what origin story you have, there are three areas of focus that you've always got to be working in, period, all the time.

And those three are education, engagement, and evolution, conveniently all starting with an e. [LAUGH] So the first one, education, educate, this is where it's you, a one-way interaction, teaching, right? You're educating folks throughout the organization. These could be potential subscribers, they could be your existing subscribers, they could be stakeholders, leadership.

And you're just essentially teaching them about the system and why this is important, right? When I mentioned those two consulting engagements from earlier, this is one of the things they had both been missing. They weren't doing the work to spread around that common language, the common understanding, the reasons why they were doing the work.

And when you make assumptions about that stuff, folks are gonna come up with their own stories. So that's really what was happening in both of those cases. The other thing you're trying to do here is really cast a vision for what the system could be and what it could do for your organization.

And that's why I think it's important to have some time in your day set aside to the higher level thinking, right? That 30,000 foot view of what is it we're actually trying to accomplish here? Where could we go if we did this really well? You're responsible for essentially leading that part of the effort.

You have to cast a vision, nobody else is gonna do that [LAUGH] for you. So that's a part of this, and that's all part of these education tasks. Engagement is a two-way interaction. This is where you're interacting with the subscribers in particular, or leadership. This is where you're learning from them, right?

So the example I gave a moment ago of observation is one way you can engage with them to understand the kind of problems that they're facing. Anything where you're getting feedback, right? So if you've got a way for them to submit bugs or ideas or that kinda thing, that's all part of engagement.

Really the goal here is to kinda give them a say in the way that the system grows, and that's how you build something that's actually valuable for them. And of course, engagement means you're always looking to recruit folks, right? You're trying to get them on the team of the system.

Not maybe necessarily full-time billing on the team, but you want them as adopters, you want them as contributors. And so in order to do that, they have to know that there's value in what they can offer you and you have to communicate that with them. And then evolution is kind of the things that everybody thinks of when they're doing a design system.

They think I need to go build this, I need to go design this. So it's a team effort, it's iterative, you're making the system better. Anything you're doing in terms of design, where you're actually creating components or development, where you're building those. Or user experience, maybe where you're testing and iterating on those, all of those things, right?

And remember not just the assets, but your documentation and your processes, all of that is part of evolving the design system. One of the most common problems that I see in folks when we're doing sort of these assessments of a system. When somebody feels like they're kinda getting stuck and they can't break through into another stage of maturity, most often it's because they're focused on only one or two of these things.

And they haven't done the work to either educate, or maybe they haven't done the work to engage, so they're having a hard time with adoption, right? For me, it's usually pretty simple. It's kinda go in, understand the steps they've taken so far, do some interviews with subscribers and the systems team, and then we can quickly identify, you know what?

There's a lot of confusion about this. Or you asked for people to contribute and they did, but you didn't use their contributions. So now they're feeling like, we didn't have a good process around contribution, right? So there's maybe gaps in some of the things that you've tried. So what we try to do is help them take that bigger view, sit back and take a look at all the things they've done, map out where those fit into something like this, and then say, actually, we are missing this and we're missing this.

Let's show up the foundational pieces so we can move through this in a healthy way. Now I wish it was as easy as just do the education, do the engagement, do the evolution, and then you move into the next stage. But [LAUGH] of course, it's not. So I tend to think of it kinda more like this, right?

It's just a cycle of these three things, and you're just constantly doing these. And after you do that long enough, you're gonna kinda look up and realize, we've actually matured in a really healthy way into the next stage. So, very simple, right? If we take this, we can kinda overlay it on top of the four stages of maturity like this.

And I draw it like this because I want you to see that. I call this an additive framework. In other words, it's not a set of things you do in stage 1 that are educational and then you stop doing those when you get to stage 2. Instead, when you move to stage 2, you're adding more of those tasks, but you can never stop being the person casting the vision, right?

You can never stop educating about what a system is, why it's important. Those are just things that have to be part, they just always have to be coming out of your mouth. [LAUGH] People are gonna get sick of it and you, as a leader, are gonna feel like you're just repeating yourself.

But the thing is you're talking to different people all the time, so you have to push through that kind of fear of just sounding repetitious. And the other reason I draw this is cuz when I have conversations with executives about budgets, I like to show them that the volume of work this team is trying to tackle is growing a lot as the system matures, right?

The things you have to do in stage 1 just to get the first version live, well, it's a smaller team, very focused. But when you get to stage 2, when you get to stage 3, you need more people, you need more time, it's almost impossible to do this without that.

And so this visually tries to kinda communicate that, hey, we're expanding the scope of the work here. So let's talk about, just quickly, the way that these three es, education, evolution, and engagement, change through the stages a little bit, okay? So in stage 1, education tends to be things like just very simply defining what systems are, [LAUGH] and doing so in the context of your specific organization.

So this is not you going out and looking up someone else's definition of a design system and then just putting it in your PowerPoint, right? This is you actually thinking through how does this impact us in our context and communicating about that, right? Sharing the benefits, sharing the investment costs, the approach, casting that vision that we talked about.

Engagement here, and we're gonna spend a lot more time on this a little later, but this idea of discovering what will make your first version really desirable, right? So in stage 1, you're setting yourself up for either your adoption success or your adoption failure. And what I would recommend is that you really invest in this engagement activity stuff in stage 1, because that's kinda set you up for a really easy stage 2, if you've built something that's valuable.

Of course, also engagement, you're gonna be identifying early adopters who might test, identifying leaders who might be interested in supporting things like this. And evolution, it's all the stuff you need to get that first version live in stage 1, so you're iterating toward that first release, you're sometimes focused on the fundamental layers.

You're building a doc site often, we haven't even talked a lot about that, but most design systems have a documentation site where these things kinda live. There's all kinds of great third-party tools for building those. A lot of folks build those from the ground up themselves. But it's sort of a single place where all of this lives, and you kinda link out to all the important resources and assets and stuff for folks.

And you're writing really good docs here, especially around how to use the system and how to come on board as a subscriber. So that's high level the kinds of things that you'll be thinking about at stage 1. Now when you move into stage 2, you've got that first version live, you don't stop doing these things, [LAUGH] right?

You're gonna continue iterating, right? You're gonna continue building the doc set, you're gonna continue evolving all this stuff, but you're also gonna add to it a bunch of new stuff. So in stage 2, education grows, right? Now I didn't have a system to show in stage 1, now I have one.

So now in terms of education, I can demo this thing. I can actually show you how it works, I can even sit with you, maybe in the engagement section, I can help you do that. We wanna capture these demos and record those and put them in the doc site and even transcribe them so the content is searchable, and all of that should be part of what you're thinking about, right?

You wanna share some adoption stories, I actually recommend that you tell some really good stories. Here's a couple use cases where this team really wanted it. They came on board and a matter of weeks and all of a sudden we're seeing some really good improvements. And tell some of the horror stories too, right?

This team tried to use it, they really struggled, and here's why, and here's what we did to help them, right? That's you communicating that you're a partner to them, not just that you want the folks to come on and figure it out themselves. This is where you now have probably a roadmap, you're thinking about the future of the system.

You're giving those folks a voice collaborating in the roadmap in the engaged area. But you wanna share in terms of education of what's coming next and why we've chosen to do those things. And then we're gonna talk a lot more about adoption goals and metrics too, because that's a really tricky, that's a very nuanced conversation, so we've got a whole deep dive section on that in a moment here.

But it's time, as you develop those things, you really have to be educating folks about what it means to adopt, cuz that's a whole another conversation of complexity. Pairing in the engage area, gathering feedback, collaborating on that roadmap. Of course, supporting the people who have already subscribed, and then doing the work to go up, if you're grassroots, talk to leaders, get financial support.

Doing the work to move down, get to know the individual contributors, understand how you can support them better if you're top down. And then evolution, of course, you're continuing to evolve the system, right? But specifically, documentation that really covers how to adopt, this is one of the ways you make it easy for them to come on board as you make it very clear and very simple for them to do so.

I say strategically adding new features because in stage 2, oftentimes your team hasn't actually grown in size, but the scope of work is larger. So you've gotta be really careful about where you spend your time here. I think you've gotta be really specific about the features you wanna add or the new components or whatever it is that you're adding to the system.

And you've gotta make sure that it's really well documented so that it's trustworthy, the quality has to be there. And again, strategically fixing issues, there's a lot of prioritization that has to happen in stage 2. Stage 3, surviving the teenage years. Now we actually have some adoption going on.

So what we can do is, and we're gonna talk a lot more about this, we're gonna start to correlate improvements, the promises we made earlier, we're gonna be more efficient. It's very generic, but we're gonna be more efficient. So now you can start to correlate the use of the system with better efficiency in those teams.

And that's tricky to do, but that's how you kinda make good on your promises. We see lots more sophisticated communication strategies here, very refined documentation for how to use the system and how to adopt. We're starting to see things like governance and contribution come into play. And so we're educating, we're doing the work to kinda share all of that.

There's this sort of series of processes that kinda come into play usually in stage 3, ambassador or something like this is kinda what they're called. But the idea is just that an individual who's not dedicated to one team or the other spends time with one team or the other.

So you may be sending somebody as an ambassador into a product or feature team, or they may be sending somebody to kinda come on board the systems team for a while and spend some time there. So there's all kinds of different ways to structure that. That's a really cool way to engage with folks, it's also really disruptive to all the teams involved.

So it comes with pros and cons and it kinda depends on what you need in a given season as to whether I would recommend you doing that kinda thing. I see organizations start to host those folks coming in, but also to provide really cool onboarding, right? This is another way where you can sort of solidify the value of the system in different ways is by saying, hey, all of our product teams are supposed to be using this thing.

When a new employee starts, we've developed the whole curriculum for them to learn the system, all right? So now new employees spend a few weeks learning the system, they go into your product or feature teams as real advocates with a solid understanding of how we do interface work, right?

So this is powerful stuff. You're taking the load off of other teams, you're the right person to be doing that, you're the right team to be doing that. So I think there's a lot of value in that as a potential engagement, sometimes accepting contributions, really solidifying that support, and of course, continuing to evolve the thing, right?

We start to see a lot more definition of more complicated processes here, continuing to add documentation and assets. This is where we're seeing teams, well, okay, we've done all the things we can do to support the folks using React, now we gotta bite the bullet and get all the Angular stuff in here.

So now we're taking on that extra work of saying, we're gonna manage two sets of assets and two different frameworks for our dev teams to use, and we're gonna own keeping those things in sync. And we're gonna work with those teams to really figure out how to do this in a healthy way.

In that case, you might also choose to scale back a little bit on how much you're gonna offer, right? So it's okay to be removing some of these things, that's where we start to see deprecation come into play. So stage 4, all the things we've talked about, of course, but also this is where you're kinda getting a seat at the bigger table, right?

So here it's where you're actively participating in some bigger picture conversations. These teams are the ones that have their pulse on what's happening in the industry, pulse on what's happening throughout the organization. And they're explaining the design system's role in any of these new initiatives that might come along.

They're actively demonstrating how the system is making all the product work better. They are continuously interacting with subscriber groups of course, and they're sitting at the table for big conversations. Really, the evolution here is about making sure that we're actually giving you the best way to design and build digital interfaces in our context.

So it's very much a leadership, it's a really proactive kind of approach, whereas a lot of the earlier stages are a little bit more reactive.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now