PMs treat UX differently - why? [closed]

Question

As a java developer, if I want to refactor some code, I can usually just go ahead and do it. I might need to approve it with team lead or head of R&D, but generally, if it is a small refactoring task (make static methods to singelton) and the team is fine with it, I can go ahead with it.

If my code was part of API, obviously it would have better supervision, but it is not. As long as the code works fine, and the tests pass right, everything is well. PMs are never involved in this process because they do not always have the experties, interest or "jurisdiction".

This is somehow intuitive to a lot of companies.

Sometimes UX is like a refactor to the UI. We have a web application. Our application has a page where you select a value from a drop box and then click on button "execute" which opens a confirm dialog. A UX expert told me the "Confirm" dialog is bad UX and not required. Users will not select a value from the dropbox AND click execute without meaning to do it.

I talk to head of R&D, we decide to go ahead with the task. We make sure it doesn't break any API and that all tests pass and we complete the task.

If it was a big UX change, we would have notified the users (like google did with instant search), but it is not. Moreover, this is the first version! so no customers to notify. But generally, It is a UX responsibility to make sure users have a nice transition.

But the PM is angry.

Why? Why do PMs treat UX differently? It seems unfair. I mean it is obvious this is because UX is visible unlike code refactoring, but why do PMs treat it differently?

Even more so it seems to me unhealthy to the company.

Am I wrong here? Should PMs have so much control over UX? Is there no best practice for this in the UX/PM world to stop these roles from colliding all the time?

Answer 1

I believe you hit the nail on the head when you said:

I mean it is obvious this is because UX is visible unlike code refactoring

Project Managers tend to assert control over all aspects of the application, but especially over what he/she, and the user, can see and interact with. In this case, it seems like a relatively simple change and I'm a bit surprised that the PM got so bent out of shape over such a small impact.

This particular instance may have more to do with the principal of the matter. If you were supposed to discuss with him the UI/UX change and you didn't, it wouldn't matter how small or large the change was, if the PM is the type of person that gets angry when he/she is not informed about changes that they believe impact their area directly.

Should PMs have so much control over UX?

Well, that's a tricky question. Yes, and no. PMs should definitely have some control over UI/UX because they tend to be more seasoned with understanding the business, the users, and the interactions between the two. So, they tend to offer very valuable input on what will work well for your user base, and what won't. However, at the same time, if a PM is too involved in this process, it can definitely hinder efficiency and effectiveness. A good PM knows how to offer solid feedback on the UI/UX design and what will work for the user base, while also realizing that the technical design and implementation aspects are best left to the development team.

Is there no best practice for this in the UX/PM world to stop these roles from colliding all the time?

"Best practice" will differ from business to business. My personal approach as a PM is to give enough input to the technical team so that the interface is efficient, easy to use, and makes sense to the user base. However, I don't bother with mundane details. If it's a small change, and it needs to be made....I say "do it!" But our business seems to work better with the PM focusing on exactly that: Project Management. Being a PM means making sure that all aspects of the project are managed efficiently and effectively. When a PM gets too involved in one area, or gets his/her ego hurt when a small change is made without his/her approval, it tends to hurt the entire project.

Hope this helped.

Answer 2

Because UX is a forward-facing element.

You mention in your question,

If my code was part of API, obviously it would have better supervision

The UX is the API to the end-user, if you think about it. You don't have to look farther than MS Office to see how changing the experience can cause problems even if it's now "better".

Answer 3

tl;dr

The PM has (or should have) sufficient power to ensure that the scope is completed on time, on budget and is suitable to the customer. The PM is the executive agent for all of the stakeholders, and for the sponsor. The solution to the problem is to recruit the PM as an ally rather than an adversary.

Does the PM have a vested interest in controlling UI changes?

Yes. The PM has a vested interest in all changes. Changes have been proven to affect schedule, cost and quality. Changes to UI have a particular impact on quality and on the customer's perception. So the PM is within his rights to examine the problem.

Solution

I think this is an example of needless conflict. The PM wants to assess the change

• what effect will it have on cost?
• What effect will it have on quality?
• What effect will it have on the customer's perception?

If you can offer that analysis, you can recruit the PM as an ally.