I’ve meant to write this article for several months, and I finally had a chance to put it together. Thanks to my GoDaddy colleagues, Tapan Kamdar, Sarah Ptalis Phoenix and Jyothi Trishuleshwar for sharing their Product Management perspective.

UX Designers: Have you ever started working on a User Experience problem that began as a happy relationship between you and your Product or Program Manager only to turn sour a few weeks or months later? Have you found yourself feeling disempowered and ignored by what you perceive to be a lack of customer empathy and an over-emphasis on business goals? Have you felt like you are being treated as a “wrist,” simply there to articulate someone else’s vision of what the product should be?

Believe it or not, you may have brought it onto yourself by not taking the time to set up your engagement model.

Whether I’m working on an extra large UX problem or a small UI design, I’ve come to realize that I can take certain steps to improve the way I work with my Product and Program Manager Teammates.

I hope that this article will help you have a smoother sailing as you work with your counterparts:

Tip 1: Set expectations

One of the basic things one must do is to make sure that you understand what your purpose is in the new project and also to create a mutual understanding of what your role is and what you will be delivering as part of your engagement.

Make sure that you set up a kick-off meeting with your peer so that you are both in agreement as to what your responsibilities are and what s/he will be delivering in order to support the effort.

At this point, you can talk about some other things that you believe you could bring to the table. For example, you can talk about how you will go about understanding the problem, how you will define the information architecture, create wireframes, identify pain points, the method s/he might use to communicate your design and how you expect to work together.

Tip 2: Roles and responsibilities

As we move through a UX problem, we are often surprised by finding out that there are people whom we should’ve included in the process as a point of contact or a source of feedback. This becomes even more complicated when we don’t understand what to do with the feedback that has been provided because s/he has not been clear about how we are expected to process their input. In order to minimize this problem, I always work with my PM to create a responsibility Matrix. My favorite one is called RACI and I use it to understand who is responsible to make what type of decisions, who is accountable to make a final call, who should be included as a tribute to the effort, as well as to identify who should be informed of what we are working on. The responsibility matrix should not take you a long time to capture and should be a living document which evolves as the project moves forward and people come in and out of the project.

“Understanding the RACI model around how you are going to solve a UX problem is one of the most important alignment issues to solve at the start. Not just your understanding, but also making your stakeholders understand their role in the process. Everyone thinks they are a decision maker and designing a solution is not a consensus-based approach.” — Tapan Kamdar. Vice President Product Management

Who makes the final UX Call?

One sure way to drive away designers and UX architects is to disempower them by giving product managers the final say on every detail of a UX solution or design. Making a final call on interaction, layout or look and feel should be left to experts. Product and program managers should make calls based on impact and amount of effort it will take to implement, maybe helping prioritize what gets done first and second, but not making decisions which those of us with training and expertise should be making. To that effect, UX designers should learn to ask questions to understand when somebody is communicating requirements and when somebody is simply expressing their opinion. On the other hand, product owners can become more effective by asking questions such as “How could we make this easier to read?” rather than, “You need to make this two columns because I don’t think users will understand what is going on”.

Scope

Depending on the complexity of the project, the scope of your engagement will be different so it’s important to have a brief conversation to understand it. Include a section that talks about what you will do and what you will not be doing. As an example, you can talk about how you will be working to articulate the vision of what the project should identify, pain points, etc. But perhaps you will not be responsible for doing a competitive study or maybe you are running a quantitative survey. It’s also important to talk about what you expect from your program manager in order to support you during this process. For example, if you need help identifying technical issues that may affect your project, that would be a good thing to talk about here.

“Historically, in days of waterfall and “handing off the baton”, product management wrote requirements to an extreme. Sometimes as a job function and sometimes as a CYA. As a Product Manager, I prefer that my peers tell me what they need to be successful in their discipline. Not only does this reduce work on me, but often leads to improved working relationships, time to delivery, and a better design.” — Sarah Phoenix-Sr. Director Product Management

Tip 3: Write a creative brief

The way that managers and UX experts communicate is often different. Product managers usually concentrate on articulating their version of what the product should be and important things such as how systems will talk to each other, what kind of ROI they expect, what teams should be involved, etc. UX experts need to communicate what the vision of the project is from a customer perspective. In order to do that, I often write a creative brief which includes my thoughts on what the end solution will look like to customers. I could write an entire entry on how to write a creative brief, but for now, I would usually divide it up into the following sections:

