I am a young UX specialist. I have worked on a few real projects at university, but I was not really that invested in them, there was not so much real pressure to get them right.

For the last year and a half, I have been working on my first real job. It is a greenfield development at a government institution. While they got me mainly as a developer, they chose me because want me to use my skills in software engineering and UX.

My only source for gathering requirements so far has been the product owner. I always thought that she is very committed to the project, dedicating lots of time to it. Everybody on the team (me, a fulltime junior developer, and my boss who has a project management role) developed a very good relationship with her, and I always had the feeling that we four are working together towards a common goal.

Last week, I started doing usability tests. And after the second test, I was so full of bad news that I decided that we have to delay the other tests. I called a crisis meeting while I was still completely distressed (now I notice it was a mistake).

What I learned from the tests were two problems: first, the users are encountering so many issues that my estimation of how much work is needed at the design level is way too low. Second, our users don't want our application. If they were to use it, they would find it too much work for too little return. But they are actually actively opposed to documenting the kind of information the application needs from them.

In the crisis meeting, I informed the team of the problems, and expected that we will start working together towards somehow patching the situation and finding a solution which can be implemented in the little time we have left, triaging other parts of a real solution into the "next release" list. Instead, both my boss and the product owner said that we should change nothing and just continue working according to the "original plan". They are both surprised that I am so committed to system success.

Regarding the second problem, the product owner said that she is creating this database for the users, and if they are "too selfish" to enter information into it, that's their problem, she doesn't care if a single record lands into it.

As for the first problem, I told them that my original plan had not been "do work on the UI until it looks like a concept I have ready in my head" but "do work on the UI until the users have a reasonable rate of task success". So I can't just continue my work and meet the deadline; rather, I will probably need to cut out some of the more intricate features (which cause the most confusion) and need the OK from the product owner to remove them, and a brainstorming on how we can keep the usefulness of the application without these intricate features. She absolutely refuses to cut out features, and says that I have to deliver the software as she wants it, and if the users are too dumb to use it, she doesn't care about that. We were both so wound that, without the project manager's balancing moderation, this would have turned into an ugly interpersonal conflict.

My project manager supports the idea of delivering as-is, because she is afraid that any large change so late can cause us to miss the deadline.

I understand the position of my boss, and I have to do what she tells me anyway. But I have a really hard time doing it, because I don't know how. My criterion for declaring my work completed has been forbidden, and I have no other. I am somehow trying to adjust to it, but it is hard not doing what I believe needs to be done.

As for the product owner, I cannot find understanding for her position, no matter how hard I try. If she doesn't care for system success, then what does she care for? Why did she initiate the project in the first place? What goal are we working towards?

I see now that I am much more committed to system success than I had thought. It is a combination of

  • pouring lots of effort into the application,
  • the puppy eagerness of this being the first project I really care about
  • my still somewhat low professional confidence. This is the start of my career in UX, the first time I apply the indecently large amount of theory I have poured into my head, and if this project fails because it turns out to be both misaligned with users' needs and to have an unusably bad design, then I will feel inadequate for my chosen line of work, and
  • feeling responsible for the usability of the system, thinking that as a UX person, I have to advocate the users' position when other stakeholders want to conveniently forget it.

Seeing that I have four strong motivators, I doubt that I can bring myself to a point where I am indifferent to system success the way the product owner and the project manager are. But without such indifference, each hour I spend putting lipstick on the pig is torturing and demotivating. I calmed down on the weekend, but I already know that 9:00 on Monday morning, I will be entering a cognitive dissonance zone.

What can I do so I can see this project through to release without worrying myself into a mental disorder?

  • 5
    Like in most situations, you're probably seeing just the tip of the iceberg that is this project. There are probably other forces or aspects at play here which your product owner can not disclose... Jun 15, 2014 at 16:10
  • 2
    One thing you need to learn from this is to involve the users much earlier in the process when change is still possible.
    – HLGEM
    Jun 16, 2014 at 13:10
  • "feeling responsible for the usability of the system, thinking that as a UX person, I have to advocate the users' position when other stakeholders want to conveniently forget it." Advocate, yes. But this does not mean that your findings will have any impact if the product owner has other priorities.
    – pmf
    Jan 24, 2018 at 8:41
  • Bad news: Nobody cares what you are doing. Good news: Nobody cares what you are doing. So take the job and turn it into as much of a learning experience as is possible. You won't fix the project for the users. Turn it into something positive for yourself.
    – gnasher729
    Apr 9, 2018 at 10:53
  • Have you ever heard the saying "In theory, there is no difference between theory and practice. But, in practice, there is." What you want to do seems to be based mainly on theory. What the other people want to do seems to be based on their experience of what is best. In college, theory is often king. In the work place, theory can be useful, but you should rely much more on practice. People often want to do things in ways that seem to go against theory that you have learned. Those are the people who usually last much longer at their jobs than people who rely on theory.
    – Itsme2003
    Mar 26, 2019 at 5:43

