To a certain extent, every UX designer is a human behaviour specialist. But that does not necessarily mean that we know what other people are thinking. And it is painfully evident when it comes to communication within a team. Case in point - product owner/UX designer relations. Ever since I became a UX designer, these relations have been somewhat of a mystery to me. But what a mystery was the understanding that well-being of the whole project sort of depended on them. After all, proper communication between a product owner and a UX designer helps maintain unified vision of the product and effectively manage backlog. All of that is essential if you want to deliver a well-designed product with a potential of becoming a user-favourite. wasn’t Thanks to the many years I’ve spent working in the field, I now possess both knowledge and skills that allow me to efficiently communicate with product owners. But I don’t want to rush into sharing my surefire tips with you just yet. First, let me briefly tell you about the project I'm involved in as a designer and what my role in it. Project’s Context Currently, I work as a lead UX/UI designer of a squad in a 5-squad project. Each squad has its own product owner. Our product is evolving at an increasing rate. The design team pulls double duty - we enhance the current functionality all while developing new features for the product. So you can imagine how busy we are. There are instances when one squad’s design work crosses paths with another squad’s functionality. That’s why each squad’s designers have a neck for efficient collaboration. Despite the seemingly chaotic workflow, we manage to deliver a product that is usable, accessible, and that follows the best user-behaviour practices. And we’ve managed to achieve it through proper communication of product owners and designers. Want to reach the same level of efficiency? Then without further ado, here are the tips I believe will help you. Surefire PO/UX Designer Collaboration Tips Perform Regular Catch-Ups This might be a no-brainer, but still some will ask - how regular should they be? In the course of my current project, the product owner and myself have meetings once a week. We discuss the backlog and establish task priorities for a certain span of time, ranging from one week to a month. If other squads are working on a similar task, I might ask for a brief update on their progress. Keep in mind that during these meetings we refrain from discussing designs or any related issues in terms of future projects. These catch-ups are solely designed to make sure me and the product owner are on the same page when it comes to backlog projects and their priority. Define Design Functionality KPIs Once a design task from a PO drops, I am in charge of acquiring initial design and technical requirements. And one of the first questions that I ask is “ ?” You wouldn’t believe how much it changes the way we view the design process. Say, the primary KPI of a new feature is the engagement rate. With this in mind, a designer will come up with a page navigation solution that will walk the user through the page to their destination. In other words, knowing your design KPIs is the key to success. What are we going to base design evaluation on **Hold Inter-Team Workshops \ I’m not exaggerating when I call workshops an absolutely necessary activity before you start working on your design. With the PO and your technical team on board for these, you’ll be able to foresee all the potential pitfalls, especially if you are working on a complex functionality. During these workshops, you can acquaint your team (devs, QAs, business analysts) with the product concept and your vision of its functionality. Consult with your team on whether what you have in mind is doable and how to deliver designs most efficiently. After all, the technical team always has their own vision that might be different from yours. So go the extra mile to learn it. Define Clear Deadlines Throughout Clearly set deadlines are a key to your product’s success. The product owner is the one who is responsible for the backlog, i.e. they decide when a certain feature should be available for your user. But setting a deadline for a feature stretches far beyond a deadline for its design. It should also include a deadline for the delivery phase as well. By the way, workshops from tip 3 work wonders in this regard. In summation, if you and your PO split your design into several phases and assign a deadline to each of them, you both will have a clearer understanding of the leeway you have. And being on the same page when it comes to deadlines will only improve your relationship and collaboration skills. Be Mindful of the Technical Side As I said before, as a designer, I am responsible for collecting technical requirements for the initial stage of designing. Knowing the technical part of the whole process helps me understand whether my vision can be realised at all and whether it can be realised within the time limit set by the PO. Granted, this process stage eats up my time, but it fills me with confidence. I call it the discovery phase - it is the time when I actively discuss the feature concept with back-end and front-end devs all while having the prototype and the feature warframes at hand. Don’t Be Afraid to Say ‘No’ to your PO This is a skill learnt with time. But the sooner you acquire it, the better. The ability to say no will save you a lot of time and headache, and not just for you, for that matter. POs can be creative. Devs might consider themselves omnipotent. But even if you as a team do something, it doesn't mean you . Try to strike a balance between the value of a specific feature for your user ( keep in mind the KPIs from tip 2), the entire product’s design consistency, and the time spent on developing a certain functionality. So if your PO has a crazy idea, and you recognise it for what it is, be polite but firm. “No”. can should Three Pillars of Success And that’s it. So if I was to condense my vast knowledge on the matter into a few words, here it is - you will have a superb product owner/UX designer relationship if you bring to it honesty, frequent communication, regular check-ups, and design decisions that are based on data and analysis. Ticking all these boxes efficiently takes time, and both the PO and the designer should contribute. That wouldn't be fair of me to say that all these tips are universal and can be applied anywhere in your job as a designer. After I've worked on projects of varying scale - from a one-designer startup to a 12-designer team - I've come to realise that sometimes universal tips aren't your best option. That is why expanding your knowledge and skills through observing your fellow designers, reading books, and taking courses will teach you to come up with solutions to any cases. But if everything fails, remember this - when it comes to PO/UX designer collaboration, it’s a bit like parenting. Instead of bickering with each other, you need to work on how to solve a problem or decide on an issue. The best tactic is to communicate. So let yourself be heard.
