Measuring Quality in Design Systems

Excellent. I could start. I could give us a prompt, if that's okay. Unless, Amy, you would rather do that.

No, please do.

Okay, cool. So where we last left off, we had a good conversation a couple weeks ago about design systems and speed and efficiency and the difference and quality. And we got into a bunch of things that we're like, oh, we got to talk about this again and further. So there's a couple of directions that we could go. I'll tee them up, and then we can kind of pick live, you know, where we want to go. I bet we'll get to all of them in a roundabout way. One is that, Amy, you had some really good prompts around. Like, what would it look like, though, if we didn't focus on speed? Like, what would design system. What would the design system world look like if that was just taken off the table? And forgive me if I'm paraphrasing poorly or for free to correct. Correct that. So that's one thing that we could touch on that I think would be really interesting, you know, that I bet we all have thoughts on. The other thing that we could talk about is, like, we sort of open this door to just metrics in general, like, what should you measure? And we talked about that a little bit last time, but we didn't really dive into that too much. So that's another place that we could go is like, what are things that are worth measuring? How do we measure them? What's difficult to measure? What's still worthwhile to, you know, all of those things was kind of a door that we. We cracked open last time. So those are the two things that, to me, I think could be good starting points. But I'd love to hear from the two of you about if you have other things you want to add to that.

Well, I could pick up the thread on metrics. I have some stuff to say about that. So I think something I was kind of reflecting on after we spoke last time is you said, dan, I think you made a really good point, which is that moving fast isn't the same as rushing, which I guess was kind of my initial complaint was, you know, people who are measuring speed, in my view, or the people that I'm kind of working with and stuff, are often in an environment where they're pressured to rush, which means kind of a lot of the time, sort of unacceptable compromises on quality. And I think that, likewise, it's kind of important to preface this whole conversation by saying that less than perfect isn't the same as unacceptably. Bad. So, you know, I was kind of thinking about what do we mean by quality? Like it's not, you know, that say, just saying quality is probably not that helpful because everybody has different ideas about what quality means and everybody I guess has different kind of non negotiables and things that, you know, actually they may be happy to let slide. And I would love to hear from both of you if you have any sort of specific thoughts around what does quality mean for design systems.

I would almost want you to clarify. Are you talking about quality of the produced experience or quality of the design system that enables you to produce the experiences?

Yeah, that's a really good question. I guess both. But I think that the thing that's more realistic for design system teams to accurately kind of measure and quantify is the quality of the things that they produce and give to teams. I think that it's definitely worth somehow engaging with the quality of the end product. And I don't sort of buy the argument that I've heard a fair bit that design system teams can't take any responsibility for the quality of the end product. But I do think that it becomes a lot harder to measure and it becomes a lot hazier in that respect. And I certainly think that's something that they share responsibility for with the end product teams. I don't think I likewise, I think they can own it. So I guess for the purposes of this I'm thinking about the quality of the stuff that design system teams give to teams to use.

Yeah, I think if you remove the constraint of speed, that can certainly lead to higher quality. But I think that will also lead to a lack of satisfaction and a lack of evolution of the system being able to grow and evolve to suit the needs and so people that will erode satisfaction and trust. I think about a conversation I had an hour and a half ago with a design system design lead who is creating a library in figma but started to use S, M and L instead of in the code and sketch and docs, it's sm lg, MD for like those terms. And so it's like a little leak in quality. I'm like, why are you changing that? Yeah, I kind of agree it should be one character, but it leads to a lack of alignment of outputs. And so one of the aspects of quality that I aspire to is alignment across outputs. But would I block the release of a FIGMA library to get it in the hands of people using it? If we already know what the levels are? We're just quibbling on A little bit of the semantic naming. No, I would let it go. And so that's where that good, good perfect is the enemy of the good. Enough like you were referring. I think you were implying in the way you framed it too.

I've never heard that phrase, Nathan, that you just use. I love it. The leak. A leak in quality. Cause like I think that describes well like what happens for better or worse at scale with design systems. It's like a leak in quality on a component. It's like that's not so bad. They're doing, they're doing a thing. But then times 60 components in the design system times however many more usages of that or instances of that or implementations of that. That's where the leak in quality becomes like oh, that's where our user, our experience is actually deficient by 50% or something drastic because of all the scale of that. So thanks for that. I'm going to keep using that phrase, a leak in quality. I wonder if the two of you think that like are there objective ways to measure or define quality? Because I know that my mind goes specifically to subjective ways right away and I don't think that's complete. But when I think about quality of I think Amy, how you phrased it is the things that people who are working on the design system work on. So like namely components or at least largely components. When I think about the quality of component, I'm like, is that the visual design? Is that how tight the rounded corners are? Like that's where my mind goes when it comes to quality. But I wonder if the two of you think differently about that.

