What Makes a Design System Win

So I want to say, thank you all for welcoming me here. I am actually speaking Monday. I'm giving a remote talk on testing. And I came here just to hang out because I talked to Tejas and he said the community here was so warm, so amazing. This was just such a great vibe that I had to come see it here in person. And I told the organizers, because this happens, in case somebody can't make it here, I actually have this talk that I've just written that I'm really excited about. I hope I don't get to give it, but just in case, here you go. And they immediately said, we need your help. And I actually feel really sad that Marin couldn't be here today. I know he worked really hard on his talk, so I want all of us to just send him some really good vibes right now that we miss him and that we hope he does well, and we hope to see him soon.

And with that said, I have a story to tell. So going back six years now, I joined my first big tech company, and where I joined isn't that important, and what project I worked on isn't that important. This could have been really anywhere.

For context, this is March 2018, and I joined this big company that was an enterprise application. And as you might guess with some enterprise applications, the UX and UI could be a little challenging for some of our users. And the project I got to join was founded to address that specifically for the majority of our users for our most common use cases. So the UI and the UX for this was very, very pivotal. We also got to try out TypeScript full stack for the very first time. So it was a bit ambitious, and we cared a lot about quality. We cared a lot about that UX and that UI, getting that right, making sure that we could deliver value to our users so they didn't have to click around 20 screens just to submit time off. We wanted that to be a lot easier for them.

And two years later, we achieved that. We ended up releasing to over 60 million users. Nothing went wrong. To my surprise. But we were able to deliver this UX improvement to so many people where they could go in and just send some chat messages saying, hey, I want to take today off and be done with it in 10 seconds. Things like that. And we felt great. And by all of our measures that we had going into this, we had achieved our mission.

But there was one thing that really was missing that was pivotal, if you think about it. In building our crucial piece of UI and UX for our application, we were missing something that I think was extremely important, and that was our design system. We had not leveraged our design system to build this. Now, our design system is prescriptive and suggestive and gives guidance to make sure that we're providing a cohesive user experience. That we're following best practices. That when you go from screen to screen, things look consistent and they don't feel like all these disparate applications. And in an enterprise application where really there's something like 100 products all smashed together, shuffled into a deck, that's really important to get that to be cohesive as possible. And our experience was on every single page of the application. It was ubiquitous. For us to not have this, to not leverage this, was potentially a massive failure. And while we were compatible and it didn't look different initially, if the design system were to evolve, we weren't going to evolve with it, because we weren't using it.

We were off in our own territory, living in our own world. So this was a challenge that I thought was very interesting, because I was a senior UI developer, and I knew about the design system, and for us to have succeeded in our project, but to not use the design system, I felt like that was something I couldn't measure at the time or I couldn't really put my finger on how problematic it would be, but I just knew there was something in my gut that just told me there's something wrong here that could be better.

So with that, in this time when our design system had failed, I want to share with you what I believe makes a design system win. My name is Will Klein. I got to experience 2020 like everybody else, and for me, this was a very, very challenging time, and actually I had been burned out for a year going into it, and I jumped onto a Zoom call. I remember jumping onto a Zoom call, and it was my second time joining this meeting that was this monthly demo that our design system team was putting together. I'd been there before, and I was finally joining it again now that I was disconnected from everybody, and I was actually a bit eager to jump on Zoom and see a person or see a group of people and hang out, and I saw their work, and it was so clear to me that they were doing amazing work, so if their work was so good, why wasn't I aware of it or why wasn't it apparent to me how to bring the design system into my work and to be effective with it? So I pondered this as well as being burned out, and I felt like I needed a change, so I had this wild idea, and I reached out to the design system manager. His name was Lynn, and I said I remember sitting on my back porch, and he's like how is everything? How are things going? I think we had met a year before over some drinks.

We were already kind of friends, like we were fond of each other's work. The design system had open sourced a year before, which I was a fan of. I was trying to get the company to go to more meetups and conferences and be out in the community sharing our work, and we were doing that. We sponsored our first conference in 2019, and here we are a year later. We've known about each other. We're friends with each other. Two of the people that ended up becoming co-leads on the team, I had recommended to him. So he had a great appreciation for this, and I said hey, this design system is really good, but I don't get it. I don't see it, and I feel like this isn't just me. This is a lot of people. This is a problem across our whole UI community at this big company. There's something like 80 teams that we could be reaching, and they're reaching a fraction of them. There's some amount of them that are using it, but there's a larger whole that we are not addressing, that we're not reaching, that are frankly very distracted with, or focused on the work they're trying to build, and they're also distracted by all the communications coming across the company, all the all hands and all the growth we're experiencing.

