The Struggles & Triumphs of Creating a Design System Practice

Of creating a design system practice. Welcome. I see a bunch of people here in the chat. This is so cool. I always love doing this. I always love seeing where everybody is from. My name is Dan. My name is Dan Mall. I'm the founder of Design System University. I'll tell you all about that in just a minute. Thank you all for being here. So many cool people and locations in the chat. People from Philly. I'm just outside of Philly as well. Shout out to Philly folks. We've got people from Brazil, people from Chicago, Colorado, New York, Florida, California, Bangladesh, Germany. Oh, man, this is incredible. This is so cool. Thank you. Thank you everybody for being here. We're going to get started in just a minute. I have a couple of housekeeping things and then we'll get started with our webinar and bring up our guest in just a few minutes. They'll introduce themselves and they have so many great things to share with you. So we'll get to that in just, just a few minutes here. For those of you that are not familiar, this is a Design System University event. And at DesignSystem University, if you're not familiar with that, we're striving to help designers and engineers and product people to design effectively at scale through things like curriculum and courses and content and apparently events. This seems to be a thing that we're doing. We had an event last month about 2024 design system planning. A ton of people attended that. I know a lot of you have been doing that recently. So when I email. When we email you the recap of this event, we'll email you the video after it's done in case you want to revisit anything. We'll also include a link to the previous event if you missed that one that's freely available for you to watch. So you can see that, that 2024 design system planning, if that's relevant to you. And if you like these events, like today's and like the last one, please reply to that email and let us know. And we will do another one in January. Maybe we'll make it like a monthly thing. We'll have some monthly free events around design systems if that's a thing that is valuable and useful to everybody. So today we're going to be hearing from three, three amazing people. I am going to leave it to them to introduce themselves in just a few minutes when I bring them up on stage. But in the meantime, all of them, just so you know, all of them were part of the inaugural live cohort of our Design System in 90 days program. And that's a class where I teach the 52 steps and plays that I found to be most useful in setting up a design system practice from scratch. That particular cohort ended last week. So of course we celebrated the last class that all of these folks have been doing such incredible work. We celebrated with cake and candy and coffee and, and all sorts of other treats. So what you're going to hear today is you're going to hear some of the journeys that our panelists went through to set up design system practices with their teams and at their organizations. We do have the next cohort starting at the beginning of next year. So if getting, if getting a design system practice up and running is on your 2024 roadmap, and you want to learn how to do that with a group of peers and other professionals and with professional and experience guidance, at the end of this webinar, I will share more details about dates and where you can find more info and all that kind of stuff. So stay tuned for that last piece of housekeeping is that I wrote a book about design systems. I've got it right here. It's called Design that Scales. If you're interested, if you haven't seen it yet, you can go to design that scales.com and today we're going to be giving away actually two copies. So we'll have a giveaway during this. So please do pay attention. I'll tell you the criteria for the giveaway. The first one is we are going to have a Q and A. So you can use the Q and A panel. The Q and A panel is here. You can use that to write any questions that you might have. Write it in the, in the Q and A panel and, and the question that gets the most upvoted, you will win a book. So I'll get in touch with you. I'll make sure to get all of your address. I'll ship a copy of the book to you with a signed first page in the two. So that's thing number one. Thing number two is if you like things from this webinar, if you hear something or you you see something that you like, we're going to be doing some, some screen sharing as well. Take a screenshot, tweet about it, post it on LinkedIn, post it on Instagram, wherever you share so that other people can learn from it too. And whoever has the most liked post from this webinar, if you tag me or Design System University or anybody, any of the panelists, the most liked view the most liked post from this webinar. I'll also send you a book as well, a signed copy of the book, too, so hopefully you have a chance to share what you're learning and then also learn some more, too, through a design system book that hopefully will be valuable to you. All right, without further ado, I want to bring up our panelists here. So Malika and Aisha and David, if you would turn your videos on. We will get started with the. With the panel here. There you are. Your lovely faces, everybody. I'm so excited that everybody is here. This is going to be so good. Excellent. Well, thank you all for being here. The first thing that we'll start with is maybe each of you could introduce yourselves, tell us a little bit about where you're from, what you do, what your job is, what your role is at your job, maybe a little bit about your organization. So just tell us about that, give us some context before we get into some design system stuff. Malika, maybe I could start with you. And then after Malika, then Aisha, and after Aisha, then David.

Hey, y'.

All.

Thanks, Dan, for setting up this event and kind of letting us all share a little bit about our experiences. I'm Malika. I'm a senior product designer at the Obama Foundation. So we have a pretty small product and technology team team that is right now mainly responsible for our website. And then we have a lot of other digital products that we're working on. So we are. We do have a design system. We're kind of in the early stages of our design system. So there's lots of potential impact that we're excited to have, also lots of things to learn. So having Dan's guidance through this course at this stage has been really, really helpful for us. And then for me, personally, over my career, I've worked at companies that have had no design system, to companies that have had a really mature design system that's been around for more than a decade. But I had. Hadn't been part of a core team that was actually building out the design system. So that was a new experience for me. And then personally. So I, I've spent most of my time, my career in New York and Chicago, but a couple years ago, I moved down to Raleigh, North Carolina. So that's where I'm at now. And my partner and I, we. We love it down here. I have a toddler and I have a golden doodle, and I actually have one on the way. So I'm pregnant, actually, currently, and I'm due in February. I don't know if I even shared that with this group, so I didn't know that.