I, I think it depends. And that's an annoying answer, isn't it? No, I think, I do think it kind of, it depends on what we're talking about. Like the quality of what specifically. So I think a lot of the time it's going to be a combination, isn't it? Like the first place that my mind went when I thought about quality. The thing that is generally a kind of non negotiable for me is accessibility. Like I just, that's something that I feel is really important and obviously you can make a really inaccessible bad user experience with some really accessible components. So certainly I think it's worth kind of thinking about like where the line is there between what a design system team can control and what product teams can control, especially on the subject of accessibility. But in terms of the kind of basic boxes that we can tick, for me that kind of thing is reasonably measurable. I mean we have a standard, a global standard to follow there. And I think that, sort of making sure that we've adhered to that and kind of, I think, coming back to what Nathan was saying earlier, but correct me if I've sort of misinterpreted this, I think that it kind of uses the system and it's, it's. It works as part of the system. That also feels like quite an important quality measure because I think that the implications of it not doing that are quite significant, I suppose. Like, I think what kind of message does it send if we're not even using our own system to make our system, if that makes sense. So I guess for me, like, kind of, I am quite, I am quite pedantic about that kind of thing. I'm quite, you know, specific about, about following system standards.

I love the word pedantic, by the way. I love pejorative and punitive also, as similar words. Anyway, what you make me think about there is also the framing of the question. Like, it is a very black and white question to talk about. Is this of high quality or not? Well, everything's on a continuum. I wrote an article about testing figma components on medium, and you can definitely establish the very specific criteria that you're looking for. Even when you start talking about layout, you start talking about fixed versus fluid and height versus width, and you can break down how you assess the quality of something and whether it works as you expect it to in very well defined criteria. You can do that with accessibility. And so even there, it starts to get more onerous the more specific you get, and you start to exclude things that you actually intend. But you also establish a boundary, like, you're not going to meet all the accessibility criteria in your first pass Based on WCAG 2.1 or whatever the latest release is. And so even Amy, it's like, I would be challenging you how much accessibility, which criteria can we sort of flex on or not? And the other thing, particularly when, if we bring it back to consistency, which is a hobgoblin of. I forget what the word hobgoblin. Goblin of Foolish Minds is the Emerson quote consistency. Like, if you talk about the nav, you have a nav bar that goes at the top. Well, is everybody using it at the top? Or is everybody locating the account profile in the upper right? Or is everybody actually in the menu showing the exact same links? To navigate a shared space, to wayfind across journeys, to have crossover journeys that all weave together. Okay, I just mentioned a lot of different things. So actually, what is Consistency. Because the design system doesn't own any of those questions. Does anyone actually delivering on those things, like you talked about.

When do you think? Or sorry, not when do you think? When do each of you bring up that question? When you work with clients, teams, you know, like, because at some point I imagine you address it. Right, so when, when does that happen? Is there a sequence that, that goes in and I have, That's a leading question. I have an answer to that as well. When do you, when do you bring that up?

Oh, you're such a consultant. And you know what? As a client, what I typically hear is just tell us the answer, Dan. I wonder. I'm not trying to, like, just. I don't have an answer, Dan. I, like, want to hear yours, but Amy, like, I don't want to disrupt your ability.

I also want to hear yours. And I also want to clarify. When you say, when do you ask clients that question, you mean the question of what is consistency? Who owns it?

Yeah, like, like when, when do we define what consistency is? Like, is that a prerequisite to each of your work? Is that like, ah, we could figure that out later. There's some other things that are bigger fish to fry. Like that. That's mostly what I'm poking at is like, where does that go in the sequence? Because I think, and this is. I'll, I'll start, I'll give the framing for it. The. That comes up a lot in, in my work, in that I think a lot of the teams I work with are surprised when those questions come up because it's not where they think. It's like, oh, I would have thought we would have addressed that sooner. Or, oh, I would have thought we would have talked about that later. So that's why I'm like, oh, I wonder where that initial set of expectations come from.