1. Articulate the current problem you believe customers face and what this solution will solve

2. Talk about how this solution will improve the experience for customers and how it will address their pain points

3. Tell a story of how one of your personas would interact with the new user experience solution, how they would feel and what would excite him or her

4. You might want to talk a little bit about some of the complexities involved, such as how your solution is tied to the rest of the business ecosystem

5. Finally, I recommend that you write a couple of press releases or Tweet samples to communicate how people or customers will feel about the product when it ships.

“When I think about the role of product, it is critical the product manager articulates the problem faced by your customer. The PM often gets lost in defining vision, requirements, and priorities that sometimes blend with the “how”. It is important to be clear this is the expectation of the product manager early in the process, even though you will both uncover the details of the problem as a team. “ — Sarah Phoenix-Sr. Director Product Management

Tip 4: Do your research, gather feedback

As you move along a project, you’ll often find that you get a lot of opinions on what the final solution, layout, or even the colors your UI should be. This can become very confusing, but it’s exactly the reason why you created a RACI in the first place. You can refer to that and respectfully communicate how you will validate some of the assumptions and comments you have been given. You need to support and validate all assumptions by doing your research before, during and after the project. You also need to make sure that as you do this, you and your product manager agree both on the methods and findings of research so that you can be on the same page and communicate the same way. If there is a disagreement on the conclusions of any research, you must both agree to disagree and find a way to move forward and not continue to spin on the project.

Tip 5: Move quickly

I’ve found that one of the greatest fears from many product teams is thinking that some of the work you are proposing is going to slow the project down too much. This is particularly true when we propose what they perceive as large amounts of qualitative and quantitative studies in order to understand the problem we’re trying to solve, and how we are doing as we reach a design solution. This is probably due to the fact that up to a few years ago finding participants, working with your research team, setting up a study, gathering feedback and reporting it used to take a significant amount of time. However, nowadays there are tools and services available to the UX team which make it rather easy to collect the necessary information and validation in a relatively short amount of time. We have tools such as usertesting.com which allows us to put it all together within a few days and quickly turn the results into action. So, as you talk about the deliverables you’re planning to do, make sure that you get give a sense of how long it will take you to deliver whatever you’re proposing so that you can set the team at ease.

Be open to learning as you go.

As Designers, we often strive to design the perfect User Experience or User Interface and continue to spin on details before putting something out there to learn from. We focus on the perfect “Can they use it?” before understanding the “Will they use it?”. Sometimes this is done out of fear that shipping something that is not perfect will never get fixed again or that it will reflect badly on us as designers. Try to remember that your design is ever evolving and there will eventually be an opportunity to improve it, even if it’s not by you.

“Designers and Product Managers are two sides of a see-saw. Each role strives for perfection around different views. Everyone values customer experience, yet each side adds his or her own additional metrics to evaluating outcomes. If both sides are happy with their MVP , you have failed. MVPs should help you get feedback from users on an end to end experience, but not make you feel so proud that you would announce it to your friends and colleagues.” — Tapan Kamdar. Vice President Product Management

“Product and UX need to learn to be iterative in their design discovery. There should be some level of defined work, clear decisions made, and rapid sharing (in market or testing with customers is best). I often find PM and UX can fear making decisions. It is best to make a joint assumptive decision and move in the wrong direction together than spin on decisions to make a perfect choice independently. The latter often creates lousy working relationships, and the decision is ultimately flawed once you get to market and realize how customers use the product delivered.” — Sarah Phoenix-Sr. Director Product Management

Tip 6: Win and Lose together

There’s nothing more frustrating for a designer than to be hired into a project or company which is risk-averse. By this, I mean a company which is so afraid to try new things that whatever the proposals being put together by the design and product team, they never see the light of day. The company and the designers need to be willing to take responsibility for the final outcomes together. Whether the product ships with some issues, whether it was well or badly received, whether the result was what was expected or not, there should be no blaming. Everyone needs to take it as a learning lesson and move on. That’s why it is so critical to work as a team from day one. We need to back each other up if we want to succeed at delivering great customer experience solutions.

“High performing product teams are characterized by Product Managers and UX designers who complement each other well. Great UX designers help their PM counterparts by pushing boundaries of customer centricity and in striking the right balance between customer and business outcomes.” — Jyothi Trishuleshwar — Sr. Product Manager

Challenge:

In one or two sentences tell us a tip you would give a UX or PM peer as they start working on their next design project together!