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?

  • How is this different from your original question: pm.stackexchange.com/questions/10973/… ? Feb 26 '14 at 16:15
  • 1
    Additionally, it is not reasonable to ask PMSE why your PM is angry and why they took the decision they did. Why don't you just ask the PM what the problem is and how you can jointly deploy a process that allows critical UX changes into scope with the PMs approval?
    – Marv Mills
    Feb 26 '14 at 16:19
  • The first question was about all UX decisions, while this question is about small UX decisions. The first question was about UX final say, while this one is about involvement in general. I see these as 2 different questions. Feb 26 '14 at 16:25
  • 1
    I fully intend to have a talk with the people involved, but before that I want to have an expert advice me on the matter. Someone must have a reference to some best-practice/guideline/example to support either side. The more info I get beforehand the better. Feb 26 '14 at 16:27
  • 1
    Unfortunately it is not possible to advise - weird. mike m. gave great advice. I did not make any assumptions. I am stating facts. Your comment just strengthens my case - when UX is involved, all of a sudden scope creep and budget overrun are used, but when it is a code refactoring task of same scale, PMs are usually not involved and they are fine with it. I never heard a PM get mad about not being involved in a small refactoring task. I did hear it about same scale UX tasks. I think it is very weird. Feb 26 '14 at 18:49

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.

  • Being a PM means making sure that all aspects of the project are managed efficiently and effectively. Great input. Thanks. Feb 26 '14 at 18:44

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".

  • First of all, UX is not an API to the user. The UI is. How the user experiences the UI is a different topic. And if there was a big change, UX should be responsible to guide the user along the process. Microsoft did a mistake in my opinion. Their change should have been made with "return to old Look and Feel" option if you ask me like a lot of sites do to let users get accustomed. Feb 26 '14 at 18:41
  • @guymograbi fair enough - I am mixing terms a bit. But I think the core point stands - there's a difference between making a change that no-one else needs to know the details about and changing things that do affect other people. Feb 26 '14 at 19:21


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.