And to be clear, are you talking about consistency of the end of the user experience, the eventual user experience?

I think I'm talking about when do you even start talking about what are we going to agree on as consistency? So like, Nathan brought up a couple of different ways you could talk about consistency. My opinion about most design system things is it actually doesn't matter what you agree on. It just matters that you agree on something. I'm like, it doesn't. The answer actually doesn't matter. It just matters that this group of folks align on that. So whether we define consistency as like, everything in the nav has to be in the same place every time on every interface, or consistency just means we have all of these things present and where you put them is up to you. That doesn't need to be consistent. To me, neither of those answers are wrong or right. It just matters that the team goes like, yeah, we agree that that's the thing that we're all going to do. So where does that conversation happen? Is that like, all right, week one, I'm starting with a new client. We're going to create a glossary that includes a definition of consistency. Or for me personally, I'm like, let's just let that emerge. Let's just build some interfaces together or do some exercises together or do this other thing together and then out of that, then we'll go. It seemed like what we were trying to make consistent was this and this and this. And now we can canonize that as our definition of our starting definition of consistency. But that happens weeks in, as opposed to where some teams are like, I thought we would have done that on day one. On day one, as we define quality and consistency and this and that, and then we're going to go follow those, those definitions.

No, I mean, I'm with you on feeling your way and thank you for clarifying that. I think where I was getting slightly distracted there was my pedantic brain again and fixating on the idea that, you know, we can define consistency. Like consistency is consistency is, is consistency just means consistency. So I think actually what we're talking about defining here is like, consistency of what with what? And I think like, and sorry, that's not me trying to be a smart ass. That's just me, like, turning the question over in my mind. And yeah, I really agree. Like, I think sort of feeling your way as you go is really important there because there's no point sort of trying to standardize things that don't need standardizing and actually benefit from more kind of contextual attention and divergence potentially. So, yeah, I also am not particularly interested in starting out with saying, like, this stuff all has to be the same and this stuff should always be different. And, you know, I think it's very much kind of something that you learn as you go along as people start to use the system. And also, you know, as your audience broadens, like, it's going to become potentially less possible to be consistent about things that might be feasible to align when you're. You're only serving two teams, you know, whereas actually, like, I'm thinking of a client I'm working with right now and we're focusing on kind of quite a well defined but narrow sort of portion of the organization. And I absolutely know that, you know, in two years time, half of what we've built is probably not going to be relevant because it's, you know, it's going to go to a bit of the organization that just has a very different approach, like they're operating in a different country, like it's, it's just not going to work. So I think building systems that are kind of designed to evolve and change and are set up well to do that is really important and not kind of expecting to set those things in stone.

I too agree that you don't need to solve all those things up front. And it can really feel boil the ocean like when you get into those conversations and they can swirl into lots of different directions, like with just designing a component, frankly, these kind of things. I tell a story about designing a card component, for example, and there's so many different features and ways that you can approach solving a card as a component in your design system. But ultimately I try as a person to facilitate the conversation around the range of things that people are talking about and then first start to say there's clearly not alignment in this first third of things. And can we all just agree we don't need to solve for those right now? Let's just put those down the line, let's not have those conversations yet, let's not have opinions. And then there's this second set of things where we actually all agree and can we acknowledge all the things that we agree on? And then there's a third set of things in the middle that we need to kind of agree on enough so that we can move forward. I use the term can we make a provisional decision to choose A, B and C and we'll let data that we feel back or get back into the system, or we'll let other constraints that we see emerging enable us to acknowledge A, B and C are still squishy. We're moving forward with A, B and C, and if they need to change, we'll change them. Everybody cool with going forward with A, B and C for now, until we learn more. And, and that provision, sort of giving that an implicit provisional, prepended term in front of those decisions disarms the group. Okay, yes. And it enables the group to be able to say in another week, I'm bringing up B again because I learned these two other things, we need to change our view on B. And so that sort of disarms and empowers the team to continue to grow together.

It's funny, Nathan. I have my Own version of that. The phrase that I use is McDonald's theory. Do you know that phrase?

No.

