Scaling Your Design Systems

Davy Fung, Donnie D'Amato, Troy Azmoon, Alkistis Mavroeidi at UXDX USA. Video: https://www.youtube.com/watch?v=Vw4yuz6FV4g

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

When does a team need a design system

[00:00:01] Troy: Hey everybody, we're going to have a little talk about design systems. Let's do a little bit of questions up here, and as we get through them we'll probably go to the audience and see where it takes us. Just to start out, I've been on both sides of this design system equation. I can remember the first time vividly. I was a product leader, and designers came to me and said, we need a design system, and I was like, what, how many people is this going to cost us? So, when and why is the design system important? What stage does a company or a team need to start worrying about solving for this problem? Who's going first?

[00:00:41] Davy: I could go first. I think you could start at any stage. A good thing to think about is that, I mentioned this in my talk, if you have not seen my talk yet, you could start a design system with a team of one and a team of two, and it's really more about planning for the future and trying to understand where you might want to go, that you might be building more than one application across multiple platforms. So I truly believe you could start at any point, and the value of it becomes exponentially better as your team scales beyond one or two people.

[00:01:21] Alkistis: I would agree with that. I think that the minimum in terms of how big the team has to be, or how big the product has to be, is very low, really, for anyone to get into design systems and see the benefits of it. And what it really offers is just the possibility to scale your product. So the moment that starts becoming a challenge, then you're in need of a design system that's going to help you build the efficiency for the team and ensure as well the quality for your product. So yes, the barrier is very low, I think everybody should be thinking about design systems.

[00:01:58] Donnie: I relate it to the way that we think about accessibility. One of the recommendations we all hear about accessibility is you should start with accessibility right from the beginning. You shouldn't have to try to backport and go in and try to get accessibility after the fact, because that's going to just be a lot of extra time that could have been spent on just doing it right from the beginning. So I like to also use that from the design system standpoint, because if you start it out from the beginning and have that foundation, so that you can iterate and create these new experiences, create these features, as opposed to reinventing the wheel for each one of these features. Because inevitably, especially for a successful product, the design system is only going to help you. There's really no hurt. Of course, I guess there could be some hurt if you do it maybe incorrectly. But I think doing it sooner rather than later is going to help you, as long as you have the research behind it to inform what you need.

Selling the investment

[00:02:59] Troy: Okay, and that's interesting because that kind of brings my next question, which was, how do you go about selling the project of, we need to invest in a design system, to stakeholders, engineers, product managers, executives? What are some of your techniques or strategies? Can you give everybody some of the secrets?

[00:03:20] Alkistis: I think it solves the same problems for cross-functional teams, and the moment that the organization understands that, and doesn't think that it's just a request from the design team but it's actually something that's going to create the efficiency cross-functionally, then that's a big win. And then if you want to be more specific, I think if you do a more visual collection of inconsistencies, or accessibility is a huge benefit of having a system that has all these things built in, so that foundationally you can have these bricks and you don't have to spend your team's energy into building this from scratch every time. And that's also a big, big win.

[00:04:00] Donnie: There's a lot of contention when it comes to trying to provide the metrics for a design system, because that's what the stakeholders want, they want to see what the ROI is for the design system. And actually, I think I was speaking on another panel of folks where I related to trying to identify the ROI in the same way that you would do from a security standpoint. Because with security, you pay for security but you don't see the benefit of security until it's too late. So similarly you're paying for the design system, and it's hard to see the benefit of that design system when you are rapidly iterating on prototypes and features, because everything's just working. Only until it doesn't work, and you didn't have the system or the security in place, do you identify that you needed one.

[00:04:48] So that's what ends up being really difficult, is how do you identify that there's worth in here through means? And admittedly I haven't solved that personally, because I'm terrible in terms of sales. But that's really what this is, it's trying to sell the idea of the design system to a stakeholder in a way where it looks like there's no benefit if everything's working.

[00:05:14] Davy: I like the you're not reinventing the wheel. I think you have to understand what the love language of leadership stakeholders is. Selling to engineering I think is very simple, it's, you're going to reduce lines of code, you're not going to have to reinvent the wheel, like you said. In terms of selling it to product leadership or other parts of leadership, it does save money, it saves you time, and it would provide, I think the best thing for designers, it provides a better starting point for you to start your project on. So those are the types of things that we like to look at. ROI is a little tricky to quantify, if you're looking just at how many times this thing has been used in Figma. We're still working through how to understand that impact, but I would certainly leverage how we could save the engineering time.