Congratulations.

Thank you. Thank you. Yeah, that's the focus of my life right now. It's crazy, but it's good. All good.

Awesome. Congrats. Aisha, over to you.

Hey. Congratulations, Malika. So I'm from, I work at Scholastic. I'm a front end developer. Been here for a couple years now. Scholastic is in books and publishing, so lots of education technology focused things. At Scholastic, we tend to do. We have the main website and stuff that's worked on by corporate, but we also have a lot of digital products, like resources for teachers and students. That's primarily the side that I'm on in the digital education world. So with design systems in particular Scholastic, we just started spinning up our design system. We kind of had an iteration of it in the past, kind of fell through and we're working from scratch on this new one and we're really excited to be getting it rolled out soon. At my internship before this, I did kind of work on a design system. And I think like now, having done this whole court and gone through the process of setting up a design system, it was like a totally different experience than what I was doing there. So it's been interesting to see the growth of that and how my mindset has changed on design systems a lot. So I'm really excited as to where we are as a company and where we're headed. I love reading and stuff. I also really love language, so I learn know a couple different languages. And as a part of that, I also really like doing calligraphy. So I do a little bit of Arabic calligraphy, which is fun. Dabble in a few different hobbies. But that, that's a one that's on my mind right now.

So cool. Aisha, awesome. Thank you for being here. David, over to you.

Yeah, I can totally relate about the mindset mindset shift since doing this course. Aisha. Hey, everybody. I'm David. I am from South Africa, which is where the accent is primarily from. But I was born in England, grew up in South Africa, married an American, which is how I ended up in Cleveland, Ohio. I'm the senior brand designer at ConvertKit. We are essentially an email marketing tool for creators. But we're much more than that in terms of having an entire ecosystem for creators to earn a living online. So I'm the senior brand designer there. We're a very small team, so my main responsibility is actually the marketing website. So instead of a design system for a product I'm creating a design system for a marketing website which is. Has a whole new set of challenges. But at the same time, if you think of the marketing site like a product, there's a lot of similarities as well. Previously I've worked at another web application and then before that a mobile application for iOS and Android. And that was where a lot of kind of design system thinking started in my career. So I've got that experience of working in the mobile and the application landscape now with, with the web stuff as well. Outside of design, I am a big Fulham Football Club fan in the English Premier League, which is a very niche team. And I don't know if you can see my golf clubs behind me. I'm an avid golfer and I'm very sad about how cold and wintery it gets in Ohio because I cannot play golf. That's me.

Sorry for your misfortune, David, about. About not playing golf. I hope that turns around soon. Thank you for being here. Teresa does say in the chat that they do say Cleveland rocks, so hopefully you're experiencing at least a bit of that. Awesome. Well, as a reminder for those of you who are in the chat and listening along now that you know a little bit about our panelists, please do post questions for them. We'll have a Q and A section at the end. We might splice in a couple here and there, but feel free to use the Q and A panel to ask questions and we'll get to answering them. So one of the questions that I'd like to ask each of you now is, and kind of hear you talk through, is you spent the last 12 weeks in the cohort learning about setting up design system practices. As you all mentioned, some of you have had experience in that before, some of you have had different experience in that before, some of you had no experience of that before. So varied levels of experience there. I'd love for you all to share some of the things that you have done over the last couple of weeks with your teams, with your organizations to just kind of show us, like, how do you, how do you get a design system practice started? And I know one of the focuses of the cohort is picking a specific component that you can pilot with specific teams. And each of you have such incredible stories. I was lucky to be able to witness how you all have done this with your organizations. And they're all so different and they're all so unique and that's what I love about design system work too. So I'd love to turn it to you all to Kind of just share the, the long versions of the stories of how did you go about it? What was the process? I know some of you are going to screen share some stuff, some of you are going to talk through some of the things that you've done, but just maybe describe to us and kind of show us, like, how does that work? How did that work at your organization? Who got involved? Who did you have to talk to? What did you actually work on? What did, what did you do? So, you know, please do take the scenic route on this one and describe to us as much as you can on just how setting up a design system practice worked for you. Malika, can I turn it over to you first to start?

