And today's episode we're talking about design systems with Anne Grundhoefer. My name is Jonathan Cutrell 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 Grundhoefer and 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 Grundhoefer. So I'm here with Anne Grundhoefer and 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 and we talked about all the things that you're doing there. Can you give it just a general idea of what your job is at Project 202? Yes. So I am a senior UX designer at Project 202 and I've been working there for about a year and a half now. And one of my first projects that I was kind of thrown into at Project 202 was a design system and 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 was 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 largest piece, the kind of the biggest thing that you'll have to do. So it's a full project. Yeah, so 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 kind of my biggest one because then I kind of became a pro at it. You kind of have to do wrangle the biggest one in order to kind of get good at it. So it was really difficult but all in all it was probably the best projects that I could have been a safton. Sure, it's a comprehensive project. Exactly. Because you have, I don't know how many thousands, plenty of thousands of users on the software where it has to be representative in every environment. Exactly. Talking about every browser, every device, every print, I assume. And also their internal software that they use as well. Sure. So their internal systems is so consumer facing as well as business facing. 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, staking the ground. 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 it, you know, how you take these values and distill them down into font sizes. Sure. But let's start with this research. How do you determine, you know, with a 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, you know, couldn't take into account every single tiny little piece of software that they did. So we kind of took their, 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, you need to time box it a little bit. So design system is huge and you could do it for years and 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 interface is 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, what their common problems that they're always solving. So we kind of had to, 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. And also having them fuel involved in 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, you have to make sure that they feel like they're being heard, you know, early, very, very early to get buy-in of the system. Sure, that's an incredible important. I think, you know, 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. It is. It really is. You don't know it until you experience it. 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 someone, you start losing care and it's kind of out of your hands, even if you wanted to. And especially as an outside company coming in and doing it for this company, you know, they, a lot of the designers and developers, but oh, you know, we don't need this. They didn't really understand a lot of it. So kind of going in and, you know, saying, hey, we're here to help or not here too, kind of, you know, take any power away from you or ruin your creativity. You know, 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. You know, 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, you know, 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 on. You're a future. Exactly. Because if it probably feels intrusive, right? It does. So it's difficult to come in. I'm sure that's, that was one of the hardest parts. And so, you know, because you really have to tow this line 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 within the company. And so there's balance between those two kind of opposing or seemingly opposing. Exactly. So, you're building both that and the end users, you know, 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 know, you build this thing for this company and then, you know, you, you, you can't just build it and say, okay, well, here it is. Go with it. You know, you have to, during this entire process, you have to be asking the questions of who's going to own this, you know, who's maintaining this going forward because when we leave, you know, you, we can't, yeah, it's your responsibility. And, you know, we want to give them the tools and then the knowledge to be able to keep this going after we're gone. Right. So, having that, you know, this person is going to be the one that's going to be maintaining the pull requests and updating it frequently and fixing bugs. Right. So, that's a, that's a huge piece with an organization to have that established beforehand. You know, since this happens on projects of all sizes, we have been developing these kinds of things for our agency, specifically for developers. So, and this is outside of the, the realm of UI, actually, this is more like encode style guidelines and everything. And anytime you're building a system like this, you know, there's, there's all of these, 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? Because the moment you cross that line and you fail, now you feel like it's okay to fail. Yes. So, instead of that, you have a way of saying, here's how you, here's how you would implement an exception to the rule. Exactly. So it's 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, bring, bring guidelines side. Yeah. So I think every project experience. Yeah, that's where the governance is really key because you can't have, 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 the software. 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. Yeah. Instead of having everyone say, well, I'm just going to do it myself and then it becomes just completely awesome. Right. Yeah. Absolutely. But talking more specifically about the guidelines themselves and the system rather. Yeah. Because we've mixed up words and I was speaking with Will before this. We're talking about design systems 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 are 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 and then what it isn't, what doesn't that cover, what doesn't that support? Okay. So a design system is a container for institutional knowledge that's kind of the, the so incentive to set this before it is. 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, in these words are kind of interchangeable to 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. And in 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 color that's not accessible and then your web guideline might be a little darker version of that color or something like that. So they actually do have some variance. And what it is, what it is not is it is not a framework. It is, it is really only a container for, for knowledge that design teams and development teams can go and grab 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 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. 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. Respect out of Fuse, respect out of Fuse and love for you guys to check it out. Thanks so much again to Fuse for sponsoring today's episode of Developer Tea. I think a lot of people get this wrong, specifically around the idea of framework. I think a lot of people want to create what amounts to, and this is, this may be going kind of against your, your metaphor about Legos, but they want to create like a big box of Legos. Yeah. So you can 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 language around how to use these pieces. And that gets even specific as to not only which buttons you use, it's the placement of the buttons. The primary buttons go here, secondary buttons go here. But if you have a large modal, they go here. If you haven't even larger modal, they're positioned here. Where does the text link go in that whole scenario? It's very, very specific down to when to use them, how not to use them. And the guidelines actually was one of the hardest parts for me to kind of work with a copy writer to come up with. So as I was designing the UI components, I would write down specific reasons why I did things. And now that's one of the big takeaways I think for my talk is that if you're doing this, be sure you're writing down as you go because I sometimes wouldn't. And then it became time to work with the copy writer to write the guidelines. And I was like, oh man, I was like six weeks ago. Why did I do that again? I know I had a reason. And then I'll be like, oh, okay. So writing down every little thing, even if it's just bullet points because I myself am not a writer. I had worked with an amazing copy writer that took my tiny little bullets. It was just a Y and made it into beautiful, beautiful text. But writing down those decisions because so many people are going to try and challenge why, you know, 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 don't you do certain design decisions? They're going to ask you. And that could be three years later why they would ask you. So writing down that to have the guidelines is also just, it's crucial to success. It's very interesting how all of this is kind of lining up with what I was speaking with Will. Yeah. We discussed, he's also implementing a design system. And the language is so interesting because the language he's using for guidelines is reason. So you have the rule and you have the reason. And the reason being a descriptor of the decision. Yeah. The point at which and the justification of that point of decision, right, it could just be that we like it. But even if that's enough, then that's fine. I think that's so that's so crucial. And 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. So if you have a decision that you can collaborate with and 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 end result, then you have nothing to better it with. Exactly. Other than individual opinions. Yeah. And that's where the guidelines are so important because you can't just have the components and the users and the team just kind of grab them and use them however they want because then it wouldn't really do exactly what a design system kind of has in place. And so I think that that's why reading the design guidelines and also having a section for design principles. So kind of why you even started the design as a company. What's your voice and tone? How do you interact with users? Those kind of separate separated out from specific guidelines as well are also something that's really important. Sure. So I know I'm trying to play the questions in my mind of what listeners are going to be asking about the subject. And there's so many questions to ask about this because it is kind of a disconnected concept from most people's current. Because we have the question of, okay, yes, I understand that I might need a design system but how big should it be? How is it a global thing? Is it something that I can start small with? What is the easiest way to get my company to buy into this kind of thing? How do I start building one? Are there tools that I need to use or should I just make it in a design program? Or, you know, so let's start with maybe the easiest of those questions. How do I know that my thing, whatever it is, my software or my company is large enough to justify something like this? Yeah, sure. So I think that any company that has even one product could use a design system. I mean, 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 know, 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 want to say. So I think that if you, even if you're very small, you can have different elements and that also helps with onboarding of other designers. You know, if you have, you can bring on another designer as you grow, then you can say, hey, we have this design system already in place. And if you suffer from visual regression bugs, you know, if you, you know, need, if you have things that are breaking in different places, I think that any company really 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, 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 a potential way of handling this. As a developer, I use something, I use code pen. It's possible that 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 code pen, take a screenshot, and keep it in a Google Doc even, right? It's a very, it's a, it's not as comprehensive as maybe would be, you know, ideal, but I'm thinking, you know, what is the easiest way that 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. That's kind of when you get into the full-fledged system where you actually have a website that houses all of this. And, you know, when people see these, they think, God, that's going to be so much work. You know, we're never going to get there. 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. You still have someone governing it. Right. You still have someone, you know, making sure that the sketch file isn't getting updated without people, you know, other people's knowledge. But I still think that even if you can start small, it's better than nothing. And I know that these websites that take a really long time to create with the guidelines and all of the code snippets, I think 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 small things and just run it like an open source project. Sure. And the cool thing is you can actually use your design system to create your design system. Yeah, exactly. That's kind of a... Yeah, that's exactly right. When you start building the website, you're like, okay, cool. I have this accordion batter. You know, I have this tab pattern and these panels. And I know exactly the columns that are supposed to be in the grid and they're the break points, you know. Sure. And it's a good way to test them as well. Right. Yeah. You start finding the edges and the edge cases. Exactly. Yeah. Yeah. Very cool. So, I think that that kind of covers the general idea that pretty much any projects can use this. And the level of investment that you put into it can be relative, right? It just... You don't have to go and talk about every single edge case if it's a one-page landing page for a weekend. But certainly, and this is something that I spoke with Brad Frost about. He said that even a landing page, you could reuse one day. Right. Yeah. And the other 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 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, you know, he kind of talks about having the atoms, the molecules, and then you work at organisms and page templates. So even having that page template, you've already kind of built up to there. You've already built the atoms and you know the colors, the font sizes. When do you 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, and 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 about? More people would ask you about. Ooh, 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 our boards 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 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 systems for the 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 know, you can push an update with designs and I mean, push and pull with within 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, or some easy developers, older files that don't actually have the updates. So something that you don't really think about and so you get really good in there. Sure. Yeah. That makes sense. And so if you see in at a conference or something like that, then go and ask in about whether or not she figured out the symbol problem. Yes, maybe by then I will have figured it out. Yeah. Great. So the other question that I ask every guest is if you have 30 seconds to give advice to developers, developers of any background or experience level, what would you tell them? Ooh, that is a good one. Anything I would ask or I would tell Developer That are new new developers or just anyone of any kind of experience level. Okay, I would say in terms of design system, don't get your feelings hurt too easily. That's the 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. It's a design system in terms of development is not to stifle your creativity or to kind of bore you with code snippets that you just have to plug and play. So don't get offended or annoyed that 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 changing and making things better and sometimes making things better is going to mean changing something that you think is already good. 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? Exactly. This is how we've always done it. Come on. I can't change. This is a sense of safety and constant. The ability to stay stable. Your users will appreciate it. They will definitely appreciate you'll be able to roll things out faster. You'll be able to do your job faster because ultimately I think that design and development, it's about building relationships between products and your users. You're going to make them happy and you'll be happy in the end. Awesome. Thank you so much, Anne. No problem. Thank you. Thank you again to Anne Grundhoefer for joining me on the show, taking some time out of the busy schedule at Squares this year to talk to me at the table there. Thank you again, 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 and 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 downloaded on your phone and it will 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 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.