Scaling Your Design Systems

Troy Azmoon
Hey everybody, so yeah, 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. So just to start out, I've been on both sides of this design system equation. I can remember the first time vividly, was a product leader, designers came to me and said, we needed a design system. I was like, what, how many people? Is this going to cost us? So you know, when and why is the design system important? What stage does a company or team need to start worrying about solving for this problem?

Donnie D’Amato
Who's going first?

Davy Fung
I could go first. I think you could start at any stage. So I think 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 team or 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 we could start at any point and, the value of it becomes exponentially better as your team skills beyond one or two people.

Alkistis Mavroeidi
I would agree with that. I think that the minimum in terms of how big the team has to be or how the product, 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 talent, then you know 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.

Donnie D’Amato
I related to the way that we think about accessibility. I think one of the recommendations we all hear about accessibility is, you should start with accessibility, right from the beginning, right, you shouldn't have to try to backward 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 started out from the beginning, and have that foundation, so that you can iterate and create these new experiences, create these features, as opposed to you know, reinventing the wheel for each one of these features. Because inevitably, especially from 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 yeah, doing it sooner rather than later is going to help you as long as you have that, the research behind it to inform what you need.

Troy Azmoon
Okay, that's interesting, because that kind of brings up my next question, which was, you know, how do you go about selling, like the project of... we need to invest in a design system to stakeholders, engineers, product managers, executives, and what are some of your techniques or strategies that give everybody, some of the secrets?

Alkistis Mavroeidi
I think it solves the same problems for cross-functional teams. And the moment that the organization understands that. And don't think that it's just a request from the design team, but it's actually something that's going to create 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, and so that foundationally, you can have these bricks, and you don't have to spend your team's energy into building these from scratch every time, and that's also a big win.

Donnie D’Amato
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 when security you pay for security, but you don't see the benefit of security, right 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? 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 stakeholder in a way where it looks like there's no benefit if everything's working.

Davy Fung
I like you, you're not reinventing the wheel. So I think you have to understand what the love language of leadership stakeholders are, I think. 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 going to, it's a little tricky to quantify, like, 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 can save the engineering time.

Donnie D’Amato
I'm going to take him to all my pitches then.

Troy Azmoon
With your voice and some of the things he's saying I think we can really... Yeah, you know, it's interesting. I think that, you know, 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 more successful. And if we talk about solving for the future, as these teams develop and grow our product lines, becomes even more compelling, right? It's kind of like compound interest. Yeah, you only get 10% a year, but after 10, 20 years, you've got a lot more, you know, that's sort of the investment in the future, that I think a good design system would probably bring us. You know, this is a... I don't have this in here, but I'm just curious about it. You know, 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 V1? You know, wait, I mean, this is v1. Okay, now, we've sort of figured out and everybody's on board, and, you know, mic-drop, there it is V3, is we got this, or has it always just been smooth sailing?

Donnie D’Amato
I think, as an architect of the design systems and done it a couple of times no. 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 what where the money's coming in, it's those features, right? Not necessarily so much of the design system. So, you know, 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, but absolutely, especially in places where there's an existing design system, from an architect standpoint, or for consultancies, they have questions, say, coming in, and identifying what the current organization is? What resources are today? And understand what these folks needs are, versus any other particular company that have different needs. I mean, even thinking about, you know, 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.

Troy Azmoon
Right, right. So 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 Yeah, right.

Donnie D’Amato
Exactly. And I've also seen it where the one product is driving that design system, and I think that works to a point. It's difficult because there's a little bit of bias in that product, right. And when you build a design system localized to that product, it's... you have to be a little careful that there's some communication against other products that the design system is expected to support.

Troy Azmoon
That makes sense. How about you Dave?

Davy Fung
Donnie had a really good answer. We could go home now. I think our problem at Disney is it has notoriously been the amount of platforms that we support. So 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. So like a perfect example would be a big portion of design systems and science Systems thinking is the need for coding components and sort of that may be good for, I think, 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 can implement then across the scale of our apps.