So it comes from John Bell, who was a designer that worked at Twitter for a while. I don't know where he is now, but he wrote this great article about McDonald's theory, which is that when you try to decide with a group where to go for lunch, it's always weird because everybody's like, where do you want to go for lunch? Everybody's like, oh, I don't know. But instead he's like, so what I do is I go, hey, everybody, let's go to McDonald's. And as soon as he says that, everybody's like, no, no, I don't want to go to McDonald's. That's dumb. That's, you know, I'd rather have something healthier. Let's go for Thai food. No, I don't want Thai food. I had Thai food last week. Let's do pizza. And like, the theory, the McDonald's theory is people will come up with better ideas to ward off bad ones. So, same idea, a provisional decision. And so that's a thing that a lot of the teams that I work with, they adopt that vocabulary now where they go like, well, let's just. McDonald's theory this, which is basically meaning let's just suggest a thing that we're going to start with, and if somebody has a better decision, they will surface it. And if we don't, well, then that's the best decision for right now until we come up with something a week later, two weeks later. So that idea, I think that idea, whatever we call it, is so important in design systems, and I think is a little bit antithetical to what design system teams think they should be doing, which is like, we gotta say what the best thing to do is, right? Like, so we have to have the answer. And it's like, well, yeah, but, like, you know how hard it is to have, like, the best answer right now. So let's have the best answer for now, I guess, until a better answer comes along and let that be fine, let that be normal, is that, like, this is what we did and said, and then this is what we learned, and now we have this new thing that we're going to operate with. But I find a lot of teams have trouble with that idea that they're like, but we can't change it, though, because we're supposed to be the rules, right?

McDonald's theory, I'm stealing that. And I like. I think, yeah, it's. It's really interesting because I think something that it does is it forces people to also think about what they care about. Like, I think it's really hard to be given a kind of blank canvas and say, like, what do you care about what you know, as I kind of did at the start of this conversation, to say, like, what are your non negotiables, what are you willing to kind of move on? Whereas actually doing what you said and kind of proposing something, like, you learn a lot from your reaction to that thing, don't you? So you can kind of, you can, you know, potentially, like, I think sometimes people aren't just being polite. I think sometimes people genuinely don't really know what matters to them or what they feel kind of strongly about until it's put in front of them. So I like that idea. I am interested in this kind of, this, this idea about sort of we can always evolve things and we can always change things. And I absolutely do think that design systems need to be sort of designed to evolve and teams need to be set up to kind of evolve with them. But I'm interested in sort of, if you have any thoughts about what the right kind of balance is and if that varies. Because I certainly think it varies between clients that I've seen because, you know, my stance, I guess would have been once upon a time, like the more that you introduce kind of improvements to the system and the more you're sort of forcing updates on your teams, like that creates quite an unstable system. And potentially like certainly in government I really noticed, like that was, that was a problem, like teams were not set up to be kind of constantly bringing in changes, especially kind of breaking changes and stuff. So we had to be really mindful of that. And I just wonder like if you have kind of thoughts on, you know, where the line is there or like how you go about finding the line.

I think certainty is something that people expect out of a design system. The design system is the place for the answers that everybody's made and once it's answered, we can move forward with confidence. And so whether it's what your vision of the system is in general versus how you're labeling your scale of typography, size choices, when you ruffle the feathers of that uncertainty and you start to change those things, it does create an instability. And so I often characterize the most mature and effective systems are the ones that have prepared the people that use those systems to change at the rates that they need and want to change in a way that's fairly predictable. And so you make change visible, you communicate how it works really well. You're really sensitive to the fact that people might not want to upgrade when you make the change, but how does that enable them to change the things they want to change and not change the other things they don't want to change, which is you get into questions around component versus library level versioning. As a part of that, I want to change my button, but I don't have to upgrade my modals and my banners and my toasts in order to get the change for the button. And so that makes people anxious. On the other end of the spectrum, though, I worked with a client that said we used to change so often and then we went to quarterly enhancement releases and annual breaking change releases just because we heard from our community that created the predictable cadence that they could target with how they're thinking about their apps. And can you imagine like, you know, when the next major change is going to come and if the only thing that will disrupt that is external forces, like a rebrand or something like that, but still like that kind of predictability so that they can time how they change with how they know you're going to change is just the visible and transparent communications between the two. And how can you make that really, really predictable?

Yeah, and I just think like a really interesting question that raises is like, yeah, there's absolutely value in that kind of predictable cadence of releases, but how does that impact our kind of original question about quality and what's good enough to release? Because if you know you're not going to change this thing again for a year, like, does that not raise the bar?

