Chelsea Otakan: Design and build systems, not just features

​ 

CJ: Welcome to Build and Learn. My name is CJ.

Colin: And I'm Colin. And today we are joined by Chelsea Otakan. Chelsea is a product designer and front end developer. She is also a self-proclaimed lover of design systems, writing code, red pandas, karaoke, and learning new things. Welcome to the show, Chelsea.

Chelsea: Hi. I do love all those things that has stayed the same.

Colin: So far on this show, we've talked a lot about software development mostly in terms of like programming languages and tools, culture, those kinds of things. If you're just joining us, you can go check those out in our show notes. But this week we wanted to kind of turn it on its head a little bit and dive into Chelsea's approach to designing and building things for the web. So if you've been listening to the show for a while we're gonna mix it up a little bit and yeah, we're excited to dig in.

Chelsea: Yeah, so I, I work at Lattice so if you're not familiar with Lattice, we build kinda like performance kind of software. So software to do performance reviews, feedback things like that at your company. I've been there for about a year. I joined last January. And before that I was working with CJ at Stripe. In terms of things that are relevant to me, I think the things you listed off were, are still my interests. But I feel like a lot has changed in my life since then. Mostly I have a one and a half year old. That keeps me very, very busy. Her name's Penny. Yeah, I got a snotty, little toddler to runaround after, so that's like a lot of my life lately.

CJ: Having kids changes perspectives so much. I remember yeah, it kind of, I, there's like also some research about like how it like literally changes the chemistry in your brain, even as like the non birthing parent, right? Like when you see the kid as a baby and they're like, you know, skin to skin or whatever, it just like changes everything. And so, yeah, not surprised to hear that some of those priorities have shifted a bit

Chelsea: Yeah. Yeah. It might be like above red pandas, but you

CJ: Okay.

Chelsea: the jury's out. Like it depends on the day.

CJ: Yeah,

Chelsea: day?

Colin: karaoke is just in there somewhere. It's so something that you can do,

Chelsea: We do together. Really? So, you know,

CJ: Nice. That's amazing.

Colin: get Penny into that early.

Chelsea: Yeah, I'm actually in my basement and our home karaoke setup is like over there,

CJ: Nice. I guess that's a good thing to start talking about. What is karaoke night?

Chelsea: Oh gosh, I forgot about I guess that's sort of kind of related to my story too. So background, I started off in design, but I'm not, I'm not, I don't have like a formal design background, so I didn't go to design school. I started making websites when I was like in high school. I was super into neo pets and a actually, as I progressed with my career, I found like many other people, like that's how they got into design or coding or tech in general is like some neo pets was somewhere in your path. And it was definitely in mine. And I was like into live journal and blogs and all that stuff. And so I'd been doing that for a while and then, I went to college and was like figuring out what I wanted to do. It was like maybe biology, but it wasn't really feeling right. And then I needed a job and so I like walked into what I thought was like the magazine office, but it was actually the newspaper office and someone was like, we need someone. We need another person on our website and let's like, wait here, I'll go get the, the guy that runs our website and it was Colin and he like, just gave me a job. I was like, whoa. Okay. And that's kind of was the first time I like, figured out that this was something people would pay you for and was like a career path. Kind of fast forward, sorry, I went roundabout. I was doing design for a while and I've always been sort of, sort of a technical designer, but never really progressed past, like copy and pasting a little bit of JavaScript and writing CSS and was starting to get more interested in programming. And then I, I work somewhere that. Sort of like paid for me to do a front end development. Like course it was through, I think it's called something else now, but it was through bloc.io. So I did this like self-paced course and they give you a mentor and I really just wanted to get over that hump of like, can I start. Like solving problems on my own without like just copy and pasting something and then vaguely editing code and like crossing my fingers. Like, can I actually read code and understand how it works and, and problem solve? And so that really helped me get over that hump and the like little karaoke night app, which never really launched. But that was sort of like my test project of like, okay. , they give you like structured projects, but can I make something up and then like and, and figure out how to work on it? And I think I got like 80% of the way there, but never really launched it. Like I got the shape of the app. I got like, like a single page app running and then I started trying to write scrapers for like music databases to try to like scrape the databases and, and put together lists and stuff. And so so yeah, I was just trying to find something that I like was really into at the time, and that was karaoke. So and if you've ever tried to use a karaoke app, it like the karaoke DJs like, download this app. They're really bad. They're like, so bad.

Colin: The best way to do side projects is to find something that you're passionate about and you're gonna spend more time than you would on anything else to figure it out because you, you want, you want it for yourself.