Yeah, definitely. And if I start to like, veer off course, please interrupt me. So I'll start by sharing that. So we have a design system at the Obama foundation right now, and it's primarily for our website and it's still very much in the early stages. But the reason it exists is actually, if you go to obama.org right now, a lot of what you'll see on the website is already a reusable component. And the reason it's structured that way is because a lot of it is backed by our content management system. So one of the value propositions of our website and of the foundation as a whole is storytelling and having inspirational content. And so we wanted to make sure that everything on our site was entirely configurable by content editors and not dependent on engineers to make updates in real time or changes like that. So, yeah, so having this kind of structure where everything is a component to work off of in a way, was really an exciting way to enter into this course because we kind of had a jumping off point that we could, we could work from. At the same time, having that type of structure was also really challenging because as we learned as we went through the course, not everything needs to be part of a design system. So we learned that things should really be part of the design system when they're solving the same problem multiple times or they're solving a certain use case for different teams. And so since we had this approach where we were building a lot of components early, we didn't have a chance to understand all of the use cases that we'd be solving before we build the component. So let me give you an example. We have a component on our site that we refer to as a block quote component. And so that's something that's meant to showcase short, punchy quotes amidst our content. But we were Finding more and more use cases for longer, more verbose quotes. And our existing component couldn't really flex to support that type of use case. And so one of the struggles that we had throughout this course was kind of rethinking and restructuring existing components that we already had and kind of factoring in that rework. I'll share another story of a different component. So one that we chose to focus on as part of this course was something we called Image Group. So basically an image group is kind of how it sounds. It's a component that shows multiple images at once to a user. And so when we started this course, we chose that component because it's pretty simple. It was an existing component. We were mostly aligned across our different functions, but we knew there were some discrepancies. And so we wanted to kind of use that as a way to try out the process, make mistakes. You know, it's pretty simple, so how bad could it go? So we started off by having each function kind of share out what they thought or how they thought about the component. So design shared, you know, how we thought about Image Group, you know, how it should be presented to users, how users should interact with it, content shared with, you know, their perspective from what actually populates the component. And then engineering shared how it should be structured, how it should be built. And one of the discrepancies we found was as simple as terminology. So, you know, one variant or one way that users can experience Image Group is by viewing one image at a time and then kind of clicking through the images. So that was something that Design referred to as a carousel, but Content and Engineering referred to that as a slider. Sounds pretty minor, but it was causing some downstream effects. And so part of this course was kind of getting us all in a room, having these real time discussions cross functionally. And so we did that. We came to a consensus, we renamed the variant and we solved a problem that seemed minor, but was actually has some value in solving. But really the main takeaway here is that we practice this process that we could now apply to more complex components and then have, have that process kind of ironed out in terms of details and kind of get more comfortable with that way of working. And so I'll just, I'll share one other component that we started working on towards the end of the course, which is what we call a donation component. And so I mean, it's, it is what it sounds like. It's where a user can give a donation to the foundation. So it's, it's really Important to us. This is different than the image group because it's a brand new component. So yes, we're applying this new cross functional process, but we, we're testing a new skill here which, you know, that we tried to learn from Dan, which was how good is our team at figuring out what should be a component? And so with donation, you know, we're, this is an experience that we have across our site. It's really important to us. It's important to leadership and multiple teams at the foundation. And it really, I mean it provides direct business impact. And so we felt like this was something definitely worth working on and you know, weren't going to have as much trouble with buy in or making sure that it was useful to the foundation. And so that's something that we are currently working on and we're hoping that the process that we learned we can kind of continue to apply to future components and just keep, keep iterating and keep improving our system.

Awesome, Malka, thanks for that. I have a couple of follow up questions for you, is that right?

Yeah.

Okay, so one observation that I want to share too is like I loved working with you all on the donate component because one of the conversations that I thought was really good that we had was the fact that we picked the donate component because it didn't appear everywhere, because it actually had a limited scope. It was like it wasn't like button or it wasn't like a widespread component that was like if we do button it goes everywhere. And that was actually too much to wrangle. And I remember one of the things that you had pointed out was like we picked donate because it has a limited scope that we can get our head, our heads around. And so I thought that that was a really wise decision that you and your team made about like how to pick components. So the follow up question that I'll ask you about this is like for a lot of people who haven't worked at big organizations or on big teams, a lot of questions that I get, and you kind of hint at it too is like, I mean, what's so complicated about picking a component and doing it right? Like if you pick image group, isn't that just like spending a couple hours in Figma designing it, giving it to an engineer, they build it, you say I have a meeting, you know, a couple minute meeting that are we going to call a carousel or slider and then you pick one and like, isn't that just like a day of work? Like what's so hard about it? Maybe you could Talk a little bit about, like what, what is so hard about why does it take days or weeks, you know, to actually get through something that, like, you could design in Figma in a couple of hours and build in a couple of hours?

Yeah, that's. There are a lot of, A lot of things along that process that make it a little bit more complicated. Even just consensus building can be a lot more complicated than you think it might be. You know, design calling something a carousel might seem obvious to us, but is not obvious and can conflict, you know, with other things that content or engineering are thinking about. So little things like that can, can definitely throw in some roadblocks. But I also think the, the bigger factor in choosing what should be a component is almost the end of that process. So we've designed it, we've built it, we know how to use it, but is it getting used? I think that's the question that we started asking ourselves more. So in order for something to be useful and to get used, it has to be important to other teams, not just us. Even though it's, you know, having an image group component is going to make our lives super easy. When we want to put images up on the site, if our product teams don't want to put images on the site, then, you know, there was no point in doing all of that work. So having those conversations with teams outside of our immediate team, that's a really important step and that can be very, very time consuming. But obviously it's incredibly, it's worth it because if that's how you define value for your design system, actually getting something launched and used, then it's, it's completely necessary.

Awesome. Great points. Malka, thank you. Thank you for sharing those stories.

Yeah, appreciate it.

Aisha, let's. Let's turn it over to you. Maybe you can tell us a little bit about your equivalent journey over at Scholastic, like how how did the design system work go? What kind of components did you use or decide to tackle, and what were some of the roadblocks that you faced in that?