So people, as much as I like Zoom at the time, people were definitely starting to experience meeting fatigue before the pandemic. Now everything is on Zoom. It's only getting worse, getting everybody's attention and keeping their attention. So how would we solve this? I proposed this wild idea. I said what if we worked on that? What if we got people excited about the design system? What would that look like? By the way, I'm kind of looking for a career change. I might need to just quit my job because I'm having so much trouble, and this is so hard, but 2020 is crazy. I don't know what's going to happen. What if I did this with you? He went for it. He was thrilled with the idea even when I told him I was burned out and it was a massive risk and this might totally crash and fail, and it would look terrible. But he said no. We need to figure this out and he gave me that trust and gave me that opportunity to see what we could do.

So he brought me under the team. I remember him sending me an empty document that was write your job description, which was kind of fun. And we ended up defining it as an internal developer advocate role. I got to still write code. I got to show things off. I got to largely figure it out, and I'd never done this before. And I also, by the way, I did not know design systems. Defining a design system, even to today, I would say is a little bit of a challenge. What's the right way to define that? And back then I had no idea. I just knew that it had things that we should be using as UI developers.

Ah, see, where am I at? I want to say one more thing about the team and their work. They were really good. The problem was not how good the design system was. It wasn't how good the code was. It wasn't how good the design was. Even their docs were very good. In terms of documented projects and how they're described and examples, it was, I would say, far better average than what you'd see in, say, open source. And in terms of a corporate project, it felt like it was just super high quality.

And in terms of a corporate project, it felt like it was just super high quality. That was not the issue. And what I would get to do with this team was largely add to what they had as a culture. So I don't want to take any credit for what I'm going to describe next. But I did get to work first hand on a lot of these things.

So as I was saying, my problem as a non consumer was not their fault. And it was a common challenge. I want to say, not just for our design system, but we talked to other design systems. We would have these calls with other companies. We would find they had the same type of challenges. And we would also talk to other teams where they were shipping code that other developers were using, like platform engineering. Like, I remember there was a rich text editor project. They came and talked to us about these things. Really, any time that you're shipping code that other developers consume, which I believe happens at some point in our career, you have this potential challenge of getting people to buy in and believe in what you're doing. And have a clear path to bring it into their work. Developers take the path of least resistance. They want to build something and ship something. I want to get something done. I want to get it out there. And if it's not clear to me how something else that I'm unfamiliar with is going to come in and make that better, that's going to be a massive challenge for me.

So when I started, I said before, I really didn't know what I was doing. But I had some ideas. I felt like I was the target customer that I needed to solve for. I was distracted. I have ADHD, actually. It's hard for me to keep my attention on things that I don't want my attention on. That I'm not driven and motivated to stick to. And I was on that project, where it was so important that we use this, and we had not. So with that, all right. Let me go with this.

I love this quote from the American actor Steve Martin. Be so good, they can't ignore you. And I'm going to add to this, or iterate on this for this context a little bit. As I said, our code and our design were very good. But there's something else that I found our team doing that was absolutely pivotal in building credibility and getting attention and building trust across this company. And that was being very helpful.

This team was comprised of people who loved to help each other. And not just each other on this team, but anybody who had a problem. Anybody who had a question. And they knew TypeScript, they knew React, they knew frontend, they knew accessibility very well. And at this big company, there's a lot of people that have lots of questions about these things. And I've been doing them for a very long time. And so something that we found ourselves doing very often was just hanging out in Slack, especially during 2020, and just answering questions that we saw happening in the TypeScript channel and the React channel. And other team channels that were important. And so we took the time to just go out of our way and be as helpful and useful as possible.

And by answering questions that weren't related to the design system, we just went out and just offered the expertise that we had. And I think this was absolutely pivotal in building the credibility that we hadn't lost, but we didn't have. We had to earn it. And by being helpful and answering these questions, and being very kind about it, we sort of set a tone where people could tell that if we saw what they were asking, we would not only help them, but we would be really happy to help them. We'd be very kind and generous with it. We wouldn't ever say something was a dumb question or assume they knew something or fault them for getting it wrong. That was absolutely expected. We got things wrong, and that was okay.

And I think the really cool thing was that as people came into our design system channel, because they knew that we were answering these questions, and they'd see that we worked in design systems, so they'd join our channel, our public channel, for people to join. They'd come and they'd ask more and more questions. We saw that just grow and grow and grow. And part of this was getting their attention, and part of this was people adopting things. But it really did start with people just wanting to be better developers. We're all here because we want to be better developers. And this company is filled with people just like us.

