There’s a buzz going around about the conflict and collaboration between product managers and user experience professionals. It started with a pair of articles co-written by Jeff Lash and Chris Baum. In short, with a user-centric view of products, both roles are responsible for the success of the user-interactions. Who makes the decisions?
Ultimately, since product managers are responsible for the overall success of the product, they are the final arbiters of what the product should do. A good market-focused product manager understands the market context and customer needs and makes appropriate decisions about features and functionality based on first-hand experience and all available research.
Jeff and Chris make a really good point, but note that they do not propose delegating decision-making to the UX professional. While this statement is certainly true, it reads as if there is an opportunity to delegate more.
Roger Cauvin wrote an excellent summary of the conflict and proposes a resolution that involves more delegation.
“A product manager frames the usability metrics… An information architect designs the user interactions and interfaces that will satisfy these usability metrics.”
We agree with Roger (mostly*).
Don’t Do Someone Else’s Job
They won’t do yours.
Very few product managers would argue about “back end” architecture decisions. The decision that the implementation team makes (say relational database versus flat files) is intuitively not a “Why” decision but a “How” decision. Why do product managers then get involved in debates about user interface decisions?
Do you argue for things like:
- The user must be able to order their item with no more than two clicks.
- The UI can not use a CAPTCHA to validate that users are actual people.
- The information must be presented in a tree control.
These are implementation and design choices. Not requirements. They may be classified as constraints, because someone (the customer) mandates it – perhaps you are writing custom software for a company that enforces a style guide or other interface-guidelines. But they are not requirements. If they come from the customers, they are constraints – if they come from you (as a product manager or business analyst), they are “design ideas.”
Usability Requirements
This is a very difficult thing to do. Here’s how we would approach the examples above. Comment below with alternative suggestions, there are probably better ways.
- The ordering process funnel (from decision to purchase until purchase has been executed) must have no more than 10% fallout (customers who initiate, but fail to complete an order).
- (A) The user interface must prevent access by bots (automated external systems). (B) The user interface must meet accessibility guideline [insert spec here] for visually impaired users.
- The hierarchical nature of the information must be presented to the user.
*This is the one area where we disagreed a little bit with Roger above. We completely agree with his view on responsibility, we just disagree on his (referenced) approach to documenting usability metrics.
Comparing Approaches
In the first example, we replace “two clicks” with a fallout metric. This is more aligned with our actual goal (high conversion), without specifying design. If the design had ten clicks, but they were compelling enough that people were not giving up, we would be fine.
In the second example, we specify accessibility criteria for visually impaired users (technically a constraint) and the requirement that automated systems not have access to the system. There are “audio captchas” that could work, and “interrogation systems” (pick the picture of a dog, what is 8 divided by 2, etc) that would not meet our true requirement.
The third example is more obvious – we require that hierarchical information be communicated. We don’t specify that it be in a tree.
Summary
The product manager should be just as “tapped in” to the customers as the UX professionals on the team. That doesn’t, however, mean that the product manager is as good at making user experience decisions. The product manager gets a veto vote, but should be very cautious in using it. Likewise, the product manager can veto the choice to use AJAX vs. Flash. That doesn’t mean he should.
Roger’s approach of delegating responsibility for implementation decisions (including interface design) is definitely the right one. The challenge is to define those requirements without specifying design or otherwise being arbitrary (like specifying a maximum number of clicks).
Also – even if you aren’t interested in the user-experience side of product management, the article starts with another great description of the product manager as the “president of the product.” It’s a good read.
Latest Articles
Comments on all Articles
