Design Systems Q&A

[00:00:00]
>> Ben: I know that we said we would have some time to kinda follow up with bigger questions here at the end too. So questions? Yeah, what's up?
>> Speaker 2: What's the ideal size and makeup of a design systems team?
>> Ben: Yeah, it's hard. I think that changes as the system matures, I know that.

[00:00:19]
Usually, the perfect team for stage 1 is not the perfect team for stages 2 and 3. So I think that the team needs to grow, especially around in the areas of customer support. That's just an area where your design system team needs to be really thinking that through.

[00:00:37]
So around stage 2 and 3 is when I need to see those people being added to the team for it to sort of be healthy. I mean, I know I was just at Clarity at the end of last year, Clarity Conference, it's a design system event. There was a really interesting conversation happening among the attendees about how a lot of them feel so lonely in this work, because they are, in many respects, the only person dedicated to this inside their organization.

[00:01:06]
So there's a whole channel now created in that design system Slack group that's just designed system team of one. And, I mean, we see all these articles from these big teams, right, and we read about how IBM is doing this amazing work. And they are, it's brilliant stuff, I love it, but it's also not the norm [LAUGH].

[00:01:26]
So I love those articles, I read all of those, and I would definitely encourage you to do the same. But I would also say, you gotta be realistic with what you can accomplish given the resources that have been allocated in your context. I love this conceptual thinking, but I've tried to make this more practical, but it's impossible, because every system is unique.

[00:01:49]
They're all different based on the needs of the actual organization. So one thing that I can encourage you to do if you're asking that question is to look at the different product teams or feature teams or squads or however you break up your work. Look at the way those teams are structured and at least use that as a model, okay?

[00:02:10]
That could be a way that would get you into stage 3 pretty easily. So that might be something to think about. I wish I had a number to give you, but [LAUGH] it's not that easy [LAUGH]. Any other questions? Or any aha moments, yeah, what's up?
>> Speaker 3: So what do you do when you've got that stage 1, stage 2 design system team, and kinda the resources that the team is using to educate itself and to sort of try to create sort of a shoot for are looking at Adobe's work.

[00:02:46]
And they're looking at the Carbon's work and they're like, yeah, well, this is how they do it.
>> Ben: Yeah.
>> Speaker 3: How do you kinda rectify the fact that your team probably can't do that? [LAUGH]
>> Ben: Yeah.
>> Speaker 3: At least not at first.
>> Ben: Man, it's so hard. I mean, I have definitely been guilty of that in the past.

[00:03:07]
>> Speaker 2: It's easy to fall into that [COUGH].
>> Ben: I think the cultural stuff that I've been doing has helped me have conversations with an organization about how, hey, we need to structure the approach here based on who we are. So just that simple concept goes a long way toward saying that that work that Carbon did or that's in Spectrum or whatever, those are great examples, but we have a different culture, we have different skill sets.

[00:03:36]
We have different experience levels here. So also something like Spectrum and Adobe is a little bit more externally oriented too. So it's kinda like, okay, is that what we're doing? Are we trying to build something for other people to build stuff with or are we trying to focus on something for our team?

[00:03:55]
So it's those kinds of conversations that have helped sort of slowly move that dial, but it's not a quick change. And it's also really possible to look at those articles and read whatever and say, you know what, here's the thing we can pull from this that will actually help us.

[00:04:14]
And maybe here's a few things that probably don't apply, and to be sort of more vocal about calling that stuff out instead of posting the article and not saying anything, right? That, I think, is actually really dangerous. Cuz what are you communicating with that? You throw the article in the design system channel or whatever, are you saying we should all work like this?

[00:04:33]
Or are you just saying this is interesting, or here's another perspective? So maybe a little bit more communication, a little bit more transparency about your thinking for the piece, which requires you to get in and actually read it [LAUGH] and dissect it. But I think that's where I would say don't just willy-nilly throw that stuff around.

[00:04:51]
Post it at the beginning and say, you know what, I think this is brilliant, but we're not a system of systems, so we're not gonna do what Spotify did or whatever, we've got to be more controlling than that, and here's why. But I love this little bit that they did, this way that they sent so and so out to work on these product teams or whatever.

[00:05:10]
So maybe there's nuggets you could pull, I don't know if that would help, but yeah. Another one online?
>> Speaker 4: I think this is probably related, but what do you think about white-label component libraries, like Microsoft's FAST or ING s Lion?
>> Ben: Yeah, I mean, we were talking a little bit about this over one of the breaks.

[00:05:29]
[LAUGH] I think we've been in a lot of situations where an organization started with another system as sort of a starting point for their work. And they've come to us because they feel like it's slowing them down and they need something that's more of a custom fit for them.

[00:05:48]
So I'm definitely biased by that experience. I'm sure there are systems out there that have been built on those third party or white-label platforms or frameworks. I think it can be, depending on where you are culturally, if speed is the most important thing, then maybe that's a great opportunity for you to kinda get a lot of work done in a quick time.

