Subscribers & Stakeholders

[00:00:00]
>> So, let's dive a little deeper into stage one. I've really been sort of very high level with it so far and basically all I've told you is it's just all the stuff you're doing up to your first release. So, I actually think the focus for your stage one is really simple and I've used this phrase a few times with you, but I like this idea of discovering the right version one.

[00:00:21]
If you're in the business of software you know this, right? It's really risky. The biggest risk in software is that you've just built the wrong thing. [LAUGH] So, you do that and you've spent so much money moving down a path, now you have gotta to come back. You've gotta rediscover, it's expensive, right?

[00:00:39]
It's a lot of risks. And I think that's actually true in design system work to. What's funny about it is most people that I talk to, they just start by building a button, they start even building colors. They don't think about how to start, they just start. And so, I think this is where everything begins.

[00:01:00]
This is where you get to model that you're gonna be a part of the organization that engages with your subscribers. And so your challenge here is balancing that, we gotta release something quickly and we gotta show some value, right. We want to try to make this happen fairly quickly and we want to make sure that the things that we choose to build are going to show value out of the gate.

[00:01:21]
The way you succeed with that is you shape the project, right? You shape your early system approach, to show value to the right potential subscribers. And I want to talk first a little bit about how to do that because I think you have to start with your audience.

[00:01:36]
So this is a little bit controversial, I think, this this approach, but I'm okay with it and I would just say, do it on a piece of paper and then throw it away at the end. [LAUGH] I like to think about categorizing potential stakeholders or subscribers in this way.

[00:01:52]
So you wanna look around and you wanna see who has influence inside the organization and who doesn't. And then once you understand that, you're gonna actually try to do the work to understand who's with me in this approach and who's not. Who's an advocate for the system work, for the approach of a design system, and who's on the really extreme side, a potential saboteur, right?

[00:02:13]
Who's gonna do everything they can to make this fail? And as you start talking to folks, you kinda just generally sort of put them in these quadrants, right? So you can start to think, you know what? That VP of engineering was really against this. He feels like or she feels like we've got all the systems in place we need.

[00:02:32]
They've got a lot of influence, but they're also really not a part of this, they're not an advocate. So I've put them in that top left, high influence, potential saboteur, right? And once you've done this, you can start to really easily see, I wanna start with the folks who have some influence.

[00:02:49]
So I'm gonna look at the top of this chart. And then, it's it's funny cuz I think human nature is, let's just avoid the conflict, right? I'm gonna focus in on my advocates that have influence and we're gonna sit around the table and sing Kumbaya, we're gonna get this work done.

[00:03:05]
The problem is the real value here is actually in that top left quadrant. If you can build some relationships with folks who don't understand the value yet, but who also have influence, that's really where you should be focusing. Cuz if you can just take one of these folks and move them into that top right quadrant, you're really gonna protect yourself from a lot of the risk, right of this not working.

[00:03:31]
So the way you do this is you sit down with those folks, you understand their goals, you understand their frustrations, and you go back and you try to tell that story of the system solving those problems. It's sometimes hard, right? Cuz these conversations can be tense, and sometimes they just don't even want to meet with you.

[00:03:48]
But there's kind of a little bit of a trick that I use in those meetings I'll ask them. This is an old kind of sales tactic that if you're in sales or if you've ever been in sales, people will use this. You just try to say something like there's some question kinda like this.

[00:04:04]
Imagine that it's a year from today, and this new design system is live your team is using it and loves it so much that you just wanted to take me to lunch to say thank you. Just describe for me that future state. How did we get there? What is that moment like?

[00:04:18]
What is the system doing for you, right? This takes away all the sorta day to day grind of all the reasons the politics and it just helps them and you kinda to imagine that future successful state. I love this because you will get from them if they're willing to participate, all right?

[00:04:37]
And they probably won't all be but the ones that will, you'll get from them what it is that you actually need the system to do in order for them to become an advocate. So, now you know, now you can make a choice is that the direction the system should go or not, right?

