 Our next keynote speaker is Ken. He is currently the design manager at Facebook and is leading the business design team. He has previously worked with General Electric and Salesforce. He has actively been part of UX India Conference as a workshop leader, panelist, and a keynote speaker and is going to speak about design systems. Can we welcome Ken? Good morning, everybody. How about a hand for Andy on the last presentation? We're going to get a little more tactical here. Before we jump in, I'm really, this is my first time in India, my first time at the conference. And I'm amazed at the amount of coordination that's gone in here. The volunteers are fantastic. The warmth, just how welcoming everybody's been. It's been fantastic. So another round of hands for the volunteers putting the conference on and yourselves. Just thank you so much for having me here. All right, so let's start back at the beginning. This is me, about three years old. And this is where systems started for me. I've always been into mechanics and machinery. This is me under my toy car, obviously, doing some work. I've always been interested in how things connect and how you connect one thing to another and the systems come together. Also, while I was growing up, my father was an illustrator. So I have a high level of appreciation for the craft. And these are the types of things that are around our house. So markers, gouache, graphics 360 pads, moldy coffee cups. I cleaned a lot of those growing up. But those two things eventually combined. And I ended up in a career in, originally, graphic design. And you'll see a lot of companies on here. This is what I call my t-shirt resume. If you work in the Bay Area, you get a t-shirt everywhere you work. And I've collected them over the years. But there's a lot of places on here you might recognize. A lot of them you won't. A lot of them that don't exist anymore. And one in particular was I spent about a year at eBay. And while I was working at eBay, I worked on the style sheet and the style guide for all the buttons and all the little widgets that were all over the site. And I remember being really frustrated that I couldn't. I would draw the button once. But then it was up to the teams to consume that button. And it was almost impossible to update it consistently across the site. And I got so frustrated that I left. And fortunately, years later, that eventually evolved into the last five years where I've been focused on design systems, and particularly design systems for business and enterprise. As I progressed in my career, I've just gotten more interested in harder and trickier problems to solve and also more engaged in the type of products that business and enterprise provides. Like the idea that you're building something that is critical to someone's livelihood, that someone makes their living off of, is really fascinating. I feel a great responsibility for that. So I spent some time at Salesforce, G.E. and Facebook. And really my time at Salesforce started down on a product team where I worked on Sales Cloud, which is kind of what you would think of as the core of Salesforce, the CRM. And I was fortunate to be there at a time when they decided to revamp the UI for the entire product. And this was an effort called Lightning. A lot of you may have heard of it. But I was really lucky to be there because it really informed how I worked today. They basically reoriented the entire company around this effort while I was there. And fortunately, its priority was Sales Cloud. So I was right in the thick of it. So I saw a lot of operations change. And I saw how the company aligned around that. And more importantly, I saw how valuable collaboration was. So something really clicked in my brain while I was there. So we shipped Lightning over the course of about nine months or so. And out of that work fell the Lightning design system. So I was responsible for a lot of the core patterns in that. So page headers, page layouts, that sort of thing. And I said, oh gosh, this is what I wanted to do at eBay. I can do this. And it'll actually affect the entire product. So eventually, the time came to move on from Salesforce. GE came calling. And what's cool about GE is my interest in machinery and how things work. And it doesn't get any bigger than, say, a wind farm or a gas turbine out of Power Plant. And the use cases are such a variety. You have the guy on top of the wind turbine here. You've got another guy in a dark control room. And all of their big turbines have sensors on them. And they're being instrumented. And that data goes into the cloud. And there's someone on the other end of that, the guy in the control room, that has to make a decision as to what the data is telling them. So I got to work on the predicts design system. And that provided all the components and the guidance for building these applications to help these people really analyze what was going on in their big machines and decide whether to do maintenance or whether it was working OK or otherwise. So it was really interesting and really fascinating to work on that sort of thing. And then eventually that led me to Facebook, where over the last year we've been working on updating the ads and business UI across all of our ads and business products. And a lot of you are probably like, Facebook has ads and business products? Yes, we have a lot of them. It's been a really interesting experience. I've taken what I learned at GE and what I learned at Salesforce and applied it at Facebook. And Facebook, for those who have talked to me here at the conference, it's a really collaborative culture. And you really have to learn how to work across disciplines to make things happen. And we ship a lot. So there's a lot of little moving pieces to it. So we've been focused on updating all of our ads and business products to a new design language. And it's been really, really fascinating and really exciting to be a part of that over the last year. So let's get into design systems. When you think about design systems, you're obviously going to start with design. And a lot of people, they may get this started with the system by putting together either a sketch kit or a UI library of some sort. And sometimes they stop there. This is all your widgets, your dropdowns, maybe your navigation and that sort of stuff that live in a graphic file. But that's not a system. That's a style guide, right? So the value of a design system is really the code behind it. That makes it portable, that makes it reusable. That's where you start to see the value. You're saving developers time, you're getting that propagation throughout all your products and your consistency. But the other key part of it is documentation and tooling. So you have to tell people how to use your design and your code together, right? You have an opinion in your design, you want them to be able to assemble it in a way. So that's consistent across the app. So one of the things we say is it doesn't exist until it's written down. And you also have to deliver it to people. So documentation and what I mean by tooling is like mechanisms to deliver the system. These are really the three core parts of it. But if you came here today, the title of this indicates that maybe I would provide you a list of components you need to make for your design system, that's not gonna happen. Sorry to disappoint, if you want a list of stuff, come see me afterwards, I'll rattle off 15 different components you need to make. I'm gonna tell you how to get this list of components because if those of you who were in my workshop the other day, I kicked it off by saying everybody's design system is different. There is no one standard list of components. You have to make the system fit your organization. And let's talk about how most people apply design systems. So typically you have a system that sits maybe over here, you've got your product over here, and what people try to do is just do a one-to-one mapping of it, right? Hey, can you update your dropdown to the dropdown for the design system? Hey, can you update the button so it's consistent with the design system? And really what it means is more work for the product team. So what happens is when it gets stack ranked against other priorities, all your great design system work goes in the backlog and it never sees a light of day. So really you gotta back out a little bit here and you need to think of your design system as a product because what's happening in that state where it gets pushed into the backlog is it's not really adding any value for anybody, it's just creating more work. So there's two customers for a design system. One is the people that are actually using the product, right, this is your, in the case of Facebook, it's people managing their advertising, creating their campaigns, but you've also got a set of internal stakeholders too. So that would be your developers, your other designers, your product managers. And it's important to recognize that a system needs to solve a problem for both of those people. So let's think about where that value really is here. So if you look at the spectrum, this is typically how people will apply a design system, right? We have styling only, which is kind of what I talked about a minute ago, maybe a component swap or just CSS overrides to make things look the same. In the middle, maybe they're rolling out new features with styling and then on the far side, you've got a redesign, which are pretty unusual and pretty expensive. That's more or less what we did with lightning. But if you think about the value spectrum on there, the bottom dev work is roughly the same all the way across the board, but the value to customers and the value to, to your internal stakeholders is really towards the right side of that spectrum there. You're gonna have to do the work anyway, might as well deliver something new to the customers rather than just moving, moving their elements around and making them consistent for your company, right? There's only a self-serving purpose to that. So what you're after, you really wanna build this, this relationship with a product team. So the design system informs their products, but the products also inform the design system. And you need to build these relationships throughout your company so that the system's always evolving throughout the products. You're actually grounded in real use cases. So these three things I mentioned before, can these deliver on that promise? Are these gonna give you a connection with your product teams? Not really. They're all about delivery of the system. They're about how you get it out to people. So how do you know you're building the right things if you don't have that connection with the product and the end users? It's not about the technology behind it. It's about relationships. So let's start with socialization. So you're gonna create a design system where maybe you've got an existing one. Maybe you're gonna do a new design refresh for when it's out there. You've got to tell people about it. You've got to really open a design process and invite people in and let them know it's coming. Design, you know, for a lot of designers, it's a black box for everybody outside of design. Like we know how it works. We know the thought behind it. And oftentimes we get up in our head and we'll go disappear for a little bit and come back and, you know, we'll have our mock up, our prototype and hold it up and be like, oh, we made you, right? They don't have any idea what the process is behind it or why it is the way it is. When you combine that with how frequently a system needs to change and how many products it needs to impact, that's a bad thing. You can imagine, you know, if you had a component on a site and it kept updating maybe like every week and no one knew why, they'd lose trust in the system. So it's really important that we open the process. If you're working on a system, you've got to invite everybody in to contribute. You've got to communicate frequently and regularly and let them know exactly what's going on, even if you don't have all the answers. So this is an example from GE. When I started there, the system existed, but it didn't have a lot of adoption and actually it had a lot of resistance. And I went out, one of my first things I did was I just started interviewing stakeholders and I was like, what's going on? Why aren't you using this? And, you know, I would get a list from everybody. And one thing we decided to do rather than dig our heels in and say like, nope, you know, you have to use the system the way it is, is we set up a series of workshops and we invited everybody in and we heard their point of view. We had them present their take on the system. We also had them do ideation. So we did sketching. I framed the discussions. So I said, here's what we're going to talk about. This one, for example, is for navigation. But what that gave us was when we did update the system, we were able to point to things people contributed to and say like, yeah, we made this because of the input you had. And that went a long way. But I also want to point out that did not only include designers, right? It's really important to include your cross functions in this. So that means, you know, engineering, data science, user research, of course, product marketing in some cases, like invite everybody in. Tell them how it's done. Share the process so they know how to do it too. This is at Facebook. This goes back to kind of my roots of being analog, you know, back in my dad's studio, but I love big boards. And, you know, I put them up in the office and every day I would print out our work and I put them in a really high traffic area, right? So people would walk by and they'd be like, oh, what's this? You know, and there's so much noise going on at Facebook every day that sometimes you just have to go gorilla and put your stuff up and get it literally out front of people. So you have to get creative in the way you're socializing this work, but you have to let people know it's happening. Likewise, I know a lot of people are in distributed offices, you know, so maybe a board wouldn't really work. In conjunction with this, you also have to do digital delivery mechanisms. So we use workplace internally, of course, so daily, weekly posts. We also have a tool to share designs internally. So everything we worked on, no matter how rough it was, went up there and people could comment on it and see how it progressed. Likewise, if we had a review, we'd share the good feedback as well as the bad feedback and what we were gonna do about it. So it really opened up our thinking and gave you a lot of confidence that we were headed the right direction so that when the time came to roll out the system, you know, they knew where we were at and they weren't asking questions like, why is that button blue or why is the radius eight pixels instead of 10? So once you've socialized it and you let everybody know it's coming, people will pop their heads up, right? Like maybe they were heads down in their cubicle working before and then they kind of see these posters up or they see the post on workplace. That's where you start to develop partnerships. So here's what you have to watch out for with partners. You can't help everybody. You wanna aim for influential product services and what I mean by that is services that have a lot of eyes on them, right? Or maybe it's a high value workflow for your product. It's something that's valuable to your users and internally as well. And that's like an example of lightning. We use the sales cloud flow. It was the core product, right? It had an impact at Facebook. We're doing it with ads manager. That's the main ads product, right? It's things people see and things people use. So when you have a design system, you really wanna partner up with those influential services. But partnering isn't enough. You have to make sure you're after the same thing. So you also wanna align on your priorities and create shared goals. It doesn't make sense to partner up and have a misalignment on what you're creating. Maybe you find a team and you're like, hey, we wanna work with you and they're like, yeah, well, let's have for we're doing backend performance work and we don't have any UI work. That's not a good opportunity to partner. You wanna find alignment on the roadmap and create shared goals. Like we wanna make a better experience overall. We would like you to come along and help us. And out of this, you really wanna angle to make the system as real, like as soon as possible. Don't pause to make it a system first, like get it out in front of people. So if you think about a roadmap for a product as an example, maybe there's three releases, right? One is performance improvements. There's not a lot of front end work there. There's a new UI feature coming down a road and then maybe following after that there's some Perf and new UI stuff. You're probably not gonna wanna partner where just for performance improvements they're not gonna wanna work with you or you're gonna have to pick up all the work for the team which will not make your team happy obviously. So really what you wanna look for are these opportunities to integrate where they're gonna update the UI and they're gonna deliver some value to their customers. Remember that spectrum I showed you a couple minutes ago? That's where you wanna be. So here's how we did it at Facebook. So this is Ads Manager. It's actually a combination of two different products that's been out there for a couple years now and it hasn't changed much. And as products do, they just get more complicated over time. Facebook's growing like crazy and there's a ton of use cases to accommodate for. And things just get a little long in the tooth. So it was time to take a fresh look at it and due to our socialization efforts we learned that there was a team inside it that owned the surface that said, oh, you know what? It's a priority for us to update this. You've got a new design language that sounds like a great opportunity to work together. So rather than working separately, design system team goes off and maybe does an update on how we apply our patterns to the surface and Ads Manager team goes off and works on their patterns. We got together, like actually together in a room for three weeks and updated this together. We took in our initial version of the system, you know, our buttons, our spacing, general styling and applied it to their use cases and we're able to make some tweaks to the system so it was actually accommodating for real world use cases. And going back to my earlier point, like everybody was in this room. This was not just designers. This was content strategy. This was research. This was data science. This was product management. And having everybody together in one room allowed us to move really quick. You know, we had questions. Who uses this? How much is this being used? We could pull that data up right away and make decisions on where to focus the UI. And to get it out there, we didn't wait. We said, okay, this is a central change. We need to get some early signal. So we rolled out an alpha soon after that. And, you know, it wasn't everything we wanted it in terms of the new design language but it was directionally there. You know, we changed some buttons. We changed the spacing. We got the colors kind of in the right ballpark. And those of us on the system team were like, oh, yeah, it's not there. But, you know, and what this allowed us to do, though, was get early signal on how well things were working, right? So we came in with a bunch of hypothesis for how the system should be. And once you put it in the product, you know, we learned. Some of our stuff was wrong and we had to adjust. So we got some feedback on it. And actually nothing was a component at this point. We just styled it. So consider it like a beta for the system. And we got enough feedback on it to iterate on it. So by the time we did roll out the real system a few months later, it was rooted in real data. And we knew it was usable. And our customers would be receptive to it. And you'll notice here, from that first screenshot I showed, there's a lot of functional changes in here too. So you've got some, the way the table works is now different ads and value. It's got a hierarchy to it. We've collapsed the filters down. We've got a new navigation that's flatter. Like these are all things that actually evolved into our design principles for the design language too. So we were able to pull this out of the product. So you've made some noise. You've got your key product out there. People are noticing things are changing. People are going to come running to you now. You're going to have a line of folks at your door like, oh, I'm next, help me. You can't help everybody. If your team is like mine, I know a lot of teams are distributed. Maybe there's a couple people working on a system across different audiences or different offices. We're fortunate at Facebook we have dedicated team on our design system, but we're small. We are a team of six, and we have to support hundreds of designers. And then potentially thousands of developers. So what do you do? You have to prioritize. We have a saying, this is one of our company values, focus on impact. So what that means is really focusing your efforts on the things that will drive the most value to the customer. And I think this totally applies to design systems because you can't help everybody all the time. So look at your data, look at what's being used, how frequently it's being used, maybe look at revenue across the surface, look at design system coverage, and triangulate all those data points, and that will give you a stack rank of where to focus your efforts. But sometimes the effort comes down from above, right? So this is lightning. Company culture at Salesforce is very different than Facebook. Facebook, it's bottoms up. Salesforce, it's top down. Mark said we're doing lightning, right? This is also fantastic. It gives you a good calling card when you show up to team and say like, this is a company priority, we have to work on this. But oftentimes it's a mix of the two. So what we have at Facebook now is obviously we're doing ads manager, and there's other strategic initiatives that we have to stack rank in there too. So it's really an art and a science to prioritizing. So focusing your efforts, really what you need to do is look at the data and the metrics behind the products to create a stack rank and prioritize what to work on. Hit the most meaningful surfaces that are gonna add the most value to your customers. And of course cross-reference with strategic initiatives, the big boss is gonna come down and say like, no, we're doing this now, right? You have to accommodate for that, that stuff always happens. So it's a mixed stack rank of stuff, you can't solely rely on data. Sometimes you hear it from customers too, we really need to fix this thing, it's not working well. But what's most important is you need to go back to the socialization. And then you need to really communicate to all your partners why you're focusing on these certain things and how you'll support them, how you support everybody else. Most of the time, I haven't had an issue yet, where you show up and you explain, you can articulate why you're focused on these certain surfaces and maybe not another one. And if you can align it to company goals or you have some data behind it, people agree. And they say, okay, I understand, I'm happy to work together however we can. So it's really important to get out front of that and just communicate as frequently as you can. Priorities also change, and they change, also remember, get it back out there again, some people know. So there you go, there's the components of the successful design system. It's not a dropdown, it's not a navigation, it's all these soft skills. And I think people often forget about this when they jump into solutioning for a design system. But what you'll find is if you invest a lot in the socialization, in the partnerships, and in prioritization, they'll inform the delivery and the solutions. You know, if you get out and talk to teams, learn how they're working, that's gonna tell you whether it needs to be a sketch file, whether it needs to be Figma or something else. It'll also tell you what JavaScript library they're using. Maybe it's Angular, maybe it's React. Maybe it's all of them. And then it'll also tell you how they're gonna consume it. Also learning how they work, like how, what's the best way to deliver the documentation? What's the best way to create some tooling around how we deliver the system to them? It's really basic UX design, right? Go focus on your users. How are they consuming the system? Treat it like a product. So if you go back to this, and you've built these relationships, and you have your symbiosis with your product teams, that's where you're gonna get your list of components from, right? And it's rooted in actual use cases for the product teams. You know how the customers are using the product, and you know you're building the right thing. And this list is gonna be different for everybody. And it's important to start with the relationships there. And if you do this enough, what you'll start to see happening is your design system becomes a hub. You'll start to see product teams pop up, they're pushing and pulling against the system, the system's continually evolving, and they're coming to you, they're coming to you not only for design advice, but also how you're operating, right? All those workshops I mentioned, design deep dives, that sort of thing. It becomes part of the culture in your company, and that's really exciting. And I think this often gets undersold in terms of a design system, is the cultural impact it can have across your company. And you don't have to have a dedicated team to do this. As long as, you know, if you can work distributed, as long as the communication's happening, and you all have a plan around it, you know the design system can become a hub and really impact the culture of the company. I've seen it, you know, I saw it at Salesforce, I'm seeing it at Facebook now, and things just orient differently if you have a centralized effort to really update the UI that people are excited about, and they feel like they're invested in and can contribute to. So, my ask to you, don't jump into the solution first. You know, I've had a lot of people come up to me at the conference, and you know, and they're like, what JavaScript library should we use? What components do we need? That's solutioning. Start by identifying the value, like where are the gaps? Where can a system help your company help your end users? That will tell you what your solutions need to be. Open the black box of design. You've got to remember to do this. It's uncomfortable. It's not a reflection on your skills, right? What you're doing is democratizing design, you're opening the process, you're showing everybody how to connect to the end users and add value. Particularly with, you know, myself, it took me years to do this, to get comfortable with this, to show a sketch to someone, to get comfortable with their marker board sketch. Any artifact goes a long way to give me an idea. Just have something visual. One of our tenants in the team at Facebook is show, don't tell, you know, and that can be anything. It's a mock-up, it's a sketch, it's a prototype. You just need to have something to illustrate the process and how you ended up with where you're at. And then finally, we have another saying, ruthlessly prioritize, you know, really focus your efforts, make something great. You can't make everything great all the time, right? So stack-rank those priorities and really determine where to focus your effort, particularly if you have a small team or minimal resources to put towards it. And this isn't stuff specific to a design system. Any of you out there working on any product or any UX design can apply these things. Do all these three things, you're gonna ship great stuff. So thank you again for your hospitality and warmth here. Appreciate it. Thank you Ken. And as a token of appreciation, I would like to call Mr. Ranjit, co-chair of UX India, to give this momentum to him.