Alkistis Mavroeidi
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 to different businesses that we have. But there's definitely points there where we had to do big switches, and an example of that would be, for example, 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. So there is also a little bit of stakeholder management there that you have to deal with, whenever you switch things up, there is going to be an extra bit of effort, but you have to communicate and so 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... is, the design system and 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.

Donnie D’Amato
Quick comment, you mentioned the word future proof. I personally don't believe in future proof, because I think that future proof is like impossible. It can't be proved for the future. Future is ever changing. So I like to call it future resistant.

Alkistis Mavroeidi
I like that. I think it allows for change, because if you say your future proofing and then something comes up and things change, then you're kind of future resistant.

Donnie D’Amato
It's resistant, I caught that. Resistant.

Alkistis Mavroeidi
I like that.

Troy Azmoon
Good. Good. So, that kind of gets into the next thing I mentioned earlier when we were chit chatting, which is, from your perspective, what separates the great design system from the merely good? So, where do you say like, "Hey, you know, that's where this design system really stepped".

Davy Fung
The large portion of the design systems is not your component library. So it's the people behind that. So if you have a good support team, like 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.

Alkistis Mavroeidi
I think where I would put the distinction is, you know, a good design system helps the design team build components sufficiently, like help them deliver designs and iterations. But the great design system gets everything through into production and is the 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 a one source of truth for everyone is great. And I think it works very well, and it's a system for the design team to go back to. But that extra thing is fantastic, and it really scales efficiency into different level because then you have better handoffs, you have a one to one correlation between what you have your design files and your production files. So there's so many things that come together with a design system that's cross-functional.

Donnie D’Amato
We need a good resistant design system. A good resistant design system. I mean, I think I was just going to actually mention that there is, in my opinion, right now there isn't what we're trying to define as a great design system. I think a great design system is invisible. And we take a lot of time on, you know, doing a lot of legwork to get the assets and resources, make sure it's accessible and localized. And we're doing a lot of work in there, and shuffling 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. So for example, and I was actually speaking in the lounge with Davey about this, is that there is going to be a world which it's 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, right. The 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, you know, 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.

Troy Azmoon
Yeah, it's a good vision of the future. A lot of exposed API's, a lot of capability to extend on the fly.

Donnie D’Amato
Yeah, that'd be awesome.

Troy Azmoon
So what... here's a different kind of question. Is this 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.

Alkistis Mavroeidi
I can 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 huge shout out to that team, Matt Holmes, or brand lab, our all of UX, and product designers have done this. But I think for me, what has really drawn me into learning more about sound systems is that level of efficiency, and how many things you can actually build in, from a UX perspective as well. So you mentioned accessibility, usability and also brand, all of that going into building blocks, that then you can allow you to have that compartmentalisation. Well, that's a tough word. But, you know, 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's how product designers and the different expertises that evolve as products evolve. That is another fascinating aspect to it, for me.

Donnie D’Amato
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, you know, reuse pieces to create new experiences, you know, rapidly, much faster than the other feature folks were so that came from a need of having a component library where reusable artifacts, I can go ahead and use.

Troy Azmoon
Your motivation was laziness.

Donnie D’Amato
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, right? 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 features experience. I had like anxiety, like, is it the same like 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 homepage to login to their dashboard, to the cart, to the checkout, all of 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 that everything is relatable or familiar to them, that they don't think they're on a different site because it's a completely different experience. I think that includes that trustworthy part of the design system piece.

Davy Fung
I started Design and the Arts, so it was very much like, in design was where I used to play illustrator and I learned quite a bit by this very early like style guide type of thing, and I was remembering this, like, how far back 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, and one I think, specific thing that I always found that has been something that I discovered in the past few years of 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 like a television. So it helps expand your horizons, so to speak, on what product design is.

