Building design systems that work
Design systems promise great benefits, from providing a consistent experience to enabling engineers to build new interfaces quickly. Having a design system frees up product teams to focus more time on building great products and meeting business objectives. A healthy design system gets three key things right: governance, adoption, and maintenance. Learn how to incorporate best practices and build design systems to last in ways that work for everyone.
Watch the talk:
Transcript:
Hello. Good morning. Thank you for joining me for this virtual Full Stack Friday. My name is Chris Wilkinson. I'm the director of product design at Devbridge, and I'm excited to be joining you from a snowy April morning, here in Chicago. I hope you all had excellent pancakes for breakfast or at least we know we can imagine a pancake breakfast together. This is going to be a new format for us. There is the ability over a Zoom meetup to ask questions throughout. If you have questions, feel free to ask them as you think of them. We'll go ahead and filter through those towards the end and have some time for Q&A. If you have any other questions or needs, or if video or sound cuts out for any reason, please let us know in chat, the team has a line to me as well, so hopefully it's smooth sailing. With that, let's get rolling.
Building Design Systems That Work. I think that that work part of this is really important. It's very easy to build a design system that doesn't work for one reason or another. And so today we're going to talk about some things that you can do to make sure that the investment that you make in a design system pays off. But first let's talk about what a design system is. Design systems are a unified approach to building experiences, and they are a kind of thing that is considered bigger than the sum of its parts, and each part of it is bigger into itself. That's because it is a collection of different things that you need to build a great digital experience.
Now, because design systems have so many components and pieces to them, it's impossible in a short time for us to talk about all of them together. Today I'm going to be focusing on a few areas that can make an impact. All right. First thing you need to do when starting any design system effort, is to start with a workshop and to get everyone into the same room to talk about why you're building a design system. This is because the design system itself is a product like every other product. It is its own application, its own thing that's worth investing in, prioritizing and working on as those, any other product in their product portfolio.
Now, for design system to be successful, I think you'd start with a pilot product to adopt it rather than building a design system in a vacuum, and then using those components on a product later, instead focus on building a product that consumes each of those components individually, and then proves out the fact that they're working. As that product is developed, the team that is developing the product is both the builder of the design system and the first consumers of that system. As individual components and patterns prove out, you can promote those components into a design system that can be shared and then identify a new user group, a new product, onboard them to the design system and then track that new product and to measure its successes and failures, it's struggles, as it is being used by people and then onboard another one and another one. Right?
Rather than trying to do an all in one sweep about how to develop a design system, instead what you want to do is identify that pilot product and then roll it out over several different products as that value is proved out over time. Now let's talk about who a design system is for. To do that, I want to show you a couple of photographs of that will get your mind in the right space. A lot of you probably have the sense of I've been here before, but maybe I can't quite place my finger on it. It's maybe somewhere that you went to eat, maybe the one that is in the town that you're in. Maybe there's nothing there anymore. Used to be a restaurant. Not that restaurant. There we go. This restaurant.
I think the Pizza Hut building and the iconic nature of the Pizza Hut building design is a great metaphor for how people consume a design system, in that, when you saw those buildings, you probably knew that they were Pizza Hut's at one point or another, right? And if you didn't, now that you've seen this Pizza Hut, you definitely know that those were Pizza Hut's. And you'll probably notice when you're looking around, you can tell when a building used to be a Pizza Hut because of its iconic design. Now, for Pizza Hut, what they did, is it provided a consistent sense of place. It provided a consistent experience. If you were driving down the road and you saw Pizza Hut, you went, that's definitely a Pizza Hut.
The same benefit can be provided to the people that use your products. When they see your product, they're going to know, that's where I am. This is what I'm using. This is what I'm working with. It provides a sense of familiarity and gives them a sense that, I know what to expect when I come in here. I know that there's going to be, we're back at these Pizza Huts, a bunch of kale as the salad bar decoration, not even for eating, because that's how different the world was when Pizza Hut's like this were still around. Now, they're obviously for the people that use them, but design systems are also for the designers, right?
They help designers optimize repeatable tasks and they help design teams focus on important things like research and what is going to be the more complex interaction problems that go into a product. It allows a designer to focus on how to answer the hard questions rather than really being burdened with the rogue tasks of building the same interaction in the UI over and over again. But really design systems are for developers. Therefore the people that are going to build the products and therefore the people that are going to be implementing those designs and making those interactions a reality, because otherwise you just have a picture of software, right? It's one, it is built and in people's hands that it's real.
For the business, it also helps to create a consistent experience across all the different platforms and modalities that someone may interact with a company for. If you're thinking of a design system as just the thing that you use to build digital products, that's good. And it is, but it also should be carrying through to websites, to materials people might receive in the mail, to what they might see in here, the company's say. It's more than just the actual digital interactions. It's the complete experience of working with the product and interacting with the company.
Above and all, it's about the people that are using the products. You are building an experience. You're building a place that people are going to come to and interact with. And because of that, you have to bring the same stewardship and attention to detail that you would to any product to building the design system. Because the people that are using it, are not only the users of your products, but it's also the entire organization that's consuming the design system itself.
Now, let's talk about what makes a design system work. I think there's three pillars to get right, to really make a design system work. The first one is governance. The second one is maintenance and the third is adoption. We're going to break each of these down. Governance, maintenance and adoption form the three legs of the stool that support a great design system. Governance, being the way a design system is managed. Maintenance, being how it is maintained, built, and developed. And adoption, how it's rolled out to multiple groups. Governance is really about that working agreement between the design system team and the people that are going to be consuming it, and how they address new learnings, new component requests and new features.
Whose job is it to govern the design system? You kind of picture in your head what that governance of a design system might look like, and how conversations about governing a design system might go. If you're picturing anything like the wisdom gamut, you're probably picturing too much, right? Governance is meant to be about facilitating that conversation and facilitating progress, not about a large panel of people that make sweeping judgments about how a design system should work. Now, there's a scale that you could consider, on how to think about your design system governance. I gave you a couple of examples here. We have, of course the Smokey the bear, and then the cartoon favorite, Peabody the dog, of Peabody and Poindexter, bonus points to anyone who remembers that fine cartoon.
But Smokey the bear, he's really there to help you along the way. Whereas Peabody was kind of a little bit more of an explainer, still educational, but was very much, I know what's up, kind of individual. I would recommend that you try to be more like our park ranger friend Smokey the bear, when you think about how to approach governance, right? What does that mean? Well, there's a few tenants that Smokey the bear has that I think apply to how we should think about governing a design system. Right. First is, leave it better than you found it. If you find something that is out of place for a design system, and you're working on it, or you're working on a product that's not applying it correctly, leave it better than you found it. Don't just say, well, someone else needs to come back to that or file a ticket to say, someone should come and repair this later.
Instead, take that investment when it happens. If you see smoke, there's fire. What I mean by that is, if you see design debt or product debt accumulating, that's a conversation that you should bring forward to the team immediately, rather than waiting and seeing, okay, let's see how bad this gets. Especially with the design system effort, the longer you let things sit, the more debt they accumulate. Always be careful around fire. That's just a good reference for any situation. But especially when you're working with a new design system, be mindful that it has an impact and the things that you put out and say to the rest of the team and the rest of the organization that's consuming, really do impact the way they consume it. But above all, enjoy nature, enjoy where you are, enjoy where you're being. You're doing this for a reason, and it's to build something exciting and a great experience.
Enjoy the process. Don't get too caught up in, this isn't precisely exactly right, or this is slightly misapplied. Instead, find ways to help people enjoy it and then educate as you're helping them enjoy using it. Now, with the governance model, it's important to understand how you're going to encounter new changes. I want to walk you through an example of how this might work. Let's say you have a new product, and your new product has requirements, users, stakeholders, and that new product invariably is going to have a special requirements that the design system can't meet. Okay? If you have a design system and it can't meet the new requirement, well, what are you going to do? Well, they're going to say, well, it's very special and we have a special consideration and the design system doesn't cover it, so we're going to go ahead, we're going to implement.
And you say, okay, well, let's add a new component for your special requirement. If you just go straight from getting a request to adding a component what's going to happen is, your product teams are going to go, if I have special requirements, I can just send them to the team, and I don't need to actually follow the design system. The next thing you have more special requirements with more new components and the other products that are using the design system go, this is pretty great. Okay. So all I have to do is just ask for something new and they just add it for me and all the other products come in. The next thing you know, everything's a special requirement and nothing is in the design system, but everything's in the design system, and you have no governance, you just have an intake model. There's no governance happening here.
Well, our friend Smokey says, only you can prevent feature fires and a good governance model is how to prevent that from taking off. Let's go back to the start and see how we could've done this differently. A new product comes in with a special requirement. Let's break that special requirement down. Is it really a special requirement? Well, is it a new feature? Does it fail to follow any other matching pattern or similar pattern that's already in the design system? Is it truly a unique use case? If all those things are true, then the conversation can be had about will others use it. Is this something that just this team is going to use, or is this something that multiple different products and teams might use?
This is where you decide if it's going to be a one-off exception, or if it's going to be integrated. If it's going to be integrated, then each new component that enters the design system should be prototyped with the complete cycle of user testing metrics and ideally deploying it at least once into a production environment before promoting it into the design system itself. By doing that, you're able to validate that it works. Once it's validated, then add it as a new component into the design system. Now, what happens if some of these conditions aren't met? Well, if it isn't really special, then one example or one approach would be to have them use existing patterns.
And that's some moment for education, to help the teams understand how to apply this existing patterns. Another is if we're trying to figure out, well, who else does use it and we're not sure, that's where you deploy it. And then you track its usage and determine whether or not it's just a one-off exception, or if it's truly worth incorporating into the design system for other products to use. Having exceptions is okay, but having a workflow to know when those exceptions are granted and how those new changes are integrated, is the most important part. This is a process that's good to establish before you need it.
If you try to establish this as new requests are coming in, different teams will feel like they're getting different results and different participation. That lack of consistent experience across the teams will fray and may lead to some heartburn in the adoption of the design system. Now, what does this mean for design systems? Right? It means that we need to improve our products over time. You're not going to get everything right all at once. So your governance model needs to be set up to improve products over time. Your governance approach also needs to be able to introduce new elements. It needs to be able to incorporate new things as they occur.
You have to be able to provide consistent interactions, both to the team and to the people that are using it. The only way you can do that is by being mindful of what components and what aspects make it through to everyone to use. Finally, focus on building that great experience. If you get caught up and focus on having a really good governance model and being very particular about governance, your energy and time is going into an internal power struggle. It's not going to build a new great product. All right, let's go into maintenance.
Now, maintenance is I think one of the underlooked aspects of a good design system, because that investment tends to manifest in a lot of other areas, and it isn't talked about as its own particular concern. But I think that's because there's this misnomer that design systems maintain themselves. They just naturally evolve and keep up overtime. And they do. But then they're going to end up just like this. If you take a maintenance approach where everything is managed and updated as it happens, eventually the collection components, the design system will be seen like this, and as a result, it's just not going to work quite as well.
Now, maintenance is not a one team effort, right? Maintenance is an effort that encompasses the entire organization. And that means the design system team. It means the product teams that are using the design system, and it means the product organization that has needs for the product teams and the design system itself. Everyone together, is part of that design system and needs to maintain it. Now, what can happen over time, because you have these different groups and they're all have slightly different sizes, is that sometimes one group's interests can outweigh the others.
And so a product org could lean on a design system team, because it's a much harder group to take a maintenance approach that maybe allows debt to accumulate or delays maintenance in exchange for getting new features and functionality out. Design system teams, likewise, because they're so small, might move faster than the product team or the product organization itself can keep up with. And so it's important when we talk about maintenance, that all three groups take the same weight and the same energy at that maintenance problem, rather than any one group having to own it on their own. All of them collectively should have an equal and shared interest in making it successful. Let's talk about how each of those groups can do that.
For a design system team, the team that's working on a building that design system, the most important thing they can provide in terms of maintenance to the rest of the business, is predictable forward progress. It's letting everyone know when releases are coming, how they're going to be received, how changes will happen and what teams need to do to prepare for them. That also means transparency and communication. For instance, if a new release of a design system is going to potentially break existing patterns, there should be a change log that they can access to track those changes and understand what impact it would have to upgrade to a new version of that design system.
Design system team also needs to invest in the collective success of the other product organizations and the business at large. If a design system team is only focused on investing in the design system and being as cool as it can be, that is great. However, they're going to limit their impact and their potential growth and the success of the design system. Finally, it's good stewardship. A design system team is a steward of the design system. They might not be the dedicated design system team all the time. They may rotate out to other products. They may be dedicated, and they may be the only dedicated team to it.
In either scenario, they are stewards of that design system for the rest of the organization. And so they have a unique, additional responsibility of making sure that they are being those good stewards and taking care of the larger collective interests of the complete group of company, product org, product team, design system team, and every decision that they make. For the product team, they really need to focus on collaborating as a community. That means having lunch and learns where people get together and talk about what's working, what's not working with design implementation. That means helping each other out when problems happen. That means communicating readily and actively when things might not make sense. That means giving feedback both to the product org and to the design system team about what's working and what's not.
They also need to take ownership of their outcomes. I think, one of the things that is a trap, it's easy to fall into with a design system, especially when it comes to maintenance, is falling to the trap of, well, it wasn't in the design system or the design system wasn't quite right, or we just had to get this out the door. We just had to meet this deadline. We just had to, and as a result, additional product debt accumulates, not only in the product that they're building, but also for the design system team, because they're fracturing the experience by rushing through something.
It's really important that the team takes ownership of the outcomes of their work and contributing back to the design system. The other piece, is to support every discipline and role. No one role is the, be all end all role, to run and manage the design system. Every discipline has a part to play and should be supported and should have that cultural support, whether it's someone in an analyst role, an engineering role, or is a designer themselves. Everyone has that part to play and should be equally supported. This is very, very important as well, respect the design system team and the mission that they're doing. I've seen scenarios where it can become a little bit antagonistic between the team that's building the design system and the other teams that are consuming it, because they're not all heading in the same direction.
Those teams really need to see themselves as working alongside each other to make that delivery a success. For the product org, this is really at the highest levels of the company, right? Think, your VPs of product in your C-suite, be prepared to designate and reinforce something as the design system. Other teams may in a Suncorp fashion, especially in a large organization, try to spin up additional versions of their design system, because they're a very, very special use case. In these scenarios, the product organization needs to be able to say, this is the design system that we're using. And in a very large organization, if introducing additional design systems, as a requirement, say, this is how those design systems get integrated. They need to make the expectations known to the entire organization on what it means to use the design system and what their expectations are for that onboarding.
There also needs to be an investment in continuing education. Design systems are often chasing multiple different tech stacks and approaches at the same time. And so the team needs to have the resources and tools necessary to keep up with the momentum of the rest of the business. Finally, there also needs to be an effort to protect the design system team. So that means making sure that the team itself is protected to focus and work on the design system and they don't get pulled out every single time there's a fire drill in another product. I've seen the robbing Peter to pay Paul, raiding the cupboard happen, where a design system team gets fractured in order to chase other specific delivery efforts.
I think in very, very short term bursts, you could do that, but you're running the risk of the design system falling behind the rest of the business, and then losing out on that investment and the momentum that's been built out. Now, maintenance effort doesn't have to be done entirely on its own or entirely ad hoc between teams. There's a lot of great tools out there that can help the maintenance process move forward. One that I really like is Storybook. Storybook will allow you to host all of your components and documentation and customization in one spot for engineers, product professionals, designers alike, to all go see and access those, and then pull them into the application. By pulling everyone in to a single source of truth, you then have a much easier time implementing the solution across the different groups. And then as new components get introduced, there's a single place for people to go and worry about those.
Now, Storybook is not the, be all end all for maintenance. I think this is part of why the maintenance topic needs its own special attention, is because there's a lot of different tech stacks and platforms and design applications and design system management tools out there. This is only a small selection of what you could find, right? And so every design system maybe addressing multiple tech stacks, it maybe addressing multiple mobile platforms. It may be addressing multiple different design languages throughout different design teams that use different design applications. And there may even be multiple efforts to manage it, unless there's a cohesive management strategy.
With a cohesive management strategy, there can be a consistent place to work on the designs, a consistent place to go to, to learn about those designs, and then a known approach for how to work on different applications, whether it's Angular or React, potentially even Drupal, or if you're building an iOS app, an Android app, or even one of the new pre-compiled apps like Flutter. All these different aspects, further complicating the maintenance conversation, which is why it's important to identify what the stack is, that will be the focus of your teams, and then develop that maintenance plan for each instance. Ideally, the effort should be to optimize for the teams that are implementing that design system. It's easy to make choices that we do to focus on optimizing for the design system team, especially if you design system yourself, instead you focus on broadening that impact across multiple groups.
Let's talk about adoption. Adoption is more than just the development of a design system for onboarding people to it. It's also about getting people excited about using it. Now, when does a design system adoption efforts start? I think it starts as soon as you sow the early seeds of development for that design system. That means at the inception of the effort, design system adoption starts, it continues throughout the development and then following any design system release. That adoption takes a lot of different forms. I'm going to tell you a little bit about how to think about that adoption.
Now, adoption, a lot of it is communication and helping teams understand how to put things into practice. A lot of you may recognize this as something that used to be a common method of communicating with teams. This friend here, the three column layout wire frame, this unique, an abstract placement of rectangles, I'm sure evokes a certain emotion in many of you. Now, let's that forget its siblings, the tablet collection of rectangles and the mobile collection of rectangles. One slightly more stack than the other. A bit of advice, don't do this anymore. These approaches to laying out designs in a healthy design system aren't required, because each of these really is a picture of software. What a design system can do, is it can help you facilitate the process of moving from pictures of software to actually talking about building and constructing that software, by referencing the existing components.
Now, again, that's only possible if you have a single source of truth to go to, to call on those different components and work through them together. A great way to do that, is through having a microsite for your design system that shares all the different expectations around all these different things about adoption, governance, maintenance, how to use it, where to go and what you need, right? That single source of truth is providing cross disciplinary support by providing code UI/UX patterns and any necessary downloads to support the design system, as well as clean and consistent documentation of what is expected and of course access to the design system team. And the reason for this is, because if you think about a design system inside the context of a team, or even any application like Storybook or documentation site, it's kind of in its own little design system greenhouse.
The reality is, when a design system goes out into the world, there's a lot of different environments it has to survive and thrive in. And so by taking an adoption approach, where you're providing the tools necessary to the team and bringing them up to speed in any aspect that they need and allowing them to self-service as they adopt the design system, they're going to have an easier time integrating that design system into the many different challenging environments they might face. That's because a greenhouse is a cool place to visit, but it's not a very realistic place to think of any product living. They all have their unique challenges and they all have special considerations, just like every plant has its own considerations for how to water and take care of it. One of the things that you can do to help drive adoption, is to also have that thorough documentation to show how to implement that design system.
I think material design does a really good job of this showing each of the different aspects of a design system elements and components. What goes into it, the code that's required, usage and design examples, and also tips for accessibility. Now, I'd be remiss if I didn't talk about the most important part of design system adoption. Now, there is a need for messaging. Communication strategy is also very important, being vocal and talking to the teams about what's coming and why it's coming. And all of that, that I've talked about, but really important is the swag plan. The reason for that, there's four key points to the swag plan. It's because people love free stuff. They just do. Who doesn't love good swag? Right? I think part of what makes swag a powerful part of adoption is how you get that swag.
I think what's great about this example here from Microsoft, from MSBuild, is they hand out these cards whenever you've interacted with them. And then after the interaction, you then had to go and drive yourself to a second interaction with the design system team to get the swag. And so they said, okay, we're being modest, but it's pretty great swag. I had to figure out what was this great swag they were talking about. They were right. I found a photo of a swag they offered. It's pretty fantastic. You got a water bottle, you got a t-shirt, you got swag bag, you got enamel pins and you have design system socks, maybe not a requirement for your design system to have socks. Maybe it should be, who doesn't love good socks? But either way they created excitement around their design system.
And then anytime anyone wore any of the swag or used it, people got to see that design system branding out in action. This is especially powerful if you're rolling out a design system within the larger organization, build some really cool swag, a really great hoodie, a cool water bottle, something like that. So that when people see it in the wild, they're able to go, "Oh, wow, okay, this is pretty cool. Where'd you get that?" And then a conversation happens about the design system. Swag is actually helping generate that community building aspect that makes a design system thrive and succeed over the long term. When you have that community-driven progress, that's when the rest of it all comes together, much more naturally. It's a much less forced effort when it's a community behind the design system itself. Now, I want to touch very briefly on metrics.
Measuring a design system is all about measuring the outcomes, not the activity. There's maybe one scenario where you might consider measuring lines of code for your design system, and you could track something like, the number of changes to CSS files in a deploy, before the design system was rolled out versus after. I think you'd see a significant difference than the amount of new code written. But really any design system measurement should be about the outcomes it produces for the business and how each team successfully implements that, which means that your measurement strategy for design systems should be the same measurement strategy that you have for any system being used.
Now, you can also track things like number of people that visit the site, number of components in production, what the overall coverage is of design system components per application. All of that are good ways to track how effectively the design system is being used, which is good. But the reason that you're doing this, is to provide the impact for the business. Bringing it all together. To build a design system that works, you need to develop a governance model that encourages exploration, builds excitement, gets teams ready to work together in a collaborative way and adapt to changing requirements. The second piece is, you need to build a maintenance plan that accounts for those changing requirements and every different tech stack and new technologies that might come about. If you have a culture of healthy maintenance, when that new great tech stack comes out, the team will have a much easier time adopting to it.
And finally, adoption is as much a community-building exercise as it is a technical exercise. That means you need to start your effort for adoption at day one and keep it going throughout the development. When you're building a design system, the people that you test the design system with the people that you've talked to about successful development, are the same people that are going to become champions for it in the future. And finally revisiting the great advice of our dear friend Smokey, only you can prevent feature fires. All right. Thanks very much for spending the time with us today. I saw a handful of questions come in. So give me just a second here, I'm going to pull up those questions, and then we're going to start answering a couple of them.
Okay. So the first one we have is about governance. And this is from Tyler lo Miller. Tyler asks about an example of a governance process in the context of how it might play out for a product. And so give me a second here and I'm going to go back to that slide to answer Tyler's question. When we look at this governance mode, we talk about how it might happen for a product, a way to think about it is, you're working on the product and you're on the team that's working on it. And as you're working on that product, let's say you're building out a new resource center for a series of applications, and you need to display high density, tabular data. And there's not a good solution for high-density tabular data inside the design system.
Well, that's because high-density data is usually pretty particular based on who's reading that data and why. That's a good example of something that would probably be a one-off special requirement for the design system, where it's designed just for that instance. And then other teams might borrow from the pattern loosely, but the design system itself might not support that same high-density data pattern, because it's so unique to the product. Conversely, let's say there's a need for a four column layout, and there's no four column layout in the design system yet. That's something that you might come through and say, well, does it really need to be four columns? Or do you just want a four column layout?
Most of the time, something that's randomly a four column layout, is probably trying to put too much content on the page anyway. If you're able to have a better conversation about the content and how it structured, and talk about different ways that content could be arranged, you can probably solve that problem with the existing patterns in the design system. I hope that answers your question, and if not, Tyler, go ahead and shoot me a chat message, I'll take a look for it. All right. We have the next one here from Daniel Lopez. Are there instances where a pattern exists in the design system, but there are significant customizations to the pattern, color, more content, new buttons, et cetera. Is that a new pattern or do you try to fit the existing pattern?
Something that Daniel's talking about and I went back and forth about including it in this talk, is the idea about, if your design system is serving a branded house or a house of brands. You might be familiar with that term. A branded house is, it's one house where everything looks and feels the same. The other is a house of brands where there are many different brands under one roof, and each of those brands has its own unique personality and feeling. If you're in the scenario, especially where you're in the house of brands, but you want to have a shared design system, that's where customization is really important and an application like Storybook can help provide those customization options by team, and also provide that teaming by team as it's necessary.
In terms of a new pattern versus an existing pattern in the house of brands example, I would still try to keep the patterns as consistent as possible across the different products and then customize, but some might just need to be their own very unique solution, and that's okay as well. All right. Have you ever encountered a situation where you realized that the current design system doesn't fit with the organization's current tech stack and what's your approach in addressing this situation? A couple of ways this could happen. If you're bringing a design system into the organization wholesale from the outside, like let's say Google's material design, then yes, you could have a scenario where the design system might not fit with the organization's current tech stack.
Ideally the design system as you're building, is built with the organization's tech stack in mind, but let's say there's a scenario where the design system is in Angular. It's been an Angular and it's been working in Angular and developed in Angular, and then separately from the design system, everything starts happening in React. And everything's in reaction zone. You have a couple of options here. The first is that, you can spin up a parallel React and Angular support structure for the design system. I think that's probably the one that most groups are going to do. When you do that, you're introducing an additional step of when a design system asset is promoted to being component. It has to be built twice.
But if you have a legitimate need to have those multiple tech stacks, I think it's a fine way to do it. The other is to have a healthy conversation as an organization about why there are so many tech stacks. A design system can be in a position where it's just trying to fit and fix every little problem that the business has, because so many different problems manifest in the design system. That's because the design system is really this complex object, that's the sum of many smaller objects within it. And so all of these problems bubble up, if you try to solve each of those problems individually, then the design system team becomes triaged.
Instead, the team can identify moments like that, where let's say there's a tech stack conflict, elevate that to a larger conversation within the product organization and then decide, okay, how do we separate these things out and how do we actually address the problem with multiple tech stacks, and then make an intentional decision about if we're going to invest in multiple tech stacks for the design system. Let's see. We have a question here, should the gatekeeper be an existing member of the org or a new hire, if existing, who? This is from Allister Dance, talking about a gatekeeper, I'm assuming that you're mentioning someone who is deciding what goes in and what doesn't go into the design system and what makes and what doesn't.
For that person to be effective, they have to have relationships across the organization and across the design system team. An internal hire make a lot of sense for that person to bring someone who already has that expertise enrolling them into that role. It can also be somebody new. I don't think their newness to the company is detrimental at all. I think that also then provides that fresh set of eyes, that objectivism, and the reality is, after a handful of months of working on it, they're going to be as though they've been at the company for a while anyway, because patterns and systems and teams change so quickly. I think either scenario could work.
Let's see here, we have a question here from Georgia Sullivan. How do you differentiate the use of Storybook and a micro-site for examples in documentation? Georgia, I think for something like this, I think Storybook is often more team focused and it's more inwardly focused inside the organization. This is a good question. I didn't touch on this earlier. The Storybook is really about the people that are using the design system, more so than anything else. Whereas the documentation side of it and the documentation site or the design system microsite should have a broader audience.
That could be other teams within the company that could be stakeholders at the company that wants to learn about the design system. That could be executives that are curious what's happening with the design system. Something like Storybook is more of that work bench for the team. And that microsite is more about that adoption curve and that information curve and that communication side with everyone else. You can serve both in the same place, and a lot of people do have a microsite that functions as both an example of source and the documentation. I think that's fine, as long as there's clear areas for all of those different audiences and those needs to be met.
We have, let's see here. Can you speak a bit more about measuring the impact of putting design systems in place, improve development speed, easier support, faster issue, resolution, et cetera? I think there was another question here as well. Can you speak a little bit more about metrics? I'll go ahead and try to answer both of those. I think when you're measuring whether or not the design system effort is successful, I think that is where you can measure the time to market part of it a little bit. There's a risk there where you're giving the design system too much credit or not enough credit. What I mean by that is, every new product that you build is going to have its unique challenges and its unique considerations. So you could look at something, especially if your teams are logging their time, how much time is invested in what say developing UI stories, developing friends stories, versus developing backend stories. But you also have to take into consideration when you compare those numbers.
Is it a very complex backend integration product with a very lightweight UI, or is it a very complex UI that's made easier by the design system, versus something that is maybe a little bit more lightweight on the backend? Both of those realities are possible. So you have to look at any of roll out metric like that, with the two combined. I think another thing about any kind of metrics with the design system is, it's very easy to tie it to productivity. How much a team gets done and how little time they're spending on building individual assets. But I think the real metric is something like, how many additional research cycles the team is able to do, how much more time they can invest in something like service design and mapping out the service blueprint, how much more time and energy the team has to focus on the really valuable pieces of validation and experimentation and prototyping, versus only building mock-up, after mock-up, after mock-up for an engineering team.
I think that benefit also plays into it. Thank you all for coming. Again, hope to see everyone back here, May 8th, RMS, for product funding. Have a great morning. Thank you.
About the event:
Full Stack Friday is a monthly, meet up hosted by Devbridge at our Chicago headquarters. We get together to indulge in a delicious pancake breakfast and talk shop. We bring in guest speakers to present talks focused on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.