So we were in a different position, I guess, than Obama foundation was in that we were basically starting from scratch with our design system. And so we had no idea what components we needed, who needed them. We had no starting point, and I think so as we were going through the different activities and figuring out who we were going to talk to and what teams were going to use this, and there was a lot of. At the beginning, everybody was like, yeah, we're going to use the design system. And it's Going to be great. We can build the entire app with the design system. And we had to kind of figure, figure out, okay, like, what are we doing and how are we doing it and what's important. And I think along the way, like, one of the biggest things we had to do was earn everybody's trust in that. Like, okay, it's coming. We don't have every component for you to use right now, but we'll get there, right? Like, we. But we need to know what we're doing. We need to understand our process, we need to understand our priorities. We need to understand, like all the governance around it. We can't just hand you, like you're saying it sounds easy like, okay, build a, build a button, input whatever it is in figma, build it in code here, hand it off. But there's so much more nuance that goes into the system of it, not just the design of it. And I think that's what really the cohort empowered us to figure out. One of the things that we really appreciated having was the backing to say, well, in the class, we learned to do it this way. And so can we try it this way? Let's do it. And then we had the permission from stakeholders and from management to be like, okay, fine, try it this way. They saw the value in it, they're paying for the course, let's try it this way. And that gave us some solid foundation grounding to work on and say, okay, let's identify needs, let's identify users, let's go through the whole process. And that's when we were really able to say, okay, look, we have a system, we have a process now we can tell you when we can release something and when we can build a component and how you can use it. So that's been a really cool part of the journey. I don't know that we expected to learn, but definitely really, really needed. And so one of the components I think I can talk through, that we were doing was our input component. So the product that or this is like the input field is something that a couple of different teams needed. One of the principles we learned was that there's multiple teams that need it. It's worth going to design system. And so we were like, okay, let's start with this one. And so we started designing it, we started building it out and we actually got pretty far. So it's pretty code, code complete. And we were able to get like a lot of the documentation written for it and get it up on the reference site and to be able to demonstrate that, like, look, here's a working component that you will have soon. And here's the progress on it has been really cool. So I can actually share our reference site. This is a little bit of a sneak peek because we haven't really shared it publicly at work yet. Scholastic, you get a little bit of a sneak peek. But can, can you see my screen? Yeah. So we got our reference site set up, which was a huge win, huge. It felt like we actually had a design system now because we had somewhere to showcase it. So if we go in here, we can, we can kind of talk through, like, how do you use this? And you know, what are, what is important? And one of the things that we had to struggle, we had to not struggle with, but one of the things that we had to keep in mind was when we were making decisions, we were actually, we had to work with. So the, the way that the corporate stuff works is different than the way that the education stuff works because corporate sites are. A lot of it is focused on adults marketing. A lot of our stuff is focused on students and teachers. And so, for example, something as simple as error, Red, like Scholastic red is a primary brand color. But we can't use that as a primary button color because red in education means it's bad, it's wrong. So things like that, right, like we had to figure out where to deviate from the corporate system and come into the education system. And that's why there's a difference. And so we started going through what corporate had design went through, figured out our requirements, and then we started building it. And so we were able to get some of that documentation in here. And so to be able to say, like, okay, look, there's information here, that's been a huge thing for building trust. And I think that was a huge factor in getting this off the ground was that we really did have to build trust within the organization, trust for the team, but we also had to figure out where we fit into the organization. I think before we started, nobody at the company knew where we slotted in and how to prioritize us. And we knew it was an important effort, but we didn't know where and how. And so as we went through this process, we had to figure out where do we fit. I think that's something that took us a while to learn and to be able to say, okay, we serve all of digital education or all of education solutions, that's been an interesting shift in our mindset. So having the permission to go through the process, having the foundation to say this is what we're doing. And having now the space to say this is what we do has been really cool. We've learned a lot of different things along the way. So we've learned how to say no to some things. Did not know how to do that before, actually more than we didn't know how to say no. We didn't know why to say no. And so now we know why we're saying no to something and we can explain that. And part of that journey has been like just being transparent with people again. Part of that building trust is that we really do have to be transparent with everybody. A design system's efficacy is really dependent on its adoption and people really want to know how it works and where we're going. And so if we can tell them that, then it's a lot easier for people to accept, for teams to accept what we're doing, why we're doing it, why we're not doing something else. So that's been an interesting journey and I think we're really getting comfortable with the prioritization and decision making going forward.

Amazing. Aisha, that's such a great story. I love hearing all the different parts of that. I have a few follow up questions for you if that's okay. Can I ask you a few?

Yeah.

So one thing to just point out is that you and that I really felt, and I think that a lot of folks in the chat too is that, you know, you said like when just having the reference site, it felt like we had a design system. And I think that's such an important point. I'm so glad that you brought that up. Is like sometimes like you, you know, you have a design system but it's, you don't feel it yet. And something as simple as like we put up a reference site, we gave it a name, by the way, Mockingjay. Amazing name for a, for a design system. So cool. So the follow up question that I have for you is kind of a two parter. You brought up a really important point and you said like we learned why to say no. And I think a lot of teams see a lot of teams who don't, they just don't have that muscle because they've never been able to exercise it. I also noticed that, that in your reference site you have a section that is a little bit unusual that I don't see in a lot of sites. Like most reference sites, they have design and code and guidelines. You had one called design decisions. Are those two things related? Like the fact that you have a design decision section and the ability that you know of why to say no. Like, are those two things related? Maybe you could talk a little bit about, like, how did that section come to be and what were some of the ways that you. Now you know how to, you know why to say, now maybe you could talk a little bit about that.