2 Answers 2


Welcome to the working world!

May I offer you a couple of slogans?

  1. The perfect is the enemy of the good.
  2. Fail fast!

Seriously, this is probably your first exposure to a real-world system. The most important and hardest-to-understand components of real-world systems are the people. Will it be hard for your software package's people -- your intended users -- to apply it? Probably. Does it matter how hard it is to use? Possibly it does not. These are government administrative workers doing their jobs, not hipsters downloading apps to their devices for fun. They'll use your system if their supervisors instruct them to.

Change threatens people. Information is power, and new information systems sometimes promise to redistribute power. That means insecurity. The people with whom you conducted your usability testing may be reacting to that sort of thing. And, believe me, a lot of their reaction may not be conscious. The UX difficulties you observe may be due to reluctance to embrace this new thing.

Don't ever let anyone tell you to stop worrying about usability. But, at the same time, accept the wisdom of your product owner (it is indeed wisdom born of experience, even if that's hard to see) about what is good enough for your project.

You will learn a lot by riding this horse all the way around the racetrack. You can develop relationships with some of the users and find out their motivations. You can observe the rollout of an imperfect system and learn from that. You will start learning the rhythm of rollouts, and how necessary it is to be a little bit subversive to inject excellence into systems.

You seem like a systems thinker. That is a very rare trait; please cultivate it. Obtain a copy of The Fifth Discipline by Peter Senge and read it, while you're watching this project unfold.


You say this; emphasis mine:

My project manager supports the idea of delivering as-is, because she is afraid that any large change so late can cause us to miss the deadline.

And say this; emphasis again is mine:

As for the product owner, I cannot find understanding for her position, no matter how hard I try. If she doesn't care for system success, then what does she care for? Why did she initiate the project in the first place? What goal are we working towards?

In your mind, being a project manager means someone is the product owner as well. That is not the case. As the project manager her benchmark is not quality assurance—which is really the core of what you are concerned about—but the overall management of the project.

Meaning—and I am just giving a pseudo-example—let’s say this is the highest level criteria she deals with:

  • Take on the management role in a project.
  • Address basic needs as outlined by whoever assigned her to the project.
  • Assign resources to address needs.
  • Deliver a final product based on the above.

Then her job is done.

Now you might be wincing at how this can be a completed job when the final product is so bad and can so easily be improved. But again, that is not the job of the project manager.

This is the basic bureaucratic conundrum any developer deals with when dealing with a project or project manager. Sometimes they do not understand the nuts and bolts of an issue. And there is no way to solve that… But one…

Quality assurance.

Now you might think that you—as a developer—believe you include quality assurance in your process, but that is not what I mean.

What I mean is that somehow—at higher levels than your project manager—the concept that there needs to be a quality assurance stage in the process needs to be addressed. Now how to do that? Unclear. And here is why.

The reason why so many projects end up in dysfunctional states like this is that either:

  • Someone wants the project dead, but explicitly killing it off is not an option.
  • Nobody understand the value of the project, believes the solution is easier than they think and that’s that.
  • Funding doesn’t exist to properly deal with the project, but nobody wants to admit it.

Basically, this is where you have to face the harsh reality that while you might be correct about the quality issues, you have no real power to change things.

And—this is key—if you decide to work harder or work extra hours to solve these issues, you might face backlash. Meaning, while you made the project better either nobody will care at worst, or will be so offended that you “stepped out of line” they will figure out a way to just punish you for daring to do extra work.

Yes, this sounds like B.S. And yes, it is B.S. And yes at the end of the day nobody really wins. But sadly in some work environments the passion of the job at hand takes a back seat to bureaucratic nonsense and overall dysfunctionality.

The best you can do is to be realistic and try not to treat each project like a special magical diamond or something like that. And yes, it is demoralizing. But guess what? That is why many people create side-projects independent of work to express their skills in an unfettered way.

For your own professional health it might be best to start to divide up your coding life between the things you truly do for work and the things you truly do for yourself.

Not the answer you're looking for? Browse other questions tagged .