[00:06:11] Donnie: I'm going to take him to all my pitches though.

[00:06:13] Davy: Yeah, yeah, I mean, better.

[00:06:16] Troy: With your voice and some of the things he's saying, I think we can really make some progress. It's interesting, I think that if we also look at this in terms of the evolution of a company, I mean all companies want to grow and become bigger and have more products and be more successful, and if we talk about solving for the future as these teams develop and we grow our product lines, it becomes even more compelling. It's kind of like compound interest. You only get 10 a year, but after 10, 20 years you've got a lot more. That's sort of the investment in the future that I think a good design system could probably bring us.

Is it ever smooth sailing?

[00:06:53] Troy: I don't have this in here but I'm just curious about it. Have you found that you can just come in and make the bomb design system right off the bat, or do you typically go through a few different v1s, like, wait, this is v1, okay now we've sort of figured out and everybody's on board, and mic drop, there it is, v3 is, we got this. Or has it always just been smooth sailing?

[00:07:20] Donnie: I think, as an architect of design systems, and having done it a couple of times now, I have a really good understanding from my experience about what the best case scenario for their system would probably be. But in reality, people are attempting to ship features, and there's a lot of focus in that, because that's where the money's coming in, it's those features, not necessarily so much the design system. So there's a balance that you have to have between what you can do today to support that design system and work toward what that final result is.

[00:07:59] But absolutely, especially in places where there's an existing design system, from an architect standpoint, or for a consultant for example I should say, coming in and identifying what the current organization is, what the resources are today, and understanding what these folks' needs are versus any other particular company that has different needs. Even thinking about, this team is using Angular but this team is using React is going to have different ways of architecting that system to support those people, because they're just working in different ways.

[00:08:34] Troy: Right, right. As soon as you have those teams trying to get this done, they come in, they're like, we got the design system now already, it's in our new product, we got this.

[00:08:41] Donnie: Yeah, right, exactly. And I've also seen it where the one product is driving that design system. I think that works to a point. It's difficult, because there's a little bit of bias in that product, of course, and when you build a design system localized to that product, you have to be a little careful that there's some communication against other products that the design system is expected to support.

[00:09:08] Troy: That makes sense. Go ahead, Davy.

[00:09:10] Davy: Donnie had a really good answer, so we could go home now. I think our problem at Disney has notoriously been the amount of platforms that we support. There's seven distinct platforms, I think at least four different scripting languages. So if we were to go in, or if someone came in and said, this recipe would work for you, it wouldn't be so cut and dry. A perfect example would be, a big portion of design systems and systems thinking is the need for coded components, and that may be good for most organizations, but that's not something that we've been able to focus on. So we focus on something that's more foundational, like design tokens for instance. So really trying to understand what we could accomplish and what we could implement across the scale of our apps.

[00:10:05] Alkistis: I will say, just to the question of whether it was smooth sailing, it definitely hasn't been. And I feel very happy and honored that I got to witness that journey at KAYAK, from starting to even think about the design system to having something that's so efficient that we can scale to seven brands and also white label two different businesses that we have. But there's definitely points there where we had to do big switches. An example of that would be setting up our color scheme in a way that was primary, secondary, and then figuring out how to translate that efficiently into other brands, and we had to do a big switch into a functional setup.

[00:10:49] So there is also a little bit of stakeholder management there that you have to do, where it's like, whenever you switch things up there's going to be an extra piece of effort, but you have to communicate why that is an investment into a future-proof design system. So yes, it's exciting to also see the limitations and kind of overcome them when you get to that. But the big challenge for KAYAK has been, and is, the design system, what it has very creatively supported is this idea of having seven brands that we can support with a lean team of designers. There's about 30 designers that we have.

Future proof or future resistant

[00:11:32] Donnie: Quick comment. You mentioned the word future proof. I personally don't believe in future proof, because I think that future proof is impossible. It can't be proofed for the future, the future's ever changing. So I like to call it future resistant.

[00:11:45] Alkistis: I like that.

[00:11:49] Donnie: It's good. I think it allows for change, because if you say you're future proofing and then something comes up and things change, then you're uncomfortable.

[00:11:57] Alkistis: Right, yeah. Resistant. Ah, I caught that, it's okay, it's resistant. I like that.

Good versus great

[00:12:03] Troy: Good, good. So that kind of gets into the next thing I mentioned earlier when we were chatting, which is, from your perspective, what separates the great design system from the merely good? That's a good one. Like a great one. So where do you say, hey, that's where this design system really stepped up?