Chelsea: Yeah. Yeah.

CJ: Yeah, that was a, I was gonna say, that's like a, there's a couple like really interesting nuggets in that, in that backstory. Like one is build side projects cuz you'll learn stuff. But the other is that you didn't go to design school. So like if, yeah. I guess like, I'm curious if you were to restart today, would you recommend a certain design school? Do they have like boot camps for learning design or is this something that people usually kind of pick up on the side?

Chelsea: It's hard for me to say and I, I feel like I've. I've mentored a few designers and it's been tough for me to like, relate my experience cuz I think that the industry is just so different. I'm not saying I'm old, but it makes me feel old. . But like I, I mentored an intern at Stripe and she went to Carnegie Mellon and , you know, she was asking me questions about like, like what, in, like what internship did you, how did you decide where to do your internship? And I was like, I went to journalism school so that like we had to do internships, but like the way I did my internship was like, it was required, but I just took my job that I was do, like I had a part-time job at the museum and I just asked them to sign my in. Papers because like I already had a job that they were like paying me to do. And so I, I, I didn't go to like, I think today you like go to like Carnegie Mellon. They're like schools for product design. A lot of people go to, and then they had these like internship fairs, which I went to Grace Hopper one year and like saw the, they have like an internship fair hall. And that was just like, it blew my mind. It was like, like all these companies like Apple and Workday and, and they just had all these booths and endless stripe like I was there with them. We had the booth and it's just like these leagues of interns like interviewing like, like a hundred people in line to interview at Apple and they're just like standing in line and there's a guy at a counter like doing an inter a quick interview with them and they're like, next. And then like they just go to like 50 companies that day or whatever and try to get internships. In turn these companies are like, are like banging to like work here, like we want you to, and I did not have that experience like at all. So a part of it is like hard for me to say cuz I didn't go to design school. So I actually, I can't say what the value or not value of design school is. I feel like I can't really say what that is, but I think that. I think one of the values of my path and, and to maybe like, fill the gaps from earlier, like, I went, I went to work at the newspaper and then I decided to like join the J school which is the journalism school at UNR. And I, I would say the journalism school at UNR is more. does more broad communications. So there's like an advertising path. There's like print journalism, there's, so there's a few different paths. And I I didn't choose a path. I kind of decided to get a more general degree and then so I got to sort of like pick classes from any of the paths. And one of the classes was a design class and . Bonnie was a sort of like design professor who had joined the J school, I think in my, like, sophomore year of college. And so I just sort of like latched on to what he was doing. But I took her all the classes that she taught and then did a like, I forgot what it was called, but basically a, a like independent study. Me and another another designer who was in the J school, Kevin Jones, who I think you guys, you guys know, like me and Kevin were kind of like doing similar things when we were in college. So we did an independent study with Bonnie and just sort of like made stuff, well, like had few peers to make stuff and did, and she like kind of like made up projects for us and. and yeah, so I kind of like chose that path. And then and then I, while I was in college, I was also working like part-time design jobs, so I was contracting I worked at Twelve Horses with Colin again, sort of Colin got me like my first two jobs, so hey and like contracted around with different companies in Reno. And then I started doing like volunteer ui work with wordpress.org. And so my first job outta college was at WordPress. I kind of had started working within the community there and doing open source work and then got to know everybody there and, and got a job there. So that was, that was sort of how I landed my first job. So it's a atypical path, I think. But at the time, , the typical paths that I've learned exist. Like they weren't really there. I have a hard time giving advice on like how you would do it today. I just like, was like, how can I do more of this? Or when, you know, when I joined the newspaper and I was like really into, into doing web stuff and I was like, okay, how do I do more of this? Either in this job ended up working at Twelve Horses and so it was really like trying to evaluate like what do I wanna do more of? And then like, how do I just like keep going down that rabbit hole?

Colin: Yeah, the industry has definitely gotten more mature. I mean now we have boot camps for all like data scientists and design and all these things. But like, you know, thinking back like I was actually in the business school because I also couldn't really find, like, there was no program for people who were building for the web. And I ended up working with the J School as well cuz they were. They were kind of like a startup in that like newspapers were dying. They had to reinvent themselves, they had to be on that bleeding edge. And so you and I got exposure to web through that. There was a grad program that was like, Hey, we're playing with this thing Google released called the Google Maps API like, can you figure out how this works? And we were like doing like, like realtime news on a map, like with pins and stuff and like using the first version of the api. And I actually, they're. , we'll pay you for this. And it was like weird to be like, oh, I can get paid to code. And you're totally right. Like now there are those, these like paths you can follow and like little guideposts. Your website does a really good job of kind of doing a few things, showing some things that you've done over your career at different companies but then you also outlined some philosophies that you've clearly like developed over all of your time from you know, from the newspaper all the way since today. And so I thought it might be good for us to, to dig into some of those. And you, in fact, digging deep is, is one that you just mentioned. And, and one of the ones that you have up.

