Maturing Design Systems

Ben Callahan at UXDX Community: USA Online Series. Video: https://youtu.be/a7y10Z6nepY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The phone call that started the research

[00:00:00] Welcome back to the thing. Thank you so much. I'm okay, cheers. I'll start off with a quick story. About eight, or I think it's probably eight or nine years ago now, we were approached by a large retailer to help them with, believe it or not, a responsive redesign. Do you remember those, back in the day? A responsive redesign of their product detail page.

[00:00:27] It was a large organization. This single template on their website was responsible for billions of dollars of revenue every year, and so this was a huge deal for their organization to undertake. We spent an entire year working alongside their team, and we researched and iterated and truly worked on this thing to get it to be one of the best pages we could make, one that would help their customers make really easy purchases online. They had multiple brands, and so this single template served all of those brands.

[00:01:03] After a year of that work, that project went live and it was a massive success. Everybody was really excited about it, and there was a lot more work to do. That was one template inside of an entire e-commerce experience, and so the client asked us if we would continue on and take some of that good work that we'd done and spread it around the rest of that experience. We said we would love to do that, but we actually said, give us a couple of days to just try something.

[00:01:35] We went back, our team — this was before design systems was really a thing people talked about — and we took a look at the work we had done on this single page, and we realized that by default the way we were working at the time was to take a very systematic approach to the work. With a little bit of exploration and a couple of ideas and some prototyping, we took some of those things back to the client and said, if we could spend about three months here taking this work that we've done and refactoring it into what became a design system for them, we think we could be much more efficient, much more consistent across the rest of the experience.

[00:02:14] They were excited about that idea, and so we jumped into that work with them. Three months later we had the first version of a system for them. It was very basic at the time, but it worked really well. We saw that increase our efficiency across the rest of that e-commerce experience. A year after that, so we're now two years into working with this client, we had almost 12 different organizations inside their company subscribing to that system, and lots of people in the company were excited about it.

[00:02:49] But then I got a phone call from somebody. Our connection inside the client called me and said, hey, we need you to stop all the work that you're doing on the design system. At the time we were a fairly small company and this was a big project for us, so that was a bit of a scary call to receive, to have somebody say stop all the work and not really give us a reason why. I think that's really the moment for me when I realized we as an organization, my company Sparkbox, needed to better understand design systems. We needed to better understand the reasons our clients would want them, and the politics involved in implementing them. That moment was the start — I look back at that moment as the start of my journey on a bunch of research that we've been doing into design systems ever since.

[00:03:42] This year we released our fifth edition of the design systems survey. You can see that online; I'll share links and stuff towards the end. We just ask lots of questions of folks in the industry trying to solve these problems as well, and we take those results and aggregate them and share back what we learn. I do tons of interviews with folks who are also doing design system work. That's a big part of how we keep the survey relevant, just chatting with folks like yourselves who are in the work. And then of course we do lots of work with clients. We help big organizations that want to implement systems, or that are having a hard time with their systems. So what I'm going to share with you today comes from all of that research, all of this work, and just from being in the conversation for the last seven or eight years around systems.

Defining a design system in context

[00:04:33] Now, when I say design system, there's a lot of confusion still — that's one thing that I've learned. So I do want to spend a few moments just defining what I mean when I say design systems, because a lot of people have different ideas about what those words mean when you put them together. And I think any good definition should start with some context.

[00:04:54] For us, the context is that every organization is trying to connect its brand to some audience. Pretty much every client we work with, all of the companies that you work for, this is just what we do. And so we do that in a lot of different ways. Sometimes we print stuff and mail it to people. Sometimes we create an amazing in-store experience and invite people to come in and be a part of the brand in some way. Sometimes we create ads, perhaps audio ads in a podcast you listen to, or even a billboard somewhere that you might see as you're driving. Lots of different ways that you can advertise.

