“I know a great designer” is not enough

“I know a great designer” sounds like the beginning of a solved problem. For a founder trying to hire, it can feel like a shortcut through an unfamiliar market. Someone you trust has a name. The person has good work. Perhaps you can skip the difficult part.

I think the difficult part starts there. A referral tells you that someone is willing to recommend a person. It does not yet tell you whether that designer can solve your company's problem in the conditions you can offer. Great for whom, and great at what, are still unanswered questions.

When I recommend a designer, my credibility depends on the match. I cannot borrow confidence from liking the person or admiring their portfolio. I need a reason that connects their evidence to this company, at this stage, with this team.

Turn the vacancy into a problem statement

A title is useful for organizing a search, but it is too broad to make the decision. “Senior Product Designer” can mean an independent generalist, a specialist in an established team, or someone expected to create the company's first design practice.

Start with a short description of the situation. What is happening now that should change? What is the cost of leaving it as it is? What would a useful result look like after the person has had time to understand the company?

For example, a team may need to understand a confusing onboarding journey before it redesigns anything. Another may already understand the problem and need someone who can work closely with engineers to improve the interface. Both need design work. The strongest evidence for one job may be less relevant to the other.

Ask what the referrer actually observed

A recommendation becomes more useful when you unpack it. Did the referrer manage this designer, work alongside them, hire them for a project, or mainly follow their published work? Each relationship offers a different view.

Ask what the person did that earned the recommendation. Was it the quality of the finished interaction? The way they clarified an ambiguous brief? Their response when an engineering constraint changed the design? A concrete example is more useful than another adjective.

Then ask about the environment. How much support did the designer have? Who defined the problem? Were research, writing, product strategy, and visual design separate responsibilities? You are trying to understand the work behind the recommendation, not catch the referrer in a mistake.

Separate skills from conditions

The same person can perform very differently across teams. A designer may be strong at making decisions once the objective is clear, but struggle in a role where the founder expects them to discover and negotiate the objective alone. Another may excel at that early ambiguity but dislike maintaining a mature system.

Neither is a character flaw. It is a question of fit between the role and the way the person contributes. Ask candidates which conditions helped their best work, and which conditions made it harder. Ask yourself whether your company can provide the support they describe.

This is where honesty matters. If you cannot offer design mentorship, do not imply that you can. If the person will spend a substantial part of the week explaining decisions to stakeholders, put that in the brief. A match built on an idealized version of the job will unravel when ordinary work begins.

Use the portfolio as evidence, not a verdict

A portfolio should give you material to investigate. Choose work connected to the role and ask the designer to explain the original problem, their responsibility, and a decision that was genuinely theirs.

I want to hear what alternatives they considered, why they rejected them, and what changed after feedback or implementation. The polished artifact matters, but it is only part of the evidence. A case study can be beautifully presented while leaving individual contribution unclear.

Use the same core questions for referred candidates and everyone else. Familiarity can make us stop asking precisely when we should be getting specific. A trusted introduction should improve access to the conversation, not lower the standard of assessment.

Write down the trade-offs before deciding

Every candidate will have strengths and areas where the team must make an accommodation. Write those down in relation to the job. “Needs support with research planning” is useful if research ownership is central. “Less polished presentation” may be less important if the person communicates clearly in working sessions.

Avoid turning the discussion into a contest of impressions. Instead, compare the evidence against a small number of requirements agreed before the interviews. Where there is uncertainty, identify a proportionate next step: another example, a targeted reference conversation with consent, or a clarification of the role.

You should also name what would make you reject the match. If every concern can be explained away because the referral came from someone important, the process is no longer assessing the candidate. It is defending the introduction.

Make a recommendation you can explain

A useful recommendation sounds like this: the company needs a particular kind of contribution, this person's work provides relevant evidence, and these are the conditions or risks to discuss before offering the role.

That explanation helps the founder interview more effectively. It also respects the designer by describing why their experience matters rather than treating them as a generally impressive person who should work anywhere.

I still value introductions. Relationships can surface people a public job advertisement will miss. But the name is the beginning of the work. The quality of the match depends on how carefully you connect the person, the problem, and the environment they are about to enter.