[00:04:52]
And you can do the evaluation on how much time will it take to sort of meet those needs. This is really powerful, right? This will change. If you can do this, tell that story in an effective way. You're moving folks who are potentially gonna stop the work into people who want the work to be successful.

[00:05:07]
That's probably the biggest way that I would recommend you're looking to in terms of figuring out what that first thing should be. You also have to do the work to kind of define your subscriber groups. So, this is like the beginning of you being able to at some point in the future track adoption in an actual valuable, nuanced way.

[00:05:30]
In order to do that you first have to understand who are the groups of folks that could use a system. Now, this is highly dependent on how your organization is structured. So, I'll give you three specific examples of how you could approach it, but you'll have to kinda make the connection to the way your titles and teams and all that work.

[00:05:48]
So, one approach is product or feature driven subscriber groups. So you might have a group 1, which is e-commerce web. So this is the product, the e-commerce web product. So anybody who does anything on this product is a group. Maybe the iOS shopping app is another group that you are gonna attempt to support as a subscriber.

[00:06:12]
Or maybe the checkout flow. So, this is like a feature of a specific product, right? The people who are focused on the checkout flow for E-com, that's one subscriber group. So, you can break your subscriber groups down in this way, product or feature driven. Another way to break them down is discipline-driven groups, right?

[00:06:33]
So, this is simple. You might say all of the UI designers are one subscriber group. All of the UI developers are another subscriber group. All of the product owners, all of the UX researchers, all the content, you name all the different disciplines that are involved in getting interfaces designed and built and into production, each one of those could be in this example, a type of subscriber group for you.

[00:06:58]
So, that the first one is product or feature driven. This one is discipline driven. And then the third is actually a combination of those. So that's where you're thinking about discipline by product or discipline by feature. And some examples, there might be all of the UI designers that work on the E-commerce web product, right?

[00:07:17]
All of the UI devs that are working in checkout flow of the E-com web. So, now what you've gotta do is make your decision on how you want to classify these groups. And then just make a list of those groups, right, and where they sit in the organization.

[00:07:32]
In stage one, I spent a lot of time looking at org charts [LAUGH] that's just a weird part of this work but because the system touches all of these different pieces and parts throughout the organization, you really do have to have a good understanding of who sits where and who reports to who and all of that.

[00:07:52]
So you're gonna spend some time looking at the org chart [LAUGH] and you'll make your own list of here's how we think about the groups of subscribers. Once you've done that, you can then do the work to understand how those groups track their own metrics, okay? This is really important, again, for when you go to try to measure this stuff later.

[00:08:12]
If you haven't done this, they all have their own ways of measurements. They all have their own KPIs or their own goals that their boss is having them meet. So, what you need to do is do the work to understand how they're tracking that stuff. It's not your job, actually, as a design system team to track the velocity or efficiency of a product team, right?

[00:08:36]
Hopefully you can correlate as teams begin using the system that that metric improves, but those teams should be responsible for measuring their own efficiency. So, you need to understand how they do that. And then you need to have them, or you need to get access to that data, and you need to start capturing baselines in stage one.

[00:08:54]
Cuz if you can't show how fast, in this case speed, how fast we used to be, you're not gonna be able to show the improvement we've made, right? So you've gotta capture those baselines. So, this is sort of the beginnings of you getting to understand how we can actually at some point in the future track this stuff.

[00:09:13]
Now, I keep using this word discover, so let's talk a little bit more about that. Now, we've done the work to sorta define our subscriber groups. So, I just have sort of some generic concepts down here brands products division, however you have categorized your subscribers, right? We're gonna plot those out along the x axis here.

[00:09:33]
And however you categorize your scope in this case, I'm using that definition the anatomy of a design system, from the very first section today, to say we've got foundational stuff, we've got tokens, we've got core systems, we've got components, right? So, there's assets, documentation and processes for each of those four layers.