[00:05:32] Pretty much every organization today has a major touch point here of digital experiences. These are things like your website, or any native applications that you might have if you have digital products, a kiosk, all these kinds of things that have a digital interface. This, I believe, helps us to understand where a design system fits inside of an organization, and I believe that it fits here. They sit between the brand and these digital experiences that we're offering to our customers.

[00:06:07] I think it's important to think about this because it helps us see what feeds into a design system, what the inputs of a design system are and what a design system has to offer as its outputs. When we think about it like this, we can then break things down and come up with a definition that helps us understand, in the big picture, in this context, what a system is. What I also like about this little bit of context is that if we think about it in this way, a design system then creates consistency with all those other touch points — the print things, the advertising, the in-store experiences — because they're all rooted in that brand.

Foundations and tokens

[00:06:45] So let's talk about this vague box that says design system. What is it made up of inside of this box? I believe that design systems start with foundations, and the foundations layer is a subset of the organization's brand, with the intent that it's used in the design and development of digital interfaces. There are lots and lots of things that can exist at this inner foundations layer. You'll see the word guidelines a lot here, because a lot of what we're offering here is a point of view, a guideline for our designers, developers, UXRs, product folks, all of them, to think about when they're working on digital interfaces. Of course this is not extensive — there are many other things that could exist at this foundations layer — but these are the kinds of things you could expect to see here.

[00:07:40] Once we've got a subset of those things from the brand defined in the foundations, then we can create a tokens layer, and the tokens layer is a set of codified design decisions that are based on the things we defined in that foundations layer. The goal of this tokens layer is to take those concepts that we express in the foundations layer and codify them, and when I say codify, all I mean is that those concepts are given a name and a value.

[00:08:11] There are lots of things that we can codify. Things like color: we could say I want to have brand blue as the name, and here's a definition for the hex value of that color, and now when people use that brand blue token they know they're getting the right color, the right version of the blue. That's one tiny example. You can codify lots and lots of things, and again this is not extensive, but these are the kinds of things that you might see in a token system.

Core systems and components

[00:08:44] Once we've got foundations and tokens defined, then we can create what I call the core systems layer, and this is a set of building-block systems that are used to solve common interface challenges. One way to think about this layer is that at the tokens layer we're codifying a single design decision, but here this is how we codify how all of those design decisions could work together in a specific area. So you might create a token for spacing, something like how much margin do we want in a certain context, but then we might use that token in a bigger system around layout: how do we handle layout on a page, as an example. And of course there are lots of core systems that we can create, things like layout and grid systems, theming systems, type scale, animation. Again, this is just a few examples; there are many that you could create.

[00:09:39] These three inner layers we just call the fundamental layers. That's because this is what everything else is based on, and if you're someone who's building or maintaining a design system, then creating stability in these three inner fundamental layers is going to be a big part of your job.

[00:09:59] Once we have these defined, we can add in a fourth layer, and that fourth layer in the anatomy of a design system we call the components layer. This is just the reusable parts of a digital interface. This is what most people think of when they talk about a design system. These are the things you see when you look at an interface: the form inputs, or labels, or text next to pictures, search results listings, all that kind of stuff. They can be simple, like an input, or they can be complex, like maybe a search bar that includes a label, an input and a button. So you can nest them to create more complexity.

[00:10:32] Now, when you are working on a system, oftentimes you start in this inner part, towards the foundations, and you work out. But the folks who use your system — we call them subscribers — those folks are going to approach your system from the outside in. They're going to come to this and hopefully most of what they need exists at that components layer. Again, a few examples I've listed here: things like buttons and text inputs, radio buttons, tooltips, tabs, breadcrumbs, all of this kind of stuff, many many more. If you go look at some examples of design systems you'll find probably hundreds of these that we could list here.

Assets at each layer