[00:12:29] Davy: Yeah, I mean, the large portion of design systems is not your component library, it's the people behind that. So if you have a good support team, a good team of practitioners that could help and work with designers, pair with them, pair with engineering, I think that's really indicative of how good the system could be.

[00:12:56] Alkistis: I think where I would put the distinction is, a good design system helps the design team build components sufficiently, helps them deliver designs and iterations. But the great design system gets everything through into production and is a third language that then you can point to and say that the designers are naming things the same way that the engineers are naming things, or cross-platform. So the value that it can add as a glue between the teams and creating one source of truth for everyone is great. I think it works very well when it's a system for the design team to go back to, but that extra thing is fantastic and it really scales efficiency into a different level, because then you have better handoffs, you have one-to-one correlation between what you have on your design files and your production files. So there's so many things that come together with a design system that's cross-functional.

[00:14:03] Troy: We need a good resistant design system.

[00:14:06] Donnie: A good resistant design system. I was just going to actually mention that there is, in my opinion, right now, there isn't a what we're trying to define as a great design system. I think a great design system is invisible. We take a lot of time doing a lot of leg work to get the assets and resources and make sure it's accessible and localized, and we're doing a lot of work in there and shopping around, and that's all fine and dandy, but I think there's going to be a point in the future where enough of the infrastructure is in place where things kind of just work.

[00:14:41] So for an example, and I was actually speaking in the lounge with Davy about this, there is going to be a world, which is coming, where a designer can basically draw a wireframe, input it into a system, and it would spit out that interface, that experience, based on the wireframe, using the design system rule set. Using the colors that are there, the typography, all of that stuff, from a user experience standpoint, is actually noise, it's things that are distracting. So there's going to be a point where we as user experience designers are actually purely designing the experience, and all the noise and all the additional nuance that occurs with contrasting colors and typography hierarchy and all that stuff is going to be highlighted by the system and formed by the system, so that the designer can really focus on providing the true, correct experience for the user. And I think that's going to be a great system, where that great system just supports the experience as opposed to having all these kind of additional bells and whistles, potentially.

[00:16:00] Troy: Yeah, it's a good vision of the future. A lot of exposed APIs, a lot of capability to extend on the fly, would be awesome.

How they got into design systems

[00:16:09] Troy: So here's a different kind of question. This is kind of an unusual space, at least I think it's unusual, most people don't identify themselves as design system designers. It's niche a bit. How did you get into it? What inspired you to be like, yeah, I want to actually design the Lego blocks, so to speak, that people build with?

[00:16:32] Alkistis: I can just start that, because I'm not a design systems expert, I'm actually representing here the work that our amazing team has done. So I've again been very lucky to be involved and witness that, but a huge shout out to that team, Mat Homes[?], our brand lab, all of UX and product designers have done this. But I think for me, what has really drawn me into learning more about design systems is that level of efficiency and how many things you can actually build in from a UX perspective as well. So we mentioned accessibility, usability and also brand, all of that going into building blocks that then can allow you to have that competitive compartmentalization, and then, whoa, that's a tough word. But kind of break down the process and allow people to focus into the specific areas of expertise that they have. I think that's amazing. And actually, coming from a background of UX design and having witnessed a little bit the differentiation between UI designers and UX designers, and how that evolved into a common role, that of product designers, and the different expertises that evolve as products evolve, that is another fascinating aspect to it for me.

[00:18:00] Donnie: Yeah, I got started with design systems from, I guess, identifying, I was a UX engineer originally at Compass, and making lots of prototypes there for different features, and realizing clearly that if I keep making the same kinds of things over and over again, I need to be able to reuse pieces to create new experiences rapidly, much faster than the other feature folks were. So that came from a need of having a component library, or reusable artifacts that I can go ahead and use.

[00:18:35] Troy: Your motivation was laziness.

[00:18:36] Donnie: Absolutely. I think there's a lot of motivation for folks in terms of wanting to have a design system in the first place, because you don't want to reinvent the wheel, as we've mentioned. So that's where it came from. And I identified a little later on that I don't want to do feature development, because I get anxiety about if my feature and its experience matches another feature's experience. I had anxiety like, is it the same? I don't know. So now all I want to do is look at the platform, and not focus specifically on the depth of a particular feature but more so the experience overall of a user as they come from the home page to login to their dashboard to the cart to the checkout, all that stuff. I don't necessarily care about that specific experience about how that works, but I want to make sure that as they go through that experience, everything is relatable or familiar to them, that they don't think they're in a different site because it's a completely different experience. I think that includes that trustworthy part of the design system piece.

