How to evaluate candidates for my startup's first UX hire?
How do I know what to look for when they know more about UX than I do?
Welcome to Ask a UX Consultant! This newsletter is for developers, PMs, founders, and other non-designers who want to get better at UX. If you have a question, send it to ask@uxbysarah.com. The more specific, the better!
J writes:
I’m a security engineer and I’ve been asked to interview UX candidates soon for my early-stage startup. I have no idea what to ask except maybe some dead simple stuff and some philosophical warning signs. Since we're so early, we're looking for someone who can guide the look and feel from now on. At this stage everyone will be instrumental in the direction the company goes. Do you have advice for how to interview a UX person?
Great question! A lot of startups have this exact challenge. There are tons of great ways to evaluate UX candidates, but I’ve found these three components to be very effective:
Let’s discuss these in detail.
1. Determine if the candidate will think critically about solving problems rather than just doing what seems obvious.
You can do this by giving a little background on a UX problem you're having, explaining a planned solution, and asking how they might begin designing it. The catch is that your proposed solution should actually not solve the problem and would only solve the symptom.
A great candidate will identify that your proposed solution doesn't actually solve the problem and may push back on why you chose that plan. Depending on the specifics of the problem, he may also ask about what data led you to draw your conclusions and propose other data that would help identify the actual problem. He should also ask questions about your users: how technical they are, what their demographics are, do they use your product on mobile or only on web, etc. It would also be a good sign if he says "Does there need to be a mobile flow for this as well?" Even if you don't have a mobile app, it's good to think about that when designing the UI so you can make sure you don't have to change the UI dramatically if you make an app in nine months.
A bad candidate will compartmentalize the problem – separating it from the actual goals of the company – and will begin talking through your proposed solution. He will effectively ignore all the background info you gave and will completely miss that your solution doesn't solve the problem. Because of this, it's important that your question provides enough background that it is apparent that your solution is insufficient.
Some good candidates (that may be great) might be reluctant to push back on your solution because doing so might offend you. If you think you're dealing with a candidate like this, let him continue down his path for a while and then ask more probing questions like "Do you think this is the best solution to the problem?" "Can you think of any better solutions?" Etc.
Here is an example:
"Our dashboard has lots of data to display at once, and our customers and test users have found it hard to know what they're looking at. We want to create a system of icons and hover-over tooltips that we can apply to the current dashboard that will make clearer what each piece of data is. How would you go about designing this?"
True solution: Adding icons and tooltips probably won't help and will just make any dashboard busier. Instead, (a) the dashboard should be organized better (or at least be evaluated to see if this is an option), (b) it could have better copy explaining what each tab/section does, (c) it could better utilize design patterns that wordlessly express the hierarchy and organization to users.
Bad solutions: Make a list of tooltip text, consider different icons, test the icons with users, design them myself, etc. (These would be fine things to do if they actually solved the problem, but they don't.)
2. Determine if the candidate respects data and financials over design for design's sake
Have a short list of tasks that your UX person would work on: 1-2 that are tied to measurable financial goals and 1-2 that are nice-to-haves. Ask the candidate how he would go about deciding which of these to prioritize within the company.
Example tasks:
The weekly reports we send to all users are pretty bare-bones and unattractive – it would be nice if they were redesigned and looked nicer.
About 2% of the time the values in the dashboard are such that a CSS bug means everything wraps in a way that looks kind of broken and unprofessional. It only happens to existing customers and the data is still readable and reliable, but it looks kind of bad. It's not a quick fix and will be a little time consuming.
Build [some completely new feature of value to prospective customers, like a quote generator or a demo].
Integrate the site with Optimizely to do A/B testing on users who haven't signed up yet.
Good prioritization: Any process that considers the company's goals and metrics
Bad prioritization: "The site should look good because design is important, so we should redesign the reports and fix the bug."
3. See if the candidate's design process is good.
Ask him to select a project in his portfolio in which he had major impact – preferably one you can see at that moment – and then to talk through a few key decisions that he made that were important to the project's outcome. Lots of people work on teams, so be sure to ask explicitly about the nature of his contributions. Look out for when he says "we decided" rather than "I decided," and probe further to try to understand if the candidate himself was responsible for the decision. Ask about why that decision was important, what were the tradeoffs, how he convinced others to go along with it, whether it was successful, how he measured its success, how he implemented it, etc.
Things to look for in this conversation:
Good: Candidate has awareness that the project had goals and his decisions worked towards those goals. Bad: design for design's sake
Good: Candidate considered the success metrics before executing the project
Bad: Candidate says he implemented it but can't go into precise detail about the technical components of the project
Good: Candidate made efforts to validate his assumptions before starting the project
Good: Candidate talked to users or attempted to get other user feedback before executing on the project
Good: Candidate tried several ideas in low-fidelity (maybe prototype, mocks, or just sketches) before committing to one idea
4. The obvious
In addition to the above, there are a few more obvious boxes to check that I didn’t cover. With any UX candidate, make sure you’re on the same page about aesthetics, what constitutes good and bad design, and that you have professionally compatible personalities.
Good luck with your UX hire!
Sign up now so you don’t miss an issue
In coming issues, I’ll do deep dives into specific UX examples, answer more of your questions, discuss low-cost user research techniques, and share practical tips and advice for improving your UX skills. Even if (or especially if) you don’t have a UX or design background yourself.
In the next issue I’ll discuss the Amazon delivery-option box in the checkout flow. Is it good or bad UX? Why or why not? Sign up now so you don’t miss it.
Send me your UX question.
What topics would you like me to cover next time? Send your UX questions to ask@uxbysarah.com. The more specific, the better! I also <3 screenshots, but they are not required. Don’t overthink it; just click this button and ask me now.
Thanks for joining me on this inaugural issue.
If you know someone who would be interested in this newsletter, share the love by sending it to them. See you next time!