So you think you need a Design System?


We talk about Design Systems. Why you need them, where to start, what it takes to really make them happen and do it in such a way that it’s sustainable.


Matthew: Hey, good news, everybody.

Matt: Hey, what is your good news? I'm switching to minimal view, there we go. Now we're ready, ready to roll.

Matthew: Hold on, let me try that again. Hey, good news, everybody.

Matt: Hey, you want to start an episode?

Matthew: I don't know.

Matt: All right, we don't have to.

Matthew: All right, let's do it anyway.

Matt: All right. So you know what I was thinking about our show, Matthew.

Matthew: I'm serious to know what you're thinking.

Matt: One thing that we're missing or we've been missing.

Matthew: Oh, shit, this is a real thing we're missing? Okay, go ahead, let me write it down.

Matt: All right.

Matthew: Go.

Matt: Drum rolls. So.

Matthew: Okay, all right.

Matt: You know what today's topic is?

Matthew: Okay. That's future Matthew, putting in the sound of a drum roll, go ahead.

Matt: We're gonna talk about design systems.

Matthew: Yeah, they're great.

Matt: Design systems can be great. And it's ironic about this topic is we were kind of bashing them a few episodes ago in season two.

Matthew: Here's why they might work, why you might want one.

Matt: Yeah, so our special guest today is David Malouf.

Matthew: Hey, David.

Matt: Hey.

Matthew: Scoot on in here.

Matt: Oh my gosh.

Matthew: Damn it, here's me without a sock puppet with googly eyes.

Matt: Now my stomach hurts from laughing. Good, it's all right. Talking earlier about doing an episode about design systems, pattern libraries, all those intertangled artifacts that are part of enterprise typically designed design shops. And we thought we would talk about the pros, cons, issues, risks, all those kinds of things that go along with endeavoring, setting something up like that, because it is a large task.

Matthew: It is a large and continuous task.

Matt: Yes.

Matthew: That gets less large over time, but

Matt: Right, but the maintenance I think that's, I mean, not to jump to the conclusion.

Matthew: Let's jump to the conclusion.

Matt: So, first of all, you get your design system. Once that's all done, then you have this whole problem with maintaining it. And that's all ongoing task of someone or some people to kind of be the gatekeepers and make sure it's still fulfilling its true purpose.

Matthew: The first huge effort is getting the organization to buy into the need in the first place. And the second effort is building it and the third huge effort is keeping it relevant.

Matt: Yeah, exactly. And a lot of times companies don't even know they need it. So they're kind of in this floundering mode even before they ask for the business to pay for it or support it. They're in this floundering back and forth with development. They're making one off controls. It's a little haphazard and unorganized as you would expect, which is all the things that the pattern library design system would solve, if done correctly. But it's not a cheap endeavor, it's not a quick endeavor. Depending on the size you're talking about. During the full on current state inventory, you're talking about budgeting to get software to manage, you're talking about getting training and developing the new system. It is a huge undertaking.

Matthew: Yeah, and you're also talking about getting a good portion of the organization to buy into doing it. And I don't just mean buy in philosophically but buying in with budget, and time to establish it and maintain it. It's not an easy task and that's I think, why a lot of companies are like, "Well, we'll do that next year."

Matt: It'll change workflows for not just the designers, but all the other R&D teams, even potentially reaching it beyond R&D. Developers, QA, content, if it's gonna span into your content development. Yeah, it's gonna touch a lot of parts of the business.

Matthew: A little background, part of the reason we're talking about this. I'm working with someone as I guess I'm a mentor, I'm a mentor. The woman that I've been talking with is in a position where she's got to come up with a design system, she knows it's necessary. And her initial ask was like, "How do I even start?" She said, one of the areas of pushback that she's getting from doing is from engineering, because two things, one design is 'always changing its mind'. I put some air quotes around that, but she said, but that's kind of fair too because we are doing that we need to get that in order. So that's one aspect of the design system that needs to be in place. And then two it's, all right, we've got this component, and maybe we make a change to that component, now we have to test it everywhere it's being used, even though we're only changing it because of this little tiny project. And so it's a big amount of effort for I think it is.