[00:19:49] Davy: Yeah, I started in design and the arts, so it was very much like InDesign was where I used to play, Illustrator. And I learned quite a bit by this very early style guide type thing, and I was remembering just how far back it was. It was quite a bit ago, but there were like paragraph styles and text styles. So back then we worked in grids, we were working in publication design, so there's a lot of the same patterns. And I think, like Donnie said, it drives back into the impact about designing something for one area and one feature group and being able to extend that across to a different part of the app.

[00:20:28] And one specific thing that I always found, that has been something that I discovered in the past few years, our team at Disney Streaming is a team that has interns, junior level designers, mid-level designers, all the way up, and it's an amazing place for junior level feature product designers and mid-level designers, because you get to design across many different things and it really does help you think about designing across something like a mobile phone to something like a television. So it helps expand your horizons, so to speak, on what product design is.

The biggest challenge

[00:21:09] Troy: Okay, cool. What do you think is maybe the biggest challenge as a design system expert or representative? What's the biggest challenge there?

[00:21:23] Davy: I think it's people wrangling. I think that's the hardest thing, because the assets are easy, right? Those are malleable for the most part, they don't have opinions. The people have opinions. So I think it's trying to get the opinions in the room, for how it's going to affect them out there and how they affect us, and trying to get all that together, I think is probably the largest challenge when it comes to design systems.

[00:21:54] Troy: That's a quick one, easy.

[00:21:56] Alkistis: That was exactly what I was thinking too. It's stakeholder management, when it comes to getting opinions in, but also making sure again that it's a cross-functional thing and it's a shared language. And that poses challenges not just for design team versus engineering team, but also within the engineering team. What are some naming conventions that people are going to understand across the board, and then how do you make sure that you have the same vocabulary, because otherwise you're still going to get the same questions, there's still going to be a lot of back and forth after handoff.

[00:22:33] Getting everybody's opinions and making this a collaborative process is one of the learnings also that we certainly, in the talk, if you can watch it online, this idea of having your engineering best buddies and people who are invested in it and are also going to help you understand how to make this a success and future resistant as well. So yeah, it's a big part of it.

[00:23:02] Donnie: I would agree. Alky had mentioned the word source of truth, and I think that's the second time this has been mentioned. But understanding that even though there is a source of truth, parentheses, quotation marks, that each stakeholder may need something different. So engineers may need something different than what a designer needs. A lot of times we think about design systems as either coded components or like our Figma file. We could optimize for both, and we could optimize how we meet designers in the file, and then we could optimize for how engineers will come in and consume the file.

Where to learn more

[00:23:48] Troy: All right, well, I have one more and then we'll open up to the floor here. Last one. A lot of folks are maybe just beginning their design system journey, or maybe they've got a style guide, or they're looking at doing a refresh. How do folks learn more? What are some great ways people can learn more about design systems and best practices? Maybe there's someone you know, or videos, or if there's a podcast, is there a podcast somewhere people can listen?

[00:24:14] Davy: Yeah, there's, I have a design systems podcast. That was not intentional.

[00:24:22] Troy: That's a lob, you know.

[00:24:25] Davy: There's a fire hose of information right now, which I think is a good thing and a bad thing, for promoting a lot of best practices. Just searching for specific things, like on YouTube, I think, like we used to go on Stack Overflow a lot to look at stuff. But really trying to understand the breadth of what design systems could be, and that may be listening to podcasts, going to conferences like this. But then understanding what design systems mean to each one of us. So for me, people engagement and earning trust of designers and engineers, that's my big thing. So, learning about all the different, although it's niche, there's a lot of nuances to what we do and what we feel passionate about.

[00:25:15] Troy: Okay, anywhere we should go, anybody we should know?

[00:25:18] Alkistis: I think it's very interesting because this community of people who are building design systems are very excited to solve these really hard problems and are sharing a lot of this information out there. So there's huge communities, we have resources, and especially in software that's built around building a design system, like Figma. Or just companies who set out their guidelines and their design system, and I think that's another great way to learn and get familiar with the unique challenges that each company has, or each organization, and try to see which of these elements fit your design system and what are the differences. So there's a lot of them out there, that's really cool.