[00:11:11] All of this stuff is very conceptual, so what I like to do is break it down a little bit further. Each of these layers can be broken down into three parts: assets, processes and documentation. So we'll just quickly look at each. Assets are the tangible things that make each of these layers very usable. Here's a few examples. At the foundations layer we might have some logo files. These take up space somewhere, and that makes them an asset, something very functional.

[00:11:41] At the tokens layer we may have a CSS file that contains color variables, CSS variables in a file. This is for someone who's doing web work, perhaps, and we've said, hey, here are the colors we want to use in the interface, and we've created for them a CSS file that contains variables — in this case white, gray 10, gray 50. Those are created from the tokens files, so it's a very helpful tool that somebody could just import directly into a project and get access to the correct colors.

[00:12:17] At the core systems layer we may have an example of a way to do layout. In this case I've got a quick little Sass mixin, again for the web, where it might help you to put together a little layout in your interface. And then at the components layer we may have a specific component, like a button or something in Figma for a design person to use. So again, just examples. There will be lots and lots of assets in your system; here's what you might expect to see, one example from each of those layers.

Processes at each layer

[00:12:51] Moving on from assets, we have processes, and when I say that I just mean that these are the things that explain how the humans work on and with and around the system. A few examples here. There are lots and lots of processes that you might want to define, but they generally fall into these categories: things around communication, governance, synchronization or testing, deprecation, onboarding, extending the system, all of this kind of stuff. These are areas where we need to put some process in place.

[00:13:20] Let's look at a few examples at each layer. At the foundations layer we may define a process for how the brand team and the design system team communicate. We said early on that the foundations layer is a subset of the stuff that exists at the brand, and so when those things change at the brand level we need to have a process that communicates that to the systems team so we know how to make those changes, and vice versa as well.

[00:13:48] At the tokens layer we'll probably need to define a process for what happens when we change the value of one of those tokens. With great power — tokens are powerful. I can define that color in one place and see it used all over, but there's also a lot of responsibility that comes with that, some risk. If I make a change to that color and it's unintentional, I could see a change ripple through the entire interface in a way that's maybe not fun if it's not correct. So we want to put some process in place to cut back on that risk.

[00:14:20] At the core systems layer we may need a process for deprecating an old core system. When you change the way you do layout in your interface work, maybe you have to support your old layout system for a while while the different subscribers come on board with the new system that you're putting in place and giving them. So how do you walk them through that deprecation of an older part of the system?

[00:14:43] And at the components layer, maybe we would have a process defined for accepting component modifications from subscribers. The likelihood that your system is going to do everything perfectly for everyone is probably zero, so how do we make it so that parts of the organization who need something different can make that modification and then push that work back into the system, so other parts of the company get access to it? Again, just a handful of examples. There are lots and lots of processes that you'll probably define if you're working on a design system, and you're not going to start with all of these defined at the beginning. As they're needed is the time to start putting them in place.

Documentation at each layer

[00:15:22] Moving on from assets and processes, the third part is documentation, and this is really the context. It explains why something is the way it is, it breaks down the when and how and all of that. A few examples here: a point of view on color at that foundations layer. We may want to pull from the brand — there are lots of different colors we could use within the brand, so what are the ones we want to focus in on for our interface? I've just got a screenshot here from IBM's Carbon design system to show you their documentation on their point of view around color. You can see they're talking about how they layer colors and how there's a set of blues that are used, the IBM blue, and then a specific set of colors for alerts.

[00:16:09] At the tokens layer we may have some documentation that explains how you name a token. This is notoriously difficult. As you know, naming anything is hard, but getting folks to agree on what these names should be can be tricky, and so we need to define that, we need a set of documentation that explains that. Again from Carbon, here's some information where they talk about how tokens are named, and that helps you as somebody who might be a subscriber to understand what a specific token does by understanding the process we go through to name it.

[00:16:42] At the core systems layer we may have some documentation that explains how to use a theming system. I put this core system together that lets you change the color and look and feel of an interface, but how do I actually use that as a subscriber? Here again from Carbon is an example where they're talking through how you apply theming in the context of using Carbon for your digital interface.

