We have people from diverse backgrounds and we will be discussing about design systems and trying to go deep down and understand that what had been their experience in setting up their systems in their organization, right? So I will be starting with a question and I would like to kind of hear your opinions, all of your opinions on that as we kind of move along, right? So the first question here is that we see more and more organizations are now building their own design system. There is a lot of hype because there's a lot of talk about design systems. Everybody is discussing about that. And since in this group we have people who have built it, who have used it. So we would like to understand that is it kind of, do you feel it's over-hyped or is there a real value attached to the organization? So there are, of course, obvious values that we sometimes know and there are sometimes values that comes out of it after we have implemented it and then we realize that, oh, wow, this is also something that is getting done with the system, right? So I would like to understand and hear from you, each of you. Sheva, you want to take a start at this? Hey, everyone. So that's a very interesting question that you just raised, Shayak. I do believe, so I am from the side that believes that design systems are necessary. I believe terms like material design, fluent design, these terms may be getting over-hyped, but the need for a design system does remain. Why? Because off late we're growing in, we are all working across geographies in distributed design teams. And it's very important that as growing design teams, as people who are looking to onboard to new design systems, we have a consistent, a uniform language that we can all converse in and work together and hopefully then give back to the system. So I believe that for people from diverse backgrounds coming together, it is something, you need a basis to communicate together and to have, to even build consistent experiences for your users. I mean, for them to, because we are now living in a connected ecosystem where a user is on a mobile phone and then they could be on a laptop or even a smart TV the next moment, it's important to give them that consistency and experience. And that is where I believe a design system does play a major role in giving them that coherent sort of an experience. Steve, you would like to add something to that? In my point of view, design compared to maybe 10 to 20 years ago, currently design is a play key important parts on the business itself. We have so many in Indonesia, we have so many startups who already have validated business model. And then there are only several key players and UX and design is the key point to win the market. And then having how we deliver product fast, how we build consistently high quality design is a must thing to do and design system help us to grow to the next level. And it's also bring our collaboration to the next process where design becomes more inclusive because design system is not only for designers, it involves developers and the mindset itself involves all the business stakeholders. That's in my opinion. I hope they're not overhyped because I've been working on them for the past six years. I think outside of the obvious benefits of reusability and portable code and that sort of stuff, one thing that gets overlooked is the cultural benefits of a system. When you have a team working across various products that are typically siloed and you're the connective tissue between those, that's a big benefit for an organization. And I think people don't recognize that immediately. So when you get executives trying to quantify your value, that's not something that you can easily quantify, but when you look at the quality of the products as a result of the collaboration as a direct benefit of maybe not necessarily the system itself, but the way the system works. Something I think we should pay more attention to. Yeah, I think that's something that people are also discussing about, right? About community. Would you like to? Yeah, so I definitely don't think they're overhyped, but I would offer kind of a word of caution that understand the problem that you're trying to solve for your company with a design system. If it's just doing a design system because it's the cool thing to do, that's not probably gonna get you as far as if you really go out and think of this like a product that you're designing. Your design system is a product. So who are you helping? What problems are you trying to solve? It may be different than the problems that Facebook or Ovo or Salesforce are trying to solve, right? So make sure that you do your homework, do your research internally to understand the process well and know that you're really solving problems that people care about with that design system. But other than that, yes, I completely echo what you said, Ken, I think the sort of hidden benefit was one that we didn't expect, but finding that developers and designers who really didn't talk much about the way that they were making things started to talk more. And teams that are in different silos, different parts of the organizations, they start to come together because you have something for them to come together to talk about. And like I said, I wasn't expecting that when we rolled out our design system, but it has been sort of the hidden and secret benefit of a design system that I would say I'm almost most proud of in what we've delivered. Amazing. Yep. Yep. Okay. So follow it up with a little serious question that how do you measure the success of design system? Right? Okay, Nick, you want to take a stab at it? Sure. My first answer is I don't know. It's not easy. Don't have any magical formula or thing like that to share with you. I think there's lots of things that we could go and measure. And I think we probably don't do as good a job of measuring that as we as we should. But I will say that the the things that I see and the reasons I know that it is adding value is I see people reach for it as the tool of choice. And I see systems being created, products being created with it, that I didn't even realize, like we didn't push it on them, they just went and used it. And so seeing that and hearing anecdotally from designers and developers about how this helps to speed up the process and get things created faster. So I kind of know it is, but I couldn't put a number on it. And sometimes that's frustrating. Can we can put a number on it at Facebook? So we have we for those who are in my workshop yesterday, I kind of hinted at some of the tooling we have. And we write a lot of our own tooling at Facebook. And one of the things we do for the design system is we have a little, a little bug that sits on the browser and you can actually look at code coverage for how the components are on the on the products. Right. So you can run that across all of them via screenshot tests or otherwise. So we get a sense of like what our what our coverage is. And we have metrics as a team that we want to hit, which tells us who we need to go work with to meet that goal. So you know, it's it's rare like I worked like we didn't instrument things at GE. We didn't instrument things at Salesforce.  But you know, I would say the irony is at Facebook, people already get it. They know the value of it. So it's, you know, we don't necessarily prove ourselves as we would have, you know, maybe GE. But yeah, we do measure it that way via code. Okay. Yeah, for me, mostly, there's three things. Yeah, for sure, a visibility, clarity, and then the consistency. But I have a cool story in when I was working in Socopedia before, before this, before at OVO. We have a mobile site, which is the metric is first interaction loading page. So it's measured when you are in first interaction to the browser. Before we implement the design system, which is the code library, it almost took 10 seconds. And then after we are defining our design system and defining a code library, we fine tune everything, it can reduce until three seconds. And it becomes a Google, Google success story of mobile page website in Indonesia. And that's one of key impact that you can show the, the, the success metrics of the design system, how the impact itself. So that's my additional point. Shavya, you want to add something? So I agree with what everybody said. And maybe what I said, say will be a repetition of what they already said. But I like the wall mentioned, I believe the, the, it can be measured in different ways. There is an internal measurement and there is an external measurement. When I say internal, there is a team that works on the design system to, to maintain it, to work on it, to add to it. How, how is it being adopted across the organization? Is it helping designers get better at, at, you know, faster and building more consistent and uniform experiences? Is it helping designers and engineers work better together? Because I believe that the design system always works along with a component library. So, you know, is it making that collaboration simpler? Also, something that is a little hard to measure, probably, because, you know, design has very, it has a sensory aspect to it. So are your designers happier with the design system in place? Is it, you know, is it, does it add delight to their lives? Is it making design a more pleasurable, joyful activity for them? Does it help them communicate better? And then, of course, the external measurement, are your users happy with it? What is the ROI? What is, what is the difference that they see between, you know, coming from a previous design system to a newer one or probably migrating to a design system from a place where we didn't have one. So some of these things can be measured like Ken said, at Salesforce we're in a place where we're trying to quantify these and we're trying to instrument for these. But yes, some of these are, these, some of these are things where you have to go to speak, speak to users and get a sense of, you know, whether your investment is working for them and it's helping, you know, build better experiences for your users, basically. Interesting. Since some of you mentioned that we are able to measure some part of the design system, do you think we are able to take them to the leadership and kind of, you know, kind of, kind of have some say on the table? Are they at that stage or is it like we are still at a very fundamental level? We are just measuring it and maybe someday we will be there where we can take it to the management meeting and say that this is performing at a certain level and you know, like we have this result out of it. What's your thought on that, Ken? I mean, yeah, I mean, we can do that. I think what we're seeing right now at Facebook is merging kind of that, that metric I talked about along with the social aspects of it and improving the quality of our products, which goes to your point about, you know, user satisfaction. Are we making it easier to get their job done? So we have an initiative in place that, you know, the design system is a core part of, that we look at quality across all the products to where, you know, I think it will potentially become a release gate for stuff. If it doesn't meet that bar, like, you know, it's not going to go out. And the design system is a core part of that. Okay. So coming to a little more, again, a little more difficult question, what are the biggest challenges that you faced when setting up a design system? Nick, you want to start with, I'm sure you would have a lot of things to share. Yeah. Biggest challenges. I'd say we, so this is a mistake to avoid for you out there who are pursuing this journey as well. We got people on board our leadership. They understood why we wanted to create a design system. They put forth the money to get a team together and actually go do it. But what we failed to do was put into their minds this understanding that a design system needs to have a product team supporting it for the long haul. And so we ended up, you know, having seven people working on this design system to get it out, released, and then kind of iterated with kind of a round of fixes. But after that, it was left to like two people in their spare time. And that's not the way to do it. So you've got to have that conversation up front with leadership to let them know. Not that we didn't ask for the team later on, but I think making that expectation very clear up front is something that I would recommend. And so the challenge then is how do you help people to see that the product team is needed and is necessary when the leadership may just see, hey, people are using it. It's working. What more do we need to do? So being able to tell those stories well and this is probably where doing some of the instrumentation and capturing some of this stuff can help even more. So that's, I'd say, one of the challenges is treating, you know, making sure you've set yourself up well for the long haul, not just an initial implementation. Yeah. Ken. Yeah, some of the biggest challenges I think, you know, and what I saw at GE and maybe even maybe some of Facebook is people think the system's taking work away from them or taking creativity away from them. Developers, you know, likewise, like I want to make my own thing. So it's it's getting people to shift their mindset to realize that it's a benefit to them and it's going to allow them to focus on the bigger problems.  Don't waste your time on that. Like focus on the big stuff that's going to make an impact for your customers. And that takes a lot of socialization, you know, to get people on board with that, which means including them in the process of ideation and bringing them along. But, you know, I think that's just consistently a challenge when you bring out a system. You still have that mindset, you know, eventually it'll probably change.  Yeah, yeah. Interesting. Steve? Yeah, quite similar. But in my opinion, there is another challenge that I can add. It's more about maintaining the design system itself. After you have defined design system, you have already implemented. Maintain itself is another challenge. How to make sure that design system don't kill your designer creativity. After we allow the design system for several months, our designers is like, okay, just I will just follow the design system. And then yeah, don't want to put my effort to exploring the others. And then it's make our design kind of left behind compared to other new style or maybe new trend in the design that they that have a good user experience. So the challenge is it's more about how to make the design system as a platform for collaboration. And if we want to explore it, it's very open and it's if we want to solve a problem, it's make us become what I can say is a broad mindset designer who think that if we want to contribute a component, we need to think brought across our products. That's the mindset that we have to put to the designer. We are not limiting them. Interesting. Yeah, I think we'll come back to this part again in more detail. Okay. But before that, you want to add to this. Just a couple of points. So something that I've noticed, like I said, we're working across distributed teams. One thing that I've noticed is especially when you're transitioning from one system to another or say from some sort of a status quo to a new system is getting everybody to onboard, encourage them to adopt it at fairly the same time. That's kind of hard because, you know, you want them to sort of get on to it at a particular time so that everybody starts designing with the new system in place to is to getting to encouraging them to contribute back to it. It sort of stems from what Steven has just said to contribute back to it. Because, you know, if we don't contribute back to it, it just a design system is a living system. It needs to grow. It needs to get better. How do we, you know, get to the next stage because the more the users, the more designers adopt it, the more they're able to, the more problems they're able to think of that, you know, could have been solved in a better way. The original designers who set it up, I'm sure there's so much that you can do beyond it. So getting people to contribute back to it and then third, because we at Salesforce, we're a very customer centric company to sort of convince your customers as well to, you know, to tag along with you in this journey and for them to onboard into the new system as well. Because we have a flourishing network of partners who help us maintain things like these. So getting everybody to, you know, just just on this ride, it's that is I think a huge challenge getting everybody to sing the same tune at the same time. Can I add one more thing? Y'all reminded me in your comments. So one of the other challenges that we faced was teaching people how to think about using a design system. So not just how to mechanically use it to, you know, pull down the code in the components and access the documentation, but to teach them to think about how to be strategic with using a design system. It's fairly simple to train people on the tactics of using it, but to teach kind of when it's right to kind of try something different, because we want people to understand that the design system doesn't solve 100 percent of your design problems. There are a lot of common problems that the design system solves. But what happens when you come to one that is not quite solved by the system in the way that we anticipated, we want people to feel that they can solve that problem the way that they always have, but while kind of referencing and respecting some of the general kind of style and guidelines of the design system. So some people we found had the misconception that it's the law.  And others didn't respect much of the components at all. So there's a balance between that and so getting people to think about when is a good time to try something and evolve something and solve a problem a little different way, and when you probably shouldn't just redesign the button because you want to. So that's one of the other challenges that we've seen. Do you give the example of Legos in such setting, because you are working in Lego at one point of time and you know, Lego blocks are exactly that. You can use it to kind of build any creative stuff, but at the fundamental level they are the same pieces to some extent. Yes, exactly. I love thinking about it as Lego building blocks. Yes, that's right. Okay, so I'm coming to the next question. Actually, this is kind of follow up on what you were talking about. Who owns it? I mean, who owns the design system? And then like, is it a single percent or is it a kind of partner mode? How do you manage it? Okay, so at first, the background behind it, the main supporter when we have Initiative for Descent System is not designer in my case. It's the engineer. You know, modularity, reusability, they already know it decades ago. And for designers, I think it's a new thing for them because design already complex, be part of the product itself. And then who owns it? In my point of view, it must be owned by every product development team. Product development team consists of engineering, product design, and also business who will handle the operational on the product itself. Why? Because, you know, the point is of Descent System is how we make all of us focus more on the problem instead of building or crafting something or reinvent the wheel. That's the main problem. So how we move faster and then using Descent System as a tool to help us to win the market, like I say before. So in my opinion, it must be owned by all the product development team. Good. Yeah, I mean, there's a subtlety to that. Whenever, you know, I go out and do a roadshow to teams, I'm very careful to say, like, that we curate the system, like my team curates it, we don't own it. Because, you know, like you're saying, I want everybody to feel like they have a stake in it.  And, but, you know, I want everybody to feel like they can push against it and contribute back or, you know, they have a stake in it as well. And I think that's really, really important.  So yeah, that's kind of my perspective on it is like, you know, curation over, you know, holding it close and owning it. Right. Yeah, I second that. It's a similar kind of a situation. We try to make sure that this feels like something that belongs to the community at large. And we, but, but to my point earlier, if you don't have somebody centrally to curate it, then, you know, nothing really moves and nothing really happens and changes and improves. So it is, it is a partnership there. But yeah, I think the point of talking about it as curation or facilitating this community is, is the right approach. The, the other thing that, that I've seen is it's going to vary by company, kind of maybe who takes the lead in some of this, because similar to what you said, Steve, they, the primary customers at ExxonMobil are our software developers. It's partly a function of numbers, because we had just been growing our design practice and didn't have a huge design team that was doing a lot of this work. We were trying to scale the impact of a small design team through a design system that could help to enable the teams where they didn't have as much design support as they needed or there were engineers that just needed sort of a, a starting point to, to get on some of this, you know, better user experience into their, their products. So, we have a lead who is a front end developer and we see a lot of benefit of being able to connect with that community directly through him. But of course then we have others, designers who contribute to champions and things like that. But in our, in our organization right now, the primary kind of lead is, is a front end developer. So, before coming back to you, Shavya, I just want to take a small detour here. The fact that we, I mean, we four are coming from a little leadership position and we want, we have a vision of the design system in an ideal way, right? At the end of it, the, the junior designers or the young designers who are executing it and typically designers come with a, you know, a teaching or education of being crafty. I mean like they have to craft something and a large part of that is taken away from them when we do have a system like this. How, how does, how can these young designers build up the maturity to kind of understand that how can they contribute to this system as a whole? I would like to hear all of your opinion. Shavya, I want to start from you because you have probably just gone through that, you know, a journey of owning the entire craft to kind of contributing. So yeah, how is that? Yeah, so to add to what Chayak said. So I'm in a sort of a position where I'm an individual contributor. I'm consuming the design system as well as I'm a proponent of it as well. So what we have at Salesforce is we're transitioning from an older design system to a newer one right now and we're a distributed team. Right now it's very important to educate people and to onboard them at the same time, like I said. So we have an interesting ambassadors program at Salesforce where, where in every member, you know, one member of every design team understands about the design system, explores it, tinkers with it and advocates for it in their respective design teams. They also very interestingly serve as a bridge between engineers and designers. So they're able to speak, you know, they're able to sort of mediate and get to a position where the design system can fulfill engineering needs because what happens sometimes with an with a design system that's growing with that's something that's just coming up is there will be a pattern but they might not always be a corresponding component to support it. So, you know, what do you do in situations like these? Where do you get to a path where experience is not compromised because that is a major fear with entry-level designers that, you know, they're not going to be able to solve the problems in the most optimum manner and that the system is going to inhibit, hinder their creativity. So solving, you know, reassuring them on that front and seeing opportunities where probably, you know, we could pick up something from the design system that it could still step into the place and take care of things. That is a very important part and that is where we have these ambassadors in place at all our teams. We have something called office hours where we set up sessions with the central design team. So ours is a co-owned one as well because I believe that's the model that works best. There is the need for a team that dedicatedly looks after maintaining and adding to it but other teams who actively consume and give feedback so that the design system grows. So ours is a similar model but we have an office hour system where individual designers, again, that is something that I help set up, establish, you know, set up some time with the central team, understand why a certain component was built and how this new designer can possibly incorporate it to solve the particular problem that they're looking to solve in the best possible manner. Steve, you want to add something? Yeah, for sure. So changing in the mindset is one of the challenge also, especially for the designer who really skilled, high skilled in crafting or building the stylist design, you know, and I remind them that what is designer? Designer is a problem solver. So you, as a designer, not only crafting the styling only but you have to solve the problem. It's okay with the product but how, for the visual, okay, the visual, the problem is this kind of component need to be used across all products and need to be consistently high quality. So that's a problem that you need to solve when you're exploring things. So I give them the challenge. It's okay, everybody can contribute to the design style but that's thing to be keep in mind. So yeah, back then I add some procedure. You need to give a PRD, PRD is product requirement documentation to enhance or build the component so they can learn a structural thinking. After they already have that mindset, I remove that policy because it makes our process long and then as long as they have the structural thinking and then when they are improving or designing and put some of their idealism, they still have that structural thinking and have it well tested across the product, across the experience to be implemented in design system, it's okay, we can review their commit or their code or their design. I think I'm seeing this as less and less of an issue. With the least the candidates we're seeing coming into Facebook, right? And what they're coming out of school with it's more about the broader problem solving and we do a, when you're a new hire, we have a design camp. Your first week at Facebook is design camp where you learn everything about how design works and how you should be working cross functionally and that sort of stuff. That is a segment on the design system and how you work with it. So it sets them up upfront for that. But inevitably there's gonna be questions or you're gonna see someone that comes in and changes the radius on something or makes the blue brighter and we just document the heck out of everything and really get meticulous with why we've made decisions especially for stuff like that that are foundational so that when someone comes in it's like I'm gonna change this because I want to where we're like we have an artifact to point to and be like well here's why it is the way it is. People will usually get a paragraph or two into that and be like all right I got it. I'm gonna change it back. But it just goes to the point of like when you're working on a systems team it doesn't exist until you write it down and you really have to be overly articulate with the decisions you're making so that people feel confident in them and really transparent in why it is. But in general like I'm seeing it less than that's a thing like I also during that design camp class like I'll generally do a survey I'm like who's worked with the system before and over the last year when I've done it every time like more hands go up so people are generally getting more familiar with the concept. Yeah, interesting. So just one thing to add is yes I do think that there's some of that concern and I've heard it from some of our designers both junior and also some of the kind of mid-career designers I think. Actually some of the junior designers I think have been relieved to have a design system because that means they don't have to go and justify some of those decisions because you can point to the source and everybody in the company has accepted this is our design system. So it kind of takes away some of the points that might have to be debated about designs and kind of helps them to kind of build some of that confidence in how to work with stakeholders and how to navigate working in projects and things like that. So there's good and the bad. Interesting, interesting. We'll move on to something a little more you know like a little larger topic like what do you think is the future of design system because in one of the design system talks that I was giving at one point of time people did ask questions about what about communication, what about new systems like AR, VR coming in and in general that where do you see the design system evolving to as more automation and AI ML keeps sipping into the systems where do you see the design system moving forward to? Great question. I don't know for sure but I think one thing that I'm seeing is that we have more and more of the kind of immersive tech and immersive experiences AR and VR that we have a team at ExxonMobil that is working on some cool things there and we've got designers in that team now and so they're starting to find some of these patterns and some of these kind of human interface guidelines that are gonna go along with that and I think that what we will see out of that is some of those patterns becoming a system of sorts and how that ties into the overall kind of system is it a multi-platform system? Is it kind of an isolation and then we bring all the systems together at some point, who knows? I think that's still a challenge that we'll see on the horizon but I definitely see it starting. Interesting. Yeah, I think there's a really interesting area in getting into things like voice, right? Like how do you, with all the variants in language, how do you systemize that? How do you maintain the way your company's voice that speaks back to them? How do you systemize that? And then some of the AR, VR stuff, like we have Oculus at Facebook, it's really interesting to consider how, that's even, that's more tangible so I think the voice stuff is really interesting to kind of figure out how you systemize that. I think as we get into some of the AI stuff too, you could see to some degree self-maintaining systems, if it's linked back to how it's used or you're examining your products how they're shipped out there. You could see that data kind of get looped back in and kind of steer the direction of the system. Even, I guess a more practical approach would be like maybe it maintains your sketch file or your style guide or something like that for you. It's where you take out some of the maintenance of it. But I think it's pretty interesting. We're just getting kind of on the cusp of that. I've heard little teams talking about that from here to there. Voice and how, I don't know, voice is not only on the written side but also on the voice and on the chat, the personality, how we make it consistent across the customer-facing point. So I think that's my homework now, things to do. And then the other thing is, I'm agree with Ken, how a design system can maintain itself because as it now, in my case, there is still so many manual or how we measure, how we're managing the design system using only Google Seats and stuff like that. How can it be, there is a helper or tools that make everything easier for us to manage the design system and reach our initial goals, which is the design system, is making us focus on problems, so instead of reinventing the wheel. I think that's the right point. So I totally agree with what everybody said, just to add to it. So right now, with design systems in place, some designers already believe that we're hindered. And with intelligence coming into the picture, I think there is another risk or concern of, hey, what are we going to do now? Intelligence is going to come in and there's not going to be enough left to do for us. I believe, however, that it's a welcome change because we're now going to go away from manual tasks to becoming enablers. So imagine with things like intelligence, AI, and machine learning coming into the picture, there are already self-training models available. Potentially there could be a system, a model that works around design systems that could self-learn and self-train, self-maintain like the other panelists said. So it could possibly be like cooking where you have a set of ingredients or say you have a set of components and building blocks available like Legos. And you give that knowledge to the system and it learns to combine, so it could possibly pick up a card from here, a list from there and possibly generate a new component for you or you could ask it, hey, I'm working on a scenario like this, it could possibly even recommend to you and you give it feedback and that's how it becomes even better and better. But a designer's role is going to change in the sense that we wouldn't, we would possibly, and we already have things like Zeppelin, we have long-stop making style guides, right? So in the future we're going to become enablers where we guide and we maintain the system. There's a system over a system which learns and which helps build things for us. But the measure of human intelligence I think will continue to stay even in this era of, you know, intelligence that's slowly coming in.