Matt: It is, I agree.

Matthew: Some effort for sure.

Matt: I mean it's part of the, I always mention with change in workflow, everyone has to be aware of a lot of stuff.

Matthew: The third thing that came up was, you touched on this a second ago about content. So there's with her company, they do healthcare education stuff, so they produce videos, both animated and live action videos for people doing physical therapy and things like that. So they've got the sort of the branding look and feel things that are in the content itself. And then they've also got the marketing side of the house and then they've got the product development side of the house. And one of the things that came up when we were talking yesterday was the color blue, the brand color blue, which is not accessible, where it gets used throughout different treatments, it doesn't have enough contrast with the background color that it gets put on. And so her question was all right, "For the sake of consistency, "and for the sake of having color that we all agree on, "do we just buy into what they're doing, "or do we push for an accessible color?" I'm throwing that out there as an example of these moments where it's not just going to be, "Hey, let's have a design system. "We'll take a hit now, but we'll save time later." But it's also this larger conversation with whoever owns the brand and the company. And the changes that may have to be made because of that. It really is a company wide effort.

Matt: Right, and it is an effort and to go back to your point of consistency, it's the user experience, which is really the driving force that needs consistency, because that's what you see in the large organizations. Is it's so large, you've got these different silos and everyone knows how we feel about silos.

Matthew: We're for them? No, we're against them.

Matt: Anti silo, companies always say we want consistency and this is one way to achieve that is to build a design system, invest in a design system, understand that it's gonna take work, time, money, like you said, but the results, if done properly, is a streamlined process, better consistency for users, better consistency for designers and engineers. Because, I talked to companies and they spin their wheels like, "Oh, we got to build this new control from scratch." And they don't even realize that it's been in this other part of the system for two years and they could just reuse it. So there's this exposure of what's already there and able to reuse which will ultimately save time in the long run.

Mattew: Right and even just your team of designers. So she's talking about they're bringing on a new designer sometime in the new year. When that designer onboards and their first project is to design some little widget or something. Are they're gonna do it from scratch and be like, "Hey, I did it for you." And it looks nothing like what they do. And "Oh, I tried to make it a lot like yours, "but I thought the rounded corners "looks better than the square corners, "so I went with that." And having that, at least from the design teams perspective, presenting a unified, it's not a fight, it shouldn't be a fight, so I really don't want to say unified front, but sort of a unified perspective of this is what we think is true and this is what we think is the best user experience that we can provide.

Matt: Wrapped into that, how does it look but how does it work? As we've all seen applications where this control drop down whatever works one way and slightly different in another part of the system and that's a very bad thing. And confusing it, and to your point, what I what I tell clients when they come up with these questions to me, is "Well here's a problem, we already have this control "and someone has a new idea "to make it better to improve it," great. "But that change should be rolled "into the overall design wide control." No one offs, unless there's a really, really good reason to have a one off.

Matthew: Or where if you have this great new idea and we all are like, "Yeah, that does make sense." The first step should be all right, where are all the instances of this? And how will this change break? Will it break anything? Will it diminish the user experience? And if so, what's the risk with that?

Matt: And a good system should indicate that to the teams, right? They should be able to go and find all those instances and make that evaluation. That's part of where they and the timing--

Matthew: And the rationale for why it is that way in the first place. Or why the change? Or why this alternate version? I think it's always important to have that why in there for your future selves, because everyone's inundated with everything all day long. It's like, "Why did we make that decision?"

Matt: And people leave and there's always new people joining the team. And it's the same thing with code and commenting code. It's commenting your design, why did we make this this decision? Here's the rationale. Here are the factors involved for either a decision or a non decision, in some cases. Like, "Yeah, we know this looks weird, "but here's what was going on at the time "and here's why we did this way." It's just providing that documentation, the archives, if you will.

Matthew: The premise again, behind this was the, so you think you need a design system? And so not just our conversation, but I thought I would reach out to some other people and get their perspective.

Matt: Perfect.