Chelsea: Is that really one that I wrote down? And then I just said it.

Colin: It is. Yeah. So we'll just skip to that one. So, so don't be afraid to dig deep.

Chelsea: I've wrote, I wrote these a while ago.

Colin: Yeah. I mean, where, where I'm at in my career. They're resonating with me very well, so I, I appreciate that they exist here. And we'll put a link to your website in the show notes, so you can also check out karaoke night and the cool designs that are on there for that. So,

Chelsea: It's all very dated content. Okay, everybody.

Colin: We can jump into the first one mostly because of this tweet that you also linked here, which is "Ship Quickly and Ship for the User" and the, tweet that you link to is building a skateboard, not a wheel.

Chelsea: Yeah. I, I feel like this has been, I think at the time I hadn't heard it in a lot of places, but now I hear, I hear this to like build a skateboard, not a wheel thing. And . I think at the time that I wrote this, I just, I had just come off working at a company where like you were just really, really like build fast, build fast, build fast. But the things we were putting out in the world were like not resonating. And I think it's because, I mean, in retrospect it was because we were putting things out that we're just like unfinished. They weren't whole product. They didn't provide like, a whole value set. We had sort of like, okay, here's the thing. We had sort of mapped out like, here's the product we think will provide value, and then we're gonna ship that part first, and then like this part over here, and then that part over there. We really prioritize that. I think in terms of like what would be the easiest versus what. , what is like an entire experience that would actually deliver value? So the like, I think a lot of people are familiar with this, but I can sort of like harp on it if there's anyone who's not like, but like if you wanna build a car, right? Your first version might look like a skateboard because someone can ride a skateboard and like get somewhere. The first version shouldn't look, shouldn't be a wheel because you can. If you have a wheel, you then still have to build like the rest of the car. Like it's not in itself valuable until you build something else with it. And so I think what I was trying to say, really. and you asked early if there's like any different philosophies and I think maybe I'll like add one and that one is like everything is a trade off. And I think this one is kind more trying to get it at at that is like to, if you wanna be fast and there's so much language about shipping quickly, and I think especially in early stage startups that is really critical, but you have to ship something whole. You can't just like ship a piece and expect people to know what to do with the piece. It's not their job to figure out what to do with it. It's your job to like show what value you bring with it. And so so yeah, I think that was like particularly something I was struggling with, like at, at the company I just worked at, which was feeling like, not like there, what we were aiming to build wasn't valuable, but that we weren't delivering like the right piece to show. We were just giving you like a wheel and saying like, you can get places with this, right? And like, no, we can't. And so like, like I think when you're, when you're thinking about iterative iter, like shipping product, iteratively, I think each iteration has to be like a whole thing that you can use. And thinking about that versus like, and, and balancing that with speed, I think.

CJ: Yeah. I think it's also kind of tricky to do because you, we hear all of this like harping on, oh, just do the MVP and ship your MVP and then get feedback and then iterate. But I think a lot of people take that as like, Just ship something that's incomplete and basic and then get feedback. But it's like, no, you've gotta like get a holistic picture. And maybe that means narrowing your scope to like a much, much tighter group of users that you're gonna solve for, but like solve something completely and perfectly for the, that, not necessarily perfectly, but solve it well for those users. And then start widening your scope to iterate and like pull in more and more users.

