So, you want to hire a UX designer? Part two: Hard requirements.

Somehow you made it through my So, you want to hire a UX designer? Part one: Four reasons why you shouldn't. At least, I hope you did, because it could save you some budget and aggravation.

Still with me? In that case, let's just jump in feet first. Today, I'll cover what I consider requirements for calling someone a UX designer. We'll cover some nice-to-haves next, but let's describe the minimum viable product first.

Your candidate …

Knows usability thinking, is well read in the field, and can articulate basic usability principles. How do you know? I'd be suspicious if they haven't read foundational figures like Don Norman, Jared Spool, Steve Krug, Bruce Tognazzini, and Jacob Nielsen. They should also be able to tell you about a recent usability article or book they read and discuss intelligently whether and how it applies to your products.

You've got usability or Human Computer Interaction (HCI) theory.

Applies usability thinking. Your candidate shows you their work and articulates how usability principles and knowledge shaped the work, whether it's wireframes, prototypes, mock-ups, or a finished product. Did they ensure visibility — can you easily see what you can and can't do on this screen? How did they build in cues, or affordance, to each widget on the screen so that you can tell what you can do with it? Did they pay attention to feedback, making sure users, e.g., always know their input was saved and their submission successful? What constraints did they work with (time, budget, legal requirements, system limitations, users' devices and environments), and how did they minimize the effect of those constraints on users?

You've got applied usability.

Knows how to identify users and determine what characteristics are relevant to the design. This is one of those areas where UX overlaps with business analysis and marketing: A basic product management question is, Who is your target market? (If you say “Anyone$#8221;, no UX for you.) You want to see smart breakdown of target customers or users into groups. If the candidate shows you personas, make sure they didn't just make up some fictional characters with attributes that look real but have no relevance to the design. You want to hear about attributes of users and user groups that made a difference to design decisions and why.

You've got user analysis, or, if you want to seem erudite, ethnographic research.

Knows how to identify and articulate users' tasks in terms of end goals. For example, submitting a form is not a goal, it's a means to an end. Buying a product or filing your taxes are goals. Within those overall goals are smaller goals (add a product to cart, enter your W2), each of which has tasks associate with it. Your candidate should be familiar with use cases, or, in Agile terms, stories. A smart candidate will also be able to talk about distinguishing main tasks from sidetracks. E.g., your're checking out on Amazon (the main task), but you need to add a new shipping address (a sidetrack).

You've got task analysis.

Knows how to order actions and steps into flows. For example, an e-commerce checkout or an account set-up form, when you break them down, are a series of actions and steps — fill these fields first, push that button, make these selections. Some choices will depend on others. Some steps feel natural to do first for people. You split the form up into multiple screens, or you keep it to a single form. Your candidate explains how and why they decided on a flow.

You've got interaction design (IxD).

Knows how to organize and tailor information to end users and the purpose at hand. Your candidate walks you through an example and explains why they decided which iformation was more and less important; how they decided on labels and headlines; why the information was broken up into pages or sections; and how each piece of information contributed to user and business goals.

You've got information architecture.

Knows how to design and conduct user tests. If your candidate confuses focus groups with user testing, toss them out. User testing is an entire field of study that has its own specialists. Your candidate doesn't need to be an expert or wear a white lab coat. What you want to ascertain is that they can design simple tasks with a measurable outcome (did the user accomplish X, and how long did it take?); that they know how to moderate the test without leading the subject; and that they know the difference, strengths, and weaknesses between large-scale testing with statistical significance and small, guerilla-style tests. You also want to hear the candidate talk about what user testing is (a way to uncover problems) and isn't (a way to rate a design or decide between two competing designs).

You've got user testing.

Designs screens and interfaces that are visually pleasing; that support user and business goals; and that reflect the company's visual identity. Don't just eyeball a design and decide whether you like it or not; this isn't about your preferences. The design needs to look current and competent. It should not draw attention to itself but to the content or interactions on the page, helping its users complete their goals. Your candidate should talk intelligently about the choices they made. Why did they choose these colors, that look of form fields and buttons, and those sizes and spacing of elements? You want to hear them describe use of design principles like contrast, chunking, visual hierarchy, and dominance in terms of design supporting the end goals of the business and its customers, not just in terms of likes and dislikes, cool and uncool, trendy and non-trendy. “Hot right now” is not a design principle.

You've got UI design.

Knows how to measure outcomes, evaluate design solutions against those metrics, and intelligently diagnose problems. UX design is a means to an end, not a goal in itself. Design problems are solved to effect business outcomes — number of sales, number of new accounts, number of hot leads generated, number and size of donations collected, etc. There is a reason you put something in front of prospects and customers. A UX person needs to know the importance of measure whether your product meets those business goals and how to do that measuring. Your candidate should be able to talk about^* A/B testing, multivariate testing, and using data from Google Analytics and your own databases to measure success. They should also show some acuity when it comes to looking at a problem (e.g., customers abandoning when they hit the second page of your cart), diagnosing a cause (e.g., shipping costs aren't made clear on page one), and proposing a solution (calculate shipping costs earlier).

You've got Web metrics, or simply metrics.

Why isn't design the top skill?

Many of you will notice I've placed UI design, which is a subset of visual or graphic design, last. Before you hit CAPS LOCK and set my contact form on fire, this is not a list ordered by importance. It's roughly organized in the order you'd typically use these skills on a project. Usability goes first because that is foundational knowledge that applies to every subsequent step.

You forgot [fill in the blank]

Next, many of you will have something you want to add. You may very well have good points to make, so, if that is the case, I invite you to use my contact form to let me know. If you persuade me to include something, I will add your suggestion to this list and make sure to attribute you prominently.

The soft stuff

Finally, a word about soft skills like negotiation, diplomacy, independence, and teamwork. I'll probably pen a screed about those at some point, but I have not included them in the core list of skills above, for a reason: The personality and work-style you need depend on the job at hand, your corporate culture, your group, and the groups you interact with. You may need someone with sales skills or a cerebral introvert; someone who'll push hard or tread softly and make compromises; someone who prefers to go solo or someone who fits well on a team. Only you can decide what the right mix is there.

^* Be prepared to cut candidates some slack on metrics in particular. Often, they're coming from a position where they've been hamstrung, prevented by organizational or cost constraints from doing things like user testing and collecting metrics. Especially metrics. It's very common for individual groups and departments to neglect measuring, and sometimes metrics are quietly but stubbornly resisted. They take effort to collect and read properly, and, unfortunately, in many cases people resist because it's easier to succeed if success is simply a matter of opinion — the quarterly report needs the Web project to be a success, therefore we say it is a success, and therefore it is. If your candidate is coming from that kind of environment, you'll just need to verify that they understand how and why to do it properly, because they haven't had the chance to show rather than tell.