I haven't, I don't think I've ever said it this way. So I'm mostly just thinking out loud, you know. So I'm a riff on something that Nathan said and that you said. Amy. The idea of design systems being certainty, I'm like, that feels like mostly right to me or mostly accurate to me. But there's. There's like a degree, a nuance that's off which to me I think about design system and I'm never again. I've never used this phrase. I'm trying it out here. It's most, it's more about the proximity to certainty than certainty itself. Right. That, like the fact that. And this is why, this is why I try to help teams evolve their thinking from a design system as like, you know, a library. Because, like that's, that's a limiting view of a design set is accurate, but it's a limiting view and thinking about it as like, you know, it's like the way that we do things.

Right.

Like, if you think about it in that broader sense, then the way that we do things is always changing. It's supposed to change because. Because otherwise, if it doesn't change, that means we haven't learned anything new since we established the thing. And that's actually a poor thing for culture. Right. And I think that's why a lot of design system work is culture work more than it is like component building, you know, designing work. I think I would imagine we would agree on that and I imagine a few more people would agree on that too. And so like, it's the proximity to certainty where I always know what the main brand color is going to be, even if it changes. And if it, if, if on my feature that I'm working on, main brand color was pink and then there was a rebrand and main brand color is orange now. Well, the proximity to orange is actually 1 npm update away. Like I could choose to do it or I could choose not to do it. You know, on my feature or on my team, I could be mandated by my manager that we, we have to upgrade to the new brand by whatever. But it's the. Without a design system, your proximity, you're a lot farther away from making that change because now you're a product cycle away. Well, we actually need two new sprints to open that code base again and then we have to refactor all this stuff. Whereas built on a design system, well, it's an easy change. So it's that proximity, I think that like that is important about the design system, not actually the fact that you're always going to have the, the certain thing right away, real time. I think that's a tough expectation.

I think like a mathematician, I have a mathematics degree and so convergence on the truth as opposed to the truth. People talk about design systems as a source of truth and so it actually isn't. This shouldn't be the source of truth. It's the source of the pursuit of the truth. And we're always going to be converging towards that. But the truth will maybe never. It really is never really reached. And so Kaleg, who works at Shopify as a Dev DevOps Dev Tools person, he worked at Salesforce, he did a lot of token work and, and so on. He, he's the person that helped me see, yeah, design systems are sort of always converging, always trying to reach for what the answers are and helping everybody else understand what the answers are, but we're never really going to get there, and that's okay. And so how do you help other people understand that you're converging, you're actually not the source of perfect, unchanging truth? Sorry, go ahead.

I was just going to say, like, a way that we kind of experimented with that in government was with being kind of fairly explicit about our uncertainties. So, you know, at the point of kind of releasing components, like being quite clear in the documentation, like we had a section in the documentation called like known gaps, known issues, known gaps and things. And actually, you know, people, people, something we learn from that is like, people are much more forgiving of you not having the answers if you're explicit about not having the answers. And I think sometimes that idea that design systems have to provide certainty, I think is a. Is a line that design system teams tell themselves. And actually, I think where we get into trouble sometimes is obscuring that we are uncertain about something. It's like, oh, you know, this is our best guess, but we'll put it live and pretend it's like the best thing ever and we're really confident in it. And actually, you know, sometimes we do have to put things live where we don't have the answers. And that's. I think it's empowering for teams to know that we don't have the answers and to know where the gaps are because then they can help us to fill them.