[00:26:07] Donnie: Right. I think people probably already know that there are Slack communities and Twitter communities about design systems, and those resources are out there. But I actually think that, and this goes back to the way that I learned how to code, identifying that when you have a problem, and doing the research to solve it, is going to be the best way. You can go ahead and recreationally read books about design systems or look at conversations about it, but until you have a problem that you need to solve, that's where you get the motivation to really dive in to solving that problem. That's how I learned how to code, for example.

[00:26:48] And I think that would really also help for people that when they have a problem like, how do I make a type ramp, or what's the best type ramp to use, that's not something that you necessarily are thinking about when you're just thinking about starting up a design system, until you get there. And then when you get there you're going to research and you're going to dive in and see what people are doing. There's enough public design systems out there that you can go ahead and compare and contrast, and, spoiler alert, they all have different type ramps. So you're going to have to also identify why you need your type ramp. There's going to be a purpose behind each one of their type ramps and why they decided to do that, and you're going to have to inject purpose into yours. So that'll only happen when you identify your first problem.

[00:27:35] Troy: That's all about identifying the right problem.

[00:27:37] Donnie: That's right.

Audience questions

[00:27:38] Troy: So okay, that was great. We have a few minutes left, we want to open it up to the floor if anybody has any burning design system questions. I see someone in the back there.

[00:27:50] Audience: Two questions really quick. The first one is, what design systems do you individually use? Did any of you roll your own, or are you using things like Material Design? That's the first question. Second question is, from your engineering team's perspective, do you get any pushback on being too prescriptive?

[00:28:10] Davy: We reference Material Design just for like a human interface guidelines. I think that's the best way we've utilized it, similar to like the Apple HIG as well. In terms of resistance, I think the thing that we've been sort of trying to work on the most is slimming down things like our type ramp, and we do get resistance when we do want to promote a new type ramp piece, and we really try to work with designers to try to not add that sort of stuff. But then I think the notion of design system police comes up, which is a little bit something to discuss on a different day, in governance and that sort of thing. But yeah, I think that's what irks the engineering teams the most.

[00:29:02] Donnie: Yeah, so the design systems that we've used have all been custom, more or less. Some of the assets that we've used, like for instance GoDaddy was based off originally of Bootstrap, but we've moved away from Bootstrap for more modern techniques, of course. So there's been some foundations there generally speaking, but ultimately most of the design systems that I've worked on are accustomed to the people that need them, kind of what we were mentioning earlier. But looking at those public design systems, and even in the cases of startups that need to quickly start up their own projects, it's helpful to use an existing system out there.

[00:29:46] And in terms of engineering pushback, I mentioned this in one of the forums earlier, but the big secret is that engineering can do anything, okay? Don't let them say that they can't do it, because they actually can, it doesn't matter. But what actually does matter there is, should you do it? And that's a conversation. It's not a stomp back to your room and complain about the engineer, it's a confront that engineer and understand what those concerns are. The no is not a hard no, it's a, let's talk about it a little bit more and get to a solution. So you always have that avenue, and I think that's important in those conversations.

[00:30:31] Troy: Okay, so this is probably our last question, we're running low on time.

[00:30:35] Alkistis: Right, so for design systems, similar answer, we also looked at what's out there for familiarity reasons as well, from a UX perspective, and also understanding how people are solving the problems. But every organization has its own challenges, so we build our own design system. But for the engineering question, I think it comes back to what I mentioned before. The resistance, or the pushback, or the tendency to be prescriptive, comes when we don't involve them in the conversation. So when we present something there's like, whoa, what, that doesn't fit what I was thinking. So I think we've come a long way with this design system to have it really embedded into having our engineering best buddies and build it from ground up together.

[00:31:20] There's always going to be space for debate and pushback, but I think it's valuable from both ways, from the design side and the engineering side. The pushback comes because there's usually a reason, and then coming down to figuring out what is the reason, what are the frustrations or friction points that we can solve, that's the key to everything. And again, it's solving the same problems for everyone. It's the glue, so it creates a certain language for people to collaborate.

[00:31:54] Troy: Yeah, and from our perspective at ServiceNow, our strategy as a company is to create a low code platform, so engineering and design and product, everybody's been aligned on how important it is for us to roll our own and enable our thousands of customers to build literally millions of products on the platform. So I think it goes to show that depending on the kind of problems you're trying to solve, your approach to your design system and some of the challenges that you're going to encounter are going to be situational. So it's important to understand your situation as you take influence from the multitude of folks that have gone there before you. All right, well, thank you everybody, appreciate your time, and thank you speakers.