And so this just grew and grew, and before long some of these questions weren't just TypeScript and React. They were, okay, what component would I use for this use case? What should I do here? I don't see a component that does this. What do I do? And now people are coming to us with the things that we've been wishing for. That direct ask of what do we do? And we're able to answer them. And they're also absorbing that culture of being kind and being welcoming and asking questions in an open-minded tone.

There would be people that would come in and sort of be accusatory, like, hey, it doesn't do this, it really should work this way. And that always happens. And we would just take it with kindness, like maybe it should. What is your use case? We would just ask questions and understand the problem they had. And it would turn into a true discussion where we're understanding where they're coming from, and maybe there is something that we got wrong. But often it would go both ways, and they would see, oh, wait, I see why you designed it this way. I see why there's flexibility here. I see why you're not telling me exactly what to do, because you're supporting so many things and it needs to work here and here, because you showed me those examples.

So yeah, having people come in and ask things was very essential, not just to be able to support them, but to hear those problems, to understand what were they trying to do. Which is, the bigger your company is, the harder it is to know everything that's going on. So we would come in and sit in everybody's standup and everybody's project meeting to know what's going on, to understand all their needs, and we had created this opportunity where people were coming to us.

There was something else that, I want to also give you a couple examples. If somebody had a problem, we also looked for something, there was always something we felt we could improve. If they didn't understand something, was there something missing from our documentation? Was there an example that we didn't have? Were we not describing a use case that they had? We were too specific about other ones and we had left them out. So we always saw every single question, even if it really was they didn't know what they were doing, we always looked for an opportunity to improve.

And this just forced, it didn't just force, but it helped us to constantly improve and iterate on our documentation and iterate on how we communicated things. Not just how we did things in written form, but how we described them to person after person. So there's a really cool thing that happened that I think was really, really great for bringing in even more people that weren't as active on Slack, that weren't already asking questions. In May of 2021, I'd been there a year, our fifth major version was coming out, and it had some massively breaking changes. In particular, we were making a big lean, a big shift into compound components.

Just in case you're not familiar with that, instead of just giving you one JSX element with maybe 30 props to configure things in a combo box, we were saying, hey, we're going to give you three or four components. That might be 20 lines of JSX and you have access to each of the individual elements in the JSX component tree, which often maps one to one with the DOM tree. So we're giving people a lot of flexibility. In fact, they, in cases, could take elements that we were providing and swap in their own and wire up the state machine so that things had the shared behavior and worked across different elements. And this is quite a bit of a paradigm shift.

So this was sort of a Trojan horse plan that we had where we would evangelize the design system, but also not like say, hey, we want you to use the design system. We wanted to come at it a different way. And so we came up with these workshops and the pitch was this. We wanted people, we knew that people wanted to be better developers, so we said, hey, you want to learn React, you want to understand React design patterns better? We're going to talk about compound components. We're going to talk about how they function and how to use them in real world use cases. And so we ended up having so many times for this that we had to split it up into like three different offerings in I think July. And we'd have 20 to 30 people in each and they would come in and for eight hours, we would go through and broke it up, not just the hours straight, but we'd go through how to use compound components. We'd go through React and we'd answer questions on React and TypeScript. We weren't focused on teaching them design system. We were focused on just teaching them what we knew about being UI developers.

And of course along the way, our design system and our components were the subject of the examples. So they could see how those things were used directly. This ended up being something that occurred the following year. I ended up giving a new iteration of this to another bunch of people. Some people came back from the first one, even though the subject matter didn't really change. They just wanted a refresher. And then they'd bring in their teammates and say, hey, you've got to see this. You've got to come check this out. And then I think a year later, 2023 in the winter, three new members of our team, because I was the start of our team kind of doubling, three new members of our team, the most junior members of our team built an entirely new workshop that focused on responsive design and the latest suite of our components.

So this became something that we would continue to give on an ongoing basis. And that, I mean, people at the company knew that this was a place where you could go to learn to be a better developer, that you could learn more about UI and not just the design system.

To keep these conversations going on a regular basis, there was something else we did. We hosted office hours every week. And there's a couple things that we tried. One of the first things we tried was signups. And some people really like signups because they like to have something in their calendar, something that they're committed to. I have this question, and they send that along. It's in a spreadsheet somewhere. And that worked for some people.

