UX Soup for the Management Soul

UX design translated.

Wednesday, January 27, 2016

So, you want to hire a UX designer? Part one: Four reasons why you shouldn't.

Someone has come to you with a request for head count. They want to hire a UX designer. Even better, maybe that's you making the request? Either way, please read the following. Is any of what I'm describing happening? Because if it is, you will have frustration and turnover, and you will be paying primo dollar for an under-utilized resource. (And, if — huzzah! — none of the following apply, I will reward you in posts, to follow shortly, that'll help you define the skill sets you need to look for.)


Setting up and hiring for a new role is a lot like adding a feature to your product. The first question any UX designer should ask is, “What problem are you trying to solve, and will the proposed solution actually solve that problem?” You should ask those same questions about this new role. Also, it's a handy-dandy clue to my first reason why you should not hire a UX designer:


You want someone to make wireframes from marketing's or product management's requirements


Blueprint of a car with the steering wheel in the back seat.
Here, I wireframed a car. That doesn't mean it's a good idea to build it.

Wireframes and other low-definition prototypes are useful. A drawing of a screen is worth multiple pages of traditional requirements documents. It makes clear to everyone involved what is going to be built. It takes guesswork and ambiguity out of the requirements when developers are trying to develop. Wireframes should be part of software and Web site requirements the same way blueprints are required when you're building a house.

So what's the problem? You're about to pay a solution designer to sit around and illustrate someone else's solution. User-centered design starts by helping to define those requirements in the first place. Recall those questions I asked in my lede — “What problem are you trying to solve, and will this solve your problem?” Those are UX questions. If your stakeholders or business analysts do not want participation that early in the process, do not waste a UX designer's time.


You want someone to make the UI look good

The idea is to take the requirements and make a UI that looks appealing. You'll get kick-ass Photoshop mock-ups, right? We need someone to rock our look and feel.


Blueprint of a house with the front door on the second floor.
“We were wondering if you look-and-feel guys could help us decide on a color for the front door?”

What's the problem? You're about to hire an architect to choose colors and window treatments for a building someone else designed. Real UX designers, though many of us are also good UI designers, will need to be involved much earlier than that. Otherwise, we're wasting our hard-earned skills and experience, and you're throwing money out the window. One dead giveaway: Your job title tries to have it both ways by including “UX/UI”.


You need muscle for an inter-departmental tug-of-war

IT/Marketing/Product Management (whichever one currently owns UI) is doing a shitty job with your application or Web site, so you're trying to get more ownership over product design. You need a real expert to add credibility and authority to your quest, so you want a UX designer to come in and wow everyone with the superior logic of ROI, metrics, customer satisfaction improvements, revenue increases, and error rate reductions.


UX stay out! The Web site belongs to us.
UX design skills do not necessarily equip anyone to win corporate turf wars.

So what's the problem? Your goal is admirable, and you may well be right. I absolutely commend you for acknowledging the importance of good user experience. You will fail, however. This is a turf battle. Turf battles aren't won or lost with expertise or experience-based arguments. They are fought and won with office politics. Often, it comes down to who has the CEO's ear. Trust me on this; I've been there many times over. What you'll end up with is an expensive and frustrated employee whose skill set is designing better products, not playing politics or persuading people who resist being persuaded because of office wars.


Your developers spend too much time writing front-end code

You want your developers spending their time where their skills are, in .Net or Java. They hate CSS and JavaScript and spend way too much time trying to figure out why things don't look the same in Chrome and Internet Explorer. You want a UX/UI/front-end person to build front-end prototypes the developers can use.


Picture of a button.
“We need the CSS for this. When do you think you can have it?”

What's the problem? You're approaching the right job with the wrong tool: What you're looking for is a front-end developer. It's true, many good UX designers are also good front-end developers. I can write 24-carat front-end code all day long. However, that is not a required skill for user-experience design, and it's not something a good UX designer will be content to do a majority of the time. If you do find a skilled UX designer who also happens to write code, do not plunk them down to receive the requirement and implement those as UI prototypes. Best case, they'll only be frustrated and under-appreciated. Worst case, the UX designer will try to do actual UX design and end up butting heads with BAs and stakeholders over requirements and specs. Dead giveaway: You're hiring for a job with a title that includes “developer”.


Executive summary

Don't hire someone with a skill set they won't be able to use. It's disrespectful to the hiree; it wastes their time and speed bumps their careers. For your company, it's expensive, for two reasons — you're paying for skills that aren't benefitting your business, and you incur the cost of turnover.

Coming soon, if you're still with me, what to look for in a UX designer.

Ask Per “Pierre” Jørgensen

Q: No comments? What gives?

A: Frankly, I don't have the patience for all the anonymous crap the comment field seems to attract. Since you, dear reader, are neither anonymous nor a purveyor of crap, please use my contact form. I promise to read it, and, if your critique is incisive or your question pertinent, I'll post it (with your permission, of course).