How to cope with a "UX Expert" who has no experience?

Question

We have had a self-proclaimed UX Expert foisted upon our development team recently and it's been nothing but headaches ever since. I am not sure what his background is but he does not know anything about HTML or CSS or browser compatibility, etc. There is no indication that he has ever worked in a development team environment and it has become painfully obvious that his design recommendations are based on his "artistic opinions" which really have no bearing on our application or what we need to accomplish. He doesn't conduct user interviews or testing nor does he do any kind of research from that angle (or any other angle). He does work with BA's and other SME's but he tends to talk at them without really paying attention to the big picture.

I understand there is a place for UX professionals out there, but we are not developing a commercial website or application, rather an internal back-office application that will be used by a limited number of people. The quick description is an application for checking account reconciliations and searching for documents and moving documents through workflows, etc. We need something that is fast and easy to use, it doesn't need to be flashy or entertaining, it needs to be solid and dependable and simple and intuitive. The end users will be trained on how to use the application, it's part of their job, and we don't need to dazzle them with intricate page controls or widgets and the simpler it is the better. That's not his mindset or approach at all.

Firing the guy is not an option, as he has connections much higher up the food chain. One thing we have tried is putting him with some junior level developers so that he feels like he is in charge of something but that has not worked out for a number of reasons, with a primary reason being that we need them for other tasks. The senior level developers have started ignoring him though because he doesn't understand or care about what they have tried to tell him about his recommendations. As the Team Lead I have expressed to him our concerns but it is not getting through - he thinks that since he is the UX Expert that whatever he recommends should be the final word.

We have tried following his recommendations to the letter in browser mock-ups to demonstrate the point we want to make. He gets frustrated and confused because it never seems to work like he expected it to... we didn't even want to take the time to do this but we thought it would help.

What should we do in this situation? Is there any way to break through? Due to resource constraints we are not in a position to offer any sort of training and I'm not sure that it would take anyway.

UPDATE:

So he interviewed for a Director level job. It was down to him and some lady from outside the company. He had the connections but she had the education. She is a PhD I think. It turns out this guy doesn't even have a bachelor's degree. Not that he would need it to do what he was doing before but this is a blue chip type company and typically to advance to a Director level position there are standards and requirements that have to be met. So she got the job and the kicker is, after he found out he resigned... someone else said they thought he had a lead at a different company. I don't know and I don't care, he's out of our misery now. :)

Answer 1

Acknowledge the problem, make him show his notes, force him to improve

[Edit: Worked in some good advice from the comments.]

The recommendation to post this over on workplace.se is not a bad one, but this political problem has such a strong UX leaning, it's unlikely that site will provide you with the specific advice you'll find most useful.

I think it's possible to make life easier with this guy, but not before stepping up, taking on the responsibility of Team Lead, and confronting the problem head on. This suggestion isn't going to make the problem disappear, just make it more livable-with, initially reduce his input by making more work for him, and eventually increasing the chances that his input provides actual value.

Engaging in some candid communication is often the best approach in these situations, but it's not an approach without risks. The main risk being that this guy turns out to be a real asshole, develops a nice big bruise on his ego, and decides to make things even worse out of spite.

I would call this guy aside and tell him that:

• As the Team Lead, and being responsible of the ultimate state of the app, I have growing concerns about the nature of the UX input - specifically with the lack of transparency into the process, and the lack of rationale provided.

• I was under the impression that UX recommendations were the result of research and evaluation (user research, heuristic evaluations, competitor benchmarking, usability testing, analytics datamining, etc.)

• I was also under the impression that the point of all that work, and user-centricity in general, was to provide the context in which to make design decisions, and in what you've provided so far, it's not clear that this is what's actually happening.

• When it comes to other aspects of the app, justifications have to be made, rationales provided. The sales guy requesting the feature needs to provide a business case, the engineer suggesting an architecture change needs to show a cost/benefits analysis of the approach, so it doesn't seem right that changes to the UI should come without any of this. Shouldn't it be the case that UX changes, because they potentially have the greatest influence on the end users, should be based on the greatest amount of research and rationale?

• When you joined the team, I was excited at the prospect of learning about the app from the UX angle. (Be careful about feigning too much interest and excitement in his role. Work on the assumption that he has a finely tuned bullshit detector, and try not to trip it) I figured we'd be seeing some surveys/interviews and working sessions with users, the development of personas that we could use through out the development process to improve decision making, user journey maps to better visualize and communicate about the app, heuristic evaluations that might show up blind spots. I also figured that you'd be backing up your intuition and experience with data from analytics and testing, and that we might end up extending and improving our analysis based on your tests.

• I didn't expect that we'd be making some of the changes you've been asking us to make without at least first testing some testing of hypotheses, or showing some proof of concept. Of course I understand that there needs to be some room for creativity, and you need flexibility when it comes to problem solving in UX, but I don't think that should be the primary driver behind change.

