In today's episode, we're talking about design systems with Anne Grundhofer. My name is Jonathan Cottrell and you're listening to Developer Tea. My job on the show is to provide you with the information and the insights, the interviews like today's episode that will help you become a better developer. And that's my entire goal on the show, to help you become a better developer and to get you interested in these higher level techniques of software development. Instead of just doing whatever it takes to get to the next job, I want you to start thinking about how you can make every minute more valuable than the last. That is a challenge that I want you to take on and that's what a design system can help you do. So we're going to be talking with Anne Grundhofer. Anne joined me at Squares. For a quick interview, she was a speaker at Squares as well. This is one of many interviews that I did at Squares. I hope you enjoy today's interview with Anne Grundhofer. So I'm here with Anne Grundhofer. Anne actually presented earlier today at Squares. Welcome to the show, Anne. Hey, thanks so much for having me. I'm excited to have you here. Excited that you're at the conference so I can have a chance to talk to you. I just spoke with some of the people you work with at Project 202. We talked about all the things that you're doing there. Can you give us a general idea of what your job is at Project 202? I am a senior UX designer at Project 202. I've been working there for about a year and a half now. One of my first projects that I was thrown into at Project 202 was a design system. That was for a global banking software client, which sounds super boring. But it was actually really fun. So that's kind of what got me into design systems. So I've been doing that was about a little over a year ago, where I first kind of got started with design systems on that project. And so when you entered this project, you have to evaluate the client at some level and then determine what are they currently using? How did that look when you first started on this project? Yeah, it was a mess. They had about 500 different pieces of software that they were using. Yeah, it was a lot of information to tackle. So going into that and especially it being one of my first design systems that I had to create, it was awesome because having to do a project like banking software that was so robust and data-driven, it's kind of like the... the largest piece, the kind of the biggest thing that you'll have to do. So it's a full project. Yeah, there was so much going on. It's not like you kind of are wrangling a mobile app design system or something. It was such a big... Which I was glad that that was, you know, kind of my biggest one because then I kind of became a pro at it. You know, you kind of have to wrangle the biggest one in order to kind of get good at it. So that was... It was really difficult, but all in all, it was probably the best project that I could have been staffed on. Sure. It's a comprehensive project, right? Exactly. Because you have, you know, I don't know how many thousands, plenty of thousands of users on the software. And it has to be represented in every environment. Exactly. Exactly. You're talking about every browser, every device. Yes, everything. In print, I assume, at some level. And also their internal software that they use as well. Sure, yeah. So their internal systems. So consumer-facing as well. As well as business-facing, so... For anybody who's been involved on a project of this size, you know that values end up being kind of the big driving, you know, stake in the ground. Right. And so I'd love to know, you know, what was that research experience like? Yeah. And then we'll talk about some more specifics of what, you know, how you take these values and distill them down into font sizes, right? Sure. But let's start with the... So, you know, when you're doing this research, how do you determine, you know, with the client or, you know, if you're building a product for yourself, how do you figure out what values are going to inform a design system? Yeah. So we obviously couldn't take in, you know, couldn't take into account every single tiny little piece of software that they did. So we kind of took their biggest pieces, like, you know, around 10 to 15 of their biggest pieces of software, and we kind of drilled it down. We identified the components with a checklist, figured out which ones we need to include. Because... You know, you really have to... You need to time box it a little bit. So a design system is huge, and you could do it for years and years and years and years if you wanted, especially with a large company like this. So we kind of time boxed, okay, so in, let's say, nine weeks, let's see how many patterns we can kind of come up with. And then do the component cut-up workshop that I kind of alluded to, where we cut up pieces of the interfaces on those 10 to 15 pieces of software. So you kind of have to narrow it down. And in terms of research, we actually went in, did some interviews with some of the designers and developers at the company to kind of see exactly what they wanted, what their biggest struggles were, what their common problems that they're always solving. So we kind of had to do that because the users of your system in a design system are truly the designers and the developers. Because they're the ones that are going to be pulling pieces, and they're the ones that we need to get buy-in from. Right. And also having them feel involved. And the process is huge. Because if they're not involved throughout the process, then they're not going to use it. So you have to make sure that they feel like they're being heard early, very, very early to get buy-in of the system. Sure. That's incredibly important. I think we talk about buy-in a lot at our company because for somebody to do truly good work, buy-in is kind of that key element. It is. It really is. You don't know it until you experience that feeling. Exactly. Exactly. You can say all day long, well, I'm going to do good work regardless. But the moment that you don't feel ownership over something, you start losing care. And it's kind of out of your hands. It is. Even if you wanted to, you can't. And especially as an outside company coming in and doing it for this company, a lot of the designers and developers were, oh, we don't need this. They didn't really understand a lot of it. So kind of going in and saying, hey, we're here to help. We're not here to kind of take any power away from you or ruin your creativity. This is actually going to save you time. It's going to save you money. And you're going to be able to focus on what you actually need to do, which is design or development. The user experience, you're not going to have to focus on creating new elements every single time you want to add that into an interface. Right. Yeah. That's so interesting because a developer, we often go through this feeling of not invented here syndrome. I'm sure you've heard of this. And having a team come in and consult. Right. Your future. Exactly. It probably feels intrusive. It does. And so it's difficult to come in. I'm sure that was one of the hardest parts. Yeah. Because you really have to toe the slime between this is ultimately going to be things that the end user is seeing. Exactly. So that's the priority. But your users of this thing you're building are developers. Yes, are within the company. Yeah. And so there's a balance between those two kind of opposing. Exactly. Or seemingly opposing. Exactly. So balancing both that and the end users. Because obviously the experience is about the end users. So the internal, the external, and the buy-in, and then the governance part was a really big piece. So you build this thing for this company and then you can't just build it and say, okay, well, here it is. Go with it. You have to, during this entire process, you have to be asking the questions of who's going to own this? Right. Who's maintaining this going forward? Because when we leave, we can't. It's your responsibility. Yeah. It's your responsibility. And we want to give them the tools and the knowledge to be able to keep this going after we're gone. Right. So having that, this person is going to be the one that's going to be maintaining the pull requests and updating it frequently and fixing bugs. So that's a huge piece within an organization to have that established beforehand. This happens on projects of all sizes. Yes. We have been developing these kinds of things for our agency, specifically for developers. And this is outside of the realm of UI, actually. This is more like in code style guidelines and that kind of thing. And anytime you're building a system like this, there's all of these different competing priorities that come into play. But then there's also what you're saying about governance, quite literally governing the implementation afterwards, knowing how much you're willing, like where is the line that you're going to draw, right? How much are you willing to flex on the rules that you created? Yes. If at all. Yeah. Typically, you know, the most successful projects allow some flex, right? Sure. Because the moment you cross that line and you fail, now you feel like it's okay to fail. Yes. You know, consistently. Yes. So instead of that, you have a way of saying, here's how you would implement an exception to the rule. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Exactly. Very interesting to know that that kind of governance stuff also would happen, you know, on the UI side. Yes. Entirely on the design side, brand guideline side. Yeah. So I think every project experiences that. Yeah. That's where the governance is really key because you can't have people creating those, you know, gotchas or those instances. And you're not going to really see those instances until you start implementing it. Right. Because, you know, you can't just predict that, you know, this is going to happen until you actually get into this. And so, you know, I think that's a great example of how you can do that. And I think that's a great example of how you can do that. And I think that's a great example of how you can do that. So having that one person that can be the, hey, yeah, do it this way. Or, yeah, you know what? That's a great exception. I'm going to add that into the system. Sure. Instead of having everyone say, oh, I'm just going to do it myself. And then it becomes just complete chaos. Right. Yeah. Yeah. Absolutely. So talking more specifically about the guidelines themselves and the system rather. Because we've mixed up words and I was speaking with Will before this. We're talking about design systems. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. And, you know, discussing the importance of language and how a design system is different from a brand guideline and how it's different from a pattern library and, you know, what pieces overlap and what pieces aren't encompassed by those things. So can you kind of explain what is a design system? Just kind of at a, you know, the elevator pitch. Yeah. And then what it isn't. What doesn't it cover? What doesn't it support? Okay. Okay. So a design system is a container for institutional knowledge. That's kind of the, the one sentence. You've said this before. Yeah. Maybe not. I don't think so. Yeah. So it is, what it's not is it's not a framework. It's not a prescriptive, you know, application template or something. It is not coupled to a framework or anything like that. It is, you know, in an ideal world when you would have what a pattern library or a style guide to me, you know, and these words are kind of interchangeable, interchangeable. So to me, a style guide is more. Just the UI patterns, just the design. Now a design system, when you have a system that is when the implementation piece comes in. Yeah. And then a print style guide, that's kind of like your brand guidelines where you have your logo and you know, your brand colors and a, a your web style guide actually might be different than that. For example, if your brand guideline color is, you know, a, a color that's not accessible and then your web guideline might be a little darker version of that color or something like that. Yeah. So they, they actually do have some variance. Um, and what, what it is, what it is not is it is not a framework. It is, um, it is really only a container for, for knowledge that design teams and, um, and development teams can go and grab, um, pieces as needed as they're making pieces for an interface. We're talking about design systems in today's episode. I want to take a quick break to talk to you about today's sponsor. In relation to design systems. Today's episode is sponsored by fuse. If you've been using your normal tool set to develop iPhone or Android apps, and if you've been a developer for long, you know that that tool set really hasn't changed drastically, maybe even in decades, right? So this is very similar to the way that we used to work before we had things like design systems, design systems, allow us to work smarter, to get more done with a given minute. And without sacrificing quality. And that's what fuse allows you to do. The smartest developers know that a lot of the time they spend writing code would be better spent elsewhere. And we like writing code as developers, but sometimes that, that time could be best spent thinking about other things, thinking about the application, thinking about the product rather than solving some technical issue. This is the case for the large majority of. iPhone and Android applications. Most of the work that you're doing to develop that application, really, you shouldn't have to write code. And that's exactly what fuse has proven with their tool. You can install it on Mac OS, or you can install it on windows and it's all in one. It's a single tool for both platforms and it creates native applications on both of these platforms. So go and check it out. Spec. FM slash fuse. Spec. FM slash fuse. I'd love for you guys to check it out. Thanks so much again to fuse for sponsoring. Today's episode of developer tee. I think a lot of people get this wrong, specifically around the idea of framework. I think a lot of people want to create, um, what, what amounts to, and this is, this may be going kind of against your, your, uh, uh, your metaphor about Legos, but they want to create like a big box of Legos that you can just grab and build whatever you want to with them. But the reality of that is you need to know the context that that particular piece was intended. For exactly. And that's where the guidelines come in. That's where you have to have a language around how to use these pieces, you know, and that, that gets even specific as to not only which buttons you use, it's the placement of the buttons, you know, primary buttons go here, secondary buttons go here. But if you have a large modal, they go here. If you have an even larger modal, they're positioned here, you know, you know, where does the text link go in, in that whole scenario? You know, it's very, very specific down to, you know, when to use them, how not to use them, you know, and, and that, and the guidelines actually was one of the hardest parts for me to kind of work with a copywriter to, to come up with. So as, as I was designing the UI components, um, I would write down specific reasons why I did things. Um, and now that's one of the big takeaways I think for my talk is that if you're doing this, make sure you're writing down as you go, because I sometimes wouldn't. And then it became time to work with the copywriter to write the guidelines. And I was like, oh man, that was like serious. Yeah. Yeah. Six weeks ago. Why did I do that again? I know I had a reason, you know? And so, and then I'll be like, oh, okay. So, so writing down every little thing, and even if it's just bullet points, because I myself am not a writer, you know, I, you know, I had to, I had worked with an amazing copywriter that took my tiny little bullets as to why and made it into beautiful, beautiful text. Um, but, but writing down those decisions because so many people are going to try and challenge why, you know, well, why is it that, why, why, why would you put that, you know, the padding? And the buttons to this, like, oh, well, because of this, or why did you make it this color? Oh, well, it's accessible. You know, why, why did you do certain design decisions? They're going to ask you, and that could be three years later, why they would, why they would ask you. Yeah. Um, so, so writing down that to have the guidelines is also just, it's, it's crucial to its success. It's very interesting how the, all of this is kind of lining up with what I was speaking with Will about. Yeah. Uh, we, we discussed, he's, he's also implementing a design system, uh, and the language is so interesting because, uh, the language he's using for, for guidelines is reason. So you have the rule and you have the reason, right? And the reason being, uh, a, a, a descriptor of the decision, right? Exactly. The, the point at which, and, and the justification of that point of decision making, right? It could just be that we like it. Yeah. But even if that's, if that's enough, then, then that's fine. Yeah. Um, I think that's so, that's so crucial. And, and a couple, a couple of other reasons we discussed was the idea that the guideline or the value that's driving these decisions is more important than the decisions themselves. Yes. So if you have a, a, if you have a decision that you can collaborate with and, and, you know, uh, uh, continue to evolve the design system to better follow the guidelines, right? The execution of that design system is ultimately going to evolve to be better. Yes. Yes. If you only have the end, like the, the end result, then you have nothing to better it with. Exactly. Other than individual opinions. Yeah. Right. And that's where, that's where the guidelines are so important because you can't just have the, the components and, and people, and you know, the users and the team just kind of grab them and use them however they want, because then it wouldn't, it wouldn't really do exactly what a design system kind of has in place. And so I think that, that, that's why reading the design, uh, guidelines and also having a section for design principles. Mm-hmm. So kind of why you even, you know, started the design as a company, you know, what, what's your voice and tone? How do you interact with users? You know, those, those, um, kind of separate, separated out from specific guidelines as well are also something that's really important. Sure. So, so I know I'm, I'm trying to play the questions in my mind of what listeners are going to be asking on, you know, about the subject. And there's so many questions to, to ask about this because it is kind of a dis, a disconnected, uh, disconnected. Uh, a concept from, from most people's current. Yeah. Right. Because, you know, we have the, the question of, okay, yes, uh, I understand that I need, I might need a design system, but how big should it be? How, how, how, uh, is it a global thing? Is it something that I can, you know, start small with? What is the easiest way to get this, to get my company to buy into this kind of thing? Um, uh, uh, you know, what, how do I start building one? Yeah. What are their tools that I need? What are their tools that I need to use? Or should I just make it in a design program or, you know, so let, let's start with one, maybe the easiest of those questions. It, uh, the, how do I know that my thing, whatever it is, my software or my, my, uh, company is large enough to justify something like this? Yeah, sure. So I think that any company that has even one product could, could use a design system. I mean, it's, if you have more than one designer working or more than one developer, working on something, I think that you could benefit from a design system. And it's also good to start small because no company is going to look at you in the face and say, yeah, we're probably not going to grow at all. You know, we're not going to, you're not going, we're not going to onboard any more designers. We're probably not going to have any more developers. I don't think that that's what anyone would actually say or, or want to say. Um, so I think that if you, um, even if you're, you're very small, you can have, uh, you can have different elements and that also helps with onboarding of other designers. You know, if you, you have, uh, you can bring on, another designer as you grow, then you can say, Hey, we have this, this design system already in place. Um, and if, if you suffer from visual regression bugs, you know, if you, um, you know, need, if, if you have things that are breaking in different places, um, I think that any company really would, would benefit from there. I mean, even if you just have some page templates that say, Hey, this is our checkout page, you know, things like that, that can be extended to, you're going to have some, some different versions of that checkout page. Here's the checkout page when you're done. You know, Yeah. Yeah. Here's when you're in the process, here's an error state on this form, you know, things like that are always going to be useful to really anyone. So let me ask you this. This is, this is a potential way of, of handling this. As a developer, I use something, I use CodePen. Um, it's possible that I could, uh, I could, I could take, and I'm thinking for the people who have small products, especially, I could take some of these elements, put them into a CodePen, take a screenshot and keep it in a Google doc even. Right. It's a very, it's a, it's not a, uh, it's not as comprehensive as, as maybe would be, you know, ideal, but I'm thinking, you know, what, what is the easiest way, the easiest barrier to entry to say, okay, now we have some documentation. Now let's evolve it into our own domain. Like let's make it a little bit more comprehensive now. Right. Right. And that's, that's kind of when you get into the full fledged system where you actually have a website that houses all of this. And, and, you know, when people see these, they think, God, that's going to be so, so much work. You know, we're never going to get there. Right. So I think that even starting small, just having them in sketch files or just having a repo on GitHub that you can just pull and say, you know, this is, this is our start. It's kind of primitive still. Um, you still have someone governing it. Right. Um, you still have someone, you know, making sure that the sketch file isn't getting updated without people, you know, other people's knowledge. Um, but I still think that even if you can start small, it's better than nothing. And I know that these websites that, that take a really long time to create with the guidelines and, and the, you know, all of the code snippets, I think that, that it is really intimidating at first, but you know, that's the ultimate goal. But, you know, in the interim, you can definitely start with, with small things and just run it like an open source project. Sure. And, uh, the cool thing is you can actually use your design system to create your design system. Yeah, exactly. That's true. You kind of have to, that's exactly right. When you start building the website, you're like, oh, okay, cool. I have this accordion pattern, you know, I have this, this tab pattern and these panels, and I know exactly the, the. The columns that are supposed to be in the grid and the, the break points, you know? So it's, it's, and it's a good way to test them as well. Right. Yeah. You start finding the edges. Exactly. And, and yeah. Yeah, edge cases. Uh, very cool. So I, I think that that kind of covers the, the, uh, the, the general idea that pretty much any, any project can, can use this. Um, and, and the level of investment that you put into it, it can be relative, right? Mm-hmm . It just, you, you don't have to, you know, go, uh, in, in, in, in, in, in, in, in, in, in, you're going to have to, you know, go, uh, and talk about every single edge case if it's a one page, you know, landing page for a weekend. Um, but certainly, uh, and this is something that I, I spoke with Brad Frost about, he said that even a landing page, you could reuse one day, right? So. Yeah. If you build some kind of system that governs some of the way that this thing was built, now, in the future, if you wanted to reiterate that same landing page, you can. You would already have it. You have everything available to you to do that. and there's very little loss associated with that. Exactly. Yeah, I think that's a really good point. Having page templates, I mean, in Brad Frost, he kind of talks about having the atoms, the molecules, and then you work out organisms and page templates. So even having that page template, you've already kind of built up to there. You know, you've already built the atoms and you know the colors, you know the font sizes, you know when to use these font sizes, what font you're actually using. So I think that you've already kind of built those atoms and you kind of already have that little design system in there. If you already have kind of a template, you can extract those out and then reuse them in other pieces of the site. Sure, yeah, absolutely makes sense. Well, Anne, thank you for being on the show. I have two questions I'd like to ask all of the guests on the show. The first question is, what do you wish more people would talk to you about, more people would ask you about? Ooh, what do I wish more people would ask me about? In terms of design systems, I think that one of the biggest questions that I don't think people ask is, how do you kind of manage multiple designers within your sketch files? Because I know that some sketch files have symbols and they're always coming out with updates with nested symbols. And sharing those symbols, however, through files instead of just artboards is actually something that I was dealing with back when I was doing this. So I think that I wish, I know that there are some tools that have tried to do that, but I don't think there are any tools that have tried to do that. So I think that I wish, I know that there are some tools that have tried to do that, but I don't think there are any tools that have tried to kind of wrangle symbols throughout actual files so that these pieces can be reused. So if you update your sketch file, how does it actually update other designers that are working on the system's sketch files? So there are some tools that I've been kind of playing around with, but none have been super successful. So I think that that's probably a question that I think that is really important, but isn't necessarily thought about a lot. Because with code, you can just push. You can push an update. Right, right. With designs, and I mean push and pull like any other open source project, but with design, it's a lot more difficult to update sketch files with, and then you end up sending to designers old, sending to developers older files that don't actually have the updates. So something that you don't really think about until you really get in there. Sure, yeah, yeah. That makes sense. And so if you see Anne at a conference, or something like that, then go and ask Anne about whether or not she's figured out the symbol problem. Yes, maybe by then I will have figured it out. Yeah, great. Exactly. So the other question that I ask every guest is, if you had 30 seconds to give advice to developers, developers of any background or experience level, what would you tell them? Ooh, that's a good one. Anything I would ask or I would tell developers, that are new developers or just general? Of any kind of experience level, yeah. Okay, I would say in terms of design system, don't get your feelings hurt too easily. That's a big piece is that they think, oh, well, this is what I have to use. This is now kind of all I'm going to be using. I can't figure out my logic anymore. A design system in terms of development is not to stifle your confidence. It's not to stifle your creativity or to kind of bore you with code snippets that you just have to kind of plug and play. So don't get offended or annoyed whenever a design system is implemented. It's actually going to allow you to focus on the more important implementation rather than kind of the boring stuff that's already been figured out. Sure, makes total sense. So developers, don't get your feelings hurt when things start changing. This is something we have to be comfortable with. Exactly. It's change. And making things better. And sometimes making things better is going to mean changing something that you think is already good, right? And that's a very difficult thing to come to terms with as a developer is I already like this. Why do you have to pull the rug out from under me? This is how we've always done it. Come on. I can't change. And this is a sense of safety and constant, you know, the ability to stay stable, right? And your users will, they will appreciate it. They will definitely appreciate it. You'll be able to roll things out faster. You'll be able to do your job faster. And, you know, because ultimately, I think that design and development, it's about building relationships between products and your users. So you're going to make them happy and you'll be happy in the end. Awesome. Thank you so much, Anne. Yeah, no problem. Thank you. Thank you again to Anne Grunhofer for joining me on the show, taking some time out of the busy schedule at Squares. Squares. Thank you so much for listening to me and for having me on the show. for joining me on the show. Thank you again to Anne Grunhofer for joining me on the show. Thank you so much for listening to me at the table there. Thank you again to Anne. Thank you so much for listening to today's episode of Developer Tea. With pretty much any podcasting app, you can subscribe so you don't miss out on future episodes. We put out three episodes a week, so it's very easy to forget and get way behind. You ultimately end up missing those episodes. So make sure you subscribe on whatever podcasting app you use. I've said it before. You may want to go into your settings and reduce the number of podcasts that you keep. Download it on your phone and it'll automatically clear out that cache as time goes on. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Fuse for sponsoring today's episode. If you are an iPhone or an Android developer and you've been using the same tool set for really the entire time that iPhone has even been around, then it's time for you to check out Fuse. It's an upgrade to your development system. It's going to allow you to write less code and more information. It's going to allow you to focus on the product a little bit more. Thank you again to Fuse. Thanks so much for listening and until next time, enjoy your tea.