Chelsea: And I think something that happens in practice, like I think everybody always has the intention to do that, and we just forget about the like, , the V and the P in that term is like viable and product. Like you have to build a whole product and it has to be viable. It can't just be minimal . Like those other two letters are important. I think what happens a lot, like, at least what I've seen happen practically is that like , like people are scared to have to repeat work. So like, okay, if you build like the wheel, if you build a skateboard, those, I'm gonna keep going with the metaphor. If you build a skateboard, you can't use the same wheels in a car. Like it's a different thing. And so like, be like, okay, but we need to make this so it is usable when we make our big product. But I. Argue, and I feel like this is something that I've always also learned the hard way in design systems that like you actually at this point in the process, you don't know what people need out of the car. Like you don't know what kind of wheels they need. You don't know, like the reason you're building this skateboard is to figure out what they need. So you like assuming that you can predict what that product will look like, what that car will look like is , I think is just kind of like a, a fool's errand. And so like if you're trying to build car pieces to fit on a skateboard, it's not gonna work. And then like you. . Like you just have to admit that you're probably gonna have to rebuild this piece, but you'll do it with like a better knowledge of what it should be every time you do it. And so if you try to design the car without building the skateboard first, you just don't have enough information to know what it should be like. And so so I think that is something. at MVP stages, you just kind of have to let go of like you might throw all of this away and that's fine. Like that's okay. You should probably throw all of it away. If you haven't thrown most of it away by the time you're at car stage, then yikes.

Colin: What I like about this, and I'll put it in the show notes for sure, is that, you know the first one is you build a wheel. No one's happy. You build two wheels, no one's really happy. You build the body to put on top of the wheels. No one's still happy because. The car's not put together yet, but in the other one, it's like you've got a skateboard. That was something you can locomote on, you can move around. Then we're gonna add like a handlebar to get a scooter, and the scooter is the new product, the new iteration, and people can get around on that. And then you have a bike. And then we added a motor to the bike. And then we're like, oh, people actually wanna sit in a car with four wheels and the engine not between their legs.

Chelsea: Yeah, I I feel like the scooter to bike thing is like really important too, cuz you basically have to throw out all the parts. Like you're like none of these parts that we used before matter and like, you should totally be fine doing that.

CJ: I think, yeah, like all of that is actually kind of also about the second point, which is that design is continuous, right? I mean, the, the fact that your product isn't done until you've got you know, an actual. Product that is in someone's hands. And then you can figure out what's good and what's bad about that product. And then iterate, like after you ship something, figure out what's good and what's bad, and then make it better. I think that's another thing that I think we forget about is shipping something and being like, yay, we made a thing. And then, you know, never going back to see how it's doing in the world, but.

Chelsea: Yeah, I think My, my second job was at an agency and that's where I started like, I don't know, just feeling really hungry to understand how the stuff I was making was doing in the world. Cuz as most people know, like agency work, it's like you do it, client takes it, and then you don't really get to see what happens. And sometimes you have continuous clients, but at the time I didn't really, I didn't really have many of those and so I, I didn't know if I. getting better. Like, I think that was almost like a personal thing. Like, am I, is this better than anything that I've made before? Like I had an idea of like, taste wise, I, I think it's better, but like actual, like ux, usability wise, like I didn't, I didn't know if anything I was making was better than what I was doing before. And so I think that's sort of like how I landed in, in product design is just, really being able to live with the products that you create. And I think that's been like, design systems is an extreme of that cuz you both have to, you also have to use that product and you're like, oh, why did I do that? Like, yikes. And now everybody has to use it. Everybody you know is using this thing that you made and telling you what's wrong with it. And you're like, oh wow, it's a good crash course in like listening to your users. Cuz when you, your users are your coworkers, like they're gonna tell you

Colin: and you, in this case, you're talking about like a literal design system that you've implemented for your team to build with, right.

Chelsea: Yes. Yeah. So a design, like an internal design system for your company to build your product with. I feel like that's been the most, the, like fastest and most aggressive, aggressive isn't the right word, but just like like powerful feedback loop in terms of, of user feedback.

CJ: It also seems like a, a really powerful skill to have both like the design experience and being a front end engineer because you can sort of build these components. That then enable a product team to go out and build faster without having to think about, oh, you know, what, is the shading supposed to be on this input box? Or what color am I supposed to use for the call to action button versus the like secondary button or whatever. And so I'm curious too, I mean, we've got a, I mean the, the next bullet is, Design and build systems, not just features. And so maybe we can talk a little bit about like what you consider a design system and like what is in scope for design systems versus what is, I don't know, part of the brand and is there a like line between the two or, yeah, kind of like how, how do you see those things coming together?