[00:17:06] And then finally at the components layer we may have some documentation that breaks down the pieces and parts of a button, and you can see here, again from Carbon, that they do that. What this does is give us the words we need to be able to have a conversation about these pieces and parts of our interface. It helps us be a lot more efficient in the work.

[00:17:26] Taken all together, this really gives us a way to talk about systems and to know that we mean the same things when we do. With this shared understanding, what I'd like to spend the next five or ten minutes walking through is, out of the experience we've had doing a lot of this work, how systems mature. I have four main things to share. There are these four stages of maturity that I'll cover really quickly, there's this concept called origin stories, which greatly impacts how a system matures, and then I have two really quick frameworks: one is how to mature your system if you're working on one today, and one is how to maintain stability as the things around your system are constantly in flux.

The four stages of design system maturity

[00:18:12] So let's dive in quickly to the four stages of design system maturity. The first stage we just call building version one. It's about as simple as it gets, and really this is everything leading up to that first release. Obviously the decisions you make here have a big impact on how your system will look. This can look wildly different based on a lot of different factors, but really it's about digging into the foundations of your brand, it's about discovering the right scope, identifying some good partners and building something that's actually valuable for the people you want to use it.

[00:18:47] Once you've released that first version you reach stage two, which we just call growing adoption. Again, it begins as soon as you release that first official version, and once it's live the question is, will anybody want to use it? That makes sense — you spend a lot of time and energy building a thing, you want to see that it's valuable to other folks. I like to focus here on this idea of making it easy and obvious to adopt. If you've built something people want to use, that's the easiest way to get them to use it. You're also going to have to start thinking about how you support the folks who do use it, and you can never stop evolving the system, so you want to iterate on the system, but you're focused on prioritizing what's really important to potential subscribers.

[00:19:34] Once you've made it really easy and obvious to adopt, and you've reached a critical mass of adoption, you transition into what we call stage three, surviving the teenage years. This is a whole new set of challenges that emerges. With lots of subscribers using your system you're going to have lots more bug reports, people complaining about the system. You're going to get lots of feature requests, I hope. You're going to get people trying to do stuff with the system you never imagined they would try to do, so that creates an interesting set of challenges for you.

[00:20:05] And of course this is where you have to prove that your system will offer the benefits to the organization that you promised it would back in stages one and two. This is where analyzing the metrics and making sure that the data you're capturing around the use of your system — the efficiency and consistency and all those benefits, accessibility and sustainability — all of those things are actually coming to fruition. The focus here is really on thinking about that product team, that product mindset. A lot of organizations in stage three are also working through accepting contribution and they have some governance in place. They're starting to think about it, they recognize they can't do it all themselves at this stage.

[00:20:51] And then finally stage four, we call evolving a healthy program, and this is really where your system is a fully realized product, but beyond that even a whole program. There's highly evolved engagement with subscribers here. You're really taking a place of leadership inside the organization. These are teams that are mentoring their subscriber teams, they're really working with those teams to make them better at what they do. The way I summarize this is that you're maturing into truly stable leadership here.

Origin stories: top down and grassroots

[00:21:24] Now, every organization has different experiences through these stages, and so when I was originally doing this work I didn't know that we could find a common model of maturity. Then I discovered there's this one concept that really impacts how a system matures, and that's called origin stories. I've identified two primary origin stories. The first we call top down, and that's when executive leadership is involved, aware and actively supportive of that first release. The other we call grassroots, and that's where your leadership was unaware, uninvolved or unsupportive of the first release.

[00:22:02] So let's talk a little bit about the differences quickly here. There's a lot more visibility, there's an actual budget established, there could be a real team dedicated in that top-down model when leadership is involved. The scope also tends to be broader here, because you've got leadership thinking about the impact this could have across the entire organization, and there's a lot of pressure to deliver because leadership is involved. With grassroots, less visibility of course, often no budget, the team isn't really defined, and the scope is narrow because it's usually an individual contributor solving their own problems. And not a lot of pressure to deliver here.

