A Designer so committed to the science and theory of user interface design, that they ignore the UI requirements coming from the stakeholders.

• Can mutate into: “The Blueprinter” Designer
• Dangerous when coupled with: “The Patent Author” Product Manager
• Likelihood of fixing: None
• Danger to project: Extremely High

Problem

User Interface (UI) design has its roots in Human Computer Interaction (HCI), a field of study that has existed since the early 1980s. The associated research and the resultant best practices – if followed – will result in an easy-to-use UI. Unfortunately, most Product Managers do not know or care about HCI, and specify requirements that fly in the face of decades of HCI research. The Professor Designer responds by simply ignoring the specifics of the requirements, and instead translates the requirements into a UI that is rejected by the Product Managers, halting the project.

The Professor designer is the only personality type that can halt the project completely, and as a result is extremely dangerous. Requirements cannot be handed off to developers, as The Professor cannot get approval on the UI from the Product Managers. However, the Professor refuses to change the UI as it is “correct” with regards to HCI-based analysis.

The obvious solution is for them to compromise, but they will not, as they view their role as enforcing HCI standards. They are no more likely to change their position than a security analyst making recommendations to patch security holes. Ultimately, they see their job as blocking Product Management’s poor UI decisions – and block them they will.

The Professor is only a problem when they do not have absolute control over the User Interface. If they do, the project will flow smoothly and will most likely have a UI the users will love. If they do not, the project will simply stop. If the project has a fixed delivery date, every day the requirements are not handed off is another day the developer cannot begin developing the requirements. This effect is amplified in projects utilizing Waterfall methodologies, where the developers are waiting for all the documentation before they can begin with analysis and implementation. The result is that the project runs out of time having delivered nothing.

Solution

You can no more fix The Professor than you can fix your doctor: If you have a disease, then you have a disease, and their recommendations for treatment will not change just because you disagree with them. Like a doctor, The Professor is doing the job they have been trained to do, and they have conditioned themselves to trust their training regardless of outside objection.

The argument could be made that The Professor is not a problem at all, and that it is Product Management who is stepping outside of their area of responsibility. Indeed, this power struggle is why the project has deadlocked. Ultimately, the best solution would be to convince Product Management to give up all UI control, leaving it in the capable hands of The Professor, but then you are removing a large part of a Product Manager’s ability to manage the product.