Chelsea: Yeah, I, I feel like this is like something that design systems people nerd out. It's, this is the core question that design systems people are like, nobody understands us. Like what, where are the bounds of a design system? And like, what is a design system for and I would say the like primary. , the primary conceit of a design system is to provide like UI primitives to the rest of the company as like base building blocks. I think some people would say like, the goal of a design system is consistency. And I think I would say that like, a good if if you're building your design system. Well, a good side effect is consistency, but it's not necessarily the goal. I think the goal is like efficiency for designers and for engineers and also like alignment for designers and engineers. Cuz you're using the same, ideally the same set of building blocks. And so you can sort of have this like shared language. And the reason I make that distinction between like consistency being the goal is that like, I think. in the times where I've worked on a design systems team and we've made consistency, our goal, the scope of what we had to do was just impossible. Like, and I don't think it's a good system to have a design systems team, almost like in charge of. Decisions for individual products. It, it creates this like really big tension between product teams and designers and engineers on product teams and the design systems team. And ultimately, I feel, I think this is one of the most, the strongest opinions that I have, , is that. The team who are closest to the customers should be making most of the product decisions. And a design systems team is at least like two degrees removed from the customer. Like the product team hears from customers, they do the user research, they're like accountable to metrics that have to do with customer happiness. And the design systems team is accountable to those product teams. And so, , I should be able to ask questions, I think on like, Hey, do you really need to use like different style tabs here? Or is using the same style gonna be like better because it's consistent? But I don't think I should have like decision making power over, like, you may not use these kinds of tabs because maybe there's a really solid user choice for. That team is doing it. And like, what do I know? I don't build that product every day. And I think it's, it can be a little contentious when a design systems team takes more of that hard line stance because you don't have the context and and it's like quite disempowering and I think can sometimes lead to like, like a lowest common denominator. Thing for a user experience where like you're using all the same components and you've got like a baseline, like I think the floor, I forgot, I think Shopify wrote an article about this, but like, thinking of design systems as a quality elevator is important. Because like if you raise the floor, but like you limit the number of things people can do, so you're never raising the ceiling. You're like lowering the ceiling. You become more of a, they described it as like a trash compactor is what they were seeing. And so you need to. Like agency for those individual teams and designers to like, explore and, and drive solutions that are like specific to their use cases, but give them a baseline where like if I, I don't, I shouldn't have to refigure out the tab design like, so I'm gonna fall back on that. I can but if I really need to like drive this new pattern because it's good for my customers, I should need to ask design systems like for permission.

CJ: it almost seems like you could, you could technically implement almost every single web application with just like a text input box. So if you're a home and you're trying to like listen and think about what like this design system might look like, imagine starting with you're only allowed to use text boxes and that's it, But like maybe your design system makes like the most badass text box you've ever seen. It's got like crazy shades and like, you know, these fancy borders and things. What you, what the customer really needs is a date picker. But like you're making them enter in some date that's slowing them down and like making their user experience worse. But like you've got a really sexy text box. It just happens to not actually solve the user's need. And so, yeah, I think I, yeah, one of the things that comes to mind too is like why not just use an off the shelf design system? For a long time used Bootstrap, and I feel like all the websites on the internet from like 2012 to like 20, I don't know, 19. Were all basically look the same. And now I'm using Tailwind ui, which like, are these design systems, how do you see these like sort of UI frameworks fitting into like that role? And, I don't know, is it like bad that people are using those or Yeah. What, what are your thoughts? Off the shelf.

Chelsea: I don't think it's bad. The latice design systems actually use a chakra under the hood, so uses chakra UI under the hood. I like that those things exist. One, because they're like a public reference. Two, because it's very clear that there's like, a set of components that like literally every company needs that Like there's just a baseline set in like how you're gonna start off with your design system. So why are we inde independently rebuilding them like at every single company? Like text boxes, inputs, buttons, tabs, redo buttons. Like the set of pro, probably like 30 components that like every, everybody. kind of needs. And so it does seem silly that we're like building them all independently. And it makes sense to have like a core to start. So I like that these things exist. I do think that, I think Rune Metson kind of talked a little bit about this, that like, I, I think like he felt like there was a, there's like a sameness about the web that design systems. I think his design systems is kind of like driving, and I think he takes the word design system slightly differently. It's like designing with a system. So like he'll create these like graphic and visual systems and like generative art or like generative ways to build things that are like somewhat unique. I think I take a little, a slightly more practical stance, which is. largely, I think the things people wanna do the web are like roughly the same . Like they're not. It's just like you need to like tipity type your text into something and like see it somewhere else and you need to click this thing and like have something like calculate. And so I think the fact that we have like patterns for that are make sense. And I, I like that. Something that, like having a few big design systems and pattern libraries does it, like, it really identifies like, which things are almost like canon, like so many people have done them. They're obviously a thing that like everybody uses and there's, and, and we can collectively like build best like a baseline of best practices around them. But again, like the other example is like, but someone could take that and like take the baseline of that and put it in a completely different direction, very specifically to what they need. Like maybe I need a carousel, but like, okay, I'll take this base carousel and it works kind of like a carousel, but I wanna make it go a bunch of different directions for some reason. Like that would work for me. . And so I think it's almost like, when you're like an artist, like you have to learn how to paint, like everybody learns how to paint and then you can start breaking the rules. I feel like a lot of these design systems just kind of like put down with the, like what are the core skills and then like give you an idea of where you. start breaking the rules. So generally I think they're also pretty good and pretty amazing. Like, I think it's having worked at a company where, like Stripe was when I left like 6,000 people and right now Latice is like a couple of hundred and earlier in my career I was like, I was working more at like 50 10 person companies, like the difficulty level in creating a system that works for a 6,000 person company. It was like quite different. Like just even like figuring out what scope you needed to sit at and like how specific you wanted to get with your patterns. So the idea that like, like Tailwind and bootstrap created things that work for like entire industries is just like really impressive.