But often what ended up happening was I would just post in our Slack channel. It was on a regular basis, like every Tuesday and Thursday or every Wednesday. It changed over time. But we'd have them roughly twice a week for 30 minutes. And people, I would just say, hey, we're having office hours now. And I would do two things. I would, because people might have questions, but they might not. And I would throw out things that were happening in the UI ecosystem. There's always something happening. So I'd say, hey, how about those? I mean, it wasn't back then. But how about those React server components? Who's using them? Or who's curious about AI right now? I'd throw out things like that, conversation starters, just get people to come hang out.

People would come sometimes with questions like, hey, I'm working on this, I want to figure this out. We'd go hands-on with it. And other times, they would come and just, hey, I'm just here to chill. And our team had a really good culture of also just joining in on these. And there'd be three or four of us in this Zoom meeting, hanging out, waiting for somebody to join. And we'd be asking each other questions, which is kind of a great team culture. We were just getting together in our own office hours for everybody else and just helping each other. And then somebody would join, they'd hear us talking.

And then somebody would join, they'd hear us talking. And I'd be like, hey, what do you have? And they would have a question, and we'd get into it. And this became popular enough that at times, we had three or four people coming in on the same call, and I'd be creating Zoom breakouts, and we'd be splitting off. And once in a while, I'd be going into Slack and be like, hey, I need help. There's more people than we have right now. So this worked really well to keep that conversation going. And I think that it's a good mechanism where sometimes in Slack, you feel like you need to prepare a good, clear message that has a clear question. And that's good. Sometimes, you're not even sure where to begin. I often don't know, like, I just don't know enough about this to even know what question to ask. And that's where Office Hours is fantastic. So somebody could just come in and just have a conversation and have a really fast feedback cycle of getting input.

Something else that we were doing was release demos. I mentioned them earlier. I was joining these monthly calls, and those monthly calls worked initially. But as the company was growing, we noticed meeting fatigue. We could see the attendance drop off as we had more things in our calendar. There were fewer people showing up. So we did a couple things here. The first was that we whittled it down to when we had a release. And we were releasing major versions every six months. And we were releasing minor versions about once a month. And we found that with some of these minor versions, there was just one thing here or one thing there. So we stopped doing them monthly. We scaled it back to doing them just twice a year with the major release demos. So you'd think we're reaching people less, but we were just investing more in fewer opportunities. And this was, I think, we went from having the attendance drop off to it coming back up for these twice a year, twice annual events. And to go along with this, I think it helped that we had a very clear release schedule. And we were intentional about, hey, breaking changes are expensive. They cost you a lot of effort to come out of what you're doing, to see how we're doing, how things are changing.

So while we're going to do these breaking changes twice a year, we're going to intentionally do the larger impact ones in May. Before the summer, as that was beginning, that ended up being a good time frame to say, hey, this is where most of the changes are going to happen. And if there's only one of these you pay attention to, this is it. And then again, in the fall, we would have another round of breaking changes, but they were much smaller, much lighter, smaller impact. We weren't going to rewrite a bunch of components then and change the API for them like we would with compound components in a fall release. But we might take the opportunity to deprecate something, to maybe remove something that we've been communicating for six months to a year, that this is going to go away, or this is going to get promoted from a lab or preview package into the main. And the imports will change. So it's just going to work the same, but some things are going to technically be breaking. And people definitely like this predictability. They like to know what's going to happen. They like to know when they should pay attention and how much. And this also helps because as we're communicating this release cycle, we're also saying, here's what's coming in three or four months. And as they're working on things, they can have that awareness of, oh, we're going to need that new sidebar. And what does that look like? We're already building. So we would have teams surface that they need these things sooner, and we could partner with them early and say, oh, maybe we should give you a head start on what we're trying out, and you can pilot this in your product. And as we release this, we'll have the benefit of your input firsthand. And that was really helpful. So what did this do for adoption? I mentioned our demos kind of dipping at first and coming back up as we changed the cadence. I mentioned our office hours were growing. Our Slack channel, I think when I joined, was 200-something people. In two and a half years, it nearly tripled to 600-plus people. It was the largest UI community at our company. It was so large that that was like the place to go to understand what was happening anywhere in UI, not just for our design system. And that was something that we were, by the way, very careful about in how we used that Slack channel. We never at-mentioned, we never at-channeled everyone or at-heared. We never tried to ping everyone saying, hey, you need to look at this. We were very respectful of that. And if we had a message to share, we had to be very upfront and very clear. Here's what you might care about. And maybe in that first line, you're like, I don't care about that.