Matthew: Talked with my friend Peter, and one of his suggestions was, to me this falls under the category of, what do you control and what do you influence? And start with the things you control. And the first thing you can do, well, there's a lot of first things you can do, but an easy first thing to do is just to do an audit.

Peter Russo: Every time I kind of run into a design system, I've run into some people who want to do them have them finished in some way before they are presented, and that's just not the approach that I believe works. I think you get too deep into, "Oh, we need to have this specific element, "and you need to have this and that." You don't think about what do the people actually need do their job? Start with an audit of the existing software. Usually, there's existing software. If you have an existing system, start by doing an audit of it, and using that audit as a conversation base, like saying, "Hey, we have seven different primary buttons," and probably you will, most people have a lot of primary buttons. "And we have this thing that was built 10 years ago, "and it's right next to this thing "that was designed last month, so they're very different, "what's working in these two." And it's a very conversational process where you're really trying to get down to not this is the one thing to rule all but this is what works, this is why it works and eventually hopefully you're leading towards something that is gonna be consistent. That's kind of the first, the bottom tier. Maslow's hierarchy of design systems, there's just lots to make it consistent. It does not need to do anything else, but just look and feel the same and work really well. I think that's the place where a lot of folks want to jump to, the real interesting stuff. But a lot of what's in a design system is not the real interesting stuff. It's the basics, the typography, colors, buttons, all that that's the grid system, all those things need to be considered before you start to dive into the interesting stuff.

Matthew: I also talked to my friend Todd, who's the I think he's Interaction Design Director at Ziba. He was saying that part of the goal, this is more on the influence side of things is you really need to develop a critical mass of interest, because this can't be funded just from a project to project basis.

Todd Greco: I'm gonna start strategically and then we can talk about tactics. So on the strategy side, one of the other parts that I always harp on with this type of problem is it's overall funding and focus. So when you have, maybe she's got a patient portal, or she's got some other type of software manifestation that is I'm assuming customer focused or maybe it's nurse focused or whatever it winds up being. All too often, these types of institutions like to think about those as projects. And so they fund them as projects. And so it's a thing that's time bounded and has certain amounts of money. And with that, we get it done in a year or six months or two years, whatever it takes. But it's a thing and then when it's done, it's an ace of diamonds that you go put on the shelf, and then you move on to the next problem. And that type of thinking gets you in serious amounts of trouble with these types of things, because you're building all of these systems on quicksand. And so like all of the underlying pieces of the software change while you're, while it's sitting on the shelf, and then you have to like pick it back up and fix it and put it back on the shelf. So I gave a lot of talks about funding as product in that project and so it's a team that then takes over the thing and then just keeps on it while it's still alive, and then moves on to a different problem, if you decide to start on that, so that's one. And if you get into that mode, then there's not this division between design and engineering because it's all one team. So it's not like design changed the thing and now engineering just lost all their velocity, because they gotta go fix something. It's much more about like we together just realized we need a dark mode version and I guess we're gonna have to do that. And it's everyone's problem.

Matthew: That program level, and supported at the C-level, or the operations level or the consortium of directors, depending on how big your organization is, and those are the places to really start those conversations. But from a design group, this is stemming from the design group, starting with the things you can actually control.

Matt: I believe, I don't know how long ago this was. But I did work with a client and they, one of the groups within the organization did kind of start their own design system, in the hopes that it would kind of catch fire. And then it would kind of grow and absorb other teams. I don't know how that actually ended up. But that was their goal, because they weren't getting the support from above. So they thought we'll just do our own and hope people realize the value that it brings, and it'll kind of just grow organically within the organization. I would hope that would work but very organization is different, so you never know.

Matthew: This is when I was talking to this woman yesterday about this quandary she's in. I said, "Maybe just start with a design system for the design team." And say, "Hey, everybody, this is what a button looks like, "this is what it does, "these are the different states it can be in. "Do we all agree, yes?" All right, boom, here's our button. You ever need one, you go here to get it. Again, that goes back to what can you control? And that's something that she can politely dictate to the team.

Matt: Yep, did you have a third expert opinion?

Matthew: You know, I did try to get other expert opinions and I was asking on Twitter, which maybe I shouldn't have. I should have asked some people directly. And I had two takers, Peter and Todd, but I haven't gotten anybody else yet.