Colin: Is there a point to that point, like at which you would recommend someone sit down and design. Or come up with their own design system. Like if you're a four person startup, it's probably not your main directive to go build your perfect design system. Right? But is there, you know, is it 10, is it 20? What, what point do you think it starts to make sense where that, that is important or, or does it, you know, it does. It depend.

Chelsea: Yeah, I don't think I have like a strong opinion on like a specific point, but maybe I can tell a story of trying to do it at like a 10 person company and then deciding that like it was probably stupid . I was, so when I was at Source Graph, I was like, okay, I'm gonna like put together a design system. And I had worked at Change.org where we like had one , that company was like a hundred people and I had like, contributed to it, but I didn't like create it and I wasn't there when, when they created it. And so I started with a baseline set of components and kind of like made a little website and, and people were like, cool. Yay. And then as folks started using it, like literally only 10 people. It was just like, why does this work this way? I'm like, oh yeah, okay, so maybe this should work a different way. And that's where I really learned like how when you have a design system that people are using, you have a product that you're now supporting. And when you have this product that you're supporting, you better have time to support it. And, and like I think design systems creates a lot of efficiencies at scale. But at that size it just was like, you know, you need to take time to support it. You need to take feedback. I think that's even where I really learned like like any API change you make to a component is like very important to like get right when you're putting it in the, because once people are using it, changing it is then like really hard. I mean, it depends on the API change, but like, it's one of those things where like it's a type two decision. It's a hard to reverse decision. So when you are ready to make it, you better be ready to make it. It wasn't quite that type two E at a small company, but again, it created like. Work for me to maintain, to develop, to support. And at, oh, like 5, 6, 5, what became like a 10 person company. She's like, I had other stuff to do and it wasn't creating, it was creating some efficiency, but like between 10 people, just like not enough that it made sense for me to also be spending like 20, 30% of my time like answering people's questions. And I was like, so I, I think at that stage, It's like more helpful just to communicate more, to align, and then at some point, like the communication gets so hard, you should create systems around it. And I think those systems should probably like scale with like, like how much efficiency is it creating versus how much work is, is it to maintain and support.

Colin: Right, and you mentioned having a design system team, which I imagined like a 6,000 person org would have, whereas a 10 person org just know what you're signing up for if you're gonna bring it into the world.

CJ: I was gonna ask, so. It sounds like maintaining a design system inside of a small company is as if you're an open source maintainer of a popular library, and you're all by yourself, , and you're still having to Yeah. Respond to all these changes and making. Product decisions about the design system so that it is customizable, flexible, and can expand into all of the needs that might arise in the future, which can be really tricky and I think it actually takes like a sort of different mindset to maintain a library that people are then gonna use to build other software because you have to think about all the different ways that it might be used and cover all those different edge cases instead of just being like, oh, here's how I would use it to build X, Y, and z. So, yeah, definitely sounds challenging.

