Once you have identified and logged user experience issues, addressing them can be challenging due to other competing priorities, especially with enterprise software.

What strategies can we use to help elevate user experience issues above the other competing priorities?

  • I'm a little confused. What do you mean by competing priorities? – Majo0od May 6 '16 at 11:43
  • Let me elaborate, what are the competition priorities? Is it another UX issue that takes precedence than the one you mentioned? Or is it out of the realm of UX? – Majo0od May 6 '16 at 11:46
  • With enterprise software, there are many things on a roadmap, some are strategic things and some are tactical things. So competing things can be bug fixes (especially high priority bugs), client request commitments, development architectural things, etc. – SteveD May 6 '16 at 11:57
  • UX should never fully stop if, say, bug fixes were being implemented. That's reliant on the dev team, unless the "bug" is UX related. In that case, you work with the dev team to find the best solution possible – Majo0od May 6 '16 at 12:05
  • But that should also be in conjunction with the bigger goals of the company. If you have a certain feature that the higher ups want and that you should work on, then work on that WITH those fixes being implemented. It should be side by side instead of one by one.\ – Majo0od May 6 '16 at 12:06

Money talks, bullshit walks

Companies that don't naturally prioritise UX (ie most companies) need to be sold why it's important to spend money on improving UX.

So the best way to do it is have a clear business rationale as to why it's important.

Is it to improve conversion? Great! What percentage increase in conversion do you expect it to improve? Even better, have you run an A/B test to have a number you can stand behind which results in $x increase in revenue?

If you can't quantify what the benefit will be (even if it's not a direct revenue improvement), then it will always be an uphill struggle to convince the business to prioritise above other work.

  • we do quantify the benefits, so I guess you are confirming we are doing all the right things - it just might take some more time before things move in the right direction – SteveD May 6 '16 at 12:31
  • If the company meets with the UX newly, I agree that it is better to talk on their priorities and many company would like to generate more money and have more paying customer. Try to find a quick return in three months, which will give you more credit for other things. – Abektes May 6 '16 at 12:34
  • 1
    Perhaps worth noting that this logic applies to virtually all decisions for a company, not just working on UX. Improving UX is spending money. What does the company get for the expenditure? Is the expected benefit worth the cost? You likely make these same types of decisions every day in your personal life. Why should I spend money for some app on my phone, when there are free alternatives? If I get more value out of the paid one, it's worth the investment. – DrewJordan May 6 '16 at 16:06

Treat your question as an exercise in user research. This time, the users who you are researching are your own development team. How and where do decisions get made? Who is influential in making those decisions? How do they communicate? What are the competing priorities? How does work actually get done?

Once you have a better understanding of your audience, you can tailor your approach. If the team communicates through their bug-tracker to capture work items, then you need to learn how to use that bug-tracker for UX work. If there's one person whose disapproval, or even noncommittal attitude, will result in nothing happening, then you need to get them on board. If there's one person who only cares about a single topic, you need to figure out how to talk about your work in terms of their single topic. If there's a leader who only seems to communicate via PowerPoint, you need to capture your ideas in a PowerPoint deck that they're going to love. If there's someone who only cares about something quantifiable, then you need to discuss your results in terms of something quantifiable. It's worthwhile noting that quantifiable is not just in terms of income from your product, but also in terms of developer productivity. If you can show that doing something one way is faster or easier to implement, or has a lower maintenance cost, that is an excellent argument to those who only want to hear about it if it's quantifiable.

Most importantly, it's not sufficient to only do this for one person or team, and it's not sufficient to do this a single time. It's not one-and-done. You need to be engaged with the team throughout the development cycle. You could do an amazing job up-front and get people on board, but disengage and learn later that they cut your work because there was no one there to represent it. Staying engaged helps you understand the team's constraints, and to work with them to come up with compromises that will make UX improvements in the short-term while still working towards the UX that will make the most improvement for your users in a future release. Staying engaged also means that you have the opportunity to represent users in discussions with them, and you might find that you can answer questions that they have or provide design direction for them without having to do a lot of additional work. Being involved makes you a better member of the team, and a more respected member of the team, which ultimately results in delivering a better user experience.

It's your job to own the user experience. Don't complete a design, or deliver a research report, and let that be the end of it. The best user experience is the one that actually gets delivered. The difference between a good designer/researcher and a great designer/researcher is the one who knows how to work with a team to make real improvements to the user experience.


Let me give you this scenario:

I (your CEO) have a set of knives; not perfect, not professional, and not too expensive. They work well enough and cut tomatoes to my liking and I've never thought to myself "I should get new/better knives". They prepare soups, salads, and breadsticks for my family without any issue.

A salesman (you) walks up to my home, selling knives (gasp! plot-twist). Anyways, he claims to have knives that will revolutionize my knifing experience for the better! He introduces a knife with a blade made from unobtanium and is so perfectly balanced (the UX issue) that a 3-year old could use it safely.

I'm sure they are great knives but I'm not coughing up $700 for a single knife, no sir. The salesman has an uphill battle against me since I essentially need nothing from him and what he is offering is already in place and working.

Had the salesman come up to me and said check out this magnificent lightsaber knife then I would be inclined to drop some serious cash rather quickly. As an added bonus the UX issue of knife balance has been perfected in this knife but that is certainly not what sold me on it.

Anyways, try presenting a new and exciting idea on a current feature and fix UX issues along the way.


So you have finished you report and have list of issues that should be fixed on. You know that time of developers is valuable so you should prioritize issues properly in order to fixing them.

Such conditions influence on issue position in the list.

  1. Urgency. If issue breaks main user scenario, this is priority No 1.
  2. Easy-to-Fix. If you already know how to fix it fast and easy.
  3. Current development pipeline. If some part of app is already remaking, you can add/change ticket to epic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.