Matt: Oh okay.

Matthew: The other thing that came up on this conversation was essentially establishing some design principles.

Matt: Those that will help you make decisions about which controls to use and how to design them.

Matthew: Yeah and when someone comes and says, "Hey, I want to do something different," you can say, "All right, well does it mesh "with our design principles" Because these are the things we're not bending on. One of the things we talked about was she wants to involve other people. So she's going to reach out to the group of front end devs, who sit in engineering and invite them to sort of a lunch and learn kind of thing where let's talk about design principles. And I pointed her to a website, which I'll link, it's an open source design principle site, really just links to other design, other companies who posted their design principles. I said, pick five or six that resonate with you, put them on sticky notes, put them up on the wall and then have lunch with these people and say let's generate more things that we believe to be true, things that we feel are important. And then start to cluster them and then start to refine them, doesn't have to be all done in one lunch and learn. But by the end of it, you can have maybe two or three design principles that you all agree on, as a group, are important and that you're not going to budge on. So that you can then say to the organization, "Hey, you wanna do this? "This doesn't mesh with our principle. "Here's the risk for not being in line "with these principles."

Matt: Right, or do we need to change our principles? Has something else changed externally, to drive the change?

Matthew: Maybe we didn't, think this through well enough or something,

Matt: But it's all being rational and deliberate about making decisions. It's not just someone has an idea and everyone runs with it. It's being intentional and thoughtful around these decisions, and it's providing that litmus test, to say are we still adhering to what we set out to do?

Matthew: The principles and the system are something that should be, that you should crow about, you should be using these as marketing tools for the value you provide, as a design organization within the company. It may not be something people are clamoring to do immediately. But if you are once a week or once a month, sending out basically a newsletter to the group internally of here's our accomplishments around the design system and the things that are baked and the things we're working on, it helps to build that critical mass of interest over time. It's that political aspect of all the work that we do.

Matt: And for getting recognition for it.

Matthew: And getting recognition for it, right. Oh, look, she's taking this very seriously and we're starting to see the value of doing this work.

Matt: And if people realize that the investment that they're making in the system is showing benefits, that can only help you get investments in other things and future enhancements.

Matthew: You know, we get there faster with two more designers.

Matt: You say two more design systems. Throw them all. Now, one thing we haven't talked about, intentionally here is specific design systems software tools. At least from my perspective, a couple reasons for that is because I haven't really been a part of the internal workings of one for over a year now, as far as helping decide and helping clients figure out how to implement one and the landscape changes so quickly, that I'm a little bit hesitant to throw some specifics out there because it's a very specific solution to a specific problem for each business and every business has obviously specific needs, budgets, all those things. And so I'm personally hesitant to throw out specific recommendations because it's a tough thing to do in this format.

Matthew: I worked with a client where we started talking about that. And the first question everybody wants to talk about is tools, what tools do we use? And my take is that it kind of doesn't matter. Use the tools you have but the real question is, what is going to help you best collaborate? What is going to help you best and easiest share and make findable the work you collaborated on? That and telling you that's like, if you end up with Photoshop and SharePoint as your answers, okay, that's fine.

Matt: What's accessible to the people that need to know, that have access to this. Yeah, I mean, that's always been my thing with design tools, it's work with what's best for you, what you know best and feel most comfortable in. But in this since it's reaching out to so many different groups, you need to find that kind of lowest common denominator, or something that everyone is familiar with and used to working around.

Matthew: Or get very used to if you're working in Sketch, exporting the artboard to PDF, and putting that in the finable place. If you're stuck on Sketch, that's what you have to do because you can't collaborate on a file in Sketch.

Matt: Right, that's a limitation.

Matthew: You can't share, not everybody has Sketch, so you can't share a Sketch file. Tools like Figma, which is yeah, I should say Figma is the the latest hotness.

Matt: And it's online, it's,

Matthew: It contains a lot more collaboration and all that kind of stuff.

Matt: But in six months there'll be something else.

