 talking about a couple of things that I see time and again in organizations that help them to be successful in delivering great experiences. When I talk about, you know, places that I've been, things that I've seen, that probably helps to give you guys a bit of context around who I am and where I've come from. Over my career, I worked in consulting for a long time, worked for the, why is that that? All right, well just ignore the fact that you can see my macOS around. So, you know, worked for a while at both Adaptive Path and Hot Studio, some well-renowned UX firms based out of San Francisco, worked with many, many clients, saw the way that lots of organizations were structured and how they could be successful, helped to train up teams. I spent a while working for GE, so inside of their organization building up a UX practice for building digital IoT experiences. And now I helped to lead the team at Informatica, a data management company, you know, that has offices both in California as well as here in Bangalore. So, you know, experiences in the consumer space, experiences in the enterprise space, done this for a while. So I think I have some good, some good background and what I've been able to see time and again is some consistent patterns on things that help us to be successful in delivering these experiences. Goes without saying that I wouldn't be doing my job if I didn't mention that Informatica is hiring here in Bangalore as well as in our other offices, so please visit one of our booths if you're interested in talking to us more about the ways that we can help you build your career. So, been talking about, you know, some of the things that UX teams can do to help them sort of push the ball forward in building great experiences. And you might say, Dan, why are you doing that? Why are you talking about this when there's so many other people who've already talked about it, right? For example, you may, you know, recall that Forester, the analyst company, came out with some studies around maturity models for how we can assess how well your company is doing. You know, my colleague Leah Bule wonderfully put together an assessment model that actually at this URL for your charge you can use to assess your own capabilities. You can look to our friend Jared, right? His company, you know, will put you through trainings and has playbooks on how you can, you know, sort of up level your game, sort of assess where you're at, and put a lot of things in place to make sure that your organization is delivering great UX. So, with that being said, why am I up here talking about things? Well, I think I've got a slightly different approach, and some of my recommendations are hopefully pretty tactical that can, they can address, you know, everybody from the student to the experienced designer in the room, including hiring managers as well. And it starts off with figuring out how can we have an organization that helps us to build the right product, right? How can we get out there and to understand exactly what should we be delivering to the market, and turning that into then actually delivering the product right, right? What are the ways that we can actually ensure that the product shipping out the end, you know, meets the needs of our end users? When I think about the ways that, you know, you can accomplish that, you know, I think that there's a few categories, four categories to be specific. One is around influencing. The next is around clarifying. Following on from that, pairing up. And lastly, accelerating. So I'm going to dig into these four areas here throughout my presentation. Hopefully again, I will deliver some tactical advice that you wherever you are in your career can use to help, you know, deliver these great experiences. So when I think about influencing, I think about the fact that a UX organization needs to be able to conduct design research. We've heard a lot about that this morning, right? You know, sort of the needs for that, how you can go about that. So conducting that that user research, and then using design thinking practices to put shape to that. When we think about this to the influencing area, you know, I think about, you know, conducting studies with real users getting out into the field and doing so. I think about the fact that we then need to take what we have learned in the field and create visual artifacts that help to explain those research findings. We collaborate with our peers, our peers in product management, our peers in engineering, marketing, sales. And when we are thinking about the shape of an organization, we need to do things like hiring dedicated researchers and interaction designers who conduct their own their own research. Right? Doing so will help us to be able to solve this sort of influencing problem that makes us possible for us to help, you know, define the right products that we want to deliver the market. A little detail on what that might look like. Here's a shot from my GE days, where we had researchers going out into the field. You know, here's a woman named Melody in purple. She is actually talking to people who are operating power plants. Right? So here's what it looks like when you were actually successful in having designed researchers who can go out into the field. You know, I've had people who had to be trained on being able to fly across the ocean to spend time on oil rigs. I've sent people into office environments where they conducted research around how people are doing, you know, using ERP systems, etc. Right? So, you know, getting out into the field, actually talking to your users is a big part of what you need to have, you know, as a discipline within your organization. Once you capture all of the data out there in the field, you didn't then need to turn it into artifacts, right? There is an often a problem where your research, you know, doesn't really make the impact you're looking for. And I find time and again that if you're not able to visually craft that and an emphasis is on the word visual, right? This is not a list of things in a spreadsheet, which are things that we heard in the field. Instead, it is turning something, you know, more, more, more evocative that really helps to bring about that empathy that's important to our, our products, right? We have here on the left side, some personas that were created by the team here at Informatica. They actually made stand-ups that can sit there in the office and can actually evoke, you know, what is a data steward and what are their needs. Over on the other side here, we have a journey map that was created back in my days at GE, sort of diagramming, you know, what is, what are the different interactions between people who are operating drill ships. So big emphasis here on taking your research findings, getting out in the field, turning those into artifacts and going through design thinking workshops as a way to sort of get everybody on board with the information you find. These workshops, you know, are a way to get the individual stakeholders throughout your organization to really understand what it is you're trying to accomplish. You know, the UX team is great at going within themselves, creating these design artifacts and pushing them out. But, you know, sometimes getting your peers, your peers from engineering and PM, and having them put pen to paper, having them work through what the solution is, is incredibly valuable to really get the organization centered in the right way. So kind of recapping on that, you know, conducting our user research, then creating visual artifacts, collaborating with our peers across disciplines, and, you know, for, again, the hiring managers, the people who are leading teams, you know, here's the kind of people that you want to have in your team in order to accomplish that. So we've now begun to start to influence the organization around things like roadmaps and products that we want to bring to market. It's time for us to then start to clarify exactly what that might look like. So my next pillar is being able to have the expertise within the organization to create prototypes. Time and again, I find that prototypes are an incredibly powerful way for teams to really rally around an idea and push it forward. So we're going from our research and our visual artifacts to then conducting design validation with our end users, right? These prototypes can get out there and be tested with our users and we can get their feedback on whether they would be accepting of it. We can create storyboards and prototypes that really feel quote real. I'll talk about the quote real thing in a second here. We collaborate, you know, with our other disciplines to iterate on the notions, you know, we're able to be nimble as our prototypes come to life. And lastly, when we think about the hiring part of it, you know, we need to have interaction designers, visual designers and prototypers, people who can actually build prototypes, you know, lots of different skills and lots of different mechanisms and ways to do that. So for your organization, you can sort of assess what you need, but being able to craft these prototypes is an important part of the puzzle. So one of the things we have at Informatica is a notion inside of our research team around the kinds of artifacts and how they can best be used to clarify user acceptance, right? Not everything is really testable, you know, in every single instance. So there's certain things like navigation you can test with end users and there's other things that are more difficult to do so. So we have an assessment and a way to think about exactly how we will take ideas and test them with our end users. Here is, you know, the result of a potential test, right, where we walk the users through tasks, we then can take this back into the team and have a discussion around what things we need to evolve on the prototype, on the idea as we push it forward. When we talk about creating storyboards and prototypes that feel real, here's an example from my GEDays where we have a tool that lets you manage IoT devices, right? Out in the world we have little computers that are connected to sensors that are collecting data day in and day out, you know, we need to update them, we need to push out a new version of firmware. Well, what if it looks something like this? What this is essentially is showing is that I have a whole bunch of devices that have gone through a process of having their JDK, their Linux kernel, a Python being applied to them and this is a very visual way that we got to by talking to users, by testing us my ideas and being able to show a prototype like this to a team, to a user, really helps them to get the idea about, you know, what would it look and feel like? Just because it's cool, I'm going to show it again. The team called it the lava lamp. I think you can tell why. Finally, it then takes you to a screen where you can see all of the successful updates to the firmware and those that had failure, you know, some action went down to the bottom here, right? So quickly making something that is, in this case, like a mid fidelity, right? It doesn't have all of the final visual polish, but it's not really a sketch either. Putting that in front of users and then also, of course, the development team and giving them a sense around the kind of product that we're trying to build is incredibly helpful and quite frankly, you know, as somebody who's responsible for a budget, pretty cheap, right? Doing this is a lot cheaper than actually building the product and finding out that you're wrong. So when we think about this clarifying point again, you know, really driving home, you know, the fact that we can spend time, you know, making these prototypes, we can validate them with our users. We can create things that feel a bit more real and then we can use these as a mechanism to collaborate with the rest of our team to iterate in our ideas and keep pushing it forward. The next pillar, moving on, is then pairing effectively with our engineers, right? One of the things that I see overlooked is this part of it where you have to get into the fray, right? Our products are not just wireframes, our products are actually shipping code. So one thing that I've seen time again to be successful is conducting a kickoff, right? Getting together with your engineering team and having them understand all the work that you've done, effectively getting onto the same page, putting together the plans together and how you're going to deliver that. Obviously, you have to create specifications, you have to create things like user stories and you have to create tests. How are you going to test the ideas that you have as they start to go through the development cycle? You have to collaborate with the engineers where they are. Every team has a different version of Agile, you need to understand what that is within the organization and you need to be effectively able to pair up with them in their own process. Finally, one of the things you might want to consider as you're building out a team and getting into this phase is design ops. So having there be a program manager, somebody who can manage operations of your interactions with an Agile team is going to be going to be something they might want to consider. So what does this kind of stuff look like? When we talk about kicking it off with a workshop, right, I have some pretty good evidence showing that spending time up front to really get together with the engineers and have them understand how the pre-work is valuable. You know, I actually had a test at a former company where we saw that we were not doing this, we did it, and we saw we post with the engineers and actually they reported back a lot more understanding and clarification. We saw that the results ended in better products. So spending that time up front really can be valuable. One of the techniques that I love is user story mapping. If you're not familiar with it, it's something that was coined by Jeff Patton a while ago. And it's a way to sort of decompose a design into user stories and flows in a very visual way, in a way that is very tuned towards workshops where you can get the whole team to sort of collaborate around that, build out your backlog in that way. Creating specifications, like I said, super important, you know, being able to, you know, do things like get involved with the agile processes to define user stories, right? You know, who says that a scrum master or a PO has to write user stories? Why can't the UX team be involved in doing that? Put those into the JIRA ticket, have them describe the actual experience that you're trying to deliver. Of course, specifications, super important, right? Detailing out here the points that are really important for the delivery of this, you know, getting down sometimes to the pixel level as necessary. Like I said, you know, working with your teams and understanding how do they, how do they operate? What's the cadence and the flow of how we build product is something that's important, right? You know, UX teams and engineering teams don't always have the same processes. You know, figuring out how can you interject into that and be able to work with your teams is very, very important. So just a recap on that pairing one there. Again, now we've gone through understanding the user needs. We have been able to, you know, do things like create prototypes that clarify what we're working on and iterate our ideas and push them forward. We're starting to get our engineers to, you know, effectively then build a product and hopefully we'll be shipping something great. But, you know, influencing, clarifying and pairing only gets you so far, right? This will help you make a product pretty well. But what if you have a large portfolio like we did at GE and like we do at Informatica? You know, we had Google on stage earlier talk about a massive portfolio. They have apps that are all over the place. What you need to do is you need to be able to accelerate, right? You need to be able to do this in a very systematic way, which means that you need a design system, right? You know, design systems, you know, are very popular these days and for good reason I have seen them create great value in organizations. So being able to, you know, create consistent user experiences and move faster through the product development cycle through a design system is something that's really important. As you consider building a design system for your team, you need to assess what you got, right? You need to be able to get out there into the company. You need to understand what are the existing patterns that you have, where do you need to fill in the gaps. You have to create your specifications, your guides, your coded components in your samples, you know, the actual elements that individual teams will use. You're going to collaborate across teams to ensure a sense of shared ownership. And this is the time when you might want to consider hiring UI engineers into the UX department, right? You know, having people who specifically are tasked with, you know, creating, you know, your design system as a shared resource that can operate across the entire organization. So when we think about this assessment piece of it, right, what might that look like? Well, it looks like a workshop, you know, you're getting your designers from across the various product teams together, you're having them, you know, start to identify, you know, all of the different pieces that they see and you might shape these products around certain areas. For example, dashboards, right? Maybe it's like, okay, everybody, let's get together and let's tackle dashboards. What are the patterns that we have across our entire company for dashboards? What's working? What's not? Where do we need to evolve? And how do we push that forward, right? Getting the designers together, do lots of sketching sessions, lots of ideation, lots of discussion, that sort of thing becomes very powerful. You're going to take those ideas, you're going to start to push them forward. You now need to have your actual elements of the design system and you need to have those specified in ways that people can utilize. Here on the screen, you see some work done where a design system is actually set as a set of reusable symbols within sketch, right? This sort of thing is probably a bit of an advanced topic for a lot of teams, but it's something to aspire towards, right? Certainly you need to have your specifications hosted in a single place where they can be utilized. And often you want to make sure that you're catering both to the design team as well as to the engineering team. Here, for example, you see a screenshot where you can see the UI of a data grid as well as the ability to visually see all of the different elements that can be configured and down at the bottom there are the code, right? So figuring out how you can create these artifacts, right? These design tools, these developer tools, etc. and get them out there into the ecosystem so that all of your teams can utilize them is important. But it's not easy, right? So Nathan Curtis here, quote from him, he's one of the premier thought leaders in design systems these days. He talks about the fact that, you know, all of these processes don't run by themselves, right? So, you know, thinking about how are you going to put the operations in place, don't just start building a design system because suddenly it'll fall flat without knowing the rigor of how you're going to set roadmaps, you're going to communicate changes, you're going to get everybody on board. And then getting everybody on board thing is a really important part of it, right? You know, we often work for very large organizations. We may be even operating in an ecosystem of third-party companies. How can everybody have a sense of shared ownership? Because as Nathan says, you know, you can't have one single team that's making all the decisions, designing all the design and developing all the code, right? There needs to be some sort of a model where you look to towards the world of open source and say, how can we find a way that all of us have shared ownership? That's the time and again something that I've seen as a successful point for driving all this home. So kind of coming back, recapping there, you know, all of the different four points around, you know, putting together your design system as a way to wrap around these other aspects of your design organization, you know, being able to consistently, you know, understand how can you operate in a way that is uniform, right? How can you create expected experiences that match your brand, that, you know, that feel the same way and frankly save you money because you're not reinvented in the wheel every time. These are some of the things to consider. So kind of bringing all these back together here, we've got, you know, four capabilities, right? Influencing, clarifying, pairing, and finally accelerating, right? You know, these are ones that I've seen, you know, again, within companies, you know, as big as, as general electric, as small as, as boutique startups. One thing that I've seen, you know, just really powerful. When you're going back into your organization now, you know, whether you're an individual designer, whether you're a manager, whether you're leading a large team, think about this. Think about, you know, where are you in being able to utilize some of these techniques? What are the areas where you need to improve upon? What are some of the things you need to do here? I've highlighted some aspects where you can consider putting processes in place, where you need to, you know, convince parts of the organization to do things a bit different, maybe where you need to even hire people as well. So as usual, I have spoken very, very fast and I'm at the end of my slides with some time left. So if anybody is interested, I would be happy to answer a couple of questions. I've got about eight minutes left or so. So anybody want to, they have one hand over here? Can we get a mic? I always talk fast. Can we get the mic on? Try it again. I think they can throw it over here. You might want to start talking. Hi, I'm Manisha. I am, I have a question here, like you suggested revalidate, right, by prototyping. So the ideal situation would be my prototype is technically feasible, would be delivered in time and with the time constraint the tech team has, where they will be able to create the same thing. So when you say validate with end customer users, is it okay or, you know, is it a good practice to bring in the technical team also before I go ahead and present the prototype? 100%, 100%. Yeah. So if we go, if we go back to that section there, I'm not going to do it, but you'll see that I called out both testing it with the end users and collaborating with our different disciplines to iterate, right? So 100%, prototypes are great for lots of different things. They're great for clarifying with a PM and letting a PM sort of get a feel for, okay, they've described something in words. You've turned it into something real. Is it actually meeting what they were looking for? Show it to an engineering team and get their technical feasibility assessment as well as showing it to the end users. Absolutely, that's fantastic to do. We're like setting the expectation already that they're going to get. I'm sorry, one more time. Like before the users get the expectation that this is what I'm going to get. Sure, why not? Yeah, I mean, I don't think there's a rule that says you have to show it to the user before you show it to the engineers. No, I think either one works fine. Thank you. Other questions? Hello. My name is Prabhat. Where are you? Oh, there you are. So nowadays, there is a philosophy going on about seven-day design sprints. Yeah. So what's the timeline on the process that you describe? I mean, where does it fit into that seven-day timeline? Yeah, if it's not on seven days, it doesn't work. I'm just kidding. So all that process should be done in seven days. You're saying that? No, not at all. Not even close. What I will say is I'm not a big believer in rules like that. Right? I think that there's some good guidelines. I've given you some good guidelines here. You know, I think trying to do things quickly and using techniques like a seven-day design sprint can prove really valuable. I've run great design thinking, design sprint exercises, and we get great results coming out the other end. I've also seen teams where the complexity of the challenge is going to take two months. Right? So what I'm showing here are things that can flex across various time frames. Mostly what I'm trying to show is the sort of shape of the organization and the things that your organization needs to be able to do. Right? Your organization needs to be able to do all of these different things. And perhaps you're going to you're going to apply a seven-day design sprint to the first two here, right? Where you're going to do some quick research. You're going to then turn that into some sort of visual artifact. You're going to then prototype something. Right? This is more about like what are the kind of things that my team needs to be able to do. I need to have the right permission, the right people, et cetera, to be able to accomplish these things. And then you can apply whatever times goes appropriate. Does that help? Good. Hi, Dan. Oh, they said you saw this from the beginning. Can you stand up? I can't see. Oh, yeah. Oh, yeah. Oh, it's Halle. Hi, Dan. This is Vesal from Deloitte. My question is more from the point of view, you have different experience from G than now in Informatica. The whole engineering process was very different, right? So personally for you, how it was very different from design patterns, how it was in G, working with a different kind of engineering team now with Informatica where it's more data driven was the difference within the processes for you? The difference in the processes? Yeah. I think it comes down to more organizational and cultural differences than necessarily some of the other things, right? As far as like the underlying materials of like how you will build out the components and that kind of stuff, what kind of patterns you're going to tackle, probably will be a lot of similarities. Enterprise software tends to fit into some pretty sort of defined buckets. And so I'm not seeing a massive change there. What I'm seeing is sort of the soft parts of it, right? You know, we talked about how do you get your organization on board? How do you get different teams to work together, right? You know, sometimes you're working in an organization where you have a lot of very hard silos and you need to figure out a way to bridge across those. Sometimes things are a lot more fluid and that changes the way that you're going to sort of build your reusable patterns and that kind of thing. Thanks. You're welcome. Hello. Yes. So let's say that, well, let's call him a friend of mine works for a company that just uses maybe a style guide. So what are some tips that you have to kind of sell a design system? Sell all these processes to the higher ups and then also bring the knowledge to the rest of the company to where, you know, you can implement something like a design system that brings so much collaboration to the table. Cool. That's a fantastic question. One of my favorite ones, first of all, partially because I love selling design. I love being on a stage like this because I love being a champion and a cheerleader of it. Let's see. First, give yourself time. Like it might take a year, right? You know, and so be comfortable with that kind of situate yourself in that a little bit. Some of the things that I've seen successful in helping to sell this investment in creating design systems is knowing that you have to maybe work with people a little bit differently. For example, you're going to have to come up with an argument and a stream of work to get your developers on board, right? Everyone's going to have to agree on a react this or whatever, right? And so how are you going to do that? And you're going to need to spend time figuring out inside of your culture inside of your organization how do you tackle the development side of it? You're going to then go over to the product management side of it, right? Who are going to be, hey, I've got a roadmap, man. You're telling me to mess up my roadmap because I have to invest in this design system thing and you're going to have to figure out how do you kind of work with and convince them, right? Then you're going to have maybe some of the financial side of it as well like how do I get the budget for it, that kind of stuff. So think about those things as a way to sort of break the problem down a little bit so it's not just one monolithic piece. As far as arguments that you can be made certainly, you know, design systems super popular this day. You know, I'm not too proud to call out the name Google and Facebook and to say, hey, what's up? You know, and prove those as examples of why we should be doing something. I think that there's also people like Nathan who I called out here, people who have done studies around the efficiencies that you can get when you have design systems in place. You know, I think the last one would be think about what is a small sort of thing that you can ask for and you can bite off on. Can you get 50% of a designer and 100% of one UI developer focused on this effort for six months? Can you start to prove out some value and you're going to put together 18 components, you know, have them up here in two products out of 20 and to say, look, it's working, right? Now that's kind of broadening our scope and kind of go for, okay, we want 100 components and we want to touch every single part of our company. Things like that might be another way to tackle it as well. Great answer. Thank you. You're welcome. Hi. Question from my side. I think it's the last question. I'm getting the hook. Yes. All right. I hope you can hear me. So two questions for you. Yeah. The first one is an extension to the answer that you just gave. So how do you see heavy duty organizations, like huge organizations following this? And the second question is how would this fit in a 15-day agile work pattern? You know, we are getting towards DevOps a week of sprint. So how would this fit in that? Yep. So I'll tackle that. The first one is actually I think an easier question to be totally honest. Large organizations, how do they do it or how should they do it? Like how do, how they do it is poorly, right? Let's be honest. Or or inconsistently, right? I was having a great lunch the other day with folks in San Francisco who run Google material material design. And they're totally trying to figure this out still and they're seeing all kinds of issues and concerns and trying to get material design stamped out across all of Google, right? We don't see it as as users, Google still looks fantastic, right? But they're internally dealing with struggles there. Some of the ways that you kind of break down those silos I think is doing both a top down and a bottoms up approach, right? So doing things like figuring out who at the top of your organization can say, yes, it is important for us to have consistent look and feel, consistent patterns, consistent reuse of design elements across our company. And then how do you get the individual teams as well to get bought off on it, right? How do you do those two things simultaneously is the way that large organizations tend to tackle this problem. How do you fit it within the 15-day sprint cycle? You know, that's a tricky one, right? It depends on the team to be sure. You know, I think that that might be something you tackle again at that grassroots, right? You go to an individual engineering team and you're like, hey, can you give me every Friday or every other Friday in a sprint, right? And in that Friday, one of the things we want to do is look at all the UI you're building and componentize two things, right? And so as the sprints progress on, what you start to do is you start to pull out all of those reusable components into a design system and as you're delivering actual product you are simultaneously building this reusable piece. Something like that might be the technique you try. All right. Well, thank you all for the time. I really appreciate you spending the time. Kind of glad that I went fast and I had some questions there. So, thank you.