Yeah, that was actually. So the design decisions tab and the decision to have that on the reference site actually came from something you said during the cohort was to chronicle all of our decision making processes so we can figure out who's making the decisions, why we're making a decision, and then we can understand going forward either where it's working or where it's inefficient. And so that was literally where we started documenting it. And we were like, wait, this is good information to publish because people know, okay, there's a component. But people never know where a component comes from and why the decisions for it to operate a certain way were made. And so for us to say, I think the design decisions guideline is a little bit different than our prioritization guidelines. But this I think gives us room to say, well, I'll use color. For example. Why is our error state red or why is our focus state blue? Well, it's because we're working in education and these were the reasons that we made those decisions. And this is why we deviated from corporate in this way. And so it gives us, it's like credibility and accountability. We're not just making decisions because it looks good, it's because it needs to function this way for what we're trying to do. And so in that sense it's like, okay, well, there's a requirement, I don't know, for something else coming up. Okay. Something actually that came up with this component was placeholder text. Should we put placeholder text inside of the input and the decision was made? No, because we're dealing with little kids and if the text disappears, they get confused, right? Because they don't know what they're looking at. So the decision was made to put the hint text on top instead of the placeholder text inside. But that was an important distinction. And a lot of times people will be like, well, why didn't you put the placeholder text? And it's like, because we considered the audience, right? And so yes, we're also dealing with teachers, but we're dealing with like 4 year old kids who don't really know how to read also. And so there's like this, this mindset of who Are we serving at the end of Something else we learned was like, our end user, our customers are our internal teams, but our end users are, at the end of the day, scholastic customers, teachers and students. And so being able to contextualize all of that information and then verbalize it and publish it has been pretty interesting. And that's also, I think, some of what empowers us to say, like, this component needs to go in, or this component doesn't need to go in, or this feature is valuable to be in the design system where it's not. So, yeah, I do think definitely those two muscles are related.

So cool. It's so, so brilliant. I love that idea. I just saw a LinkedIn post yesterday from Chris Strahl, who's the CEO of Knapsack, which is a really great design system tool. And. And he said, like, it would be great if someone had a startup that helped teams chronicle their decision making. And it's because it's like, that's such an important need and no one does that. And yet here you are going, like, we just built it in as a page in our design. Like, that's part of our process. It's part of the thing that actually gives us credibility and accountability. I think it's just a brilliant move to kind of put that in there. That's so awesome. Aisha, thank you for sharing all that stuff. I know a ton of folks learned a lot of stuff from that. I did as well. David, over to you. Maybe you can tell us a little bit about the story of some components at ConvertKit and some of the process and how design systems are really finding traction at your company.

Yeah, totally. I mean, for us, it was at the beginning of this course, our design system was very much a work in progress. It was very, very messy. A lot of, like, project priorities took preference to us working on the design system. And going back to what I said earlier, just about being a small team, it was really difficult for us to, like, say, okay, this month is the design system month, because we just wouldn't get other stuff done. Right. So it was actually at the FIGMA conference. Was that this year? Yeah, that was this year where Dan had a stage talk. And I think the title of the talk was your next component, or something like that. And I was sitting next to my boss, Charlie, who's the creative director at ConvertKit, and you started out by saying, your next component is like, what do you think? Your next component? And everybody in the audience shouted, button. And we were like, in our minds. Yeah, button. Of course. It's button. And you're like, it's not button. And we looked at each other and we're like, damn. So that was like the way the whole mind shift thing changed for us was getting out of this idea of like the word system in design system. It doesn't have to be a bunch of like small little things or detail things. It can be like an entire section or an entire like part of a site that is extremely valuable. And that's how we got to our component. So I'll share what we worked on during this course and what the outcome was. If you can't see my screen, just let me know. So this is one of our marketing site pages and this is the component that we created during this course. And the way we got here was instead of thinking, oh, we use a lot of buttons, we need to make a button. We thought what component would have the highest impact for us. So what we did was we went through an entire like site auditing process where we screenshotted a bunch of, a bunch of stuff throughout the site. We figured what, what is going to be most valuable to us? And we slowly started narrowing it down to how often we use social proof on our site. Whether it's tweets or like case study or use case carousels. We had ideas for videos and things like that. And ultimately that led us to the component that we created. We, we referenced a lot of other sites, we referenced our photography that we use a lot. And we, we want to make creators the heroes of our brand. So this felt like a good place for us to start. Ultimately, this is what it ended up looking like in Figma. So just making sure that we had broken it down into each breakpoint and that it was going to display on, on different screens correctly. And then introducing the video component is actually part of Wistia's embed control. So that was a huge bonus for us having, having that already built in and then just like for us. Okay, so this is, we're like about an 80 person company. And at the beginning it was myself, a developer, Charlie, who worked on this. And by the end of it we had 10 people involved in this process. So the reason I bring that up is because at the start I thought it was just going to be like me and a developer, you know, but when you think about how as a company we're 80 people, 10, 10 people were involved. Eventually it was like a content creator. Our video producer, because we had to put videos in, was a product marketer. It was engineers on the product side. Because we're now using this component in our product because when somebody upgrades their account from a free account to a paid account, we on that upgrade page we've included this testimonial. So not only are we using on the marketing site, reason on the product side. So all of a sudden I did the quick math. 13% of our company was involved in this component. And at the start there was going to be like two of us. And then this is a document that our, our video producer put together, suggesting to me where he thinks these video components can go. Because he's the one who's filmed the content, he's edited the content. He is so familiar with the stuff that is being said in these videos, he knows where to put them. So that is just another involvement from someone I didn't expect. But I think the outcome is great. We've ran a few tests on comparing it and in most cases it slightly increases conversion and it also achieves our main goal of making creators the heroes of our brand and utilizing content that we have already got. So that is the story of our social proof component, which we're very proud of and very grateful for for Dan walking us through a lot of that process.