Matthew: It'll be replaced by something else. And that's the point, again, you have to think in terms of outcomes, not tools. I have to collaborate with my fellow designers, I have to collaborate with engineers, I have to share this information with other directors and C-level people and marketing and content so that they can understand what we're doing and potentially contribute as well. So for me, those are like screw tools. It's just,

Matt: Yep.

Matthew: I know, we lost one of our viewers on that statement, but

Matt: I mean, that's what people are looking for, that's what they're googling. And I get it, but really back yourself up and focus more on the needs.

Matthew: Like a good designer.

Matt: Like a good designer, right.

Matthew: Not someone obsessed with tools. Yeah, I think it's not an effort to take on lightly. But I also think, most companies, even small ones, should probably do it.

Matt: Yeah, I think the scale changes. I think for small companies, it's, you always want consistency, you always want to streamline the process. So I agree with there. It's how robust of a system do you need? Because even if you're a one person design shop, you don't want to start from scratch every time you're starting a new page or whatever type of system you're designing. So you should have your own internal pattern library, which going way back into the early days of design, that's what we all did. We all had our own personal, little library that we would use. And that was where the problems would come in. So when you start this as your team grows, and as your organization grows, that's why you need that collaboration.

Matthew: Yeah, I'm having painful memories back to 2003, probably where one of the people in the design group sent out an email with a Dreamweaver file attached or no sorry, a link to Lotus Notes, where there was a Dreamweaver file stored that we were to use when we wanted to make a multi-column list box. And it was like, "Hey, I've tested this on all the browsers, "and it works, use this when you need it." Yeah, that was our design system, basically stored in Lotus Notes as individual component files.

Matt: And kind of the flip side of that is I can remember way back when I was doing design work, my first design job, you could look at the screens in the product, the finished product that we were selling and tell which designer worked on which feature.

Matthew: Hey, nice to work, Larry.

Matt: Right. So you don't want that but this was 20 years ago, we had lower standards back then.

Matthew: The buttons are so rounded corners, they're circles.

Matt: I know that font.

Matthew: Yeah, so I mean, at the very least, you're having a style guide, right? These are the colors to use, these are the fonts to use, These are where you need them. It's not, "Hey, I really like Roboto "instead of Roboto slab," or whatever, it is basic stuff, but then when you have moments like that where you've got the marketing department has established some brand guidelines and the colors they've chose aren't accessible. You got to do something about that from a design perspective.

Matt: Right, and it's not gonna make any of the changes. That's a whole separate part of this. You can identify the gaps, but then someone still has to go out and true up the system to match the guide.

Matthew: Go redo all that content.

Matt: Yep, get on that, get on that Larry.

Matthew: Get on that Larry. Larry is my 2020 version of Gary. Gary was 2019.

Matt: No Larrys were harmed in the making of this video channel.

Matthew: Yeah, so there's a lot of information out there. In fact, a book came out yesterday by I'm blanking on her name at the moment, but it's in a book, a part book and I'll link it.

Matt: It'll be in the comments.

Matthew: It will be in the comments, right. But it's probably worth looking at. I haven't looked at it but people that I know and trust have looked at it and said that it's a good thing to look at when you're thinking about a design system and where to start.

Matt: And that's what I was gonna kind of wrap up with, in the end like we're big proponents of it. And if you're already thinking about it, you probably already need it. So continue your journey. Hopefully, we're giving some good rationale for continuing on and getting the buy in from an organization because it's to your benefit, it's everyone's benefit, especially your customers.

Matthew: Especially your customers. And at the very least you want to be able to sit down and look at everything you've made and say, "Yes, a single company made this."

Matt: Exactly.

Matthew: And that's the problem that the woman I'm talking with is having where it's like, you can look at the videos they're making, at the animated videos they're making, at the marketing material they're making, at the apps, it's not quite clear except for the logo that this is all made by one company.

Matt: Right, and that's a whole another road to go down is like when you talk about companies that acquire other companies. And then you're trying to get them all to look similar and that's a whole another, a whole another thing. That's a tough problem to solve. Do a whole show on that.

Matthew: Let's never speak of this again.

Matt: All right, good show people, good show.

Related Post