[00:22:43] Now, if you're looking at this and thinking I've had a little bit of both of those in my experience, that's true, and that's because top down and grassroots are really two ends of a spectrum. Most systems mature with some characteristics of both of these. It helps me to think about them in this way, and really the origin story is about how that initial version of the system came to be. So the differences between a top-down stage one and a grassroots stage one are going to be pretty noticeable, but as the system matures the differences become more subtle. They become more and more like each other, so that by stage four the differences between a top-down and a grassroots system are often indistinguishable.

[00:23:25] So you could have a scenario like this: a top-down system becoming more like a grassroots one along that extreme side. We could have the opposite, a grassroots system becoming more like a top-down system as it matures. But these are the extreme paths, so there are lots of other ways you can move through these origin story and maturity steps.

Educate, engage, evolve

[00:23:47] So we've got the four stages, we have this concept of origin stories. Now let's talk quickly about what we do to actually have our systems mature in a healthy way. In order to do this, no matter what origin story you have, there are three areas of focus you always have to be working in. Those three are educate, engage and evolve.

[00:24:08] When I say educate I mean more of a one-way interaction. This is you creating a shared understanding of what a system is, especially in your context, at your company. This is you casting a vision for why a system is needed, that kind of thing. Engaging is a little bit more two-way. This is where you're learning from your users, this is where you're allowing them to have some say in the things that you are building. It's also you recruiting supporters, getting your leadership involved, that kind of thing. And then finally evolution: this is what most people think of, the team effort of iteration on the system itself. So you've got to be adding features, you've got to be adding components or removing components, that kind of thing, working on your assets, your documentation, your processes.

[00:24:53] Now, I wish I could say that it's as simple as do the education, do the engagement, do the evolution, but it's not that simple. I think of it more like this: it's a cycle that you're always working on, these things, and after you do this long enough you kind of look up and you realize, oh my goodness, we've moved into stage three. So we can overlay these things. We can take this concept of these three E's and layer them on top of the stages that we have, and what you'll see is you can't really stop doing the items from stage one as you move into stage two, but there are a new set of things you have to think about. This we call an additive framework — in other words, the work just continues to grow. I don't intend to scare you off, but I do want you to see that there's a lot that has to happen to make this work.

Stabilizing forces: authority, value and tradition

[00:25:43] Okay, the last concept to share with you quickly is about system stability, and I think this is really important because, as you know, everything around you is always changing, just like with any other product. I think of these as destabilizing forces. I can't tell you how many times I've been in a conversation with a client, we're getting started on great work, and then all of a sudden somebody's boss's boss changes and everything has to be reevaluated. That change creates instability in the organization. So what we want to do is surround our system with really stable characteristics, so that when things change the system at least has a lot of stability.

[00:26:26] In the research we've been doing and in the work, we've identified three primary stabilizing forces. Those three are authority, value and tradition. It'll take just a moment to walk through these and then we'll grab some questions here. The authority stabilizer — what I mean by that is that leadership is actively supportive of the system and its team. Actively is obviously the critical word here, so if you can't point to things that your leadership is doing every day, that means you're probably not benefiting a lot from this stabilizing force. You see things like real budgets, dedicated time and staff, encouragement from leadership to contribute to the system, not just use it, in organizations that have this stabilizer.

[00:27:07] Value means that the system itself offers real value to those who use it. It actually helps them in some way with their work, it makes them faster or maybe more consistent, it's going to solve real problems instead of create new ones for them. The kinds of things you see in systems with the value stabilizer are rapid adoption, or a lot of feature requests, a lot of bug reports, and a willingness from those subscribers to actually help with the system itself.