Troy Azmoon
Okay, cool. What do you think is maybe the biggest challenge as a design system expert, or representative? What's the biggest challenge there?

Donnie D’Amato
I think, it's people wrangling. I think that's the hardest thing for... because the assets are easy, right, those are valuable, 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. Yeah, that's quick one easy.

Alkistis Mavroeidi
That was exactly what I was thinking too. It's like 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 third 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, it's still going to be a lot of back and forth after handoff. Getting everybody's opinions, and making this a collaborative process is one of the learnings, also that we said in the talk if you can watch it online, but 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. I would agree.

Davy Fung
Alky had mentioned the word, source of truth. So 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 the designer needs. So 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.

Troy Azmoon
All right, well, have one more and then we'll open up to the floor here. Last one, you know, a lot of folks are maybe just beginning their design system journey. Or maybe they got a style guide, or they're looking at doing a refresh. You know, how to folks learn more about what's up? What are some great ways people can learn more about design systems, and best practices, maybe there's someone you know, or videos...

Donnie D’Amato
Is there a podcast somewhere? People can listen...

Davy Fung
I have a design systems podcast.

Troy Azmoon
That was not intentional. I was just asking the question.

Davy Fung
There's a lot of. I think where there's a firehose of information right now, which is I think, 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 StackOverflow, 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, you know, to each one of us. So for me people engagement and earning trust of designers and engineers, that's like 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.

Troy Azmoon
Okay, and where we should go? Anybody we should know?

Alkistis Mavroeidi
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 things, 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, get familiar with the unique challenges that its company has or its 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, I think.

Donnie D’Amato
Yeah, I think people will probably already know that there's like Slack communities and Twitter community about design systems, and, you know, those resources out there. But I actually think that, and this goes back to the way that I learned how to code is, you have identifying when you have a problem, and doing the research to solve it, is going to be the best way, right? You can go ahead and recreationally read books about design systems, or look at conversations about it, but until you have a problem that needs to solve, that's where you get the motivation to really dive in to solving that problem, I think, and that's how I learned how to code for example. And I think that would really also help in for people that when they have a problem, like, you know, how do I make a type ramp and or what's the best type ramp, you know, to use, like, you know, 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, you know, spoiler alert, they all have different type ramps, so you're going to have to also identify why you need your type ramp, right, 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 put an inject purpose into yours. So that only happen when you identify your first problem.

Troy Azmoon
That's all about identifying the right problem, right? So okay, that was great. We have a few minutes left, I want to open it up to the floor. If anybody has any burning design system questions. I see someone in the back there.

Audience Question
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 sort of like from your engineering team's perspective, do you get any pushback on being too prescriptive?

Davy Fung
We reference material design just for like 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 this slimming down, like things like our type ramp, and we do get resistance when we do want to promote like 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 like design system police comes up, which is a little bit something to discuss on a different day in governance and that sort of thing. I think that's what irks the engineering teams the most.

Donnie D’Amato
Yeah, so the design systems that we've used, have all been custom, more or less. Some of the things, like the assets that we've used, like, for instance, GoDaddy, was based off originally off 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, are custom to the people that need them, right, 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. And in terms of engineering pushback, I mentioned this into 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 the engineer and understand what those concerns are right? That 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 it's important in those conversations.

Troy Azmoon
Okay, that was probably our last question. We're running low on time.

Alkistis Mavroeidi
Right. So for design systems, similar answer. We also looked 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 conversations. 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. There's always going to be space for debate and pushback, but I think it's valuable from both ways, like, from design side, or an engineering side, the blue spott comes because there's usually a reason and then coming down to figuring out what is the reason? Now, 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. So it's a glue, so it creates a certain language for people to collaborate.

Troy Azmoon
And from our perspective, at ServiceNow, you know, our strategy as a company is to create a low-code platform. So engineering and design, product, everybody's been aligned, how important it is for us to roll our own and enable our 1000s 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, they're 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.