Improving the System

[00:00:00]
>> So, the transition from stage two to stage three is tricky, right? We just talked about that teeter totter possibility, that's very normal. But I wanna remind you that this transition is really about a mindset shift for the design system team. This is when you feel comfortable enough with adoption, with your grasp on adoption, that you're ready to focus on other challenges.

[00:00:23]
Now, one way that I think about the overarching focus of stage three is that they're really about finding a way to keep your promises. And this is because back in stage one or stage two, we made a bunch of promises to our leaders, to our potential subscribers, and we said, this thing is gonna help you.

[00:00:43]
And it's gonna make you faster, it's gonna spread accessibility around the organization, it's going to create more consistent interfaces, it's gonna do whatever it was that you needed to say, whatever promises you made. Well now stage three, you kinda gotta live up to that [LAUGH]. So the top challenge here is really proving that the system does what you said it would do.

[00:01:05]
The interesting thing here is, you're given a little bit of grace in stage two because people get this, right? You built the thing, but you have to spend some time bringing people on board. So until there is good adoption, there's no way for you to make any correlation to any benefits.

[00:01:21]
There's no way for you to make an impact. So now it's time to keep those promises and this is where we wanna see the actual data and it takes time, right? Even in stage three, we probably still need more time of capturing that data. And really, it's not so much, I mentioned this earlier, it's not your job to track the efficiency of your product teams, right?

[00:01:42]
Of your subscriber groups, they should be doing that. What you need to do is the correlation. And so when I say that, here's what I mean, as something changes, we see something else improve, right? So this is now for all of the data nerds out there, I don't think there is a design system that exists that has enough subscribers that we're gonna get statistically relevant correlation here, okay?

[00:02:07]
So that's not the point, but there's so many ways to make improvements in the things that we promise. So a design system is clearly not the only way for you to become more efficient. It's not the only way for you to be more consistent, it's not the only way for there to be accessibility spread around the organization.

[00:02:26]
There's lots of ways to see those benefits. So what we wanna try to do is show that when things change with adoption, which is the left side of this, we see changes or improvements, or not improvements, on the right side of this. So that's the metrics that we promised, okay?

[00:02:43]
I can't tell you what to track, right? Here's a list, I mean, this is not intended for you to read all of this. But there are thousands of things you could track, okay? Just a few, what are the percentage of products with a level one grade A adaption, right?

[00:02:57]
[LAUGH] That may be something that if we can see that change, we can then correlate that to perhaps the velocity of product or feature teams, okay? So you're looking for two sides of this equation. And you're trying to say, as we see this go, as we see this adoption change, this type of adoption metric change across our teams, we also can expect to see these kinds of improvements in their data that they're capturing about their work.

[00:03:24]
All right, so, does this make sense? This concept of correlation is kinda what you have to do, that's kinda your job, right? I do see a lot of design system teams that think it's their job to track all of the stuff on the right for their subscribers, and there is no way you could possibly do that, all right?

[00:03:41]
So this is where you almost kind of reverse engineer it, right? Once you've got a subscriber and you've defined your subscriber groups, you go to them and you find out what are the things they already track? If you're asking them to start tracking something now that's new that they never tracked before, there's even more resistance, right?

[00:04:00]
So start with the things they are already measuring. And hopefully, if you followed sort of this maturity model in the stage one, you're actually gathering baselines for a lot of the stuff on the right. So you know what this data used to be, you know what the average age of bug or feature requests was in each of your subscriber groups.

[00:04:20]
So now you can look to see that improve. The other thing that's really, really important here is adding disciplines to the design system team, right? So stage three is usually, if you're able to kinda show some of those correlations, this is usually where your leadership will say, all right, you've done well, you kept a few of those promises, good work.

[00:04:41]
And then you can say back, here's all the work we're trying to do, here's the backlog, we have a lot to accomplish. And I think we can make a bigger impact, but I need more people on my team. And so, this is challenging, right? Most teams, they see this, they get that open position and they look at their existing team and they think, we need to do more of what we're already doing.

[00:05:04]
And they hire another designer or another front end dev or something like this. Maybe that is the case, but I always try to challenge people to say design systems are for way more than designers and developers. They're for every discipline, as we talked about, that's involved in interface work.

[00:05:22]
So think about all these other potential roles that you could also be filling on your team. And in fact it doesn't hurt to write a little job description for each of these and take it to your leadership and say, look, this is what I think we actually need, right?

[00:05:37]
So now you might be showing them this is actually in stage three we do have to get to that product mindset. So we need QA, we need a content lead, we need a support person [LAUGH] there's a ton of work to be done there. So I would encourage you to branch out and think about the open positions a little differently than maybe your default sort of reaction is.

[00:05:58]
A nice way to make this list for your company cuz this is just my list, you might look at your product or feature teams and say, what are the disciplines they have? Okay, we already know culturally there's support for us to have UX writers because they are on our product teams.

[00:06:15]
Or there's a whole group of folks who do that work for us inside the organization. So you're gonna have a lot easier time hiring from roles that already exist somewhere else in the organization onto your system team, than trying to make the case that we need to create a whole new role here that people will get it, right?

[00:06:35]
They'll understand, yeah you probably do need a product owner. [LAUGH] So think about that in terms of how your organization is already set up.