Chelsea: Yeah. I, I think the open source Comparison. It's one I make a lot and I think it's like spot on. Like working on a design system is more like working on an open source library than it is like working on a product. And I think that like sometimes. At least in my experience, like often I think the company expects the design systems team to work more like a product team. It's like, are you gonna ship, like shipping more components is the goal. And I, that's a goal that I often I'm like, that's actually not the goal. Like the first goal should be that all our components are like solid. We take our components that people are using the most and make sure that they are like extendable accessible, that they're like super high quality. Before we expand our surface area of the things that we make. Cuz like you, if you ship 10 components and you ship them all with an api, that doesn't work for anyone. And then peop that doesn't work well or is extendable and then a lot of people use them and then you figure that out later. Your job now to fix those is like a hundred times harder than it was before you started. And so I think that like, like. because you need to sort of like predict this large set of use cases and you also have to have to accept that there are gonna be use cases you can't possibly predict. You have to be ready to deal with the network effects. of making it available. Cuz as soon, at least this was true at Stripe, like, because a lot of people use the design system, as soon as you dropped a new component in there, people would start using it. And once they started using it, you had to be responsible for how you were gonna change it. And we later like figured out, you know, like versioning and, and Penny. And that's in itself is its own like, you know, you have to manage. versions, people are on, recommend, choose what you're gonna support, all those things. But we did have a situation where like there was a pattern that someone wanted to contribute. And it had the potential to be used in a few use cases and some designers were trying it out. And we had a lot of pushback. We didn't wanna pull it into the design system until we sort of like had more time and validation that this was a pattern we wanted to propagate. but we got a lot of pushback and, and like, they're like, well, we don't wanna build this a bunch of times, so just put it in the design system. And so we did it. And then a couple months later, one of the products that was using it did user testing and found out it was just like horrible. Like, it, it did not test well, like people did not know how to use it. It was confusing and was causing some like bad effects and actually some other products. But because we put in the design system, like four other products, were already using it. And so at that point, You know, you don't just have to be like, okay, we're, it's not even like we are changing the pattern and updating it to, for everyone. It's like this entire design pattern should not be used. And now we have like, We have to, I mean, we don't have the power to make people do this, but like a thing we have to do is just like, Hey, we don't recommend you use this pattern from it. Like you should redesign this in your product. And like, I don't know, teams are like up in the air whether they have time to do that. So you, you kind of have to be ready to be responsible for everything you put out as well. Like if it's bad, it's gonna propagate. If it's good, it's gonna propagate. And so you have to, yeah, you have to account for all. you know, network effects.

Colin: It sounds like if something makes it into the design system, it's like a design seal of approval and then people are like, well, I'm gonna use this thing that you said I should use, and then it gets propagated and you know, you have to have, it sounds like a design system designer. Engineers, product people who are working on that have to think about the end user, but then also the developer experience too. Like yeah, it's a what a time to be alive on the internet for sure.

Chelsea: I'm generally in favor of like experimentation and seeing what happens, but also if it's not working, it's not working. . But yeah, I think that like, like. The comp of, like the skateboard and wheel situation also applies to design systems. And I think it's one of the reasons why like often people are like, I think we have this pattern. I think it'll work for a lot of use cases. So I wanna put it in the design system. And my first instinct is be like, let's wait. Like let's, why don't you guys use it for a while and maybe another product might copy. and yeah, that's some duplication of work and they'll use it. And then we have so much more information, in those two cases about how we should design the API design, the component, which pieces we should bring in just in like two cases that when we bring into the design system. I guess the comp would be, I think we at least wanna get to bike stage of something, of a component before we bring it into the design. Like all the skateboards and scooters and shit, they should be like in the product, but like we should at least be a bike by time we get the design system.

Colin: Oh my God, I love that so much.

CJ: It, it also like kind of rounds out your philosophy here, your last one of critique early and often and with everyone it's like, yeah, critique and make sure this is gonna work before it actually ends up in, in the system. But also just like generally probably seems like a good way to learn and improve. But yeah, I would love to hear maybe like tactically how you go about seeing if something is working or not working in the design system. I think it was, yeah, it was like nice to hear about your experience at the agency and how sometimes you'd work on a client project and then it's kind of like throwing it over the wall and being like, I don't know how well that did. So yeah. What has your experience been recently and maybe what can we learn about how to yeah. Critique and improve our.

