How to hire a designer when you're not sure what you need

The job description is usually the first mistake. Someone decides they need a designer, opens a template, and fills in the blanks. Senior IC or manager? Product or systems? The answers get committed to a req before anyone has thought carefully about what the actual work is.

Then the interviews happen. The team assesses candidates against the req. Someone gets hired. Six months later, it becomes clear that the hire was for a role that didn't match the actual need. Nobody's quite sure how that happened.

What happened is that the req was written too early, from instinct rather than diagnosis. The work of figuring out what you need happens before the job description, not during it.

The question you're actually trying to answer

Uncertainty about what to hire for usually comes from uncertainty about what the design problem is. If you know the problem precisely, the shape of the right hire tends to become obvious. The uncertainty in the hire is downstream of uncertainty about the work.

So the useful question isn't "what kind of designer do we need?" It's "what is broken or missing in how design is working right now, and what would fix it?"

If the answer is that design is getting pulled into every conversation but has no time to go deep, you probably need a generalist who can triage and delegate. If the answer is that product teams ship things that users find confusing and nobody is catching it until launch, you might need someone with strong UX research instincts. If the answer is that the product looks inconsistent and the team is rebuilding the same patterns over and over, that's a different problem with a different profile.

None of this is guaranteed to be right. But diagnosing the work first gives you something to hire against.

When the org itself doesn't know

The harder version of this problem is when the people you're hiring for can't articulate what they want. "We need a design person" is as far as it goes. This is more common than it should be at companies that haven't had embedded design before.

In that situation, the uncertainty is a feature of the context, not a failure of imagination. The organization doesn't know what it wants from design because it doesn't have a working model of what design does.

The hire you make in that context will define what design means there for years. If you hire a producer who executes specs, design becomes a finishing department. If you hire someone who wants to shape product direction, they'll either succeed and design becomes something else, or fail and leave, and design goes back to what it was.

This isn't a reason not to hire. It's a reason to be explicit with candidates about the ambiguity. The designers who do well in that environment are different from the ones who do well in a more defined role. They tend to be tolerant of unclear mandates and reasonably good at building credibility without positional authority. They're willing to define their own scope before executing against it.

What to look for in the portfolio

When the role is uncertain, portfolios are more informative than usual, but you have to read them differently. You're not evaluating whether they can do the specific type of design work you have in mind. You're looking for how they operate when the problem is ambiguous.

The work that's most telling is usually the work where things didn't go as planned. How did they handle a project where the brief changed mid-flight? Did they push back when the direction stopped making sense? Did they bring new constraints to the team or wait for someone else to surface them?

That judgment is what you need most when the role itself is uncertain. When to hold the line and when to adapt. A strong portfolio full of cleanly executed work from a well-defined brief tells you less than a messier portfolio where you can see the designer navigating something complicated.

On starting too senior

One common mistake when hiring into ambiguity is going too senior too fast. The reasoning is understandable: if we're not sure what we need, let's hire someone experienced enough to figure it out.

The problem is that very senior designers often have strong opinions about how design should work, and those opinions were formed in a different context. A VP-level hire at a company with no design infrastructure will spend the first year building the infrastructure that should have been built by someone below them. Meanwhile, the cost and seniority of the hire create expectations the role can't yet deliver on.

Hire for the work that actually exists, not the work you'd like to have in two years. If the work is ambiguous and early-stage, a curious mid-senior designer with a high tolerance for building from scratch will usually outperform an executive hire who expects more to already be in place.

---

The best signal you can get from an uncertain hire isn't the resume or the portfolio. It's what the candidate asks about in the interview. Someone who asks "what would success look like in year one?" is thinking about the same question you should have been thinking about before you wrote the req.