I think that's how I think about most things related to design systems is the, like, design systems are the pursuit of all of these things that we hold as good quality, consistency, certainty, all the ty words. And I don't know if this is pessimistic or realist or what, but the idea that we will never reach them shouldn't be a deterrent to doing them. And I think that relates to all the stuff that we've talked about both here and the last time that we talked, which is the things that we measure, even though they're hard to measure and even if we might not actually achieve them, it's still worth it to do a lot of those things because you're making the system system better by doing it. And I think that a lot, I see a lot of teams have a lot of dogma. I think, Amy, maybe you might have tweeted about this recently that like, just a little bit, the idea that like, design systems are about creating or establishing or enforcing this dogma that, like, it's gotta be this way. And I'm like, I think that's an unkind way to think about what a design system's role is at an organization. Like, I think. I think it's there to say, like, this is the current state of things. And if you want to be up to date with the current state of things, here you go. Do it like this, you know, do it with these things, with these assets, in these ways, you know, and then you'll be on par with what everybody else is doing here, whether on par is a good thing or are a bad thing, at least on par. So on par, without judgment about whether that's a good thing or a bad thing to do. And I think the teams that try to strive for, like, we're going to define a rule are ones that have a tough job and a tough road ahead of them. Whereas the teams that tend to be like, we're just going to try to capture this for everyone and make it easier for them to be at this bar, wherever that bar is for us, and that it's not a relative measure, that it's not like, well, this bar is like 50% of where we want to get to. But it's just this is where we are. I think one of the things that really bugged me about the culture of product work, I think, Nathan, you said this a little while ago, is that a lot of teams don't have in their product roadmap a way to change, to go back and change things. So when something changes in the design system, they're like, well, that was four sprints ago and we are never going to go back to that. It's like, okay, well then that product is going to remain legacy, you know, for some version of legacy, because you haven't built into the culture. The idea that you're going to go back and change things, which I think should be part of digital product work in general, is we learned a thing, we're going to go make it better for people, you know, if that product is still worth living. So I think, like, that's the stuff that needs to change organizationally, culturally, in order to really make good use of a design system is, you know, our product cycles have to accommodate that. And not only accommodate, but encourage that. So something like saying, this is the week where you're gonna. You should expect updates to happen. Well, great. Now everybody knows because it's planned in advance. You know, one of the things that we do with teams a lot at Super Friendly is we build in what's called a systems week. And it's sort of like a three to one Ratio of like three, three weeks out of four, we're going to do product work, you know, and that's what the design system is going to support. But then one week out of four we're going to do stuff that's not going to touch product until later, you know, which is like, we're going to do some, with some spring cleaning, we're going to clean up some stuff, we're going to refactor APIs, we're going to do some design updates that we've been meaning to do on our figma. Like we're going to do some of the spring cleaning. And I think that cadence has, I've seen that start to like really affect teams in a positive way where they're like, that's the work that we want to do as a systems team. But the priority on that work is not over indexed and it's not under indexed. It's like proportional to what it's supposed to serve. So I think that idea of like, we need to set up a cadence in advance that people can go, oh, this is where that work goes. I think it really helps people with going like, oh, now I know. So now I don't have to be anxious about it. I don't have to go like sneak that work, you know, in between the cracks. I can really just go like, all right, three weeks from now, that's where I'm going to do that work, or four weeks from now, that's where I'm going to expect these updates to come. And we could plan for it.

I think too, when you think about dealing with change, it's not just can we change and are we going to change? But it's the users of a system wanting to know when will you have that change and how much will that change from what I have today. A couple examples being when you have a backlog of components you haven't actually delivered on yet, it's not just that they want to know that it's in the backlog, they want to be able to anticipate, well, are you going to deliver it within two months? Because if not, we'll build it ourselves and that's okay. And everybody has to be okay with the sort of relationship of the timing of those two things. The other one is when you're going through a major release cycle that has a major version number on it just because you're making some breaking changes that nevertheless will take a dev team of any competence about a day to complete to like weave through the new naming structure, do some other things. But then the product manager sees a breaking change and they think the consequence of that is complete UI refactor, which really isn't what it is, that the scale of the work is different. And so helping them understand when the change is going to happen and how much that's going to impact what they've already done are the other things that you want to keep your eye on.

That's such an underrated part of the design system work is when I was working with a team just last week and we were working on a component status page and the first inclination was here's the backlog components that we have and the status that they put was upcoming. And I was like, well, that doesn't say anything, of course it's up. It just says that one day we'll work on it. I'm like, what can we do to set a better expectation, even if it's a long expectation? And so what they wrote was upcoming 2022. And I was like, great. Like, that's something that just means sometime this year we'll do it. So if you need it next month, you know, don't hold your breath that we're going to do this. If you can wait till 2023, because that's where it is on your roadmap, well then we'll, we will have it for you because we've promised it. And I was like, and it doesn't mean that we can't change those dates. We could totally change those dates, but we have to tell people about those to set those expectations. So like, just even it's still broad, but changing upcoming to upcoming 2022 or upcoming Q4, like already gives teams a lot of like, oh, now we know what to do with that piece of information.

