In this thought leadership podcast, projekt202 Senior UX Designer Anne Grundhoefer discusses best practices, challenges and lessons learned in creating and maintaining effective interface design systems.
The Developer Tea podcast is created by Whiteboard CTO Jonathan Cutrell, and we thank him for the opportunity to share this interview.
Following is a transcript of the Developer Tea podcast featuring Anne Grundhoefer and host Jonathan Cutrell:
Jonathan: In 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 this 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 this 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 the challenge that I want you to take on, and that's what a design system can help you do.
We're going to be talking with Anne Grundhoefer. Anne joined me at Squares [Conference, the annual gathering of tech professionals in design, UX, front-end, development, and products] 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. Anne actually presented earlier today at Squares. Welcome to the show, Anne.
Anne: Hey, thanks so much for having me.
I'm excited to have you here, excited that you were at the conference so I could have a chance to talk to you. I just spoke with some of the people you work with at projekt202 and we talked about all the things that you're doing there. Can you kind of give just a general idea what your job is at projekt202?
Yes. So I am a senior UX designer at projekt202. 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 projekt202 was a design system and that was for a global banking software client, which sounds super boring, but it was actually really fun. That's kind of what got me into design systems. I've been doing ... That was about a little over a year ago where I first got started with design systems on that project.
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, there ... It was a mess. They had about 500 different pieces of software that they were using. 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.
It's a full project?
So there's a lot going on.
Yeah, there was so much going on. It's not like you kind of are wrangling a mobile app design system or something. 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 wrangle the biggest ones in order to kind of get good at it. 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.
Because you have I don't know how many thousands, plenty of thousands, of users on the software, and it has to be represented in every environment.
I'm talking about every browser, every device.
Imprint, I assume at some level.
And also their internal software that they use as well. So their internal systems, 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 stake in the ground. I'd love to know what was that research experience like, and then we'll talk about some more specifics of what it, how you take these values and distill them down into font sizes. But let's start with this research. How do you determine with a client, or if you're building a product for yourself, how do you figure out what values are going to inform a design system?
Yeah. We obviously couldn't take into account every single tiny little piece of software that they did, so we kind of took their biggest pieces, like around 10, 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 really have to, you need to time box it a little bit.
A design system is huge and you could do it for years and years and years if you wanted, especially with a large company like this. We kind of time boxed, OK, 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 have to kind of narrow it down, and in terms of research we actually went in and 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. 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, and also having them feel 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 make sure that they feel like they're being heard early, very, very early to get buy-in of a system.
Sure. That's incredibly important. 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, right?
It is. It really is.
You don't know it until you experience that feeling.
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. Even if you wanted to, you can't.
It is. 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 going in and saying, "Hey, we're here to help. We're not here to 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. That's so interesting, because a developer ... We often go through this feeling of not-invented-here syndrome, and I'm sure you've heard of this. Having a team come in and consult on your future, it probably feels intrusive. It's difficult to come in. I'm sure that was one of the hardest parts, because you really have to tow this line between this is ultimately going to be things that the end user is seeing, right? So that's the priority, but your users of this thing you're building are developers.
... Are within the company.
So there's a balance between those two seemingly opposing ...
Exactly. Balancing both that and the end users, because obviously the experience is about the end users, the internal, the external, the buy-in and then the government's part is a really big piece. You build this thing for this company, and you can't just build it and say, "OK, well, here it is, go with it." During this entire process, you have to be asking the questions of who is going to own this. Who's going to be maintaining this going forward, because when we leave, we can't ...
It's your responsibility.
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. Having this person is going to be maintaining the pull requests, and updating it frequently, and fixing bugs. That's a huge piece within an organization to have that established beforehand.
This happens on projects of all sizes, too.
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. Anytime you're building a system like this, there's all of these different competing priorities that come into play, but there's also what you're saying about governance, quite literally governing the implementation afterwards. Knowing how much you're ... Where is the line that you're going to draw, right? How much you're willing to flex on the rules that you've created, if at all? Typically, the most successful projects allow some flex, because the moment you cross that line and you fail, now you feel like it's OK to fail consistently. Instead of that, you have a way of saying here's how you would implement an exception to the rule. It's very interesting to know that kind of governance stuff also would happen on the UI side, entirely on the design side, brand guideline side. I think every project experiences that.
That's where the governance is really key, because you can't have people creating those gotchas or those instances. You're not really going to see those instances until you start implementing it. You can't just predict that 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." Instead of having everyone say, "Oh, I'm just going to do it myself," and then it becomes just complete chaos.
Absolutely. Talking more specifically more about the guidelines themselves in the system, rather, because we've mixed up words. I was speaking with Will before this. We were talking about design systems, and 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 what pieces overlap and what pieces are encompassed by those things. Can you kind of explain, what is a design system, kind of an elevator pitch, and what it isn't? What doesn't it cover? What doesn't it support?
OK. A design system is a container for institutional knowledge. That's kind of the set-up.
You've said this before.
Maybe not. I don't think so. What it's not, it's not a framework. It's not a prescriptive application template or something. It is not coupled to a framework or anything like that. In an ideal world, when you would have a pattern library or a style guide to me ... These words are kind of interchangeable. To me, a style guide is more just the UI patterns, just the design.
A design system, when you have a system, that is when the implementation piece comes in. In a print style guideline, that's kind of your brand guidelines where you have your logo and your brand colors. Your web style guide might actually be different from that. For example, if your brand guideline color is a color that's not accessible, then your web guideline might be a little darker version of that color, or something like that. They actually do have some variance.
What it is not is, it is not a framework. It is really only a container for knowledge that design teams and development teams can go and grab pieces as they need it 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 tool set hasn't really changed drastically, maybe even in decades. 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. 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 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 that code. That is 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. It creates native applications on both of these platforms. Go and check it out: Spec.fm/fuse. Spec.fm/fuse. I'd 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 may be going against your metaphor about Legos, but they want to create 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 language around how to use these pieces. That gets even specific as to, not only which buttons you use, it's the placement of the buttons. Primary buttons go here. Secondary buttons go here, but if you have a large model, they go here. If you have an even larger model, they're positioned here. Where does a text link go in that whole scenario? It's very, very specific down to when to use them, how not to use them.
The guidelines were actually one of the hardest parts for me to work with a copywriter to come up with. As I was designing the UI components, I would write down specific reasons why I did things. That's one of the big takeaways from my talk, is 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 six weeks ago. Why did I do that again? I know I had a reason." Then I'd be like, "Oh, OK." Writing down every little thing, even if it's just bullet points because I, myself, am not a writer. I have worked with an amazing copywriter that took my tiny little bullets as to why, and made it into beautiful text. Writing down those decisions, because so many people are going to try and challenge why. "Why would you put the padding on the buttons to this?" "Oh, well because of this." Or "Why did you make it this color?" "Oh, well because it's accessible." "Why did 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 crucial to its success.
That's very interesting how all of this is lining up with what I was speaking with Will about. 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. You have the rule, and you have the reason, and the reason being a descriptor of the decision.
The point at which, and the justification of that point of decision-making, right? It could just be that we like it. Even if that's enough, then that's fine. I think that's so crucial. A couple 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.
If you have a decision that you can collaborate with, and continue to evolve the design system to better follow the guidelines, the execution of that design system is ultimately going to evolve to be better. If you only have the end results, then you have nothing to better it with.
Other than individual opinions, right?
That's where the guidelines are so important because you can't just have the components, and the users and the team just grab them and use them however they want, because then it wouldn't really do exactly what a design system has in place. I think that's why reading the design guidelines, and also having a section for design principles ... Why you even started the design as a company. What's your voice and tone? How you interact with users? Those separated out from specific guidelines as well are also something that's really important.
Sure. I know I'm trying to play the questions in my mind of what listeners are going to be asking about this subject. There's so many questions to ask about this because it is a disconnected concept from most people's current because we have the question of, "Yes, I understand that I might need a design system, but how big should it be? 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?" Let's start with one of 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?
Sure. I think that any company that has even one product could use a design system. If you have more than one designer or more than one developer working on something, I think that you could benefit from a design system. 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. We're not going to onboard any more designers. We're probably not going to have any more developers." I don't think that's what anyone would actually say or want to say. I think that even if you're very small, you can have different elements, and that also helps with onboarding of other designers. If you can bring on another designer as you grow, then you can say "Hey, we have this design system already in place."
If you suffer from visual regression bugs, if you have things that are breaking in different places, I think that any company really would benefit from there. Even if you just have some page templates to say, "Hey, this is our checkout page," things like that, that can be extended to you're going to have some different versions of that checkout page. Here's the checkout page when you're done. Here's when you're in the process. Here's an error state on this form. Things like that are always going to be useful to, really, anyone.
Let me ask you this. This is a potential way of handling this. As a developer, I use CodePen. It's possible that 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 screen shot, and keep it in a Google doc even, right? It's not as comprehensive as maybe would be ideal, but I'm thinking what is the easiest barrier to entry to say we have some kind of documentation, now let's evolve it into our own domain. Let's make it a little bit more comprehensive now.
Right, and that's when you get into the full-fledged system where you actually have a website that houses all of this. When people see these, they think "That's going to be so much work. We're never going to get there." 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, "This is our start. It's kind of primitive still." You still have someone governing it. You still have someone making sure that the Sketch file isn't getting updated without other people's knowledge. I think even if you can start small, it's better than nothing. I know these websites that take a really long time to create with the guidelines and all the code snippets, that it is really intimidating at first, but that's the ultimate goal. In the end term, you can definitely start with the small things and run it like an open source project.
The cool thing is, you can actually use your design system to create your design system.
Exactly. That's true. When you start building the website, you're like, "Cool. I have this accordion pattern. I have this tab pattern and these panels and I know exactly the columns that are supposed to be in the grid and the breakpoints." It's a good way to test them, as well.
You start finding the edges.
Exactly. Yeah, edge cases.
Very cool. I think that covers the general idea that pretty much any project can use this, and the level of investment that you put into it can be relative, right? 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. 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. I think that's a really good point. Having page templates ... Brad Frost, he kind of talks about having the atoms, the molecules and then you work organisms and page templates. Even having that page template, you've already built up to there. You've already built the atoms that you know the colors, you know the font sizes, you know when to use these font sizes, what font you're actually using. I think that you've already built those atoms so you already have that little design system in there if you already have a template, you can extract those out and then reuse them in other pieces of the site.
Sure, yeah, absolutely makes sense. 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?
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 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 through files instead of just art boards, is actually something that I was dealing with back when I was doing this, so I wish ... I know that there are some tools that have tried to 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 this system's Sketch files?
There are some tools that I've been playing around with, but none have been super successful. I think that's probably a question I think that is really important, but isn't necessarily thought about a lot because with code you can just push. You can just push an update. ... Push and pull within any other open source project, but with design, it's a lot more difficult to update Sketch files. Then you end up sending to developers older files that don't actually have the updates. It's something that you don't really think about until you really get in there.
That makes sense. If you see Anne at a conference or something like that, go and ask Anne about whether or not she's figured out the symbol problem, right?
Maybe by then, I will have figured it out.
The other question that I ask every guest is, if you have 30 seconds to give advice to developers of any background or experience level, what would you tell them?
That is a good one. Anything I would tell developers that are new developers or just general? Anyone?
Of any kind of experience level.
... Of any kind of experience. 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 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 creativity or to bore you with code snippets that you have to plug and play. 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 the boring stuff that's already been figured out.
Sure. Makes total sense. Developers, don't get your feelings hurt when things start changing. This is something we have to be comfortable with, with change and making things better. Sometimes making things better is going to mean changing something that you think is already good, right? That's a very difficult thing to come to terms with as a developer. "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."
This is a sense of safety and constant, and the ability to stay stable, right?
Your users 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, 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.
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, 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. Make sure you subscribe from whatever podcasting app that 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. 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 Android developer, and you've been using the same tool set for really the entire time that iPhone has 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.
projekt202 is the leader in experience-driven software design and development. We are passionate about improving the experiences that people have with enterprise and consumer digital touchpoints.