• Essentially I hoped that with arrival of a UXer, we'd see the start of an 'environment of information' in which to work and make the app awesome. The reality is that this environment hasn't emerged, and a lot of the time it feels like we're implementing your subjective opinions, which just doesn't seem like the right way to be going about this.

• So, (assuming he's not completely hostile towards your position at this stage) I'd like us to start working together on building that environment. I've mentioned the few examples that I know, but you're obviously going to have a better idea of best techniques and practices, so I think it'd make sense to start with an overall evaluation of the current approach, and then possibly turn that into a proposal to start filling in some of the blanks, with the end goal being a process where our changes and additions are based in solid data, and can be backed up.

Conclusion

Pulled off effectively, and assuming this guy is reasonable, this approach should initially get him out of your hair while he goes and spends lots of cycles strategizing about how he's going to change the world, and googling what 'heuristic evaluation' means ; )

If you can take control of the situation by showing him you have a firm grasp of what it is he should be providing, but giving him perceived freedom of going off and coming up with his own great ideas, but that are delivered on your terms i.e. with backup and rationale, you turn the tables on him. You essentially reframe the relationship.

Again, it's a risky approach, and if you don't have a great deal of confidence that you can pull it off, you should ask for general advice on how to handle this sort of situation, either from your HR dept, or somewhere like work workplace.se A couple of good books that deal with the topic are Difficult Conversations: How to Discuss What Matters Most and Crucial Conversations: Tools for Talking When the Stakes Are High

The ultimate goal is that this guy will actually learn how complex and diverse a discipline UX really is and get somewhat of a reality check, hopefully leading to a widening of his vision of his role, and eventually to an improvement in the quality of his input.

All of which should make your app better, and make life a bit easier for you and the rest of your team : )

Answer 2

Without seeing his work, I can't comment on whether his input is useful or not. However, I can point out what a UX expert doesn't need to know: the implementation details. In other words, they don't need to be able to put HTML or CSS together.

However, they do need to know how screen layout, including things like color and font choice, can impact usability. These items might appear to be "artistic options" to you, but can have an impact on a persons ability to quickly perceive what they need to do on the page. Even just a line in the right place can help break areas of the screen up into something much more readable.

How I would approach the situation: Have him create a mockup. He should be able to do this with just pencil and paper. Bonus points if he can use something like Photoshop to put the right colors/fonts in, but that's not necessary. Once done, he should present this to the group and be able to walk through the process flow. Your job then would be to point out any missing features like "how do you delete a document?" Do so in a professional way without attacking him. Make sure he has the full expected feature list prior to drawing the mockup.

Once you have an acceptable mockup, have one of your devs through together a few screens that have the look. Then step through that, making some minor tweaks. This should result in a decent screen layout your team can throw the code behind. Execute on it, even if you think that picture in the top left corner isn't necessary. Management will judge him on it later and you'll have the documentation showing how you followed his direction.

However, if he is not able to even use pencil and paper to draw his ideas or is incoherent then you need to discuss this with your management.

Answer 3

UPDATE: For some reason my answer has been described as "passing the buck" and ruining the software at "the expense of the user". Neither of these things is true. I have taken into account the comments below and attempted to make my point clearer.

Although the OP is the lead developer, and so has a lot of responsibility, suggesting that they train a management appointed UX "expert" how to do their job (as per the other answer) is potentially fraught with danger. Not least because the OP unfortunately demonstrated a very limited understanding of the value of UX in their question (claiming that it wasn't needed because the staff would be trained how to use his software, for example). To an outsider, this could easily look like a personal vendetta by someone who doesn't value UX input.

Especially when you consider that the OP's implication that this UX "expert" will be reporting to the OP's higher uppers on how they feel the project is getting on (even if it's only informally).

The best solution is to SHOW to management that you have taken their input seriously, and have tried your best to work with the appointed expert as best you can, but unfortunately their particular skillset is not right for the project at this time. Not just in your opinion, but DEMONSTRATABLY so.

By hiding this person's lack of skill, either by distracting them with other projects, or by "training" them, you are not only refusing to work with someone (which is very difficult to justify), you are attempting to improve the situation by covering your own ass: Your primary motivation by doing that is to avoid upsetting the manager who appointed the UX "expert". That's not a good thing for the company, who are spending money on this expert (with both their salary, and your team's time dealing with him and his suggestions) and it's potentially bad for the project, which could easily become internally contentious. In short: It's not professional.

Either bite the bullet and complain about this person's ability (not the best solution, IMO), or DEMONSTRATE to the powers that be that you've tried everything, but their input is hindering progress, and THEN suggest a solution of spending company time and money to work with them to improve their skillset.

I understand the reasoning behind "training" the UX expert without telling anyone, but I wonder how well you could justify doing so if you were called before management.