Yeah, I think that's so important, the whole kind of expectation management issue, because, like, I think I'm sort of getting to a place where I'm wanting to separate out component like design system backlogs from. Here's a list of components we know about that exist like in the world. Because actually, like, you know, when you've got 250 components on your backlog, like, it's not. Some of those things are just not going to get touched for years or maybe ever. And I think it's almost like having that status, I think is important because you can, you can be honest about the fact that there are some things that you're just not actively working on. And I think like a really important piece here as well around expectation management is, I don't Know if this is something you've both seen, but certainly like something I've noticed is that with, with design system clients, I quite often kind of engage with them at the point that they just had the business case signed off and they're like, right, great, we need some people to come in and help us make it happen then. And what has happened is that for several years, usually there's someone who's been sort of like banging the design system's drum and saying, we need the design system. We've got so much inconsistency and inefficiency and we need to make things better. And stakeholders have remained unpersuaded. And then at some point they go, okay, yeah, they have some money, build a design system. And then all of a sudden those stakeholders that have been being really resistant to the idea and all those teams who've been being quite resistant to the idea are like, well, okay, can I have this component tomorrow, please? And like, the message that I try and quite often sort of emphasize to clients is this isn't a new problem. Like this inconsistency in teams building product level solutions for something that probably should be centralized has been happening this whole time. And you've survived. Like, yes, we want to fix that, yes, we want to make it more efficient and more consistent. But it's okay to see that as something that we're going to chip away at over time, not something we're going to solve in a minute. And I think that that's just a really kind of interesting dynamic for me. It's like, I think with any other product you would expect this sort of iterative development, but with design systems it's quite often the bar is set quite high from day one and people become sort of something that was happening all the time as standard suddenly becomes intolerable. You know, it's like, absolutely, absolutely not. We won't be building one of these at a product level.

To me that's a challenge because we're not building with them, we're building for them. And the nature of using design systems is implicitly or explicitly, they choose to depend on us and depend have a dependency on the work we do. And so they want to understand what's the nature of that dependency, how stable is that dependency going to be, how much is it going to offer me in a timely way the things I want to depend on? Because if it's not going to, it's not going to be a good fit for me. And when I put my like, like adopter hat on like that all the way I was explaining that is from the point of view of the adopter. I totally get it. Like, if we're not going to be able to deliver things in a timely way and make sure that they're high enough quality, then they don't, they don't, don't want to do them. They don't want to have that dependency. And so that people see what we do as just another squad and all these squads making software. No, no, we're, we're, we're a different relationship to them. And that's what you really need to break in terms of assumptions around the relationship.

How much do you think quality affects that judgment from the adopter standpoint?

I go with the system has to be as good or better than what they would have made themselves in a reasonable amount of time, or else they're not going to want to use it.

Yeah, I agree with that. I think, like, I kind of find myself saying a lot, this design system isn't replacing nothing. It's replacing the, you know, context specific and probably quite good solutions that product teams are coming up with on their own. So it has to be better than that, otherwise what's the point?

This full circle now the first thing that, that makes me think of is like I've seen a lot of adopters choose a lower quality and I realized it's loaded a lower quality product, but because it's faster. So like it's not better than what they would have done, but it's faster than what they would have done otherwise.

Saying a lot. This design system isn't replacing nothing, it's replacing the, you know, context specific and probably quite good solutions that product teams are coming up with on their own. So it has to be better than that, otherwise what's the point?

The first, this full circle, now the first thing that that makes me think of is like I've seen a lot of adopters choose a lower quality and I realized it's loaded a lower quality product, but because it's faster. So like, it's not better than what they would have done, but it's faster than what they would have done otherwise, so they choose it. So back to speed. That, that's what stumped me about your question, Amy. Your prompt was like, if we remove speed, what are, you know, how does that change the dynamic of design system work? And I'm like, man, that's really breaking my brain because I've seen so many people opt for speed at the expense of a lot of other things, at the expense of consistency, quality, you know, like a bunch of other things. And speed is such a. Such a determinant for them that I'm like, I don't know what that would look like. And I'm curious if you have initial thoughts about that, like, what that dynamic would look like if we just took that off the table.

I guess, like, my initial response to that is that it is so dependent on the culture of the organization that we're talking about and stuff, because I think ultimately we're all trying to get to better quality. That's the point of moving faster. That's the point of, you know, we. We see that as a route to being able to kind of test and iterate more often and therefore get to something better more quickly. And I think that it's whether teams buy into that or not, and that is dependent on kind of organizational culture. So if they see using the quicker but maybe slightly less great than they could have made it thing as a route to getting somewhere good faster, then I absolutely see why they would make that choice. But I think I've also seen probably more of organizational cultures where they're quite suspicious of that because they aren't given the opportunity to iterate and they aren't set up well to support, you know, teams that are sharing developers with six other teams and, you know, have one day where they're able to make changes in production, like a week or something, you know, and those teams, I think, are much more suspicious of taking something that they don't think kind of matches what they could do on their own time. So again, hard.

