Stop treating “high craft” as a logo

When a hiring manager tells me they want “high craft,” I want to know what they mean. Sometimes they mean careful interaction design, strong typography, or the ability to turn a complicated task into a clear experience. Sometimes they mean they would feel more comfortable hiring someone from a company whose product they admire.

Those are different standards. A previous employer gives you context, but it does not tell you which decisions a designer made or how well they made them. I would rather use the company name to frame better questions than let it supply the answer.

Define the craft the role actually needs

Craft is easier to assess when you connect it to the work. If the role involves complex workflows, you may care about information hierarchy, interaction states, error recovery, and the ability to make trade-offs legible. If the role is focused on a consumer brand experience, visual expression and consistency across touchpoints may carry more weight.

Write down the qualities that matter and what evidence would demonstrate them. Avoid a list so broad that every candidate must be excellent at everything. A small set of explicit expectations makes it easier for interviewers to compare their observations.

The definition should also distinguish baseline requirements from areas where the person can grow. Otherwise “high craft” becomes a phrase the team uses after an interview to justify a preference nobody explained beforehand.

Ask what the designer inherited

A strong product can reflect years of decisions made by many people. Design systems, research infrastructure, clear product management, and experienced colleagues can all improve the quality of an individual designer's output. That context is valuable, but it is not identical to individual capability.

Ask what existed when the designer joined a project. Were the interaction patterns established? Was the visual language already defined? Who had identified the user problem? What could they change, and what had to remain consistent?

These questions are not a way to diminish work done inside a mature organization. Working well within a system is a real skill. They help you distinguish using an established system thoughtfully from creating one, and maintaining a successful product from finding an approach that did not previously exist.

Look closely at a decision

Instead of asking someone to prove that they have taste, choose a specific part of the work and discuss it. Why is this information shown first? What happens when the user has no data? How does this interaction behave when the operation fails?

A candidate may not remember every detail, and confidential work may limit what they can share. Give them room to explain the decision at an appropriate level. You are looking for reasoning connected to users and constraints, not a performance of certainty.

I also want to know what they would improve now. Thoughtful criticism of their own work can reveal a stronger standard than a presentation that treats every outcome as ideal. Ask which limitation they accepted consciously and which one they discovered too late.

Give constrained work a fair reading

A designer at a smaller company may have shipped something less visually polished while carrying a wider range of responsibility. They may have worked without a researcher, negotiated directly with a founder, and supported implementation in a team with limited time.

That does not automatically make their work better. Constraints explain decisions; they do not excuse every weakness. But you need to understand them before comparing the result with work produced by a much larger team.

A useful comparison separates the outcome, the person's contribution, and the conditions. Ask what they protected when time became tight. Did they preserve the clarity of the task? Did they identify an accessibility issue? Did they communicate the compromise and leave a path to improve it? Those choices can tell you a great deal about their standard of work.

Treat design maturity as a question worth investigating

In my original post, I proposed an idea: ask designers to assess the design maturity of companies they have worked with, with more weight given to direct experience. The intention was to make the context behind a company logo easier to discuss.

That remains a proposal, not an established rating system or a validated measure. Any implementation would need to address who can contribute, how recent the experience is, and how differently teams within one company can operate. A single company score could easily hide the very context it was intended to reveal.

I would also want to understand selection bias and conflicts of interest before treating a rating as hiring evidence. People who choose to vote may not represent everyone who worked there. A useful tool would make uncertainty visible instead of replacing one simplistic signal with another.

Create an assessment the team can repeat

For the next interview, ask each evaluator to record an example rather than a label. Replace “strong craft” with the decision that demonstrated it. Replace “not polished enough” with the specific weakness and why it matters for the job.

Then compare notes before deciding. If two interviewers used different definitions of quality, resolve that disagreement explicitly. Do not average the scores and assume the underlying assessment was consistent.

The goal is not to remove judgment from hiring. Judgment is necessary. The goal is to make it explainable enough that a designer from an unfamiliar company can receive the same serious consideration as someone from a famous one.

A logo can tell you where to begin the conversation. The work, the decisions, and the person's contribution should tell you how to finish it.