Awesome, David, thank you for sharing that. A couple of follow up questions for you. Do you mind if I ask you a few?

Yeah, of course.

Cool. So one of the things that I think is really cool about the story that you all have about the social proof component is that is how, how much you tied it to the rest of the organization. 13% of the organization involved in a design system component is very unusual. That's such a high percentage for small or large organizations. So like, how did you get all those people involved? Like were they just, were they nosy? Were they forced to. Did you share stuff around? Like how, how were so many people involved? What, what started all of that?

I would say ultimately it probably comes to us aligning on like a company strategy. I think a lot of us were very focused on the, the whole theme of making creators the heroes of our brand. And because we have so many great creative stories that we document, it just seemed like a good place to start. And I think we were just lucky in the sense that so many people understand the value of us telling these stories. So for us to now package these stories in another vehicle and get them across the site, it was just a bit of a bonus for us really that we were able to have alignment from the get go. And then I would just also say it's. It was down to me like butting in when I needed to. So we had some ideas on how should we increase in app conversion on our account upgrade pages. So that page I was talking about earlier, where someone's free trial ends, they get met with a screen that says, you can either continue on the free account or you can upgrade to a paid plan. And because I'd been working on this component, I suggested, hey, let's throw in this component and test it. So although there was a lot of alignment, it was also like, where can I make suggestions on how we can get this thing used? And because I'm now then introducing it onto a bit of a product workflow that involved product engineers, our director of marketing was involved in that. So all of a sudden now it's more collaborative because we've suggested it in a different part of the business.

So. So two related questions to that you meant. There's two phrases that you keep mentioning. One is making. Making heroes or making creators the heroes. And then the other is like increasing conversion. Those are not typical design system conversations, right? The. They're not, they're not about components or APIs or props or anything like that, or Figma or CSS or anything like that. So, like, how much of that. I think this is kind of related to, to something that Aisha brought up as well, which is like, yes, our customers doing design system work are other designers and engineers have to use our things, but ultimately the customer is the end customer of our company. Right? So in your case for ConvertKit, it's. It's creators, you know, because that's who ConvertKit serves. Not just the design system, serving the designers and engineers who then serve those people. So how important was that to kind of tie to like a, a slightly broader goal than just adoption, you know, of the components or, or something like that? Because you mentioned it a couple of times, it seems like that was really crucial and foundational to the work that you're. The design system work that you're doing. So how, how much did that play a part in it?

I mean, that whole mindset shift that Aisha mentioned at the beginning is like, that was critical for us. We, we've been so bogged down in the systems work, like the props and the variables and figma releases variables this year and we lose our minds and we're like, oh my gosh, I gotta change all my Figma files to work with variables. And you spend a month thinking about that and you don't do anything. But this process created action for us. And that's, that's why? That's why we ended up doing it. So that's, honestly, that's all it comes down to is we needed to find something that was going to make us do the work. And identifying like the high business impact component was the thing that, that did that. And then relating a bit to more stuff that we learned in the course. You, you taught us that later on you can then introduce Systems Week to focus on the nitty gritty details like breakpoints and properties and variables and stuff. So that gave us the freedom to think, to be a bit like, a bit feel a bit less guilty about like, oh, we're ignoring all that stuff, but we'll now have a plan to implement that.

Fantastic. Last question for you then is kind of related to all that is like, I think because of all that stuff and the kind of broader focus that you had on business impact, not just component impact or adoption, there's a lot of acclaim around this component. Like this component got mentioned by the CEO in All Hands meeting or something like that. Can you, can you talk about like, there's, there's a lot of people that are excited about this component, not just designers and engineers, but maybe you can talk a little bit about like how it actually helps the business overall, not just, you know, people who are involved in design systems.

Yeah, I guess once it was on the side, a lot of people had seen it. I mean, people were screenshotting it, putting it in Slack, being like, oh, this is so awesome. And I think there's, there's also just a lot of people involved when it comes to us getting these creators as customers.

Right.