[00:27:35] And the third stabilizer is tradition. It's a little bit different. It means that the system itself has momentum to it, it's become the way we build interfaces inside of our organization, and once the system has taken root there's a lot of stability simply in its acceptance as our way to build interfaces. A sign that you have this stabilizer, maybe, is when you hear folks from different disciplines saying that the system is the single source of truth. Now the tradition stabilizer is a little bit unique: you can only earn it with time. So you have to have authority and value over time in order to have tradition.

[00:28:16] I'll also say these three are kind of like the legs of a tripod. With one you can fall in any direction, not very stable. With two you've got some limits in terms of which direction you have stability, but you do have some stability in certain areas. And with three you really can't fall over in any way. That's kind of what we want, to maintain that area in the center.

Losing a stabilizer, and getting the work restarted

[00:28:38] Now, once you have all three of them, of course it's possible to lose them. An example might be in this area between authority and tradition. This is a risky place to be. If you slow the evolution of your system, or stop engaging with your subscribers, you might lose this value stabilizer, and that puts you in this weird place where leadership says this is what to do, tradition says this is how we do it, but it's not valuable to your subscribers. They're not going to feel like they're trusted; you're telling them to do something that actually doesn't help them. Not a good place to be. And this other spot down here between value and tradition is also a risky place to be.

[00:29:17] If you remember that story that I told you at the beginning about that organization, and they called and said stop all the work on the design system — this is actually what happened to us. We had created something that was really valuable and it had become tradition. Lots of parts of the organization were using it, but we had never done the work to go and talk to leadership. So when the amount of money they were spending on this line item called design system crossed some threshold, it bubbled up to an executive somewhere who didn't even know what this was. They called and said stop the work, because they needed an explanation.

[00:29:48] Now, lucky for us, we were able to go back and talk to those subscribers and say, do you remember the work we did over the last year with the system together? How long would it have taken you to do that work without the system? So a little bit of a guess, but we got some great answers back, and what we learned is that for every dollar they invested in the system they saved three dollars, and that's just in developer efficiency. So that was able to move us to that center again. We got support from leadership and created a lot more stability in that system. All together, this gives us a way to create stability in the system that we're working on, and that enables a real sustainable approach to the work.

Resources

[00:30:27] So: four stages, the origin stories, a framework for how to mature, and some concept of stability in your system. Now, I'll tell you there's a lot more to all of this. You can tell I'm moving quickly because I wanted to get these concepts shared with you. I'll just give you a couple of quick resources here. I mentioned that survey that we do each year. The results for 2022 are live, you can see that here; if you search design system survey you'll find that as well. We've done a bunch of studies at Sparkbox. One of them is just a study to show the impact that a system can have on efficiency.

[00:31:02] We developed a little calendar you can use. You subscribe to this and it shows up on your calendar and puts some interesting reminders to think about those three E's: how am I educating, how am I engaging, not just focusing solely on evolution. So this is a nice little tool for reminding you about those things. I've written an article on selling design systems, because that's a huge part of this work, and so if you're interested in learning how to do that work a little bit better, the selling part of the job, this will give you some insights there. Sparkbox does do gap analysis or design system consulting, so if you're interested in that you can check out our site.

[00:31:39] And then we developed a maturity assessment, so if you're not sure where you fit in that model you can go and answer just a handful of questions here. It'll give you some customized recommendations on things you can do. It's all automated so you don't have to talk to me if you don't want to, but that's a really fun little tool to use. And I'll just say that this model is always evolving, so I'd love to hear your story of maturity if yours is a little different. I created a little place for you to go where you can ask a question or give me some feedback, or just say hello if you'd like. The last thing I'll say is that none of this could have been possible without the amazing team at Sparkbox. I'm really lucky that I get to work with such kind people and smart people. You can see all of their smiling faces on sparkbox.com. Thank you all so much for listening.

Q&A

[00:32:25] Host: Great, thank you very much Ben, that was really good. And there was a lot of links at the end there, so I hope you'll share the slides with me and I'll put them up on the site so anybody can get through all of those links that you shared.

