"Can you make it more prominent?" stakeholder phenomenon

Question

I'm designing many features for a product, where many of these features are shared across the real estate of a screen. It's common for each stakeholder or product manager to feel that their feature is the most important, and common comment during the design process is "can you make it more prominent".

over a period of time, increasing the prominence of each feature would lead to a kind of inflation where each feature would be more prominent than the rest of the elements on the screen each time a feature is revised or improved. causing the whole screen to get crowded or cluttered where everything is fighting to be more prominent.

many times i've tried explaining this to the stakeholders. but in their mind their feature is the most important and needs to grab the attention of the user.

how can this be solved. trying to convince stakeholders hasn't worked. is there a process or something to avoid it.

Answer 1

tl;dr: Focus your audience on the Product's purpose

In the absence of a clear product strategy, use the User Journey Map and documented workflows to remove executive opinion and self-interest from the discussion.

---

A formula for attention deficit disorder

Everything is not important at the same time in the same place.
If you don't provide a clear path, users will struggle to find their next action.

Hick's Law tells us ...

increasing the number of choices will increase the decision time logarithmically

That last word is a bad thing. The longer it takes the user to decide the more stress they feel and the more likely they are to be dissatisfied and possibly abandon your app.

---

Establishing priorities

Your team probably doesn't believe that attention is unlimited. They just need help identifying the most important things.

Everyone naturally has some amount of bias toward their area of responsibility. So how do you get everyone on the same strategic path?

You have to eliminate domain ownership from the conversation and get right to the point:

We will be successful when we make our users successful at [ … ]

That goal will change from one view to another, but there are overarching goals that the product needs to address.

The User Journey Map

Allows designers to frame the consumer’s motivations and needs in each step of the journey, creating design solutions that are appropriate for each.

^UXDesign.cc

Developing an accurate diagram of the user's journey is one of the best ways to understand and visualize your priorities. This understanding should inform the creation of a clear product strategy. If you haven't gotten executive agreement on such a strategy, you just have to work directly from the User Journey Map to reference reality.

Workflow diagrams

the user perspective of the site organization, making it easier to identify which steps could be improved or redesigned

^UXDesign.cc

Drilling down a level deeper, documented workflows will help to expose the detail of what the user needs at any given point. The "prominence" of a given feature should be directly tied to its place in the workflow and its intersections with the larger scope of possible workflows happening at that point in the Product.

Use your metrics

The Journey and Workflow should be based on real data. You may have to start with a hypothesis, but it should be backed up over time.

Pointing to real product metrics in support of the claim that …

feature A is more critical than feature B within view 4 because [… data …]

keeps the design process on track and the strategy focused on meaningful enhancements.

It's a process

As the company matures into this way of thinking (if they are willing to do so) you won't have to be the strategy cop all the time. Others will usually see the light and start speaking up on their own.

Eventually, you want everyone to think in terms of …

• The Product's core purpose
• The current Initiatives
• How the Initiatives will be accomplished (Epics)
• Where it all fits on the Roadmap

How can we get to this point as quickly as possible ...

The Design Sprint as a jump starter

The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

I don't know of a faster way to get a team all working toward the same strategic set of priorities. Sometimes the word "design" throws the stuffy suit types off. You can also call this a Product Summit or Strategy Summit. If you need to go that route, just make sure you have the right "business sponsor" pushing the effort. The Product or UX Designer should still be the facilitator, but putting a suit at the front of the message can help.

Answer 2

The stakeholder owes you more information. If something is asked to be made MORE prominent, something else has to be made LESS prominent. This is like the full glass syndrome. Nothing new can be added to a fully-functioning full glass of water, without something else coming out.

Simply ask them to decide what gets demoted in order to make room for the promoted item.

Or do they trust you to decide what gets demoted and how?

Answer 3

"Prominent" is relative to other things that compete for attention. It isn't something you declare, it's measured.

Let's say you give some element a nice fat stroke and drop shadow and color it day-glo orange, with the intent of making it more prominent relative to something else. Until you test that assumption, it's just an arbitrary change.

But it's hard to convince in these situations arguing just from design theory, so A/B-testing subjective-y feeling stuff like "prominence" is a good way to wage low-risk arguments that help measure The Difference and focus people on the bigger fish to fry, like user needs (which have mostly squat to do with these aesthetic details.) Whatever you're designing has a job to do - to serve some human goal.

Answer 4

Measure how users are using the rest of the elements on the screen that you mention and how the prominency of working on that feature is "cannibalising" the rest of the elements.

Don't forget to present an alternative while you present the results from your KPI analysis, managers always want a solution.

Answer 5

When a stakeholder asks for a feature to be made more prominent, explain the entire problem to the stakeholder - that other stakeholders might object, that other stakeholders are likely to increase the visibility of their feature's, etc. If they insist, you have done what is within your responsibilities. Implement it as they want.

Who will suffer from this? Since the different stakeholders' features are running on the same screen, these are basically "sub-features" under some larger application. Who is the overall owner for this application? This is the one that will ultimatelly suffer from your problem. Ideally, this owner/stakeholder should be, or appoint, a master stakeholder that always has the final say when stakeholders have conflicting requirements, and can overrule the requests of the lesser stakeholders as required. If there is such a person already you might want to escalate your current problem to her/him, if there is none, you may want to suggest to your client to appoint one.

Answer 6

Solving a subjective decision using more objective information is probably the best solution, and there are three main approaches:

A - agreement by consensus: get the stakeholders to agree on a set of criteria and rate each feature on those criteria; it is not perfect and still subjective, but at least the decision is based on consensus

B - validation by data: collect and provide usage analytics or user research to show what should be more prominent according to the users

C - use a combination of both a weigh the relevance or importance of the data and consensus decision

Answer 7

It seems to me that all you need to do is get all the stakeholders in the same room and present them with the data coming from the User journey map and the Workflow diagrams, as plainclothes suggested.