Chelsea: Yeah. I, well, like from a design, design design standpoint I. I think I've gone back on this one a little bit in that like, it really depends on who you are and your personality. I think I've I'm like pretty outgoing and so I'm pretty comfortable like talking to anybody about feedback and like critiquing with like, With engineers, with designers at any stage in the process and being able to like say like, actually that's not relevant. Like just like sort through all the crap like on the fly. I think I'm someone who like thinks through speaking a lot, so that's like helpful in critique situations. I have now worked with a lot of like more different styles of people and I think there are people who just. Need that time away. And so if you, if you're critiquing like all the time, if you like, and I have these phases too personally, where like, , I need to think in private. And I think there's people I've worked with who are like brilliant that like they work best when they have that time to think in private and process. And so I think I've shifted a little bit and like, why doesn't everybody share all the time? Like even if it's messy, even if it's nothing even, and I'm like, oh, that just like doesn't work for everybody. but it works for me. But to get at your question, which is like, how do you figure out if something's working or. If you have a Slack channel, you figure out pretty quickly, cuz everybody complains like immediately. So, like I said, that like if you're working on a design system internally, that feedback like, like if it's adopted, I think there's different stages where like some people are like working on adoption, so they have to do a lot more advocacy. Most of my experience has been starting. On a design system that is like, already in place, at least to a certain extent, and then like, like working on the things that it, that are already in use. And so when you're at that stage you get the feedback like pretty constantly and immediately , it's like, what's wrong? And so I feel like the, the challenge. For me has mostly been how to prioritize because you get like such a big volume and everything feels important because everything is scaled up. And so it's been like a struggle for me actually. Personally having like a, like a medium, ADD spectrum kind of brain is like, that's important and that's important and that's important and that's important. And then like having a hard time, like really getting to focus on any one thing. And so I think a lot of, at that stage for a lot of design systems, it challenges prioritization. It's like you have so many things that you could be doing because nothing is ever perfect because it doesn't work for everybody. And so I think you really have to figure out like what what individual change will have the most the most impact. For your first line users, so your, your internal users, engineers, and designers. Like, like if I were to work on one component, how would that change the lives and efficiency of designers and engineers? And then you also have to think about the second order impact. So how is that gonna affect users and I think often those things are in line where like if you make something easy to implement and it is the right pattern, more people will use the easy thing. So if it's also the right thing, then that gets to users. So often they're in line, but it doesn't always feel like it. And sometimes you really have to like bend your brain to figure out, you know, where the effects are because the, the effect is also like slow. So the feedback is fast. But the seeing it like, like if you introduce a new pattern that you think is good, you have to wait quite a while for like, engineers to use it for then to make its way to users for then you to collect feedback on how users are reacting to it. Like it doesn't, it doesn't, it happens pretty slowly. So like a side effect of that is actually that, like, I think the, like quarterly like reviews and evaluations and goal setting and OKRs have been tough for me personally in design systems because often the. Metrics change in usage or the the, like, the feedback from users doesn't happen in the same quarter that you do the work.

CJ: Mm-hmm.

Chelsea: And so that's been a challenge.

CJ: I wonder if like a shortcut that I've seen? Oh, a shortcut that I've seen recently is people just like designing something in like Figma or Sketch or whatever, and then jumping on user calls and showing them pictures like it doesn't actually work yet, or it might sort of work, and then trying to get early, early feedback like that. But yeah, I, I totally. Understand that like the long term, long tail seems like it would be sort of exhausting and very different from like that really quick iterative feedback loop that you want. Like when building stuff on the web, it's like, oh, I, I made a change and next js just refresh my browser over there. So

Chelsea: Yeah. Yeah, I think like in product that works really well. I'm actually like in the middle of doing that right now. I have like these really early wire frames, so I'm like talking to users. I'm like, this is, this is a mess. So like it's fine. Just tell us everything like just no judgment, like this are just rough ideas. Trying to understand the flow and mental model and just showing those. I think for design systems, there's so many, like there's how it looks. , there's how it works for a user and there's the developer experience that often I think those things are like, sometimes there's so many things you have to get feedback on. We started this process at Lattice that I think has actually worked pretty well. It's not super fast, but like I basically put together a a design doc which, you know, means one thing to engineers and a different thing to designers, but it's like one doc that does both of those things. So, articulating like what the API of this thing will be, what the, and then like showing mockups of like what the actual like spec of the component will be, and then sending that round to like, all of the product teams and all of the designers and saying like, this is how we're gonna build this. And, and having like a period of, of like an like request for comment sort of period. And that's, that's worked pretty well. So like before we roll out a, a big system change, like put together one of these design docs and just like tell all the teams, here's what we're thinking about, what should, like, are we missing anything? And then giving them an idea of how we're gonna roll.

Colin: Awesome. Well, I think that's a great place to wrap things up. We can leave our listeners wanting some more. They can head over to check chexee.me. We'll put that in the show notes. So you can check out where you can find Chelsea and all of her work. Maybe she'll add some more philosophies as she develops them in her future roles. And yeah. Thanks so much for hanging out Chelsea.

Chelsea: Cool. Thanks for having me.

CJ: Yeah, thanks ton, Chelsea. You can find the show notes and all of the links to the resources at buildandlearn.dev. Thanks so much for listening, and we'll see you next time.

Colin: Bye friends.