[00:32:36] Ben: Absolutely, with links afterwards as well.

[00:32:43] Host: Excellent. So if anybody has any questions, I'm just looking over to see if anybody's posting. Please do feel free to ask some questions. I'll get the ball rolling with one, because I was kind of thinking as you were explaining that growing model from the foundations to the tokens, core systems, etc., and what jumped into my mind was, if I was trying to design that from the outside in, I'd fall into that trap of trying to over-engineer from the start. My brain jumped to that, what would likely happen as I'm making it, and then I'd hit on what you pointed out, of changing tokens, that that can have ripple and unintended consequences. So what is the solution for the people who are trying to build a component and realize, ah, you know what, I need a different token, or I need something? What is the best practice there?

[00:33:41] Ben: I'm a fan, especially in the early days of systematic work, of not thinking much about the system at all as you get started. Just build the thing you need to build, and then use this concept of refactoring to look for the commonalities. Your system should be serving the organization in areas where there's overlap, not serving every unique need. So that's where it's like, until we know something needs to be a part of the system we just build it, and maybe we use some of the same colors and tokens and things like this. Everything needs color, so we can use those across the organization.

[00:34:16] Ben: But when we get to the components, like you're describing, that's where I'm a fan of saying let's build this, and then if we feel that it's valuable for lots of parts of the organization, then we can refactor it into the system. That is really one of the core jobs of the systems team. Your subscribers may be working on pieces and parts that aren't in the system, and once they've completed those you can then think about it, because you have a connection to all the other parts of the organization. You can say, is this valuable to you? If so we'll bring it into the system, we'll help you figure out how to implement it. So that's the approach we typically would take.

[00:34:53] Host: Great. And how do you tackle it when you're bringing it in and you go, we need to change the token? As you were saying, that's a high-risk activity. Do you have any recommendations for how people should handle it when they get into that situation where they're like, oh, here, I need to do this?

[00:35:10] Ben: Yeah, that's where having that process in place around what it is that we're actually going to do here when we do need to make a change like that. The power is amazing. I remember that same customer I was describing earlier: about a year after all that story that I told, they had a rebrand happen, and the people on their systems team got really nervous. They were thinking to themselves initially, this is going to all of a sudden make our system not valuable any more, because the brand is changing. And we looked at it in the opposite way and we said, no, you're the enabler. You are the reason that the brand will be able to roll out much faster, and that is the value of the system. So instead of going to the product teams to do a rollout, they went to the systems team, did the rollout at the system level, and saw that spread across the entire organization much faster.

[00:36:04] Ben: Of course that is the reward. The risk is somebody accidentally changes the token value somewhere and then that color ripples through. So we do the same kind of thing we would do with any other product: we just have checks and balances in place, and we have some automated testing that happens, and we're monitoring things. If there's a tremendous amount of change then we just want to slow down for a moment and say, was that the intent? And I think there's so much out there about how systems are useful or valuable for UI designers and front-end developers, but there's so much value in a system for people like QA, people who are just testing everything. To have all of the pieces and parts in one place where I know what they're supposed to look like — that's huge. So you've got to think beyond just designer and developer into all the other parts of the organization too, and that's where it becomes really valuable.

[00:36:59] Host: Great, thank you sir for that. I have one other question. One of the challenges, when you're moving into that tradition element, is that instead of being the enabler that it once was, these kinds of systems can sometimes be a bit too constraining, in that people have felt that okay, well, from there we have to use the design system, and their hands are tied, it's not as flexible as it used to be, where they had basically a blank sheet of paper. So how do you tackle that balance between the speeding up of using the system versus the flexibility and the raw power of going out on your own?

