Loading...
Multiple ContributorsPersonasProduct ManagementRequirementsUser Experience

He Said, She Said: Part 2 – How can PM and UX work together

By Saeed Khan and Heather Searl

pmuxIn the first part of this discussion, Heather and Saeed covered a number of  topics related to both Product Management and User Experience, including working across teams, working with customer and organizational structures. In this part we will cover ….

Personas

Heather: Personas are critical tools when defining user interfaces, but they are not well understood and often poorly defined. Personas often become an exercise in creative writing for UX teams. Writing a persona can be fun, but you can get carried away. This kills them as a useful tool.

If the personas don’t accurately reflect the group of people being designed for, and if they don’t answer project related questions about the target customer’s goals, work, work-related challenges that could be influenced by the current project and so on, they aren’t useful.

Some UX personas are too general or they just create a character. A good persona has to be project specific and relate to features being worked on.

Saeed: I once worked on a new UI for IT administrators. The UX team had created personas for a “generic” administrator. It contained a lot of, “Fred gets up in the morning, goes for a jog, has his latte and goes to work,” info.

The engineering team wasn’t very receptive. When you present that type of persona to an engineering group, they just roll their eyes and walk away.

So we did a bunch of user research with the engineers alongside. In our findings, one big change I made was to remove the word “persona” and start using the word “role”.

We identified multiple different administrator roles such system administrator, infrastructure administrator, network administrator, database administrator et cetera.  Then we agreed that our focus was the infrastructure administrator. This made things very clear and tangible for the engineers.

We used one particular customer — Chris — who became, for us, the prototypical infrastructure administrator.

From that point forward, if there were any questions that needed decisions, we would ask ourselves, “What would Chris do?”

That worked very well for everyone. We had effectively created a persona, but it was really focused on relevant activities we needed to understand. It had a lot of credibility.

Heather: There are also buyer personas that cover how Joe makes buying decisions, what his income level is, how he does research before he buys et cetera.

I’ve been told to use them and we couldn’t create design personas because too many personas would be confusing.

But the marketing personas don’t help me do my job. They don’t answer my questions.  All a project team can do is put them in a drawer and move on.

Saeed: I think buyer personas are important, particularly in B2C scenarios where the Buyer and User are the same or very closely related.

In that scenario, why someone buys, how they evaluate and how they use can be intertwined and need to be understood.  e.g. a parent might buy a digital camera for their child, but clearly the two personas are quite different but interrelated. The parent (buyer) may also be an occasional user as well.

In B2B, buyers and users are often quite different, though in many SaaS/Cloud applications they can be the same or closely related. e.g. the marketing team will purchase and use Marketing Automation tools.

Also there are influencers, who are related to buyers, and may have product needs of their own.

e.g. for an audit compliance product, the users (and buyers) are the legal/finance teams, but IT would need to manage the software, so they are heavy influencers.

If, for example, software administration is part of IT’s qualification process, and your product is not easy to administer, that would be a strike against you, even though, technically, IT is neither the buyer nor user.

Documentation and Deliverables

Heather: What about other project documentation? I find that sometimes there is conflict between UX and Product Management about who owns what deliverable.

Saeed:  Project documentation can be a problem when there is overlap in the acquired knowledge or even authorship of documents.

Requirements is one area. Although it is generally agreed that Product Management owns requirements, there can be requirements that come out of the UX side. The solution in those cases is to work together and discuss areas of possible overlap. In theory, PM and UX are part of a TEAM. 🙂

But there is a bigger problem. You go from company to company to company, or even across teams i the same company, and there isn’t a standard definition of those deliverables except at the highest level.  Artifacts are different, formats are different, information is different…it’s a mess.

I worked at a company where we had a product management offsite where we had to present the current state and future plans of each of our products.

You’d think that since we all worked in the same company there would be consistency in the presentations. There wasn’t.

Some people had a lot of technical information. Others had a lot of financials. We didn’t look at our own products the same way. Even the financials were presented in very different ways for different products. When you bring in other groups like UX it gets more confusing.

Heather: I’ve seen great differences in what a product concept document (PCD) coming from different product managers contains, but they give me direction I need.  I’ve also worked with other Product Managers who refuse to put a meaningful PCD together.

Then you get into something that is more of a combined ownership, like requirements where you have user requirements, technical requirement, marketing requirements that all  have to come together at some level.

It falls apart when there isn’t collaboration. I’ve had product managers dictate all of the user requirements and others expect me to do it all.  I’ve also seen requirements put together in isolation that don’t make any sense as a whole.

People are trying to define the product their way by what they put in the market requirements, user requirements and technical requirements. And then there are conflicts between requirements that cause problems and create delays.

I like to work collaboratively. You start the document, I’ll add some stuff, and we’ll talk and edit and revise and see where it ends up. I struggle with almost anything that is just put together and thrown over the fence.

Saeed: I think that as soon as you start the discussion about standardizing processes you get a lot of pushback. People see added bureaucracy and more work. If you think about it in the long run, good processes should reduce work.

A friend of mine told me this story. At a startup, there was value to ambiguity from management’s perspective because it was easier to hide behind. It was an accountability issue with the board of directors.

So some senior people worked to ensure process and deliverables weren’t defined. Obviously that startup failed miserably.

In other places people are fearful of change or what the impact on them will be.

The discussion has to be what works for all of us. How can we make it better for all of us? I think that is the important question, but a lot of people don’t want to think or act on that? And in most cases, that leads to failure.

Saeed & Heather

Tweet this:  He Said, She Said: How can Product Management and UX work together – Part 2 http://wp.me/pXBON-4ci #prodmgmt #ux