It depends to me, design systems accelerate and substitute some of the problems that a team that uses a design system is out there to solve because they are actually trying to solve a real problem. Schedule a doctor's appointment, buy a product, you know, submit insurance documents, whatever it is that actually the system or the product's trying to facilitate design system quality, ratchet down one or two levels from. In terms of the level of importance of solving that big problem. And that's the problem. Those are the problems that product teams are trying to solve. And so you're an accelerator, you're an improver. You can help replace things that they then don't have to do themselves, but they don't have to use the system to solve the problem necessarily, unless there's some bigger force at play to like material. Everything at Google has to be material because that's the identity that we have as a company. Okay, that's a different problem. And suddenly the system plays a different role. But Most teams don't start their relationship with the system because of that.

I love this conversation because we are talking about all sorts of cool, important stuff. We're getting close to the time that we scheduled. So, Amy, Nathan, you got any closing thoughts? Anything that you found interesting about this conversation or a hot take that you want to get out there before we.

Run out of time?

God, I have so many closing thoughts. I have so many opening thoughts. I think something that feels important to me is kind of specificity of what we mean when we say quality. Like, I think that we've talked about a lot of different things and just in the course of our conversation, it's clear that, you know, we're probably closer than we maybe think we are. It's the way that we describe these things and the way that we emphasize them. But actually, we're all going to have things that we don't think are acceptable to give to teams, and we're all going to have things that we're happy to kind of, you know, experiment with and see. I think definitely the kind of. The conversation around predictability feels important to me because I think that that's maybe something that we don't talk about enough, but perhaps ties a lot of this together. Like if teams know. If teams have clear expectations about, you know, when they can expect improvements and updates and when they're going to have to accommodate those things like that does that gives them an important piece of information to make decisions about whether they take the system solution or do their own thing. And I think that, you know, that's. That's quite critical, but, God, I could just keep talking all day so I won't keep going.

Keep going.

No, it's too. There's too much. I guess the only. Yeah, well, I'm going to throw one more thought. The only other thing that kind of occurred to me, which we didn't really talk about at all, but is this when we're talking, when we were having that conversation about, you know, teams are choosing to depend on the system or not and that they need kind of things to be happening in a timely manner. The thing that drives me crazy is working with organizations where you kind of say, well, you know, given the size team we have, this is the rate at which we're going to be able to turn these things out. So that's what we need to communicate. And they go, it's okay because we're just going to open source it. We're just going to, like you say, like, how can we speed this up? Can we have more people on the team now. People will just contribute to it. Like, oh, God, contribution as a solution to speed is. I just. Anyway, that's a discussion for another time. But it opened up in my mind through this one.

Such a false promise. Anyway, yeah, let's talk about that another time. The one thing I would say is design systems. The good design systems really enable their customers to use all their stuff fluidly and create a great dependency and so on. The best design systems are ones that help the people that use it change over time. And so the. Your ability to make it easy to change, easy to adapt and evolve, easy to stay in touch. Like essentially a fresh dependency rather than one that ages, ages, ages, and then just breaks off like a rubber band that snaps. That's. That's. Those are the best systems that I really respect.

One thing that I like about our conversation is that it talks about the nuance of what's important in a design system and honestly, what's not. Or it's less. I should say. It's not that it's not important. It's just there is a priority ranking of those. And I like. I like our focus on, like, is it helping somebody to do a thing that they're trying to do that's more important than a lot of the things. A lot of the rules, you know, a lot of the dogma that comes with the dogma is important, but it has to support the thing, the value that we're actually trying to do. So I appreciate both of your thoughts around that thing too. Let's call it here. There is no further conversation that we have scheduled. This is not like part two of six. This is part two of two. If people enjoyed it, we might do it again. I encourage everybody to do their own versions of this too and share them, and we will join in to all of that stuff.

Th.

Yeah, thanks. This is great. I'll do this with you too, anytime.

A lot of fun. Thanks for putting it together.

All right, everybody, have a good rest of the day and a good, Spooky Friday the 13th. See you. See you all soon.

See you. Bye.

Bye.