[00:06:12]
I think I would just be conscious of the debt that you're accumulating by making a choice like that, right? You don't get anything for free. So what you're getting is a lot of quick to market, we're gonna be able to make a lot of progress in a short amount of time, but at what cost, is the question you have to ask.

[00:06:29]
So in the future, if this thing doesn't do what we need it to do, how hard will it be for us to yank it out and replace it with our own? That's the kinda questions you've gotta ask.
>> Speaker 4: One more, is Storybook really good or what tools of, let me it right.

[00:06:49]
>> Ben: That's all right, yeah.
>> Speaker 4: What's your tool of choice for tracking of a design, [SOUND] one more time. I wanna nail this question.
>> Ben: Yeah, fine.
>> Speaker 4: [LAUGH] Do you like Storybook, or what is your tool of choice generally for keeping track of a design system within a company?

[00:07:10]
>> Ben: I always get this question about tools, and I have intentionally left every reference to tooling out of all 200 of these slides. [LAUGH] And that's because the tools are gonna come and go, that's just the truth. I want you to build something that's not dependent on a tool.

[00:07:29]
I mean, this is so bizarre to say cuz at one point, I was talking with our creative director about this. And I remember saying to him, we have to understand design systems as an abstraction. We need to understand what they are absent of any tool. And he was like, absent of any tool, what do I have?

[00:07:47]
And we are just going back and forth on this. And here's the problem, right? I love Figma, I think it's an incredible tool. They've done a ton of work to build a really good community of folks who really love their product. They've built it in a way that it's extendable, they've got a really cool architecture.

[00:08:05]
I mean the collaborative stuff, it's amazing. But if you only build your system in Figma, you're fully dependent on somebody else's product to have a thing that all of your products are dependent on. That's just not a healthy place to be, so I would encourage you to define the system outside of the context of any tool.

[00:08:26]
And then of course, you're gonna use these tools to build the system but there's a thousand of them. There's I mean I love figma. We use sketch for a long time. I know folks who are using Adobe tools like they're really good designed tool. We've definitely done a ton of work with Storybook especially in our react projects, but there's lots of other options there's tons of tooling around like zero height and supernova.

[00:08:49]
And plugins for Figma that lets you manage your tokens and all of this stuff it's like really starting to kind of bloom and grow. And you're gonna be faced with making choices about how much these things cost, what's the debt that I'm getting into by aligning myself with this way of working.

[00:09:06]
So I would just say, I think there's great value in almost every tool that I've seen. I've been like, that's actually really cool. I love that they did that. [LAUGH] Just try to make sure you're also thinking about what happens when we shift away from it? So I'm sorry that I'm just not gonna answer that question in the way that it's asked but we've had great success with storybook if that's a tool you wanna use for sure if it fits your context.

[00:09:35]
>> Speaker 5: How granular should you make the design system? One of the things we're struggling with right now is do we designing component for kind of its worst case scenario. Or do we design the component for, the 90% of the time use case and try to avoid, bike shedding at all costs?

[00:09:53]
>> Ben: Yeah, I mean, you can definitely get too into the weeds. I think, there's definitely the model where you're kind of looking at, I guess in general, my approach to this is to say like, what's the commonality, right? So let's look across all of our subscriber groups and whatever this component is in their context, what's the overlap, right?

[00:10:15]
So that means you're gonna be building less in your system? But for you to do that, you also have to then think through how those subscriber teams can take that core piece and turn it into something that fits their model. So I think that's a better approach personally than trying to build a single component that can transform into all these different things.

[00:10:41]
That's my personal opinion there. And there's probably situations where I would recommend something different, but does that make sense?
>> Speaker 6: Yeah, no, absolutely. And then kind of as a follow up, how close should the representation of a component in code be to the component in whatever creative software of choice that you're using at the time?

[00:11:03]
So for me, Figma. We have our product design team that likes to build our very elaborate prototypes in Figma to show to stakeholders, what have you, but there's just a lot of limitations with how you can get. Let's say, a date picker with the drop-down calendar and a whole bunch of secondary interactions inside of it to look exactly like in the code.

[00:11:28]
So there is a little bit of disconnect for us right now, but that's more so just because from a technical standpoint, it doesn't make sense, at least from my standpoint. Sorry, from my perspective to spend time that could otherwise be spent building the component out in.
>> Ben: Yeah, [COUGH] so your question was how close should they be?

[00:11:49]
And I would say they should be very close [COUGH]. I think they should be the same. That's the ideal. But what I would say to the sort of further explanation of what you described is that's actually not a design system problem, that's just a workflow problem, right? You have a separation between design and development.

[00:12:10]
And you can't have that, you have to have those people working together. So the result would be maybe there's a front end developer that's helping in the development of this prototype, even though they're not actually coding it out. They're just like sitting there working with those folks and pairing with them as they're developing a concept.

[00:12:28]
You wouldn't wanna sell something that you can't build. So you gotta be careful with that. For a long time,my organization, we just didn't have those distinctions. And when we first started, it was even more extreme. We were just all in one room, it was a small group, and we were all literally our title, every single person was developer, whether we were a designer or not.