And you could go somewhere else and know you don't have to read the rest. But people would see, oh, I am curious about that. We put lots of details in the threads.

Something else that we did. Teammate of mine, Allen, he led the effort to reach out to product teams directly. He actually wrote a really awesome tool to pull all the Git repos for all the projects and basically build an AST of all the code that they had, and look for usages of our components in their applications. So we had metrics on how much our components were used, who is using them. We also looked at what version people were on. That's also a massive challenge that we had to figure out, because some teams were on version 3 when we had just released version 6. This is potentially years behind, and it looks terrible.

So let me talk about dependencies a bit. As I mentioned with the compound components back in 2021, we had a lot of breaking changes, and this could make or break our design system. Things are going to become more flexible. We're going to give more trust to everybody, but they're also going to have to rewrite a lot of code. That's not great, and I as a very recent product developer just thought that's effort that I wouldn't want to do. I wouldn't want to have to change hundreds of lines and across all our projects. This was thousands upon thousands of lines. So I had this idea. I was pretty keen on a couple of different tools related to ASTs, and I said, hey, what if we wrote code mods for this? The team was like, yeah, let's do it, and they jumped right on it. So as we developed or rewrote our components, we also added code mods to rewrite the code. If you're not familiar, we basically shipped a package where somebody could say, run the code mod for this version, and it would go over their code, find all the things that were changing, and rewrite them to the new version of the API. You can't do this for everything, but we were able to do this for something like 90% of changes, and those very tedious things that you're just like robotically going and changing, those were handled for you.

This went so well that I remember there was an office hours where somebody came in and I'm on years old version. I'm four versions behind. What is it like to go from here to what's up to date? I said, oh, let's try this, and I pulled up our upgrade guides, and I said, here's what we're gonna do. We're gonna run this command from the upgrade guide for the code mod, and we're gonna see what happens. In a few minutes, I'm within a few minutes of the call, within milliseconds, we ran this, and it rewrote a bunch of things. We went over the changes, went over the upgrade guide, and made sure we didn't miss anything that we might manually need to review, and then we did that again for the next version, and after ten minutes, he said, okay, whoa, whoa, whoa, wait, hold up. This is much easier than I thought. Can we get off the call now, and I wanna try the rest.

He got off the call excited to do an upgrade of his dependencies on our library, and I think 20 minutes later, he said, yep, the PR is up for bumping all these versions for our team. Our designer's reviewing the look and feel of everything, make sure everything's good. That was far easier than I expected. And that was the experience that people were having, where instead of this being a problem, they were seeing the developer experience better, frankly, than a lot of their dependency management problems.

This was really cool to do, and really awesome to offer. Let's see, that's basically what I talked about with tooling here. I'm running over time? Okay, cool. Good to know. So, with that, let's see. Jumping ahead here, I can skip a couple things.

There's one thing that I want to make sure I mention, and that is advocacy that we found happening in our community. So we essentially grew a community, and these people that were helping early on and over time ended up becoming our greatest advocates. We would hear stories of, hey, I'm on your office hours because, like somebody new would join office hours, like, why are you here? Oh, Matt told me about this, and you've been saying great things about your work.

And we would hear over and over again how people were, we just had a really good reputation. People were excited to tell each other about what we were doing, and they wanted more of this to happen in our organization. So we had a lot of advocacy happening. And one of the greatest things I saw as well was, we'd have support questions in our Slack channel that our community members were answering. We were just sitting back, watching our community help itself. And I love it when this happens. There were times where we were quick to respond, but it was good that we actually slowed down a little bit and just let that happen more and more.

And finally, with that, I want to say, I left that a year and a half ago. It was a fantastic project. When I finished, we had a massive release demo that we made at a party. We actually themed it around boy bands, NSYNC and Boyzone, and we played music, and it was very, very cheesy. I was all dressed up like a pop star, and so was my partner in Dublin on the design side, Zoe. It was a blast. We had as much fun as we could with these things, so people weren't joining another all hands or another corporate business kind of stuffy thing. We were just letting our hair down and just having fun, and that was a really awesome vibe to have.

So with that, I want to say that I encourage you to think about your own work and how you can make people feel welcome when they ask questions, how you can grow a community where people feel welcome, where they feel like they can just bring you anything and you'll be supported. I believe that those are the things that can help a design system win, and really any project where we're helping other developers. I now work on developer tools full time. I started my own company called Tool Space. You can find all my socials on my website, willkline.co. Please find me after if you have anything you want to talk about. I love to chat about design systems, developer experience, and everything else. Thank you.