Anatomy Q&A

[00:00:00]
>> And with that, we have an opportunity to kinda break and have a quick discussion. So any thoughts or questions on this initially?
>> In my experience, that anatomy is an ideal-
>> That's right.
>> Use case, right?
>> Yeah.
>> However, I've never worked on a design system that had the opportunity to really properly layer and build upon that core.

[00:00:23]
>> Yeah.
>> What are your thoughts regarding that? For example, we're still working on figuring out a tokens processing strategy, which is clearly foundational.
>> Yeah.
>> How do you continue to build up when the foundation is finished?
>> Yes, this is such a good question. I feel like design system work is notorious for this, right?

[00:00:47]
It's like we're trying to change the oil in our car while we're driving it down the road. [LAUGH] It just feels like you can never stop. And this partly is because I think the organization is never associating, the design system is too far away from revenue, right? It's too far away from the money to say we have to stop, get this right, and then start it up again.

[00:01:10]
That's, no company will do that. You can't stop work on the products, right? So, I'm a big fan, we're gonna talk a little bit more in depth when we get into stage one deep dive, but I'm a big fan of this concept that I just call, in design system work, just the refactoring build.

[00:01:29]
So, instead of you thinking, in fact, if that's something I should change with the way these slides are laid out, because I'm not telling you start with foundations and build each layer perfectly, that's just not realistic. I am trying to show you kind of the ideal. In practice what this looks like is we do the work to understand who is important for us to serve right away out of the gate cuz we want influential folks.

[00:01:51]
So I'm gonna talk about how to find those people. And then we want to think about what's gonna solve the biggest problem for them right away. And we want to do something meaningful out of the gate if we can. So we're starting with a fairly complex piece of something in your system, usually a bigger component.

[00:02:07]
And what we'll do is we'll talk a little bit more about discovering that right first piece. But from there, it's really about refactoring that into something, because those pieces that you may see that are out in products already, they're great. They may be well-built, but they're probably not built in a systematic way for all the other products to consume.

[00:02:27]
So that's the refactoring process, and that's where then slowly you're putting these little pieces and parts in, and it's a constant refactoring. That's just the only way that I know to do it. So you're never building it perfectly. [LAUGH] It will never be perfect. But I like to think in the ideal because I feel like we have to have something we're reaching towards, right?

[00:02:46]
And that gives us a really good decision-making, sort of filter. It's like okay, if I'm gonna make this choice, I have to understand the debt this is gonna give me, the technical debt or creative debt. And know this has to be a part of my backlog later to come back and refactor.

[00:03:01]
So that's kind of the only way we are able to do the work. Does that address your question, okay. Awesome, thanks. What's up Mark?
>> In an enterprise team building a new design system, what are the biggest mistakes we should try to be avoiding?
>> Yeah, I mean, I'm definitely gonna talk a lot about that.

[00:03:19]
If I was gonna pick one, well, there's sort of two, and we'll get into this when we talk about origin stories, is you can't rely too much on direction from leadership or too much on direction from individual contributors. You have to find a balance, you have to have support from your executives.

[00:03:38]
But if that's all you do, you're not gonna build something that's valuable for your subscribers. So then you need to balance that with input from subscribers, the folks who are building products every day, right? That's how you determine what's valuable, and it's a constant balance of those two things.

[00:03:54]
So I think the biggest mistake I see folks do is if they're top-down, which we'll get into, they get a budget from a boss, and they're kind of beholden to that boss to do what that boss thinks they should be doing. And that's one big mistake, they're gonna have struggle.

[00:04:09]
They're gonna struggle with adoption until they change that. I guarantee it, I've seen it 1000 times. The other side of that is, it's the grassroots model where all I do is build something that's valuable to me. And I'm not branching out and thinking about all the other disciplines that are also doing this work and reaching out to stakeholders to get long term investments so this thing can actually last and have a real impact.

[00:04:31]
So those two things are probably the most common in the early days that I see. That's more of a perspective than it is like a coding error, right? [LAUGH] Other questions?
>> Just another comment, the cost of miscommunication is incredibly under-observed, I'm excited to hear more about that discussed.

[00:04:51]
>> Yeah, it's unbelievable. I mean, I can't tell you how many times I have come out of those meetings just feeling so frustrated that we misunderstood each other. And I hate that, especially because I'm a bit of an idealist, as you can tell already, right? That's this whole day is gonna be about the ideal.

[00:05:11]
But this work has so much potential to create unity inside of our organizations. That's what I really love about it, right? We're putting everybody on the same team instead of seeing designers and developers competing or IT and communications or however you're structured, right? I've been in those meetings where the air is so thick you could cut it, I mean it's tense, right?

[00:05:32]
And that's not how it should be, we're all trying to serve our clients, we should be doing that well with each other. And I feel like you can kind of unify around building an internal thing that really does help you do that better together. That's what I love about systems.

[00:05:48]
So that is, I think, the most powerful thing. I think you had a question?
>> Yeah.
>> Yeah.
>> Have you ever worked with teams who say they know they don't prioritize a homegrown design system, so they're using something like, say, material design as their baseline. And what are the big tips you would give for that approach?

[00:06:07]
>> Yeah, I've helped a lot of organizations make a decision in that direction. And usually, so we're gonna have a whole section at the very end on culture, and I think actually, that's probably the most relevant. That's the most common factor that I can see in terms of why an organization might choose to use something like material.

[00:06:26]
I have nothing against material, I think it's brilliant. I just think in some cases, it's probably not gonna serve every need you have, right? So the more mature the systems get that have chosen to start with something like that, the more friction they feel with it. So it usually works really well early on, and it helps them make really rapid progress in those early stages, but there's always a moment where they realize it's just not gonna do what they need it to do for their brand.

[00:06:56]
And so that's where the bigger refactor kinda comes in. It's technical debt that you're assuming, and you know you'll have to pay for that at some point in the future. Now I don't wanna misspeak, right? I'm sure there are design systems out there that are using it well and feel like it's everything they need, but culturally, this is where it comes in.

[00:07:16]
It's kinda like what's important to the organization? If it's speed, if it's competitiveness, then probably doing something like that just to be fast and quick to market is probably maybe a good choice. But if it's about collaboration, if it's about our team, so we'll walk through the different types of cultures, that's a different model.

[00:07:34]
And those teams are the ones that probably will struggle using something that's like a third party out-of-the-box thing.
>> Do you see differences in approaches, say, for a B2B app versus a B2C app?
>> I've tried to look for that, and I haven't really seen a lot of that in terms of the design system approach.

[00:07:53]
So, I wish I had that data for you, but I really just don't, I mean, we're building interfaces. So a lot of times, whether it's individuals that a company using it or individual consumers using it is just not that different. So I haven't seen a lot of that.