You've got like, you've got account managers and salespeople and people putting on events where you meet these creators for the first time in person. So there are a lot of people who's like, who were emotionally invested in like seeing these creators, like highlighted more. So if somebody in our company had met somebody at our conference and then they see them in a video component, they're like, oh, they're so happy for that person to like now get the real estate on our site. So I think that was a big, big part of it, you know, was just having, being aligned on our mission of making, making creators. We want to help creators earn a living online. Right. So seeing that in the flesh on these components is a good place for us to like share that. So I think a lot of people were just aligned on that in the company. They were super stoked and kind of wanted to carry on like just shouting it out really, which was Cool for us.

That's so awesome. I mean, I don't know how many times I've seen a CEO be excited about design system work. Right? A design system component. So I think that's just like a great, a great testament to the work that you and your team, you know, really did. And, and I love how you, how you framed it and phrased it, which is that like a lot of times we're just not emotionally invested in the work that we're doing because we feel like we're working on such low level stuff, you know, the component, the buttons and the typography and the headings. And I think it's important that even in design system work, we find things that our teams can be emotionally invested in and even more so our customers, you know, our organization's customers or clients or constituents or communities, you know, that they could be invested in that stuff too. Just as a, as a props for all of you here, panelists, there's a great comment in the chat from Hildi saying, being a design system lead in banking with a federated design system, which in my world means different platforms sit in different business segments, my world can get very complicated. I love this conversation. It's helping me not lose my mind. So this is exactly why we do this, is to have people like in the trenches sharing stories about how they were able to succeed. Even though this stuff is hard because it is, you know, it is difficult, but it is also possible to have really good success, you know, little by little, and then hopefully scaling that at a time too. Awesome. Thank you so much for this. Let's move over to Q and A. We've got a few minutes left here. We've got a bunch of questions in the chat here, so I'm sorry, in the Q and A panel, not the chat, I'll ask a couple, a couple of questions so far. The winningest question so far is from Vanessa Cuevas. Vanessa, so far, I think you're the winner of this book. So unless anything changes, you will be getting a book. Vanessa's question is, and this is to all three of you, whoever wants to jump in first, please do so and answer it. How do considerations change between something like a startup versus an older enterprise and I think we have good representation of all of those, you know, on, on this panel too. So maybe you can talk about your perspective. Like, what do you think working at the kind of company that you work at, what kind of considerations are important to your organization that maybe might not be at. At others.

You could go for It, Aisha.

Okay, I guess. I mean, I work at a larger company, but even though it's a larger company, the engineering side isn't massive. It's definitely not startup small, but it's not huge. And so I'll come at it from that perspective. I think, like, with a larger organization, you tend to have to prove a little bit more. Right. Or maybe that's not true, but you have to convince more people. There's just more adoption, there's more visibility, and if something goes wrong, it's like a, you know, fail big because this is something that has a lot of eyes on it. And so you have to kind of find ways to test and fail small before publicizing. And I think like, the example Dan gives with the button is a really good example in the sense that, like, everybody needs the button. So unless you want 12 teams using a button that something's going to go wrong with, like, you start with something a lot smaller. I haven't really worked on a design system in a smaller organization, so my hunch is that. But you can kind of work on it, test it, and then you can just talk to people because you know more people there. Like, you don't have to go out of your way to find somebody whose calendar is booked for three weeks out. Maybe that's not true, I'm not sure. But I think, like, how you build trust in how you communicate about the design system is probably where the biggest differences lie.

Yeah, I'll add to that. Well, I guess the, the Obama foundation is kind of unique in that the total, it's about 250 people. I don't know if you'd consider that big or small. And I mean, I guess maybe in the middle, but the way that we work can kind of reflect a larger organization. And we do have this added complexity of content being such a, a integral part of our technology. So everything being linked to content management has just added a lot of complexity for us. Kind of to Aisha's point, like, we, it's small enough where we know a lot of our partners and we are, you know, we can build relationships with them and establish trust, whereas other companies I've worked at that have been massive. It's like you'll never know all the teams that might consume your component. So I guess the relationship building part of it is a little bit different working from bigger to smaller organizations. And then obviously, yes, coordination headwinds can be just so much greater as the organization grows. So something to keep in mind, I guess, as you're prioritizing and something not to get discouraged by.

Yeah, I mean, the only thing I would add, I guess I'm representing a smaller company. We're probably out of the startup phase and into much more of a growth phase. But I would just agree and say that communication. We definitely have the benefit of moving a little bit quicker, but then when it comes to decision making. But I would then say we also have the problem of resources sometimes, like being in this cohort. It's been so interesting hearing from other teams and bigger organizations because we have such different problems. But some of the designers in this course were. Their job title was like design systems Manager and like, I dream of having that at ConvertKit, but I know that that is not where we can prioritize our hiring. So, yeah, we're just able to move a little quicker when we make decisions.

Awesome. Thank you for those answers. A lot of this relates to another question. We'll do one last question from the Q and A panel. Casey has a question and asks, what did the process look like for understanding the need for a component? You all mentioned some version of like, multiple teams need a similar component. So how is this done? Is this done through interviews with product designers? Maybe you can each talk about, like, how did you find out how needed a component actually was?