[00:12:54]
And we thought of ourselves as just, the end product is the digital thing we're delivering. For us at that time, it was a lot of website stuff. And so we just blurred the lines. And that has kind of, that's like foundationally where we came from. And I think that sort of stayed with us.

[00:13:13]
And we definitely have distinct roles now. But we have a lot of overlap, and we don't put those people, those disciplines on work on their own. It doesn't work, it results in what you're describing all the time and it's just frustrating for everybody. So I don't like the idea of handoffs at all.

[00:13:31]
I'd rather we're just sort of cycling through together. Again, that's a cultural change though, that may be a big organization shift for you to have to require something like that. The system team could perhaps model it, right? So as you get an opportunity to build out that team, don't just hire designers.

[00:13:51]
Bring in the different disciplines so that you can actually work on these problems, solving them in really good, healthy ways together. That then becomes a model for how other teams could operate. That whole designer developer thing is still so, it's so entrenched, and it's back to just the way our organizations are structured in a lot of ways.

[00:14:16]
It's super unfortunate. I wish it wasn't still like that. But I definitely see design systems as a way to kind of get at that. Yeah.
>> Speaker 7: Could you share your personal inputs regarding component types? For example, Atomic Design by Brad Frost assumes atoms, molecules, organisms, etc.
>> Ben: Yeah, Brad's work is foundational to everything that we're doing right now in the industry.

[00:14:45]
I am so glad that he published that work and has used it with such success. We've definitely done projects, especially early in our systems work where we took that approach. We've used pattern lab in the past, and we've had good success with it. I think we've gotten away from it because in some cases the language of atoms and molecules, and all that stuff, has kind of gotten more in the way of communicating with folks than I think was necessary.

[00:15:18]
So the approach that personally that we kind of ascribe to now is kind of what I showed with the anatomy is that we think that components can be simple, or they can be complex. So, you can have a component that is very, very simple, a label. You can also combine that, with a button and an input, and now you have a search bar component.

[00:15:42]
And, so that the simple idea of just we can nest these things to create more complexity I think is all that's really needed. And that's really the root of what the atomic model is trying to communicate so regardless of what you call call those different layers. Or if you even need to call them something, I don't really care as long as you're gaining the idea that we can increase complexity by combining these things.

[00:16:11]
What's up?
>> Speaker 8: So this big picture question.
>> Ben: Okay.
>> Speaker 8: So you spent a lot of time researching, thinking about all this stuff around design systems. As you've compiled all of that knowledge, do you have any thoughts on kind of where things are going, right? Are there any things that you've seen where you say, this seems like a natural evolution from where we are now?

[00:16:39]
>> Ben: Yeah, I mean, that's interesting. I definitely think about this a lot, especially with all the stuff happening around AI. Before a lot of that, before mid journey and some of the stuff from Adobe and all these other kind of text to image type things happening. I was thinking about how, there's a bunch of books that are old architectural books on systems that I've been kinda just thumbing through and they do this even back in Roman times and stuff.

[00:17:14]
There's all these books about architecture where they just lay out all the patterns. They say, in this scenario where you have the water here and the sun's rising on this side, we wanna make sure we think about the window placement here, and the breeze, and all these. And they've literally thought it through and kind of codified their style of architecture from that time period.

[00:17:33]
And it's cool, the books also have a lot of examples, you can see these old structures, some of them still standing or almost. And it's really neat to see how those things were actually put into practice. I love the idea that we could find ways to be a little bit more explicit about the rules and the guidelines for our systems so that we could trust more generative type things to happen.

[00:18:02]
I think there is critique. This happens with every movement, especially in interface work where, when responsive happened, I remember all the articles that were like, responsive web designs is killing our creativity on the web or whatever. Same thing is happening with systems, right? Systematic approach removes all the creativity.

[00:18:22]
Well, that's just BS to me. It's like, what problems do you wanna solve, right? Do you wanna solve the border radius problem again, come on, good grief, move on. So, solve those problems, solve them well, move on to the new challenges. But I love the idea that we could articulate the sort of big picture guidelines so well that we could then trust the system to generate a new color palette for us, or whatever it is that we want it to do.

[00:18:51]
So, I definitely think there's people doing that stuff now. We'll see how it plays out in terms of its usability, and if it's actually helpful, or if it creates more confusion. I definitely think there's also a trend toward, well, I guess early on, we got this big idea of what a system could be and we thought, let's build a system that does everything.

[00:19:16]
[LAUGH] And so, systems got wildly complex, really fast, and a lot of them fell apart because of it. There is a lot happening here, there's a lot to maintain. So, I definitely think there's a trend where people have been through that pain and they're pulling back, they're scaling way back in what their system offers.

[00:19:36]
And they're choosing to offer things that are really high quality, that are well done, really well done pieces that become then the bedrock of a lot of product work instead of being the fancy stuff on the surface. So, I think that definite movement towards doing less is something I like.

[00:19:56]
And it's enabling for your teams too, right? For your subscribers to feel like okay, I got the stuff I need, I got my type and my colors and I don't wanna mess with that stuff anyway. Let me just build the actual experience. So, that can be a really good, I think, shift that we're starting to see.