[00:37:45] Ben: This is such a good question. There's a lot of nuance, I think, in this conversation, and I've always thought about this as flexibility versus consistency. The benefit of the system is that it gives us a consistent interface, but that consistency means we've had less creativity, I would say maybe, in the coming up with that interface. But what I would say is, designers — because those are the folks who usually have this issue, the people who say my job is to design the interface, why are you taking that away from me and putting it into a system and automating it — the truth is designers are problem solvers. If you want to just spend every day solving the same problems over and over again, then I guess you probably don't want a system. But if you're tired of solving those common problems over and over again, that's where a system comes in. We solve a problem really well once, and then every part of the organization gets the benefit of that good work, and now you can move on to solving a new problem. That's what we really need the human brains working on. Those designers need to be solving those new problems.

[00:39:01] Ben: So I genuinely don't think that systems are constrictive, or they don't have to be that kind of restrictive system. We try to help our clients build systems that are enablers, not restrictors. But there is a balance there, depending on the culture of your organization. This is another area where I'm doing a lot of research, around culture in terms of systems. If you've got a much more competitive or a more controlling culture, sometimes that more restrictive approach actually is better for the culture. So there's a spectrum there of how you think about the processes you're putting in place and what the expectations are on the subscribers you have.

[00:39:41] Host: Excellent. I like that, introducing culture at the end, because I think that does actually play a huge, huge role. I'm just seeing a question coming from Gary Chan, who said: I've been a part of poorly coded design systems that got launched and negatively affected sales, so it didn't seem like there was any way to repair it without completely recoding everything, which took more than a year to deploy and recode. So everything reflected badly on the design team. Any suggestions on how to handle this?

[00:40:14] Ben: Yeah, I mean, this is a similar question — thank you Gary — this is a similar question to what you were asking around tokens. The token example is, if I've got everybody using this primary blue token and then I change the value of that, it's great, unless I didn't mean for that to happen, and then it's rolled out everywhere. Well, the same thing is true with the system as a whole. In other words, if I create a system that performs more poorly than what we have in production today, and I roll it out to everybody, I'm actually doing a disservice.

[00:40:48] Ben: And so that's just something where, this is why — when I talk to these stage four teams, they are literally considered some of the highest qualified individuals inside the digital teams. These people are mentoring the rest of the organization, because at this stage the organization gets it. They see that we want to put our best people on this stuff, because this is the work that's going to the entire company. So it's not like you just want to — I mean, I know some people do this, but you don't want to just go get some third-party framework and make that your system and start modifying it. That's very risky to do. Instead we want to really take our time with this stuff and do it well.

[00:41:34] Ben: I would also say start really small and start simple. Perhaps all you do at the beginning is some type and some color work, and get that working throughout the entire organization and see the benefits of that, and then maybe you can start to put some stuff in place that is a little higher risk but also a little higher reward. The way we do layout across all these platforms could be consistent; let's do that, and let that stuff work its way in. I'm not a fan of that big bang, let's redo everything and then release it all at once. That's just a disaster waiting to happen. I'm sorry you had that experience, Gary. And I guess once you're there, I'm not quite sure what to tell you other than maybe you start refactoring.

[00:42:20] Host: No, that's great advice. I equally am not the biggest fan of the big bang approach, so hopefully — Gary said thank you for your advice — so hopefully nobody else has to suffer that. But I think that brings us up to the time, so thank you very much, Ben, for sharing all of your wisdom about design systems and maturing and how they grow. I hope everybody out there enjoyed it as much as I did, but that brings us to the end for today.

[00:42:51] Host: So thank you once again, Ben, and I'll just leave a very quick sign-off. If you did enjoy that talk today, please do join us for our upcoming conference in the USA, which is taking place in New York in May. We'll have more than 25, probably around 35-plus speakers, eight workshops, there'll be 800 people attending, and we have a fantastic venue just off Broadway Theater in New York. So if you did enjoy those talks today, please do. Thank you, thanks for coming and joining us. That brings us to the end for today, so thanks very much and I hope to see you at the next event.

[00:43:31] Ben: Thank you very much, goodbye.