 It's wonderful to be talking to all of you. I think about design systems all day, every day, and my work job. My name's Nathan Curtis. I'm from Washington, D.C. It's actually northern Virginia, so if you've ever traveled through Dulles Airport, I've heard your plane come in and leave. I've had a journey through information architecture and becoming a UX designer, ultimately, too, in about the last five years or so, double down and focus only on design systems. So all my client work is leading design system teams, helping groups with their strategy and coaching other programs as they get their design systems off the ground. When I talk about design systems, I really introduce them and try and boil down to what are we trying to solve? What's the main thing we do? And design systems in today's interface world consist of a visual style, a visual language of color, typography, iconography, space, and things, applied to UI components, buttons, forms, and all the other smallest parts, part of our core that we use to make our experiences. And we take those systems and we make products out of them. We make interfaces that solve problems. And so we see that big black canvas and we take features of the system, like a grid and all of the components that we can apply in order to solve a problem like authentication. How can I sign into an experience? And as a designer, that's not just a page, it's a flow, it's a journey to get you into a different place in this case. And so you create pages like created accounts, I forgot my password. You start to solve a myriad of different tasks or problems for the user. And as a designer, you're using programs like Sketch to do so. Figma, Studio from Envision, Adobe XD, whatever product you use. And ideally when you're working with a set of developers, maybe that have their own React library, they have complementary tools that are the same features, that express the same thing, that have the same building blocks to compose the experience with that material. And so the challenge of systems is really building upon that. You have a team of designers, engineers, and maybe some other people. And there's six teams in your organization and you all want to build the same way. You all want to achieve consistency. You all want to increase your speed to market and you want to raise quality. And in today's world, these digital product organizations are getting bigger and bigger. Maybe it's 36 teams. Actually, maybe it's 200 teams. And so part of the scale of design systems is taking that system and I'm gonna represent that by a diamond today in the diagrams you'll see. And applying it to be consumed or depended upon by product teams. That's the relationship. Those are our customers. And so we think about systems and we think we're the top note of the tree and then we realize we're not. We depend on brand identity. There might be a group in some other place that helps us understand how to apply color, typography, a logo mark, other simple principles because they're applying that across lots of other places too. And so we're a node in the chain of that dependency. But to our product teams that adopt us, we are the single source of truth. We have achieved the scale. Everybody's happy. We've solved the problem of design systems. Gosh darn it, it's never that simple. If it was that simple, everybody would make visual style and UI components and call it a day. And so there are challenges that we have with this. And those challenges are what I'm gonna cover with the rest of this talk. That I'm starting to discover that are more and more painful and harder problems than actually making a library. And that involves the outputs we produce, the adoption we seek, the generations over time that we have, ultimately the competition that emerges in these organizations at scale and finally the opportunities we have through the hierarchy of systems that we can create. And so let's talk about outputs first. Throughout the rest of today, we're gonna take a look at that diamond of a system and realize that that diamond provides different things for different people. On the one side, we position the designers tool. Like I said, sketch. All those assets that they do in their day-to-day material-based making, and I'm not talking Google material, but the material that they use to compose interfaces to communicate what those are. And on the other side of the diamond is the code. And hopefully those two things are saying the same story. In addition, when we're designers, we're also documenting all those how-tos, all those additional expressions of when am I supposed to use something? What are the behavioral nuances I need to consider? Help me make good judgments with guidelines. And on the other side, code reference for engineers, which helps them understand, here are all the properties you can use. Here's how you install something. Here are the different examples of code. And so the challenge here is that when teams start to make systems, often I'll see this dichotomy. We've got a community of designers on one side. You have a design systems team of sorts that are making their guidelines and sketch assets. And on the other side, you have other engineers that are making code and the code reference material. And what we find is, actually when I make systems, teams and programs, I try to encourage a product mentality to this. The communities are important, but when we think about adoption, when we think about relationship, that tie, that dependency happens at a team level. And so how can we serve those teams and at the same time come together as a team to express and create those tools together? And so that's why when you see design systems early on in their life cycle, you'll see those things separate. Do you want the design? Go over to this website and learn about it. When you want the code reference material, go to that site and learn about that. And as those tools change at different rates, as those tools are influenced by both types of disciplines, what we find is actually designers out there on the teams, working with their engineers, they go to the code site because that's their source of truth. Leaving behind or on an island, all this other design guidance that you have. And so when you think about building your design system, like Shopify Polaris, like Morningstar or IBM Carbon, think about ways to fuse the message of what your system provides so that designers and engineers using your system can use it together and have that shared vocabulary and have that synchronized set of tools that they need to have. But these things change over time. And as they change, we need to think about the adoption of these tools by different teams. And so a quick thing is, okay, we've got 36, or in this case, 21 product squads using our system. Turns out some of them don't use the code. They stick with their own code but embed the design into that. And others actually don't adopt it at all. And so over time, we're not gonna have just 21 teams adopt the system. It's wonderful. We have to think about ways that we're going to understand this gradually increased way to connect with the system. And how can we monitor and represent that over time? And yes, it involves spreadsheets or it involves some sort of data that we need to have. This is a spreadsheet of actually Morningstar, a company that I worked with. There are about 50 rows in the spreadsheet of all the different product squads using it. And we are tracking over time their level of commitment or integration of a system. Zero is a non-adopter. Four is they are using all the system code and they have adopted everything that they can. And we have a series of stages or steps in between that we can express. Understand that some of them are never gonna use it. Some of them don't even have interfaces to speak of. But also, great out here is an understanding of who our customers are. Who's the product lead? What's the name of the tech lead? What's the name of the designer? And organizations that can't fill out this spreadsheet can't help me understand who my customers are. And as these products adopt these systems, we understand there really is no big bang anymore of systems, there's no massive redesign. Each of these products are integrating the system independently at different times on the timeline and that they do this incrementally. That's a very attractive word to most product managers. Can I do this a step at a time rather than having to stop all the priorities I do have and I already committed to in order to use the thing that you're now telling me I need to use to be consistent with everybody else. And then they get grouchy because your system goes through generations of change. And so when I talk about a generation, that is a shift in the design language, that visual style and the designed expression of all the components or the code behind the scenes and how it's architected to support them. And you go through generational change where your adopters look at it and say, oh, that's like a redesign to us. We really need to strip out and refactor so much in order to use what you're now telling us is the new standards, the new sauce. At an insurance company I was working with recently, they helped me realize across their six key flagship products that they really emerged starting in 2011 but actually about one a year through 2017. And over that course of time, they did many big launches and each of these launches represented a big refactor, a big redesign or a rethinking from the ground up of what their product experience is. And they realized that, yes, we've been living with some of these products designs for a really long time. And so you overlay all of these different system generations as the systems change and you start to map that to the big periods of change for each of those products. And you'll realize that in some cases over the course of two years, you get one shot. And that one shot isn't necessarily when your system comes out. It's actually maybe 12 months later or 18 months later. And so that means from a systems perspective, you can't just keep focusing on the new thing and just get them a new thing in their hands so they can make new great stuff because other teams are gonna live with the old thing. And that means support, you have a product. That product and its use is going to diminish over time as others adopt a new version of the system. And that ending the life of the system isn't at the end of the dark gray bar, it's at the end of the orange bar. To give your adopters confidence, you're gonna be around to answer the phone, fix their critical defects and still have a repository that if they need to live in the old system, they can still build some features into the old system and that's going to help them out. And so we think about that generational change over time and if it happened from 2012 to 2018, it might be that from a design perspective, the last real major generational change happened in 2015. That's when you've got this primary button that's blue, it's rounded, it's got a pill-like shape and it's changed much less over the years since then. But from a code perspective, we need to be empathetic to the people that spend probably 10 times as long working to code up the system that we've designed for them that the API to that system has changed before it was a class CTA, now it's a class BTN because that's how Bootstrap does it and then we have 2017 and we're calling this SysButton because we're using block element modifier as our CSS methodology. And then even in 2019, well, we're just gonna make web components because we have React here and View here and Angular there and we know that to be maintainable over a long period of time, again, the API is gonna change. And so the adopters tolerate this process of adoption. They know they need to do it. They are bought into the fact that consistency across or cohesiveness across a customer journey has value to our overall product portfolio. But they don't like to change and they definitely get annoyed when you ask them to change what they've already adopted. And so thinking about words that we use to talk about systems frames a language that's gonna be successful or not successful. When you use words like migrate, refactor, new or monolithic, oh my gosh, people get really tense. And so how can we start to use language that instead is upgrade or swap which feels much lighter weight and next and incremental. But I say this not as a vocabulary exercise. I say this as a spirit or principled way of looking at our system and being empathetic with our customers because we have to be like the green words. We can't just say the green words and what are we doing about how the system works and it's integrated to achieve or reveal that. And so we have version numbers. We have ways to help them understand that change happens and they love patches. When that final number changes that means you fixed a defect. Nothing else has changed. There's no new features. There's nothing's broken. But if you add a new feature we call that a minor release. Sometimes people call that a feature release. And so that middle number changes, that's good. I like new features, but ooh, that big number? That means the whole bet is off. That means everything's changed. That means, oh my gosh, we have to readop this monolithic thing. And that's not necessarily the case. It actually just means the API broke and you might be calling something SysButton and you wanna change it to SysPrimaryButton and somebody could do a cut and paste and otherwise everything works exactly the same. And so the amount of effort to change and adapt to a breaking major release doesn't have to be really huge. And so we think about our design objectives too. It's not just about classes in CSS, but instead in 2015 that button it actually wasn't the best kind of text and background contrast. But by 2017's generation we solved that. We got to a level of contrast between the white text and the blue button that met accessibility rules. And in that generation we also started to add support for a wide range of different color backgrounds. Essentially light modes and dark modes. There were other colors too. And we needed to ensure that everything remained accessible, except those rules we depend on changed. And so when WCAG 2.1 came out and said it's not just about the color of primary as text and the background color of blue. It's about the relationship of that background color blue to the background that it rests on. It's adjacent color. It needs to have a three to one contrast ratio. And then we test those and we're like oh my gosh, we thought we had solved for accessibility but accessibility's rules changed. And so what does that mean? Well we just add a new feature we think to the design system. We change the color of the primary button on the darker backgrounds to increase the contrast level to an acceptable threshold. And so then in 2019 we've got a new system and it looks like from a code perspective that it's just a feature change. We've now got a new color. But actually it's not. When you adopt the system, if they just adopted and change nothing, nothing should break. But we are now actually saying from a design perspective you have a visual breaking change which requires you to go in and refactor your code by adding the class. It's a subtlety. But designers from a systemic level need to get involved with conversations where it's not just the code's API but the relationship of the design choices you have threaded through a system where other people that invoke that system need to be much more cognizant and aware of how those rules change. And so that can also, these generations can result in what we sometimes call Frankensteins. That's where visual style and UI components are from different generation in the same page and it all just looks messed up. Or is that the right mentality? Sometimes is it a patchwork? Is the degree of difference between those designs okay? So on the left hand side, that's a Frankenstein. You've got that orange gradient, I'm a misgradients. Oh gosh, didn't, actually maybe we should go back but maybe not. But we've got a primary button on the left hand side that's orange and it's in clear conflict from a visual language perspective with the secondary ghost buttons that are down. That's a Frankenstein. But on the right hand side, team one might be working on the top part of a page and teams two and three on other parts of a page and they're on different generations but that level of difference is acceptable. And so as you think about graduating or upgrading teams across different versions of your system, how are you thinking about communicating what's a level of difference that's acceptable enough and how long are we willing to live with that level of difference? But you don't wanna communicate that when a new system comes out you have to change everything now because there's no acceptable difference and there's no time. And instead, often characterizing as you build new features, use the new system and be cognizant of the level of difference within the old system, within a page or within a flow or within an overall customer journey that you have. And so then we get to competition. Why? Because you have lots of products. In this case, maybe upwards of nearly 100 products, maybe 80 products and it turns out that those products are made in different organizations and it's so common. If you have an organization, a digital organization that has a dot-com group and a product group and an enterprise intranet building tools group that they're all gonna have their own systems. Of course, they are solving a great systems challenge because there are 15 product teams making the dot-com experience. That's a lot of teams to coordinate. But is it okay that we've got these lines separating parts of the business and they really form this sort of challenge for us to think holistically about what our overall customer experience is or what people's engagement with our digital portfolio is. Banks are similar. They have like credit cards and bank accounts and loans and other kinds of investing products. And it turns out that banks also have different segments. They have their consumers and they have their business and their institutional clients, many of which have all those different kinds of products available to different types of customers. Oh, and then there's different points in the customer journey. And so you have to think about marketing, acquisition and servicing. These combinatorical effects result in lots of systems all over. And so how do you deal with the fact that these systems exist? And when you ask the question, is it okay to have two or more design systems? Should we consolidate? And if so, how is that gonna work? And so you have problems to solve. And grounding the work that you do to consider consolidation needs to consider is the design language convergence, our primary goal, is the redundant code libraries that we have and the architecture of those are problem to solve. Is it the redundancy of the operations and the program and the design ops and the teams are problem? Because it turns out, like a project I'm on now, all three of those are challenges that are problems we wanna solve. But it was a big step for us to recognize we can solve the third one in about two sprints. We can solve the first one in about three months. And it'll take us maybe years to solve the second one. And that's okay. We need to plan to solve those things. And so you do do diligence. When you're talking mergers and acquisitions, you need to look into the assets of all the different things that you have in your existing systems. Design systems one and two might have visual style that's actually look similar to sort of a bird's eye view, but it's incredibly different. Different font, different levels for orange and blue. They share a lot of components, but they have their own distinct components as well. They have distinct tool sets that they support, whether it's a stack of sketch and vision and abstract versus another team that's been on Illustrator forever. But wants to use Figma because Figma's the new awesome. And so how do you think about the choices you make to rationalize these different points of view? Code is even harder. There's a huge list of things that you can compare across categories like how do we make the features we have in design systems? What are the tools and architectures that we have that support that making? What kind of testing suites do each of the systems have? And how do they make and publish the documentation that everybody else learns from? I had a spreadsheet that was about a hundred rows long that covered all these different categories and subcategories and lots of columns comparing different things and even getting that to recognize the level of comfort or discomfort that individuals in the development community had around the choices to the 2B that we had was difficult. And that gets at power dynamics. Because when you have a system team one on one side and system team two on another side, they may bring different mindsets to this process. One might be believing our teams are coming together. We're gonna merge and we're gonna address the enterprise together to solve all these great problems. And on the other side, the other team might think we are awesome. We have an adopted design system. We've got the most modern tools. We're just taking that other team, absorbing them into us and we're gonna take our tools and move them even further forward. And you can imagine the kind of dissonance that you run into between teams that come in with different expectations about a merger or acquisition. And so it gets at mindsets that you have. Are people coming from an individual perspective? My designers want. My architecture demands. My teams won't like. Or are they trying to see the collective in the way that they look at the world? Our design could do this. Our code library must do all these things. Or do it in a different way to address more people. Similarly, there might be a second mindset. How rigid are they to what they've already made versus how adaptive are they to change? Our design is good enough. I hear that from incoming system designers. Our code library works already. We're committed to what we have, as is all of our adopters. And others on the adaptive scale think, our design is ready for an update. We've been living for two or three years with this thing. Our code needs fresh tools and models to solve our problems in a better way. We are ready for something new. And so as you take a look at the teams that are coming together and the sentiments or the mentalities that they bring, you might think you'll run into perhaps a system team one that is very individualistic, is serving their current customers extremely well, but makes them also very rigid in the way that they're looking at this process of coming together. Whereas system two might already be serving two large subgroups, and yet their system is a little bit aged. Their subgroups are going through a transformation and are ready for change. They're expecting the fact that they're gonna refactor and retool a lot of what they have. And so how do you bring them together as a collective pursuit? And how do you raise empathy for team one with the broad array of other customers that are going through other kinds of changes they haven't seen before? And team two to recognize that change costs money and they need to be empathetic to team one's great investment they've made over the last year or two. And it takes a balance. And so you have to ask good questions, difficult questions. Like are you ready to engage regularly and in good faith? Everybody says yes, but their behaviors may not indicate that. Are you ready to support those with different needs than your own? Are you ready to relinquish things you've built already? Are you ready to change things if you have to? And are you ready to pay for this? Because change costs time, change costs money, change costs capacity and what we have to do. And so we have options to consolidate things. One, we could choose to do nothing at all. And so even as a baseline, as a placebo effect, how are we gonna measure the difference between changing one or at least maybe starting by sustaining the systems we have and starting to draw out common tooling that they can both share? Or how do we retire one and have us adopt the other across both product sets? Or how about we retire both and create something new together? Or how about we retire one, start sharing some stuff and build something new? And so these are actually options to choose from that have trade-offs. And those trade-offs include how much is it gonna cost for us to reproduce this new system? But more so, let's think about our customers online too. How much is it gonna cost for them to migrate across this big portfolio? And ultimately, our goal is in the future we have an easier to maintain consolidated system architecture for design and code. How much is that gonna cost and how are we gonna balance these trade-offs? Are we in the game of supporting the next six to 12 months? Are we in the game of supporting the next two to four years? And even thinking about those kind of time frames changes the way you look at these trade-offs. And so I remember talking to K-Lig, he's a Dev Ops supporter of Shopify and he said, you gotta realize you're in a long game here and you're gonna be in a point where you're trying to converge folks on a target state that you can help define and that convergence is gonna happen at different times and it's gonna be imperfect. But you're still going to have to be a light that they follow, that Polaris that Shopify in their case has created and it can take years. Because this is our goal, right? We have one system. We have one system that has all the answers. It's singular, it's perfect, it's the truth. That's where we wanna be. Except maybe it's not. Because hierarchy in systems might be something that instead of thinking of it as complexity we can think of it as a level of complicatedness that's desirable because it helps us achieve more goals. It's even evident in systems today. As you look at the IBM design language they have a design language with many guidelines that then is used and applied to Carbon which serves their product org and another digital library that serves their web org. Yes, there's some redundancy in the latter too but they are being built with a common shared core that creates hierarchy within how it works at IBM. I'm fairly confident that there's some other design systems out there that leverage that common core and I'm also confident that there's some that don't leverage any of that at all. But it's at least it's a hierarchy. And another example that I have run across with insurance companies for example is that you have the dot com, the sales and the servicing points of the life cycle that divide out their product teams into three big groups and they had a design system that had design guidance and the code libraries but the sales team wanted to move fast and they said can we use your architecture and create a second repository and just reuse that whole stuff, we wanna make our components there the way you make your components. Why not, that's an opportunity and it turns out that that collection of system tooling enabled them to work so much faster and in alignment with how the system works. And now it's a question of of those 100 components in the sales kit, maybe 20 are relevant to the other two orgs. And so how are we gonna think about promotion from the sales kit to the core kit and how are we gonna think about challenges of equipping the designers in the sales org with design tools corresponding to that sales kit and communicating through documentation what's in that sales kit and should that be an investment that we take. Target did something similar, they used lingo app and lingo app is a way to have a lot of sketch assets across different kits so that different teams have access to different parts of the tools and so they had six, their design system was called Nicolette and they also had a separate kit because there's so many icons it's huge and so they had two kits that corresponded to the core that they provided. It was viewable by the entire design community but it was only editable by a choice few essentially the members of the Nicolette team and a few of their closest friends. But then that architecture was expanded with a second tier to support all the other groups making stuff themselves and so as you think about for example the account group that they had they were working heavily on cards but their cards had different kinds of requirements around the kind of content that went in that card and different kinds of connections to different data repositories to render those cards and so they had their own set in the account group of components they were working on and so the Nicolette team hadn't edit access to that the whole account design group had access to that and then everybody else could still see that so that as they raised opportunities for sharing those opportunities bubbled up and so for Target to them they suddenly had the design tools that they were using lowering where the threshold is of the system providing an architecture that many designers use rather than just seeing the system as this core set the sketch file and the documentation site that they used in their day to day work. A more sophisticated example I've seen in the wild was an online software company that had lots of different groups they probably had over 100 teams so this is being a little generous but there were three main products the 15 team product, the 10 team product and the five team product that were really the three big flagships and so as it turns out within those groups two of them had design leads that had a close relationship with the system team that made their own sketch extension kits on their own and then you had in the third group a woman dev lead that said I'm making our own kit and I'm gonna model some of what we have based on how the core kit works at the top but it's the additional components that we need that nobody else needs but they'd also enabled this behavior within their core code kit the ability to work on things across groups too and so they had a navigation kit and an editor kit and think of editor like you have the ability to edit text, you have a toolbar above how to edit text you have different models that come up when you have certain kinds of uploads you wanna do into that rich text editor and so on and that's shared across many different teams and so as they had these kits emerging across the group suddenly their code kit both expanded significantly which was great but then started to involve a lot of different people working at different levels of quality and so that became a challenge but it makes me wonder how far down is this system going to be an architecture for making things that enable us to share not just across groups but within groups because even that first out of four product groups had 15 in there and that kind of sharing is the amount of sharing and scale that the system promises to provide and so we need to think about the quality that we expect out of all those different things the closer you get to the bottom of this diagram the closer you get to an individual team the faster they wanna move and the less they wanna be encumbered by rules of the system, complexities of the system but the higher you get the more people expect that this stuff is gonna be excellent it's going to be perfect, it's never perfect but it's gonna be close to perfect and so how do you set rules or create ways that people engage from the lower part to the upper part such that they're willing to do so and it might be to get from good you just need to make a component to have what we call a visual testing page it's just a page with a bunch of rendered examples that have some structure to them we have hostile styles that try and penetrate the CSS walls of that blocks to make it look incorrect and so on for the better ones that may be getting across groups you have to have robust unit testing visual regression testing that has to be audited for accessibility as opposed to just we're making it to try and be accessible and then to get to the very top to be part of the core it has to work across all the color modes it has to be brandable it has to incorporate right to left displays it has to have all the analytics embedded in it and so you can imagine a contributor trying to just share something across their group they don't want to do this stuff on the right that doesn't matter to them and so how are you going to create whether it's code here or design there rules that help people understand how much work they need to do before it's legitimately shareable with others and so it asks questions of us with our design system are we going to remain a small core kit made by a smaller group of people that everybody else reuses because that's how a lot of people start and it's a great place to start but it's also sort of a ceiling that many hit or we're going to start to transform our work to gradually expand from being just a tool set to be an architecture for sharing because that's going to change the nature of who system teams think that they are and what systems are offering as features so I do a lot of writing on this stuff if you liked the diagramming stuff there's an article for that I talk about design system tiers and visual breaking changes and other things visit that stuff on medium and if you're in the design system space but not yet a member of design systems slack there's over at this point 10,000 members and you go to design.systems you get invited and there's a robust array of topics and I'm one of the admins of that so we'd love to see you there and talk more about design systems thank you very much