[00:09:50]
So, that's sort of in general the scope of a system. And so what I like to do is take a look at all of the different potential systematic approaches that it already exists within your subscriber groups. So, I met this woman once I was just literally looking on LinkedIn for people who do design system work in the research, I've just done a lot of reaching out, getting to know people.

[00:10:16]
And I came across this woman who's title was, design system archaeologist. And I was like, what the heck is that? So, I just messaged her, and we did a call, and she told me her job, which I love. It is basically she just is responsible for going through all of the work that subscriber groups are doing and looking for really good systematic nuggets of work.

[00:10:41]
And you might take the approach of saying, let's build a color system that works for everybody, right? That's a really broad approach. This woman's job was not to to do this, right? She was on the design system team. This is how you would typically start, a lot of teams start this way, they might say I'm gonna build the color system.

[00:11:00]
Everybody needs colors, so let's build a color system. We'll do some tokens and we'll make this really useful thing. But instead, she was out there looking for specific parts of the organization that had their own color system, right? Each of these groups probably has their own stuff, right?

[00:11:18]
They've got these vertical flows, right? I've built my own way to handle the checkout flow in my subscriber group. But what we're interested in identifying, is this little color system that subscriber group one has built, right? And that's what this woman's job was. She was out there digging literally, and talking to folks and finding really good approaches that already existed.

[00:11:40]
But that just weren't made systematically. So, then the goal becomes, let's take that little nugget, and we're gonna make that. We're gonna expand that horizontally here to work for all these other subscriber groups, right? We're gonna build a color system that works for everyone. And we're gonna start with the work of one group.

[00:11:59]
What's really cool about this is that you're building trust with this group. You're making them very much interested in becoming an adopter of your system. By default, they're contributing to your system, [LAUGH] right? You're building a relationship you're getting to showcase their work. And this becomes a nice model for how you can discover a good way to move forward.

[00:12:22]
So when you combine this with the concepts about influence and sabotage, that's where you can say, okay, I know this one exact is not for this work they have a lot of influence. I'm gonna go take a look at everybody underneath them.. Let's find something systematic that we can use as a nugget to start with.

[00:12:41]
And all of a sudden you're bringing them into the conversation with you. Does this make sense as an approach? Okay, now, again, this is the ideal, right? It's possible that you gonna look out and everything is spaghetti code and terrible or there is no systematic approach and maybe that's why you're brought in at the beginning.

[00:13:01]
But start with this, right? Start by looking, cuz what you'll see is that the work that it takes to go do this digging actually helps you build some rapport, build some relationships anyway, and you have to do that work regardless, yeah.
>> Just curious, in this circumstance is it better to try to cater the design system to work?

[00:13:22]
For everyone, so maybe expanding upon some of the operating so that it's a little bit more broadly adopted, or trying to get the individual teams to focus in and take what you built out for that one subset. And try to make it consistent, I guess in the reverse order.

[00:13:39]
>> Yeah, maybe this is sort of the challenge of systems work in general, right? It's like, how custom is this? Am I asking everybody to change to work towards the way that I think it should work? Or am I as a design system team accommodating more folks with with the work.

[00:13:57]
So, everything you're asking me is culture related. So, when we get to the culture, I'm wanna show you specifically how that decision is actually it's a spectrum of choices that you have to make, depending on the culture of the organisation and the culture that you're trying to build in your systems team.

[00:14:13]
So everything is on the table here, right? If you're more of a collaborative organization, you're probably gonna want to work with these groups to let them have influence in how in this case a color system is built. If you're more on the control side, it's actually part of the culture for you to say actually top down this is what we're doing?

[00:14:39]
You need to come on board, right? So, obviously you gonna be nice about it [LAUGH] but those are two okay approaches. There's nothing wrong with either of those. But I can't tell you which one to do because I don't know the organization well enough to make a recommendation.

[00:14:52]
So, you'll get a chance to kind do a high level assessment of your culture and that'll actually lead you down a good path for a decision there.