Maturity Q&A

[00:00:00]
>> Quick pause for conversation around the three Es and how you see those kind of filtering into your work. Are you doing all three of those things? If not, what are you missing? Anybody have thoughts or ideas here?
>> I guess more broadly, this is probably something we should have discussed at the very beginning, but how would you define a design system, right?

[00:00:22]
Because for us it's the component library, and then the actual UI assets within Figma, but then also the style guide that's associated with how they should be used in the real world. And those kind of three things combined identify as our design system. And for us, especially with the educate and the style guide associated with an input field, for example, and how you should be using an input field, is where we struggle the most.

[00:00:53]
Because there are so many different nuanced instances of where it kind of abides by the rule set, but there's this unique circumstance where it needs to be its own special use case.
>> Yeah.
>> Which, I think, once our engineering staff sees that once, it's just kind of a slippery slope where it becomes much easier for them to shy away from the guidelines that we've tried to establish.

[00:01:21]
>> Yeah.
>> So, I guess, for me, how do you take the expertise of your product designers, your UX designers, and try to gracefully tell your engineers like, these are things that are set for a reason and we need to abide by them?
>> Yeah, there's sort of a complicated answer to this, and it comes into the sort of cultural side of things, which is how individuals interact with each other inside the organization.

[00:01:53]
So if you are a designer, you've designed and built this input for all these engineers to use. And you're going to them and saying, we finally have the tools now as designers to work more systematically. So Figma gives us the ability to do this, a more systematic approach.

[00:02:10]
Well, I guarantee you those developers are gonna say we've been working systematically since we were born. [LAUGH] That's just the way development works, right? If you do CSS, we come up with classes. That's a way to abstract a set of styles. That's a systems thinking approach, right? So we now have the ability to do that in design.

[00:02:32]
And so, I think the approach to somebody like in that scenario where a designer is saying, here's the input you need to use this engineers. We have to go to them with the understanding that, hey, this is actually new for us, but we know you've been doing this a while, and let's talk about why these things are the way they are.

[00:02:50]
This is also a combination of leadership. So if you're in a more of a top down scenario or you've got more of a control type culture, that's where it's okay for one part of the organization to say, this is the process you follow, these are the rules, follow the process.

[00:03:05]
In a more collaborative culture, that's not okay. That means we have to work together to come up with a solution, and that's the right way in this culture for us to operate. So I can't answer that without knowing more about your organization. But when we get to the culture section, like I'll ask you, where do you fit here?

[00:03:25]
And then that'll maybe help us inform the way that we would go about addressing that specific issue. Does that make sense?
>> Yeah, absolutely. Thank you.
>> Okay, yeah. The last thing I asked you to do before was to come up with one or two ideas for things that you needed to do to move your system into the next stage of maturity.

[00:03:41]
So what I want you to do now, this is an exercise we go through with our clients, is we go look at their backlog and we take every single item, every story, every ticket, however they do it, and we break it into these three things. And that's because everything that you're gonna do in your system, there's always an educational component to it.

[00:04:00]
There's always an engagement component and there's always an evolution. A lot of times we're only thinking about that third column. So I would encourage you just to spend a minute, you don't have to necessarily get all this done now. But this is an approach you can take with your backlog to go through it and say, okay, we actually haven't accounted for all the educational side of what we have to do here, so let's think through each of these tasks and try to figure out who do we need to educate.

[00:04:25]
Who do we have to engage with to actually make sure that what we're doing is the right thing, right? So this is a helpful little exercise you can do.
>> Should we use the same colors for all the products of the company? Or maybe it ties in with this, but-

[00:04:40]
>> Man, that's like, [LAUGH] that's a huge question. Actually, that's a brand question probably more than it is a design system question. I mean, there's so many ways to tackle that. I don't know that I can give an actual answer to that. Because without knowing the intent of the products and the different set of audiences, it's really hard to know.

[00:05:05]
We've definitely built systems that are multi-brand, a single organization owning multiple brands. So they have this idea of kind of brand themes associated with them, we usually use tokens and a token system to enable that. We've also worked with organizations that have dozens of products all under the same brand.

[00:05:25]
And so those have a very consistent or cohesive look and feel. So I think it sort of depends on the specific use case. That's a great question, and I would probably encourage you to take that to folks at brand inside the organization and start a relationship with them, cuz that's really the way you get to the answer to that.