gray road

Applying UX to a project where stakeholders aren’t fully invested in it

It can be difficult to find a sustainable way to work with some stakeholders. In your career you will encounter people that think UX works like traditional UI design, or don't invest enough time integrating it into project planning and development cycles. The ability to follow a solid UX process is key to formulating solutions that are on target - without it the project can feel like it's on a road to nowhere. This article discusses some of my experiences and ways I've tackled the problems.

This is a big challenge for a UX Designer. Good UX takes enough research to understand / empathise with the users and then ideas can be informed and well formulated. The process will require buy in from the stakeholders, but getting buy in for this investment is not always easy.

The following is a scenario I have experienced recently in a project:

  1. The Product Owner gets an idea about something they want to implement as a new feature or as an improvement for existing functionality. It doesn’t fit into the current list of priorities which contain cores pieces of functionality – these features are key to the saleability of the product that is currently a green field project.

  2. They formulate an idea in their head they think is right for the user, without any real data to back up this claim. They bypass the UX designer’s input as they are convinced it works with no need for that viewpoint.

  3. They are adamant that the idea is foolproof and well thought out and want to put it straight into the product and development schedule.

You’ve probably experienced similar situations in your projects. From a UX perspective there are several problems with this solution:

The PM has formulated their own ideas of how a UI should be implemented and not followed UX process

They have bypassed the input of the UX designer who will have a completely different perspective on the problem they are trying to solve.  They will frame the problem from the user’s perspective, and also have knowledge of the organisation’s existing product(s) and common patterns. There’s a lot of value lost by not involving UX and the final solution will more than likely be less effective.
 
In my experience this is an issue that arises where an organisation has low UX maturity – they don’t have the hierarchy or processes in place that align UX, design and development efforts. An alternative reason may be that the PM doesn’t see the value in utilising UX which is a much more difficult issue to resolve.

There is no research / design thinking involved in the formulation of the idea

This idea has been brought forward without any validation around suitability for the product / user needs. A Project Manager or Product Owner doesn’t have the skillset or the experience in this field to make successful decisions. Their role is to drive the product vision or to facilitate that vision, so they should work alongside UX to make better informed decisions. The idea may appear up front to be viable but it still needs validated by user testing. There have been times I have created solutions I thought were fit for purpose, but in reality were unviable when put in the hands of users and needed tweaked – it’s why we have the process. A good idea won’t stop being one after validation so spending the time upfront saves time in the long run.

The stakeholder is pushing hard for this idea to be implemented as are adamant it will work

This can be a delicate subject to approach, especially with strong personalities at work so a bit of tact and understanding is required. Why have they perceived this to be a good idea? If a PM / PO tends to change their mind repeatedly they may not have a clear vision for the product, or it could be that the defined target user archetypes / personas are not on point. Or it could just be that they’ve got an idea and are being stubborn about it,  so taking a step back, asking questions and reframing the problem is maybe the best approach. What is the main goal of the new feature? What problem is it solving? Who are the users and we are targeting and what are their goals / behaviours / expectations? Without have good answers to these questions what looks like it works on paper could fail to meet user expectations and business needs in reality.

This is where the UX designer’s skillset comes to the forefront. They can formulate ideas that fit the existing product and target the users needs and behave how they expect. They can then build prototypes, test with users and provide the insights required to give the idea validity. If the user testing reveals that the idea is not viable this is a positive outcome, as a lot of resource / development time has been saved. Sometimes as a side effect of this process is a new idea has been formulated and a different solution appears. My advice in this situation is to trust in the process. This is time well spent as the solution will more than likely will be the right one for from all perspectives.

Some approaches to getting a solution

This is a difficult situation to tackle but there are ways to get to the right solution. Here are some approaches I would consider taking:

Ask more questions about the proposed solution

Usually just asking more questions is the quickest way to finding a solution that works for all parties. Breaking things down can help each party understand each other’s perspective and align thinking moving forward:

What problem are we trying to solve here?

Get to the crux of the problem and determine if it’s a valid and fits the product and user’s needs.

Does this solution fit the product / product vision?

Is this a bit of an off piste idea that contradicts the existing product and just doesn’t fit user expectations? Point out the issues and discuss better solutions.

Is there any key features scheduled for development that cover the same scenario?

If this is the case point them out and talk through how they solve the problem outlined. There may be a feature in the backlog that already covers this subject and fits the bill perfectly, so maybe it’s just a shift in priorities is required. Demonstrate to the stakeholders how it is a solution to the same problem through examples.

In the scenario I used at the start of this article there was a core feature that was already designed out that provided the same functionality the PM was asking for.  It added more value to the overall product so the resolution was quite simple in the end.

If the solution appears unviable - break the problem down and explain it from a user's perspective to try to get the point across

If this is an addition to the existing functionality you can talk through how this change doesn’t fit the user’s expectations. In my scenario – what was suggested by the PM was existing functionality put in the wrong place in the hierarchy. In summary – it didn’t fit with the users expectation and was presented as hidden content. After running through the designs of the existing core feature and explaining the user journey the PM realised they had misunderstood the solution and that what we had in place was better formed and made more sense to the user.

If all else fails ask to validate the solution through user testing

If you think the solution is not ideal but stakeholder(s) disagree then ask to validate it through A/B testing. Develop other more viable solutions alongside the stakeholders idea and put them all in the hands of the users – if your instincts are correct your improved solution will be validated or maybe the PM’s idea will still fly. Either way there’s a solution that works for the users which is paramount. The data will speak for itself and close off any disagreements on which solution is better. With this approach you’ve given the stakeholder’s idea an opportunity to be validated so they feel they had their input in the process even though the outcome may not have matched their original vision.

In summary

You’ll encounter strong personalities, opinions or biases on projects at times. Getting alignment with UX can be problematic when this happens but peeling back the layers and getting to the core of the problem is always the solution. 

Here are the main takeaways from what has been discussed in this article:

  • Break the problem down again and try to empathise with the stakeholders perspective. Reframe how you approach your reservations and talk on their terms.

     

  • Point out where the proposed solution doesn’t fit the existing product or doesn’t match good HCI / patterns / convention. Make your case with examples.

  • Look through existing / proposed features and determine if what they are suggesting is just a repackage of something that was already formulated using UX.

  • If there is still push back the best plan of attack is to validate in the hands of the users and let them decide. Test prototypes in an A/B test with your ideal solution against the stakeholders idea.
Share on
Facebook
LinkedIn
X
Threads