Across the last four years I've sat on the other side of roughly sixty founder calls where the first sentence was some variation of: "We've never hired a designer before and we're not sure what we should be looking for." Some of those calls turned into engagements with me. Most didn't — and the ones that didn't are why I'm writing this. Too many of those founders went on to hire badly, burn six months, and then either give up on design as a function or hire a second time in panic.
This post is the version of the conversation I now have on those intro calls. It covers the four portfolio red flags I see all the time, five questions that filter the 80% of candidates who can't ship, the difference between a junior, senior and contractor hire, and the pricing-conversation signals that tell you whether the person across the table is going to be a real partner or a billable headache. No fluff. No "it depends" hedging.
A laptop on a desk showing a portfolio in browser, mid-review by a hiring manager
Why your first design hire matters more than your fifth
By the time a company has five designers, the design culture, the system, the rituals and the language are already set. The first hire is the person setting all of that. If they ship the wrong system, every subsequent designer either fights it or inherits its problems.
This is the opposite of how most founders treat the role. The first design hire is often "the most junior person we can afford because we just need wireframes." That framing is almost always wrong. Not because juniors are bad — they aren't — but because a junior with no senior to learn from will calcify the wrong patterns within their first three months. They're not failing; they're being failed.
The right first hire is someone who has shipped at least one complete product end-to-end and who can articulate why they made the trade-offs they made. That person can be a senior employee, a contractor, or a fractional design lead. It is rarely a designer one year out of bootcamp.
The 4 portfolio red flags I see all the time
I review somewhere between fifty and a hundred designer portfolios a year — sometimes as a hiring filter for founder friends, sometimes because junior designers in Pakistan ask me for feedback. The same four red flags come up over and over.
Pixel-perfect mocks with no flow context
The portfolio is a parade of beautiful single screens — a dashboard here, a settings page there, a sign-up flow rendered as one polished frame. There's no flow context. No before/after. No "here's what the user was trying to do and here's how this screen helped them do it."
Beautiful single screens are easy to make in 2026. Midjourney plus a few hours in Figma produces them. What's hard, and what you're hiring for, is the reasoning that connects screens to outcomes. If the portfolio doesn't show that reasoning, the designer probably doesn't have it.
Case studies that don't mention engineering
A real case study mentions the engineer they worked with, the technical constraint that changed the design, the moment they had to redesign a flow because the API didn't support what the mock implied. A fake case study mentions only the designer.
Design doesn't ship without engineering. A designer who can't tell you the name of the engineer they shipped with — or the technical constraint that shaped the final design — has likely never shipped anything that left a Figma file.
One-off "concepts" instead of shipped work
Concept work has a place — for designers building a portfolio early, or for senior designers exploring an unfamiliar domain. But if the entire portfolio is unsolicited redesigns of Spotify, Airbnb and Notion, the designer has not been hired to do real work yet. That is fine for an internship. It is not fine for the person setting your design culture.
Generic design system in every example
If every project in the portfolio uses the same blue-and-grey, the same Inter font, the same shadcn-shaped components, the designer has one taste setting. That's fine if your product happens to need exactly that taste. It is a problem if you need a brand that doesn't look like every other 2024 SaaS dashboard. Look for range — a healthcare flow that feels warm, a fintech dashboard that feels precise, an e-commerce surface that feels playful, all from the same person.
5 questions to ask in the interview
These are the five questions I ask when I'm helping a founder run an interview round. Each one filters for a specific signal.
1. "Walk me through a decision you made that turned out to be wrong. What did you learn?"
What you're listening for: specificity. A real answer mentions a project, a user behaviour, a metric that went the wrong direction, and a concrete change in how the designer now works. A fake answer is abstract — "I learned to listen more to users" without a story attached. Designers who can't name their own mistakes haven't reflected on them.
2. "What was the last time you pushed back on a stakeholder, and what happened?"
What you're listening for: that they have pushed back at all, and that they did it with evidence rather than opinion. Designers who can't say no to a stakeholder will ship whatever you ask for — including the wrong thing. Designers who push back with "I just don't like it" are a different kind of problem.
3. "Show me a flow you designed and tell me which fields you fought to remove."
What you're listening for: progressive-disclosure instinct. Every form-based flow has fields the team wanted to keep that the designer wanted to defer. A senior designer can name which ones and why. A junior designer adds everything the PM asks for.
4. "What's your weekly rhythm with engineering?"
What you're listening for: a real answer involves shared rituals — design QA on staging, a shared Figma file, Friday office hours with the eng team, async Slack threads on Slack channels they're actually in. A weak answer is "I throw the file over the wall and they build it."
5. "If we hired you tomorrow, what's the first thing you'd do in the first two weeks?"
What you're listening for: research before design. A strong answer talks about meeting users, auditing the current product, understanding the team's existing constraints, and producing a shared language document before any new pixels are pushed. A weak answer jumps straight to "redesign the home page."
Skills checklist — must-have vs nice-to-have
A working version of the skills matrix I send founders when they ask me to write a job description. Drop the nice-to-haves. They are nice. They are not deciders.
| Skill area | Must-have for first hire | Nice-to-have |
|---|---|---|
| User research | Can run an unmoderated test on Maze or UserTesting solo | Has run moderated diary studies |
| Figma | Component variants, auto-layout, Dev Mode, variables | Tokens Studio, Code Connect, advanced animation |
| Information architecture | Can map a user flow on a whiteboard cold | Has built a design system from zero |
| Visual design | Range across at least 3 industries | Strong illustration or brand-design background |
| Copywriting | Can write a usable empty state, error, and CTA | Has owned product copy across an entire app |
| Engineering literacy | Can read a React component and not flinch | Has shipped frontend code themselves |
| Stakeholder communication | Has presented design to a CEO or board | Has run a workshop with non-design execs |
| Prototyping | Smart Animate, basic Lottie integration | Rive, ProtoPie, after-effects pipelines |
| Accessibility | Knows WCAG AA contrast basics, focus states | Has shipped a screen-reader-tested app |
| Domain knowledge | None required if research skill is strong | Direct experience in your specific industry |
The trap is hiring on the nice-to-have column because it sounds impressive. The first hire ships if the must-have column is full. The first hire stalls if the must-have column has holes, no matter how full the nice-to-have column is.
Junior vs senior vs contractor — when each makes sense
Three real scenarios I see weekly.
Hire a junior when
You already have a senior designer on the team (employee or fractional) who can mentor. You have well-defined sub-projects — a settings flow, a notification system, a single feature — that a junior can own end-to-end with feedback. Your timeline is six-plus months and your design rituals are already set.
Hire a senior employee when
Design is going to be a core function of the company. You have at least eighteen months of runway. You're committed to building a design team rather than buying design as a service. You can pay market for a senior — in 2026 that's $150-220k base in the US, equivalent ranges in other markets — and you have a credible roadmap that justifies the cost.
Hire a contractor or fractional lead when
You need to ship a specific thing in the next ninety days. You're not yet sure design is the bottleneck. You want a senior brain on the problem without the full-time cost. You're pre-Series-A and you cannot make a full-time hire mistake. This is the scenario where most pre-seed and seed-stage founders should be — and where most of my own engagements fit. A six-week sprint with a senior contractor will produce more shipped value than three months of a junior's first job.
Red flags in pricing conversations
Three signals in the pricing conversation that tell you the person across the table is not a real partner.
They refuse to talk about scope before quoting. A real designer asks what you're shipping, what the timeline is, what's already in place, and what the team looks like — before giving you a number. A designer who throws a number across the table without those questions is selling a commodity, not a service.
They quote by hour with no upper bound. Hourly with a cap is fine. Hourly with no cap is an invitation to scope creep that benefits one side of the table. Fixed-fee per phase is better. The strongest contractors quote per outcome — "I will ship the redesigned onboarding flow in six weeks for $X" — and own the timeline.
They are dramatically cheaper than market. A senior contract designer in 2026 charges between $4k and $12k per week depending on geography and specialism. A "senior designer" quoting $800 per week is either not senior, not honest, or not going to be available when you need them. Cheap design is the most expensive line item you will ever ship.
What good first-month deliverables look like
This is the contract I write into the first month of any engagement. If you hire someone — employee or contractor — and they cannot produce these by end of week four, you have hired the wrong person.
- A written audit of the current product with at least ten specific friction points and proposed fixes
- A user-flow map of the most-used path through the product, with friction annotated
- A research plan for the first sprint, with target users, recruitment channels, and budget
- At least one shipped change — even a small one — to demonstrate they can move things into production, not just into Figma
- A short "what I'm not doing and why" doc that calibrates expectations with the founder
If month one ends with only a Figma file full of mocks and nothing in production, the designer is in the wrong job — or in the wrong relationship with engineering. Either way, the problem is now visible and you can fix it.
Related reading
- Why I'm a Figma-first designer — the toolchain question, answered
- My UX redesign process — Take Therapy — what the first-month deliverables look like in practice
- Designing crypto wallets for first-time users — what good portfolio work actually contains
See it in practice on the Take Therapy case study and the Enrichplay case study — both are examples of the six-week sprint format I described under "contractor" above.
If you're about to make this hire
If you're weighing your first design hire and you'd like a second opinion before you commit — or if you want to run a six-week sprint with a senior contractor first to see what's possible — tell me about your stage. Read how I work for the shape of the engagement, or walk through my process to see what the first four weeks actually look like.