Yeah, I can start with that one. So I think it depends on, on who's using your design system and like, where you start with it. But for us it was, we went through like the flows for the different products of the teams that we are supporting. We started off with like, we're starting a smaller set of teams. There are other products that are eventually going to be using the design system, but we haven't onboarded them onto it yet. And so from the teams that we are supporting, we kind of went through their flows with their. During like our planning sessions, like the team planning sessions, and said, oh, okay, well, you need this component and you need this component and you need this component. You also need this other one, but nobody else needs this other one. So let's start with the one that all three of you need. That's kind of how we went with it. Now we're kind of like learning, okay, maybe we should start looking at across the organization as opposed to just these three small teams. Because if there's only three teams and they're doing very distinct types of works, there's not going to be a ton of overlap in what they need. But we have 12 teams that maybe four of them need the same component. So now we're starting to we're at a place where we can start broadening that horizon. But it took us time to establish ourselves to a point where we can now look at 12 teams worth of components. I don't know that we're 100% there, but we're like, way closer than we were 90 days ago. So I think, yeah, it really is just a matter of going through and like, what do they have slated for the quarter? Or what do they have slated for the Sprint and maybe not the Sprint. Maybe for the quarter. Sprint is too close.

But.

And then kind of going. Figuring it out from there. So just having communication with the product teams.

Yeah, plus one. To communicating with the different product teams and keeping that. Keeping an eye on their roadmaps and what their needs are. Being a content first organization, I'll add that we. Something we started doing is looking at the content that our team was or our foundation was producing. So right now that process is basically people will write up documents of this is what the story should be that we should publish or what the quotes should be. So we started kind of studying the content and understanding what needs were emerging there. So going back to our blog quote component, we started noticing they're really long quotes that keep getting published. So obviously there's this need for some type of component that supports that. And so that was another way that we started to understand how important something might be.

Yeah, I think I covered this a little bit when I was screen sharing earlier, but we, we audited our site. We screenshotted, like, what was being used a ton. We definitely weighed up what component was taking a long time to maybe build or design so that we could create something that we can use repeatedly and not have to redesign every time. But ultimately it came down to what was going to have the biggest impact on us across the company. And I feel like we've chosen the right one and hopefully it's not all downhill from here.

Awesome. Well, thank you. Thank you all for those questions. For those of you who put questions in the chat, congratulations to Vanessa Cuevas. Vanessa, for you, get a signed copy of the book. Look for an email from us about that. We'll get some details from you and we'll get a book to you. To our panelists, Amazing, amazing answers. Malika, Aisha, David, thank you to all three of you. You all learned a ton in the cohort, but the cohort only goes so far. It's really what you do with it and how you apply that stuff. So, you know, part of the thing that I love about this panel is that even though you all learned the same thing, you applied it in such different ways, that was really unique to your teams, to your organizations, to your stakeholders. I think that's really the thing that hopefully everybody gets out of this, too, is, you know, your design system is going to look different than everybody else's, and that's okay. That's a good thing. And so hopefully, you know, hearing the stories and hearing the journeys from these three panelists, you can be encouraged in that and you can kind of be reinforced in that idea that, like, your design system has to serve your organization really well. And there's lots of different ways that it can do that. So for everybody listening, a round of applause in the chat, or, you know, even if you're. You're at your desk, round of applause, too. Thank you, Malika and Aisha and David. Such, such valuable info that you've shared. I can't thank you enough for this, for being here. So thank you for sharing that. In the couple of minutes that we have left, I'll just share a couple of things. For those of you who are interested in doing the cohort or something like it, I want to share with you some details of what's coming up. I'll just share my screen again here. All right, so you should all be seeing this now in front of my screen. The cohort that we did was design system in 90 days. So it's 12 weeks. It's 90 days of learning the 52 plays that I've identified as things that can help get a design system off the ground in a way that is unique to you. The next cohort is going to be running February 13th to May 14th. I'll sit on the slide for a little bit. If anybody wants to take a picture of the QR code or visit that URL, you can find more info there. So February 13th and May 14th is when the new cohort is running. Registration is going to open up in January. So if this is something that you and your team are interested in doing, we had a few people join as a single person and then reported back to their team what they learned in the cohort. We had a few that were joined that joined as a whole team, a multidisciplinary team. And so it's up to you what's better for you and what works out for your organization. But you can find more info there. The easiest way to find out info is to sign up for the mailing list. You'll get all of the info about pricing and dates and, and what to expect and outcomes and a convince your boss guide and all of that kind of stuff you'll get. The easiest way is through the mailing list. So sign up for the mailing list at this URL and we'll get you more info about that if you're interested in joining that next year. Last thing, thank you. Thank you. Thank you. Malika, Aisha, David, just such excellent work that you all did over the last couple of weeks, the last couple of months, I should say, with your teams. And the results really show. And thank you so much for sharing it with everybody here. It's just really wonderful. So I really appreciate it. Hope everybody learned some things as judging by the chat, everybody did. And if you like this, send us a note and let us know that we should do this again and we'll do it again in January. We'll bring up other panelists from the cohort and they'll share some of their stories of what they've learned, too, as well as other topics. All right, we're at the top of the hour. Thanks, everybody for being here. Enjoy the rest of your day and your weekend and the holidays. And hopefully we'll see you next month at the next event. Thanks, y'.

All.

See you soon.