 So, before starting on my topic, I want to tell that in today's world, everything is based on experience. Experience sells, not the product in itself, right? So that's where designing beyond becomes like much more attribute for any designer in this field. And if you see, our major tool is a design system, and it has its own constraints, right? So how do we design beyond in this constrained ecosystem? That's my talk. I don't know whether I can do justice within 18 minutes. It's like kind of a very, very large topic, right? So I'll try to cover up as quickly as possible. So before going in, we are having Google Home Contest going around in our Salesforce booth. We are giving away four Google Homes. Please participate, and there are clues in the topic, so please be attentive. And moving on about me, I'm a UX designer more than 10 years of experience. I've been with Microsoft and many enterprise companies, that's like kind of my core. And grassroots innovations are like kind of my key focus areas, long-term. And yeah, animation, comics, pets, and tennis. These are like kind of my serene zones I get into before innovating. Yeah, but a little bit about Salesforce. We are not just the number one CRM in the world. We are like kind of the most innovative and admired company over the years, right? And this is possible only because of having a strong design team. We are a design team of more than 700 people with teams contributing to innovation, product, design systems, and marketing. Talking about the Hyderabad team, we have grown very rapidly in the last one year from three-membered team to 11-membered team. And we have no thoughts of slowing down, we are still going on. And we have hired from companies like Google, Microsoft, Amazon, Samsung. Now, this is our mission statement, to make work awesome and also to make awesome work. This actually translates to the design system that we are going to talk about. Because it's a system which is gonna make awesome work and also make work awesome. Now, I want to just have a quick raise of hands. How many of you guys use a design system? Not bad, I would say almost 70% of the room. So I did a quick research, and the research said more than 80% of the people in design world use a design system. And that too, it's not just corporates, 20% of the people who are freelancers, even they use a design system, right? And I'm no exception. We have something called lightning design, which has more than 300 components serving millions of users. But I don't wanna talk about my system today. I wanna empathize with you guys, understand something more common. That's why I wanted to look at something more common like material design, right? So that is kind of having the foundational aspects of all designs, right? Starting from animation and what are the design needs, everything. It can be scaled across to anything, even enterprise. Every one of us refer to this whenever we have a doubt. But I wanted to think a little bit more foundational, where all did these things start, right? When I started looking around myself, what other things can we start looking and deriving design systems out of, right? These are the three big things I was able to identify. The first one, a LEGO system. Every one of us love LEGOs, right? How each and every component works with each other. That is actually a LEGO system, a design system. Using which they keep innovating, they keep expanding. Second thing, roads. How many of you guys know roads is a design system? Whenever we travel from different countries, do we even think how does this work? Except for the left lane and the right lane, which is more like Windows and Mac. But other than that, everything is exactly same, right? The padding between the dimensions of the road, and then even the lanes, dimensions, even the ramp height when you're climbing a bridge. Everything is like kind of a design system, right? And I want to touch upon Anthropometry. Anthropometry is like kind of the oldest science of design, which kind of is derived out of the human dimensions. Because every object around us is designed for us, right? So this designs again talks about how every object has to be designed depending on the human dimensions, right? Starting from laptop, even the padding between each keyboard, right? The key words I would say, the table height, the chairs, right? Everything, but actually that's not the oldest. It goes all the way back to 5000 years old. Think of Minecraft, but for real, right? How many of you guys have played Sims or Minecraft, where you guys have the templates to start creating your own city, right? So that's what Indus Valley Civilization people did, and deriving that. So here, if you see, the main roads used to be aligned from north to south, and all the connecting roads has to be like east to west, and each and every houses has its own private bathrooms with closed channels for swimmers. Sounds like our city, right? From there. So now if you see, now if you see all of these things actually do two things, they are modular and repeatable, and what do they achieve? They achieve faster and consistent experience throughout, right? So these are like kind of the design systems of all the four things I was talking about. So moving ahead, we are designers, even though these have like such good foundation, such good roots, we have our own thoughts and individuality. That's where we tend to break out and say, hey, design systems are good, but... So these are the caveats that each design system presents, starting with constraints. Hey, you say lighting design system has 300 components, man, but you cannot create this experience out of it, right? Can you? Second thing, developer pushpacks, developer use this as a tool to say that, hey, we don't have this component, you know, she's already like laughing at it, right? The third thing, when something is already given to me, when I'm playing with the ego, do you say, am I unique or am I just being productive, right? That's the third one. The fourth one, this is like kind of, I have seen it many a times, whenever you are entering a new company starting to use a design system, you start feeling like, why is it like so old? Can we change the colors or can we change the components, right? So these are the four things. And finally, all these things actually build up to the big thing called innovation, right? How do we innovate? Actually, if you see really, really deeper and into it, these can be perceptions. I'll try to start breaking these myths for you guys one by one to start with the constraints. So if you see, design system was never meant to solve everything. It was supposed to be the foundational layer, which can solve 80% of the use cases for you. The remaining 20 is actually meant for your innovation, right? So think of it that way. And actually because of this, and actually because of this, companies are more than 23% productive when they use a design system. In terms of development, I don't have to say about design. That is going to go way up the roof, right? And also since the base components are already ready for you, you're already thinking at a higher level of innovation. It's not about like basic thing, hey, how should I design a grid or like what should I do with the colors or the schema or even accessibility, right? All of these things are solved for you. And the last one, don't undermine the multiplier effect. Whenever you contribute or create something in a design system, that is going to go wide and into multiple teams within your own organization, right? So think of just making one thing which is going to make me money for like so many other things, right? This is called the classic PS controller way back in 1994. And this is the latest one even in 2018, which we use. Can you see the similarities? Did they start like completely diverging into like, hey, let's create something new, right? No, they kept the bonding boxes and start innovating, right? For example, if you see these are like stick controllers, they have added a trackpad for God's sake. They had sound systems, you have the feedback haptics, right? So many things they have innovated within that space. Now talking about in UX, iPhone, right? It started with the 3.5 inch. Now it's almost double the size. Still, the foundations are really same. The design systems is just evolving, right? Second thing, yeah, this is more interesting, the developer pushbacks. So whenever you present something new to the development team, right? What they do is, hey, we don't have this component. Exactly, they don't have this component. That's what they're saying. They're not saying they cannot create this experience. Take it in that manner. Try to see what are the other components which can be clubbed together to produce almost similar experience. Which can be at least 90% or 80% at par, right? Start from there and try to see what can be taken further. This is the next thing. Try to tell them the need to your developers, right? Put them across the same table that what you know, educate them. Rather than saying, hey, I need this. You go and figure it out. That's not the way. It should be a tag team, right? And understand their constraints. I would give a very good example of constraints actually make us very innovative and productive. So for example, in the 2G era, we made a lot of Facebook light, so many Uber, and so many faster applications. And that's actually helping us now. And also, without constraints, we'll be just like painters. We'll not be innovators. Yeah, again, a very classic example. Let's say you guys are working with solid wood, right? And you guys have an innovation called foldability of the chair. If you just go and say, I want a folding chair out of wood, every carpenter is going to deny, boss, that's not here. Go to Ikea by this one, right? That's how it's going to be. But start telling that, hey, in wood, we have the concept of hinge, right? Try to put three hinges together. It becomes a folding chair. Break that basic need for him, right? Then it's going to become hand in hand. He's going to work with you. He's going to understand, and he knows he's a part of the innovation, right? The third one, how to be unique. So uniqueness is not, again, a singularity. It is a team attribute, right? Start encouraging new ideas. Try to see how much of this new idea is bringing betterment in the product compared to what is existing. So that is where I have this formula of added value that the component that you're providing, x usage. So for example, the component that I'm creating is going to save like 10 seconds for my user, or three clicks for my user, right? Versus so many millions of users. Is it worth the development effort of like two sprints of two guys, right? That's what is going to convince the stakeholders. Second, you have a central design team who's going to work on all these things, right? Pitch those ideas. If you see, this is going to add so much of value, whether it is your job or their job, right? They can take it out and build the work for you. They are going to be more happy doing that. Third thing, build for greater good. Whenever you want to innovate, it's not about a particular scenario. It is about the entire organizational wide scenario, right? Start thinking where all you can innovate. The same idea, how it can be replicated, right? So this is what is going to make you unique. Another classic example from a real life. So this is exactly the design system of a car, right? Every car that you use, this is going to be the one. And if you see, these are the different outputs they were able to build. And every year, we are getting new updates, like new classic item or like the brand new BMW or anything, right? And what happens? The innovation that happens trickles down to the other systems and other cars that they have. They pull back those innovations and put it back into the other cars as well, right? That's exactly the same thing that also we need to do as UX designers. And this uniqueness is like kind of a long term and also should be seen both as internal and external innovation. So both in Android as well as iOS use case, do you guys think when they made the initial design system or the platform, they were thinking that, hey, it can be used from augmented reality to like time machine or like everyday experiences that we are looking at? No, right? It was slowly evolving, one by one, right? So think about the extended use case for, yeah, gets outdated soon. This is the classic myth that we have. Actually, if you see, it is not getting outdated, it's getting more robust, it's getting more hard, right? If there is any one of you who is using a very new design system, they would tell or they would actually cry how hard it is to design in that because developers will say no for anything and everything because it hardly have 20% of the components of anything that you design, which is exactly the opposite a design system should do. So as it ages and as it grows, it is gonna be more matured, see it that way. Second thing, it is already has the context of your software, right? It knows what your software needs. Based on that, each design system is built, right? You cannot cross-pollinate design systems. They are built out of some need, right? So start looking at that way and especially your users are accommodated to that. They don't need to learn anything new when you're innovating on your design system. Then encourage back your team to contribute to the central design system. So if the design system is, the design system team is not able to develop these for you. You develop it and say that, hey, we found this, this is the requirement and this is the multi-fold profits that we see. They'll be happy to take it back into their runs and populate it across the cloud. And finally, I'm not saying don't add up to the newer technologies. Even within Lightning Design System, we are like kind of mobile compatible but not mobile first. That's why we are also trying to evolve to a new technology called Raptor for mobile but always think it should be backward compatible. What are the design system that you guys have, right? The newer ones should adopt back to it. It should work hand in hand. Another classic example, how many of you guys, we are all designers, right? How many of you guys have taken a newspaper and said, dude, this is the old layout. Why should I read this? Instead, we start getting into the content of it, right? Think of it that way. And here, even with that, people have started innovating. The warning and you see that. So try to break out, right? Nobody's stopping you. Now finally, let me come to the innovation mantras, summing all these because the entire topic was innovation, right? Start with defining the need. When I'm talking about defining the need, it's not about the entire need of your product. It's about the component or the innovation factor that you are doing. What is the need? Try to document that separately so that all your stakeholders can understand. And that is actually the second part where you can connect with the stakeholders to make a point that, hey, why is this need? What is the increment that we are looking at? Document both the experience with our current systems. If we do, this is what the experience is. Well, this is gonna bring so much of investment in return. Third thing, know the constraints. Understand why they are saying no, right? The classic example of the chair, right? Try to work with them and try to tweak along and go with it. And the fourth one is go for the multiplier. It's not a specific use case scenario. It's gonna be for the entire breadth and depth. And the last one, it doesn't stop there because we all of us know the first output of Dev or even UX is gonna be just an MVP, right? Start innovating, keep on innovating, right? It doesn't stop there. And bonus, I want to give a small example of what we did at Salesforce because I didn't want this session to be a GAN, right? Let's go into the details. So we had this unique requirement of life events. I work in a team called industries who kind of specialize in different industry verticals starting from manufacturing, health and different clouds. So in insurance, we got to hear a major feedback from the users is that, hey, we tend to forget like what are the needs or like what are the life cycle of a user, how they are, depending on which only we can contribute our products, right? It made sense. We tried to scout the library. We couldn't get anything out. So that's where I started ideating. Came up with like multiple design concepts. One was just like kind of horizontal thing of like all the items. Second thing is like kind of a split view where I see all the life events. When I click on it, I can see the differences. Same way, like at the top, you populate all the life events together. Well, if you click on one thing, you can see. And we started looking at everything. Then we started pulling on all our stakeholders to evaluate all these things. Hey, which works better? What is the timeline you can get? And what are the constraints in developing these? Obviously, parallel you need to evaluate with your users where we got this is like kind of the best designs we want because we don't want this to take up the entire page. This is like, this should be at the back of her head but not as important when you start a conversation, right? Third, the constraints. What can be developed or not? We had nothing like these sort of things within our design system, right? So I was able to understand gauge, what can we do? What are the things that we can reuse and other things? Fourth, extending the scope for framework. When I started this, it was with insurance. But as we moved, we thought loyalty is a great example. You need to know the life cycle of a person to serve them better. Third, health cloud. You need to understand where are the interaction points for a health company with the user? Fourth, manufacturing. Even a company works that way. But the only difference is it's not a human, it's a company, right? That's where we even extend to the requirement saying that, hey, life events can be both ways. One is life event for users. The second one is business milestones for companies. Exact same component named a little bit different depending on the context, right? And yeah, we still kept improving. I'll come to that. So coming on to the final conclusion. So you see this one, right? This is the one which is live. You can even go out to our site and find it out. So what we did was this is kind of a progress component that we have within. So we use that instead of that. And this used to be kind of streamlined. I said, hey, can we cut it out? So that at least we see these are independent rather than not streamlined. And also there are feedbacks like, hey, how can I see the first ones first? Or I just want to see a picture. So that's where we had another toggle of show reasons first or like kept it in a static manner. And also these events can be multi-fold. I could have multiple cars or multiple childs, right? I want to know that. So instead of populating in multiple way, just concise it, keep it that way, right? So these are all the different kinds. And when I'm talking about the innovation, we also wanted it to be actionable, right? When I know that a customer has got a new car, I want to immediately act upon it. Is it possible to trigger something right from here, right? I can use cards where like I hover on it, I get that card, I can take that action, right? So these are all the upcoming things. So out of this, the benefit if you see what we had, first thing, we upscaled the user engagement. There you go, we get profits, right? Second thing, encouraging innovation across all roles. After this, you won't believe, even developers are open for new components. Every time when I take back like a normal design system, design they're like, hey, aren't there like any new things? This looks like kind of outdated, like yeah, yeah, wait upon, we'll come back, right? So that's like kind of the mindset people are into now. Third thing, appreciates and empathizing both sides, the users as well as the developer constraints of the design system. And finally, this is currently used in multiple industries. It started with one, but we understood how it should be multiplied. And post this, we're also looking at how we should scale across every component that we are creating new. So finally, I would thank you all and this is kind of the work that we do at Salesforce. If this excites you, please come to the booth, talk to us. We'll be more than happy to educate you. Round of applause please.