 Welcome to this session. I'm Johann and this session is about best practices when working with UX teams. Few words about myself. I work in product for 13 years now. I started my career in retail software. Then I moved to a surface as a service company offering B2B solutions in the search space. And now I'm working at eBay Klein Anzeigen, the largest classifieds player in Germany. So today I would like to talk a bit about UX and how you can best leverage this domain as a PM. So there are things that early stage PMs could do better when they interact first time with design teams. And there are also things that might be interesting to recap on if you already gained some experience. Well, as a PM you face challenges when touching the UX and the design domain. For instance, when do you involve UX teams? How best to prepare? And also how can you ensure that you create a UX that your customers love? So to spark some thinking around those questions, I divided the content into two parts, the UX briefing and the UX review. So let's start with the first part, the UX briefing. It's safe to say that the better you do your job in this phase, the smoother the second phase will be. Now when briefing UX designers, there are quite some boxes you wanna have ticked before even reach out. It's all about the objective. What do you want to achieve? Now this sounds pretty trivial, but if you zoom in a bit more, you might discover some tricky things. So first of all, who is your persona? Usually you do not only have one type of user, but you deal with segments of your entire user base. So in multi-sided marketplaces, for instance, you have buyers and your sellers. Now obviously any product feature you're planning, you need UX for and this will have impact on both sides. So think about it. Is there a persona that might benefit less or not at all? How would that persona perceive that experience? Try to cover all personas in your 360 degrees thinking. Now in order to further specify your objective, you need to differentiate between the, maybe conflicting goals your persona has and the goals your company has. So sometimes the feature you're planning is centered around certain business objectives, right? However, such an approach will not be successful if not related to actual user problems. So specify the problems your users are having and why the feature should solve those problems. It's important to focus on the why and not so much on the how. As this is the UX designer's task and you do not want to prescribe too much. However, the UX team should hear the rationale from you as a PM. Another item you would want to think about is the user journey. So usually you can expect from UX teams to be fully aware of the entire user journey. So there is no need to cover it, and it makes sense to be fully aligned on the entry points of the plan feature. Please note that talking about potential entry points could already be too prescriptive. So better phrase this as questions, even if you already have good ideas about where users should access the feature. You also want to pause a second and think about how this product change will be perceived by existing users compared to new users. While the feature could be something your existing user base is waiting for years, new users might be overwhelmed by it. So when thinking about how to merge your feature into the overall user journey, also considered a cognitive load of existing users versus new users. Another dimension you want to be aligned on with the UX team is the actual situation the user is in when being in contact with your plan feature. For instance, will it be mobile only? Can we expect users to be motivated to use it or does it somehow needs to be advertised within the overall product experience? Are users typically in a hurry when being in touch with your feature or do they have all the time in the world to explore it? What do you want to achieve is basically creating a UX that reflects real world situations your users are in. You also want to think about emotions you're aiming for, right? Just aiming for joy of use might cut it a bit short. So think about various types of emotions and which one should be predominant. Let me give you some examples. So for instance, the user experience of the Pinterest feed might be all about exciting users to discover new things they like. So excitement is the predominant emotion. In contrast, a new feature within a banking app might be more focused on making users feel in control and aspects of trust might be crucial. And products, for instance, leveraging the power of community would aim for a felt sense of relationship and identification. Think about the fact that next to functional components, there are also emotional components in your user experience. Make sure UX designers are considering both dimensions. So bottom line here is, when briefing UX teams, do not limit yourself to user problems and wireframes, but also talk about which users you are addressing exactly, in which situation they might be in and what they should feel when interacting with your product. Well, next to user-centric thinking, you also want to make sure that you have a good approach in how to measure success of your planned product feature. So be transparent about the business metric you want to drive and how this metric usually is measured. This information might have impact on how UX teams would design user flows and should not be overlooked. In the end, you want to be able to quantify the success of your planned feature and that requires tracking of your user behavior. Now, if you brief UX designers up from clearly about what exactly you want to be able to track, this can avoid a lot of back and forth. And it will be a time saver for you and for the team. Last but not least, it might make sense to also share your thoughts about the scope of the initiative. Maybe the planned product feature you're talking about today is actually just the first tiny step of a way larger initiative. And knowing this early on will make UX teams think a bit more proactively, as they might anticipate potential further iterations already when designing for the MVP. All right. So let's zoom in on the second part, how to evaluate suggested solutions and how to take it from here. So most importantly, listen first and take your time. If you think the suggested solution is not meeting your expectations, analyze precisely what you got. Think about it this way. Your design team invested reasonable amount of efforts to provide a solution to the challenge you formulated. Now it's on you to invest adequate time to work with that. Now you will feel much more comfortable if you have specified explicitly the needs and watch-outs upfront in the briefing fix. Just have a look back on your briefing and compare it with the provided solution. You will be able to clearly state which aspects would need refinement and which ones are just fine. And while doing that, clearly separate between UX and design aspects. When we talk about the UX, we often blend in design aspects and we shouldn't. It's necessary to differentiate both decisions. While UX is focusing on customer needs, information architecture and interaction principles, interface design is focusing on things like layout, visual design, spacing, fonts and colors. So when you are in a UX centered conversation with your team, make sure that you clearly separate both roles when giving feedback. And when given feedback, observe yourself. How often do you use phrases like, I think, I would, I assume. Good PMs do not center around their individual perception. Instead they have a process in place to give the voice to the users. So conducting usability testing is the best practice here and do not do it once. Make it become a habit in your organization. So you do already do UX testing on a regular basis. That's great. But just listen to users while interacting with your product could end up in having more questions than answers. So to move forward faster, I recommend to come up with clear hypothesis before the test. A handful of hypothesis covering your expected set of user reactions will allow everyone involved in the UX process to validate the current solution. And whether or not it can be built or it needs another iteration. And without a hypothesis, you would get unstructured feedback. And that would be open for interpretation and could eat up valuable time. And last hint, when conducting UX testing, take good care on wordings. So PMs and UX designers, of course, they know that wordings on a product can easily be changed before the release, right? But when conducting UX testing, one should acknowledge that how you name buttons, for example, will have huge impact on how users perceive that in the test setting. So aim for final wordings before running the test. And this will give you the best real-world feedback you can get. And with that, I conclude the session. Thank you for listening. I hope it was valuable for you. Feel free to reach out to me anytime on LinkedIn. Have a good day and take care.