 to talk to you about how to encourage everyone in your product team, so ranging from leadership, CEOs, to PMs, engineers to participate in the design process. So there is a quote that's largely attributed to Tim Brown. He's one of my design role models, and he's CEO of IDO. And he says that design is everywhere, so inevitably everyone is a designer. And I know when I posed this quote to a lot of people at work when I was practicing, this kind of was the response. And this is a PDF, so it's not working, but it's a really disgruntled panda who storms into an office, takes the computer, and swipes it off the desk. So really, I think that there is a lot of ambiguity and misunderstanding in what designers do and who should be making design decisions in a product team. So right now, I want you to think about what you do as a UX practitioner. If you're a designer, chances are you do research, right? I see some people shaking their heads. If you're a designer, you probably do some prototyping, whether it's with paper or code, envision, several of the softwares that we've talked about at this practice. So you know it's okay to wear multiple hats. So why shouldn't we expect the same of our product team? Right? As designers, as UX practitioners, whether you're a researcher, engineer, or designer, you wanna make sure that we deliver design, create, implement, fill in your verb of choice, good products. And good products are ones that meet our user needs and our business needs. But shouldn't that also be the responsibility of leadership, of engineers, whether or not they're part of the UX org, of any person who's participating on this product team? So the point of this talk is to empower all of you to go out and bring your teammates into the design process. So I don't want you to say, hey, come on, take my job. Like, you're not gonna become a full-time designer at the end of this. But what I hope we can encourage is easier collaboration. So this means when your engineers are faced with, you know, an option to come talk to you or to just do something on their own, they come talk to you. Having teaching design skills to your team will also result in design and decision-making. So ideally, you are invited to come have a seat at the table. If not, people are carrying around what you've taught them into the decisions they make. So if you have leadership going into a scoping meeting where they say, I have priority X and priority Y and they remember that user journey that you taught them, maybe they'll make the choice that you would make if you were in the room. And then the last reason I wanna talk about it is what I just said before is everyone participating in the design process has the same goal of this better end product or service or whatever you're designing. So I wanna give you five different ways or techniques to encourage people to participate in your design process. And to do that, I'm gonna give you an example of an app that we designed at Google. So this was the Google Analytics mobile app and essentially the goal of the redesign was A, to update it to the material design language, but B, to open it up to users that have previously either not been interested in the app and also to optimize it for more mobile on the go use cases. So the team was composed of two UXers, two PMs and 10 engineers. And this team had very limited experience working with UX in the past. But that's okay because they were super eager and they also had experience making UX decisions on their own because they previously didn't have the support of full-time UX designers. So in kind of this part of the speech, I wanna give you these five techniques to encourage people to design, participate in the design process. And I guess the structure that I wanna go through is I'll give you an example from the case study of the mobile app. I'll talk about what we did to solve it and then I'll end with a takeaway. So hopefully you could kind of understand if there's only one thing you leave this talk with, it's gonna be those five things. So the first challenge that we encountered in designing this app was speaking the same language. So like I said, there were a bunch of engineers, there were a bunch of PMs, a couple of UXers and we came in, did a prioritization meeting, had some scoping and wound up with these 10 features that we were gonna start to implement or start to design and work into implementation. So 10 features, 10 weeks, our very logical PM said, okay, Jen, give me one feature a week. Which you know in UX, that's really not how we work, right? I always give the analogy, you can't put nine pregnant women in a room for a month and have a baby and it's the same way in UX. But somehow I had to explain that there's a lot of thinking, a lot of discovery, a lot of process work up front before we get to kind of what you see as the end deliverable which could be mocks or specs or whatever you have negotiated with your team. So in this case, trying to explain this rationally to my PM, it wasn't really sinking in. And what we ended up doing was figuring out that we kind of weren't speaking the same way that we wanted to be spoken to, which sounds a bit silly. But this right here, it's called the true colors assessment and what you do is you kind of, you have all these values and you score it according to the directions and at the end you're left with a primary color and a secondary color and that tells you a bit about your personality but that also tells you about your teammate's personality and it tells you how to most effectively communicate with them. So how I was explaining things to one of my PMs is the way that I was expecting, is the way that I would explain things to my fellow designers or to participants that I'm working with, it didn't work. So going through this way and understanding that I was a green blue and he was a green gold, there was some sort of logical and rational aspects that overlapped but there was a very prescriptive, very logical way that he wanted everything to be broken up. So like how he deduced 10 weeks, 10 features, one feature per week. So what we did was we kind of spoke in the PM's language and we put together a schedule that outlined our key deliverables, all the key parts of our process into a way that he would understand and from that it took our very like rocky and tumultuous relationship into something that was a bit smoother. So at Google there's a very, very big stress on creating a psychologically safe environment and I propose that this is what this exercise will let you do. You wanna make sure that people are comfortable talking to you, asking questions, giving you feedback. Without that, you are not gonna draw all of the knowledge, all of the experience, all of the very valid ideas that your team has out of them. They're just gonna be closed and they're not gonna be able to communicate this to you. So there's a couple of ways that I've outlined on here. There's team bonding, there's ice breakers, there's Myers-Briggs, the true color assessments. We also value recognition a lot so it could be as simple as shooting an email to a team and saying like, hey, I worked with developer X and he was fantastic. Or I worked with researcher Y and she really helped me get to the next level. So take away one, create a psychologically safe environment. It will lie the foundation for all of your interactions moving forward on the project. The second challenge that we faced was every stakeholder. So when I say stakeholders, I'm talking about everyone ranging from the business, leadership, C-level suite, other UXers, engineers, UX engineers, prototypers, everyone. We generally have a lot of whiteboarding sessions together, especially in creating the app and for this example, there was a component called the date picker, right? So people need to select a time frame to kind of narrow their analytics window down. We were doing all of this sketching and when we were talking, I noticed that everybody was really interactive, they were throwing out examples, they were giving feedback, they were saying, oh, think about how Outlook does it. Think about how this other Google product does it. But when we moved to sketching, they kind of fell silent. I was like, oh, no, what's happening? So kind of aside, we caught up, I asked for some feedback about why things weren't going as enthusiastically as they were previously and the answer was kind of simple. They felt intimidated and they felt embarrassed that they didn't have any design skills. But that's not true, they all had design skills, they just didn't know how to communicate their thoughts properly. So what I propose you do to help solve that is to share your skills and share your files. So depending on where you are in the design process, it might be sharing a sketch document. What we did, because we were early on in the design process is we had some very basic wire-framing sketch files. We cut out the components and put kind of like sticky tack on the back, put them on the whiteboard and allowed the PMs, the engineers to come in and manipulate them, move them around, draw on them with Sharpies or whiteboard erasers or something like that. So we provided a foundation for them to come in and say, I can be creative, I have these ideas, I wasn't comfortable expressing them, just picking up the whiteboard marker myself, but now that you've given me this base foundation, I have the tools, I have the ideas and I can express them. So like I said, it's really about communication and your job as a designer is to make sure, or a UX professional, is to make sure everyone feels comfortable. So it builds off of that psychological safety foundation and comes into comfort in expressing thoughts and you could give your team the tools to do that. So ideas could be facilitating a design sprint. Google Ventures created this workshop that's really good, a workshop methodology that's really good at getting teams together and has a whole bunch of different methods for expressing ideas for people who are more thinkers or more speakers or more drawers. There's also the teaching a class or workshop. You have a whole set of skills and knowledges that other people on your team lack, share it with them. And then also maintain a design repository where people could get what they need, they know where it is and they could start communications and conversations with you about that. So the third challenge was we had two PMs, we had 10 engineers and to be honest, that's a good ratio, right? Like I will probably bet my career on saying that in every project you're on, UX will be severely outnumbered. Everyone knows the UX team of one, right? And we were fortunate enough to have two, but that doesn't mean that design can't help, right? So when an engineer comes up to me and says, I have this problem, I might not be able to solve it for them, but I could equip them with the tools or start them on the path to answering that problem themselves. So remember, we want them to think like designers when they're making decisions. We wanna give them those tools because sometimes we don't have the bandwidth to do it all ourselves. So what I propose you do that works really well for us is scheduling office hours. So essentially it's just like you're back in uni or college, once a week, for an hour each week, book a room and invite your entire team. So this provides time, really dedicated time for them to come to you with any questions they have. It could be around implementation, it could be around projects that you have not been allocated to, but you want to be there, you wanna make design accessible at all times. Basically, the other thing that I wanted to mention is in this, there is a lot of cost in task switching. So it is what you heard in the keynote a little bit this morning when you have a lot of engineers and a lot of project managers coming to you and interrupting the design work that you're doing, it could be really jarring and it takes a lot of mental work for you to switch tasks, answer their question, regain composure of what you were doing previously and then going back to designing again. This office hour technique also helps solve that because what we've noticed is a lot of people will save, a lot of your teammates will save those questions and bring them to these office hours. So instead of getting interrupted five times during the week, you have this concentrated session where you could continue to help them but you also don't have to be disrupted from whatever part of the design process or life cycle you're in. So the fourth challenge was everyone should feel like a product owner. So there's a big part of our mobile application is the data visualization. So for Google Analytics, it's really important that we could communicate things to you, communicate your data and summarize it in a really at a glance understandable, intuitive way. And because this was such high impact, PMs wanted to own the design, UX wanted to own the design and engineers wanted to own the design. And you know that's great if everyone agrees but sometimes that's a lot harder said than done. So what we did was facilitating a participatory design or co-design workshop where essentially I created these templates and I said, hey, we all have ideas around this and I want to build it together. So instead of saying, I'm the designer, here's what we're doing. I want to harness all of their information, like all of their ideas and information that they have in their head. And in some way, collect it, aggregate it, look for patterns, and then try to summarize it and put forward a proposal based on what I've learned from them and what they've learned from each other. So this is just an example of the template. We had kind of the information that we wanted to show and in this case we were looking for comparisons. What's the best way to visualize comparisons between this week and last week, this month or last month? So this can be kind of put into practice many different ways. So this is just an example of a co-design workshop. You could also delegate tasks, right? If you have built up the foundation that we've previously established here, you're making yourself accessible for when there are problems for people to come to you when they hit a roadblock. Why not give out tasks that you don't have time to do or you think someone is better suited to do? And you as the designer will continue to own them and make sure they're of the quality, they are meeting user needs and all of that, but you are empowering others to own the product just as you are owning the product yourself. So takeaway number four is sharing this ownership either through co-design or a delegation of tasks. And then the last one I have for you is kind of the definition of done. And I think this is something that all UXers struggle with a bit. Like, am I done with the design when it's successfully passed around of usability testing or is it when I hand off to engineering, is it the second I have the spec done, right? Like, it's really ambiguous and you need to determine this together as a product team. So there's a bunch of decision-making frameworks and a quick Google will yield literally tons of them. But what we basically did was we called out a bunch of design principles that if the design satisfied all of these requirements and we would have evidence based on usability testing, we'd have data analytics, we'd have a bunch of prototypes, we'd have cafe sessions where we just talked to different people during lunch. If the design met these things, then we could move forward. And even though it's not done, right, we're still iterating on it, that meant that it was safe enough to continue to share with engineers, with product, because you don't wanna keep everything to yourself and throw it over the fence afterwards. You wanna make sure that everyone has time and are empowered to kind of provide feedback, to participate in the process. So again, if we agree on a decision-making process, the last takeaway is everyone will kind of understand what you are defining. And then there will be less ambiguity and everybody will be on the same page. So you could continue to move forward together and make decisions and tackle the next feature or problem or whatever is on your to-do list. So just to recap, I've shared with you five different tools for you to help establish and grow design within your product team. The first two are really about creating this foundation. We want people to feel safe. We want people to express their opinion and thoughts. The third about scheduling office hours is about making design universally accessible and making sure you're there to help and support your team. The fourth is sharing ownership of tasks with actual impact and that's kind of self-explanatory. And then the last one is making sure everyone agrees on kind of definitions. So when a decision is made, no one feels left out, no one has any concerns or doubts and you can move forward designing the product together. And that's what I have for you guys. So I think it's, that's a very loaded question. The question was about how we define a problem statement at Google and I think it's largely marrying two things, right? We have our business needs and our user needs and each respective kind of role within the product team bubbles them up. So PM and leadership will say these are our business goals and UX will say these are our user goals and then we'll try to put them together and say, you know, here are kind of the journeys that we need to focus on, here's the problem that we need to solve and then here's kind of the metric or something that it will affect based on, you know, what we've done historically or what we could infer from the process. And then one more tool is, which records all the sessions. So Google Analytics looks like a tech oriented with all the numbers and stuff. This gives me, the other tool gives me a lot of insights about how the user is behaving. Yep. Is there any need for us to understand the user's behavior and analytics? Yeah, there are a couple of like user behavior reports in analytics. There's also a feature that's just been rolled out in the past like month or two. It's called the assistant in analytics and what it does is you could kind of ask a question and it gives you some sort of aggregated insights about it. Yeah, I'm not certain because we don't want to record anything that has PII in it. So we give them up. Thank you.