 That guy sounded like he had a much more stressful job than I have right now. Man, what a sight. It is great to be here. Let me say it's a privilege to be here in Bangalore, to be at UX India as a speaker. It's definitely a great privilege. So I flew in earlier this week, got to see some great cities. Hyderabad, Chennai, and now in Bangalore, so it's been a wild ride. It's my last day flying back tonight, so, whoo, lots to remember. But I am Andrew Pendleton, I need to pick up the clicker. I am the director of design systems at Verizon. My team focuses on growing and evolving Verizon's design system. I've been with Verizon for 10 years. I have a background in both design and computer sciences. So I kind of felt like I hit the lottery when I was asked to lead a team that has a strong mix of both designers and engineers. I'm just going to put this out there now. My talk is not about AI, so I can pause if half of you want to get up and leave. No. Instead, I'm going to be focusing on UX and more specifically how I think we elevated our UX at Verizon by leveraging our design system in ways that we hadn't before, and we actually got some pretty cool results out of it. So I'm excited to be able to share our journey in this. It just happened recently, and I hope you're excited about that too. So let me just jump right in. So my team is in the Verizon design organization. And within Verizon design, we focus on or we strive to create customer relationships by creating experiences that are meaningful, human, and responsible. Those are our guiding principles, but what does it really mean? So meaningful design is useful, simple, and reliable. We are solving real-world problems for our customers. We want to make sure our experiences are easy to understand and simple to use, and we want to make sure our experiences work every time and deliver speed and quality. Human design is personal, caring, and supportive. We want to show our customers that we know them by giving them tailored experiences specifically to what they need based on their behaviors. We lead with empathy and treat our customers like people, and we're supportive. We always want to proactively guide our customers to their goals and, if needed, quickly assist them further when it's called for. And then responsible design is honest, ethical, and sustainable. Our experiences, as well as our communication, are direct and truthful, because above all we want our customers to make informed decisions. We advocate for all, and we want to make sure that we are respectful of people's rights to privacy and choice, and then sustainable. We use technologies, infrastructure, and materials that are safe and environmentally friendly. So these are the guiding principles that direct everything that we create within Verizon Design, even the Verizon Design System, and that ensures that our designers not only reflect back what these principles are, but it ensures that they are creating the best experiences for our customers. So what exactly is the Verizon Design System? Well, we're most known for these two things, our reusable components and our usage guidelines, which inform and teach people how to utilize the components. The components themselves can be broken down into two parts. We have our Figma component, which is what our designers use to draw their experiences. And then we have the coded component. And this is what our engineers use to build those experiences. When we were first identifying and building our component library, we followed the atomic design methodology, which basically states that all UI patterns or user interfaces can be broken down to the atomic level. And then just strictly by layering atoms on top of themselves, you can grow and make more and more complex elements. Within the Verizon Design System, we have atoms and molecules. Specifically, here are some of the examples of our library. So we have a button. We have a dropdown select, a tile, and a list group. This is four of more than 30 components that make up our core component library, both Figma components for our designers and coded components for our engineers. But wait, there's more. Not just components and usage guidelines, our system is made up of our fundamentals, which are guidelines that speak to color, spacing, our grid system, typography, iconography. We also reflect our brand guidelines, our accessibility guidelines, and also our content guidelines. All of these things come together to form the Verizon Design System, which we shorten with the very creative name VDS, trademark pending. And this system, with all of its elements, is built on top of that foundation of our global design principles. And as much as I love Verizon Design and I love the people I work with on a daily basis, some of the most talented designers, most passionate in their field, this doesn't come without some challenges. So Verizon is a big company, and it is almost impossible for any one individual to be able to look across and understand all of the lines of business that we have that span the enterprise. On top of that, all of those lines of business have their own projects going on all the time, which makes it hard for any individual to keep that line of sight as to what projects and key initiatives the design system should be plugged into at any given time. But we were able to plug it into a product launch that happened recently. And we were actually able to reduce friction in our creative process and see some efficiency gains within our design iteration process, which enabled us to deliver a product within a high fidelity with minimal error and on time. Let me introduce you to my plan. My plan is Verizon's refresh of their mobile plans. This launched in May of this year. What makes this such a groundbreaking product for Verizon is that it was a complete relook at how we are offering our plans to our customers. It's all about giving flexibility and control to our customers. You get to choose your plan, starting with the data option, and then you can choose any, all, none of the perks that you want to include with your plan at a discount. And you can go back and change those at any time. This is a fundamental change from how we had structured our plans before. So to make this a reality, it was going to ask a lot of us, like we had to transform our existing plans experience. So we got really excited. Let's transform things. But keep in mind, when you're in the middle of transforming an experience on your site, you have to remember that this experience does not live in isolation. It's not a silo. This experience lives in a existing ecosystem with existing UI patterns that our customers have grown to understand, to know, to anticipate. An anticipation builds trust. They begin to trust the experience, the digital site, but more so they begin to trust Verizon more. So as we're transforming this experience, we have to be very careful that we don't do anything that's going to cause confusion or cause our customers to lose trust in the experience or even worse, lose trust in our brand. So that being said, one of the cool things that we found with using the design system in this project was that we were able to have transformational work that actually looked progressive. It looked like it was a continuation of the space that it was in. It didn't look foreign or alien. So the dynamic and often chaotic environment that we are in normally means designers don't get the time they need to deliver. I'm jumping ahead. So let me take a step back. So the transformational work that looks progressive, what we are trying to do is ensure that we build and encourage that transformational design iteration process. And we did that by embedding the design system into that process with our creative teams. That's normally not the case. But this time we did not to stifle the creativity within the transformation, but rather to provide guardrails to make sure that things weren't changed that were not necessary to change and to encourage transformation in the areas that really required it. So let's see some examples. So what we see on the left is an initial design of a redesign of our overlay pattern specifically for the MyPlan experience. This is triggered by a button on the page and it would take over the screen full width, full height up to our header, and you can interact with it, scroll, and then you would hit the X and close out. Now granted, this actually mirrors our navigational UI. However, the team had to question, does it make sense for this overlay to behave like this in this space? And so the recommendation was made, and it was later approved, that it makes more sense for this overlay to actually model after our existing VDS overlay pattern. Because this mirrors overlays that one would experience or possibly encounter before entering this experience as well as after leaving the experience, therefore maintaining that consistency of pattern. This is another more nuanced example. We're on the left side is the initial design of these select tiles, very similar to what we already had in other places, but here we decided to add a little bit more vertical space. You see that the content header is a bit smaller. Again, this prompted some questions. What are we trying to solve here? It felt more like we were just changing things for the sake of changing things. And so because of that, made the recommendation, and it got approved, you know what, it's better to align to this pattern over here that we see in other parts of the ecosystem. Because it's that type of conformity to the design system when it doesn't make sense to transform, it creates that holistic continuity that helps a customer feel like they're in the right place. This is making sense as you move through. This is a really cool example because it shows both targeted divergence from the system as well as when you should align to the system. And so this is the plan select card. This is new for the my plan plan select experience. We had not displayed our plan options in this type of format. We had not listed promos, which is the text in the red box over plan cards like this before. And so it was introduced, well, maybe this is a good use of Verizon Red. Like let's make it pop. Let's call it out. Let's put a little icon on the left side of the text. That feels like a good use of that space. Also draw your attention to the red radio button that has that red fill, Verizon fill with the white check mark. That's a new pattern. Like we've never done that anywhere on the Verizon site. But with what we were trying to do with this new experience and look for ways to actually push our brand forward, it felt right. And then I contrast that to the buttons down here at the bottom. Those buttons are using the standard VDS Verizon design system button. Standard primary, standard secondary. That is a good example of where it would not make sense to change that because buttons are all over the place. And we want to make sure that we don't break that common pattern. And so this is a really good example in my mind where targeted divergence makes a lot of sense. Another piece of value that we get from only diverging when necessary and leveraging what is existing in the design system when not is that when you leverage the design system, you are getting all of our user research, all of our testing optimization, all of our accessibility fixes and pushing forward over the years, you get that inherent in the design system. I show this as an example of our color accessibility showing where and where we don't use our Verizon vivid red in text on a black surface. We only do that when the information in red is not critical or important at all. Why? Because there are certain visual impaired users of our site who would not be able to read it based on color accessibility. And so that's why we don't say no completely, but we also make sure for those moments that matter, we're definitely not going to do that because we want to make sure our customers get the information they need built into the design system. This is another great example of new functionality that was delivered for my plan. This is the my plan per detail example. So if you're selecting your perks and you're like, I don't really know and you click one, you're going to get this overlay. Now I was showing overlays earlier, but this is a new overlay because we like to put things inside things and other things. So notice that there is a toggle button in the card that's in a carousel that's also in an overlay. That's crazy talk. A carousel on its own is almost impossible to develop accessibly, but our design team or design system team actually cracked that egg last year after months spent in close partnership with our accessibility team. Now I'm happy to say at the base component level, our carousel is 100% accessible based on the Verizon YCAD guidelines. So when this design came through, the thought wasn't, hey, I'm going to build a brand new carousel from the ground up to do all these things, no. We were actually able to pull in our carousel with all of that lovely accessibility goodness in it, and then make some modifications and updates that enabled the team to extend it further for this specific layout and functionality. I've also broken out this overlay more completely on this side just to show that there are different types of content blocks in this overlay. Some of those blocks are common standard components within the design system. Some of them are standard components that have been extended a little bit to extend their functionality based on a need, and some of them are brand new. But why I'm showing you this is that the mixture of those things, the things that are recognizable, the things that are standard across our site mixed with the transformational actually provides that cohesiveness of experience that, again, makes a customer feel comfortable going through even a new experience, because it still feels normal, still feels like Verizon. So now we're going to the logistical hurdles. The dynamic and somewhat chaotic nature of the environment that we work in sometimes means that our designers don't have the time they need to deliver. That's what I refer to as logistical hurdles. And so what we were able to do, we actually pushed the design system team right in the middle of the design iteration process and the handoff with our IT engineer teams. And by doing so, we actually saw some of those logistical hurdles disappear. So this is a very oversimplified visual of our design iteration process, very oversimplified. And so we got our design brief, we're going into exploration, we're going to figure out all these cool things that we can do, we're going to get feedback, we're going to test it, we're going to refine it, we're going to hand it off for it to be built. This is oversimplified, because there's not one design handoff, it actually looks more like this, because we have multiple journeys, multiple ecosystems, multiple development teams that we're having to hand off on succession. Oh, but this is oversimplified, because this is assuming that the designers had the time that they needed to design what needed to be done. This is assuming that the requirements were immutable, they didn't change along the way. This is assuming that communication, the needed communication, actually happened. My time at Verizon has taught me you can't make those assumptions. It actually looks like this. It's iteration after iteration after iteration accounting for missed requirements, new requirements, missed feedback, you just need more time. This pencil is down, engineering handoffs date, that's still set, and it's missed. The next one, missed too, but the thing is, you miss enough of these, and you find yourself in the very tough spot that whenever you do actually hand it off, like nothing happened, you're going to get the response like, I can't build this in two days, and so now you're having the conversation around cutting scope. Oh, yeah, and plus you're doing it across all these different flows. So cutting scope, what does that look like? This is the common dialogue that happens. You see that button? What do you want to do there? No, we can't do that. We're going to have to do something different. We're going to have to do something that's either simple or there's an existing alternative for. What's the text in this card? That's dynamic, that's going to come from a database? No, we can't do that in this timeline, and have enough time to actually test and make sure it works. You're going to have to hard code that text. This media image over here, are you wanting it to do something fancy? No, static image, like that's what's going to have to happen. This is not the ideal scenario, right? So we thought, can we do something differently? And so what we did, we asked our design system engineering team, can you deliver more? Is it possible for you to extend past molecules and actually create the organisms and templates that each of those individual ecosystem engineering teams would have to build? Can we build those once, and distribute those out in the same way we did the atoms and molecules? Yes, we can. This is what that kind of looked like. So again, atoms and molecules, these are the same ones you saw earlier. But now we have an organism card. This is the plan select card. Much more complex, it's a combination of a lot more things. And then you have this template that's actually, it feels a page. All an engineer needs to do is call this template, and he's all set, or she. They are set. And so by having the design system, design team embedded in the design iteration, the engineering team, right there in the middle handing off to our IT engineering partners, they're both on the same team, design and engineering. And so the engineering team is actually seeing things coming through the design iteration process before it would normally happen. They're able to catch key requirements that no one else might have caught before. They're like, oh, oh, oh, you're wanting to put what in that tile card? Someone's going to need to set up a database connection. All right, let me put something together. I'll ship it out to the teams. We'll figure it out, but at least they'll have that foundational connection to the database in place. Entering exit requirements, those are pretty set already, but why didn't we communicate those earlier? Let's just go ahead and do that. Functional requirements, yeah, we can do that too. And so the team was empowered to build this MVP, basically a little bit elevated prototype, that actually had those key requirements in it that the engineering teams needed. So once we were able to deliver that to the teams and they were actually able to plug it into their ecosystems, the design iteration was uninterrupted. It could continue going. And anything that comes out of that is just an update. You just push an update to what's already been implemented in those ecosystems. What that enabled then was for our design teams to keep iterating longer and longer, getting some good stuff out of those iterations, a lot more feedback, a lot more design variants, a lot more late requirements. But hey, we had the time, right? And it enabled us to use that time effectively. So this is an example of how these tiles actually evolved throughout that process. First delivery is really nothing as a placeholder. Second delivery, OK, now we're getting somewhere. This was actually the most important deliverable to our engineering partners within our IT organization, because it told them what to expect. When this was ready, the actual perks and the assets, that was easy. This is all front end stuff. The difficulty was in the back end and we were able to facilitate that development much sooner. Requirements also evolved. This is a good example of a perk tile that ended up having a more complex interaction than was originally anticipated. We discovered this new interaction about halfway through. But because we had the time, we were able to account for it. So what we saw was that the design that was actually designed makes it into production and it was delivered with very little error. Normally, when we are handing off to our engineering teams, depending on the timing of each of the handoffs, depending on the state of the ecosystem or application at the time of handoff, you could actually see an experience be deployed to production, put in front of our customers, with varying degrees of completeness, which I think that's worse than just having a unified experience that's incomplete. But now we have various states. Well, which one's the actual one? But because with my plan, we actually delivered a single library of UI elements across all the teams, that all of the teams were actually able to deliver a complete and uniform experience. And by the way, because now we are focusing on a single library of components, not all of these independent experiences, we launched with zero defects. No, we didn't. But wouldn't that be great, right? But to be fair, it was significantly less, like literally in order of magnitude, fewer defects. And why that matters to all of us is that who has to spend time triaging those visual defects? Designers. Who's got to try to figure out how to fix that broken design? We do, right? And so the fewer defects we can launch with, that's more time we get to design, right? And there's got to be that, I can't be the only one here, the satisfaction of pouring so much time and energy into crafting this, I'm a little biased here, beautiful experience. And then you actually get to see it come to life as you designed it. I mean, I get excited about that. So where do we go from here? I just told you a story that happened with us earlier this year. I presented it with a lot of good news. Hey, we made a lot of great decisions. We're still in an unstable place right now in terms of where do we go from here, right? So first, we're still trying to figure out how we decide what transformational elements actually get scaled. So the things that were new with my plan, well, do we want any of those transformational things in the system so that all experiences can leverage them? Or do we want some things to be specific to the plants experience? How can we systematically handle appropriate journey-specific divergence? This is a $10 sentence. But really, we were all up in the design iteration business, right? We were helping to coach and guide when we should diverge from the system and when we shouldn't. How can we automate that? There we go. Maybe that's an AI topic next year. And how do we continue, or not how, do we continue to provide organisms and templates within the design system? We did it to successfully launch my plan. But is this a new strategy moving forward? I know. Kind of excited. I might come back next year and tell you guys how it went. But anyway, that's all I got. I just want to say thank you. And I hope you guys have a great rest of your day. Oh, yeah, QA. Any questions? Raise your hands. You jumped up. Oh, wait a minute. Who's deciding? So just wanted to understand the templates at what break points you have them for and what platforms. How do they work on platforms like iOS and web? So you're asking about the design system specifically. It's responsive. So we cover mobile desktop tablet. We're looking at bigger screens than just desktop. But we'll see how that goes. What was your other question, platforms? You're asking about the coded components? We primarily focus on React. I'll go next. Andrew, as designers, we love to get creative. So how do you make sure that all the designers are creating everything which is design system, 100% design system compliant? Oh, I can't do that. I'm just one person. So it's really just awareness, right? Making sure people know that the design system exists. They understand what is in it, how they can leverage it. They know how to use it. And then at the leadership level, we're trying to create these best practices and principles of design within practical principles, like how we execute. We're building that into those principles. So again, there's not a catch all. There's not a way for us to 100% insure compliance or usage. But we're doing what we can just to grow the awareness and make sure people understand how it works, right? Because it makes your job easier. Like, do you want to draw a button there? Do you want to create this cool new interactive thing? It's probably not a button, right? So use a button if you need it from the design system. I'm Divya, and I am associated with the design system of my company. So it's VDS for you. It's VDS for us, principle design system. So my question to you is, what are a few challenges or resistance that you and your company faced while adoption of VDS in your company itself? I could give a whole other keynote on that topic alone, right? What's funny is that, and I'll try to keep this short, but it's never one thing, right? And that might be the biggest misconception that I found coming into my role and growing into it is that it always seems like people are personally against the system. Like, it's out to get them or take away their job. But if you actually sit down and have a conversation with your customers, the people using the system or your potential customers, you really find it's way more nuanced and complicated than that. It could be things outside of their control, like platform architecture. It could be non-aware of it. So again, my encouragement to everyone is to just sit down and have conversations and see if we can figure out what the actual issue is and see if it's resolvable that way. But it's never just one thing. Definitely. Thank you. Thank you, and we'll take one last question here. Go ahead, sir. You have the mic, so. My name is Vith. I'm here. I don't know where to look. On your right side, yeah. So my question is, when we talk about this cross-functional team, so we need to interact with a couple of designers, product managers, product owners, tech teams. So how do you optimize while understanding the component requirements from the designer's point of view, sometimes from the development point of view? How do you optimize it? And what challenges do you see? What are you wanting to optimize? That's a very general question. Yeah, very generic. So basically, while adapting the components, so I see, personally, in my current company, so there are a lot of problems. There might be versioning controls. There are existing product is there when I talk about the new component, to when, what time I supposed to adapt this. So these kind of challenges, how do you communicate with the different setup people? That's my question. Yeah, there's a long story there that I can tell you more about my background and how we kind of laid that foundation. The short answer is, well, again, from my perspective, you got to do a lot of up front work. You can't just make the decisions of your design system architecture in a vacuum. For us, we made sure that we knew what our IT enterprise architecture teams, standards, and best practices were. And we aligned to that. Like, we wanted to make sure that teams, by using the design system, were actually getting themselves more alignment with their own standards and best practices. But that caused us to have to know them better than them and get that stuff ingrained in the system directly. So start there. And for a more detailed answer, we can talk after. Thank you. Hello? Oh, yeah. Hi, Andrew. So I have a question. Our team is working on a product, which is at a stage where we are designing new features in the product. Can we, from your presentation, I can infer one thing. That more complex elements, if you are designing at an early stage in your design system, then your delivery can be fast. So at this stage, can we develop templates for different features, which we are not even aware of at the moment, or we are experimenting to expedite the process? I think that would require me to have a lot more context of your situation to give you a more accurate answer. But I would say, again, this was a very specific point in time, specific needs. So the stars were aligned for us. But generally, we wouldn't take this approach for normal product launches or new feature releases. Philosophically, as a design system team, we are reactive by design. We want things to launch. We want to be able to look broadly, and then try to encapsulate those reusable elements that we're finding out there already, and then turn them into components, and then make it easier for teams to use those same things going forward. Or else, there's a good chance we would spend a lot of our time building one-off components that are niche and aren't really used everywhere. And so we tend to take a hyper-conservative approach there, which is totally counter to what I just showed here. But again, that's why there's a lot of unanswered questions there at the end. We're having an existential crisis, not that dramatically. But yeah, so I mean, it's going to be based on your needs, what you're comfortable with, and what you think is best for that project. Maybe we can discuss this on break.