How to Evaluate a Product Designer's Portfolio

You're a founder who doesn't have a design background. You're looking at a designer's portfolio and you're not sure what you're evaluating. Everything looks polished. Some portfolios look more polished than others. You end up picking the prettiest one and hoping for the best.

This is how a lot of bad design hires happen. Visual polish is the easiest thing to fake in a portfolio — and it's the least relevant indicator of whether someone will solve your actual problems.

A strong product designer portfolio shows thinking, not just output. Here's how to read one when you're not a designer yourself.

---

Start With Structure: Are There Case Studies or Just Screens?

The first thing to look for is structure. A portfolio that shows final screens — beautiful, polished UI — with no explanation is a decoration portfolio. A portfolio that walks through a problem, a process, and a solution is a design portfolio.

The difference matters enormously. Screens tell you what the designer built. Case studies tell you how they think.

For a B2B SaaS hire, you need someone who can think through problems, not just execute them. A designer who can't explain their decisions in writing probably can't explain them in meetings either — and that's a problem when you're working together on complex product questions.

What a strong case study includes:

• What was the problem or goal?
• Who were the users and what were they trying to accomplish?
• What did the designer explore before landing on the solution?
• What did they build and why did they make the specific choices they made?
• What happened after it shipped — any results, learnings, or iterations?

You don't need to see all five in every case study, but missing all five is a red flag.

---

B2B vs. Consumer Work: Why It Matters

Not all product design experience transfers between contexts. B2B SaaS design and consumer app design are genuinely different disciplines, and a portfolio full of consumer work doesn't tell you much about whether someone can design your SaaS product.

Consumer design typically involves:

• Simple, linear user flows (one primary task)
• Emotional appeal and visual delight
• Short sessions and low learning curves
• Single user type
• Mobile-first

B2B SaaS design typically involves:

• Multi-step, multi-session workflows
• Multiple user roles with different permissions and needs
• Dense information displays — data tables, charts, filters, exports
• Admin and settings surfaces
• Long learning curves that are acceptable because users are trained
• Desktop-first or responsive with desktop as primary

A designer who excels at consumer apps isn't automatically bad at B2B — but there's a learning curve, and you'll pay for it in early output quality. If you're building a SaaS product, look for portfolios that show:

• Dashboard interfaces with meaningful data complexity
• Multi-step onboarding flows
• Settings or admin screens
• Filtering, search, and data organization patterns
• Role-based access or team management features

If their strongest work is a weather app redesign and a food delivery concept, ask hard questions before proceeding.

---

Process Signals vs. Output Signals

Output signals are what you see: the finished screens. Process signals are what happened before them. For hiring decisions, process signals are more predictive.

Strong process signals:

• Wireframes or lo-fi sketches shown alongside finals — indicates they explored before committing, didn't just jump to polished UI
• User research or user quotes mentioned — indicates decisions are user-grounded, not just opinion-based
• Iteration examples — "here's version 1 and here's what changed and why" is gold
• Constraint acknowledgment — good designers name what they couldn't do and why, not just what they built
• Tradeoffs explained — "we chose X over Y because of Z" indicates systematic thinking

Weak process signals (or no signal):

• "I researched, I iterated, I delivered" with no specifics
• Final screens only, no mention of how they got there
• Vague outcomes: "improved the user experience"
• Heavy use of jargon without substance: "design thinking," "user-centric approach"

Process language can be faked. Watch for case studies that name the process (user interviews, affinity mapping, usability testing) without showing any artifacts or outputs from that process. If they did 12 user interviews, you'd expect to see at least a summary of what they learned.

---

Questions to Ask About Portfolio Pieces

Don't evaluate a portfolio passively. Use it as the basis for a structured conversation. These questions surface real capability:

"Walk me through your design process on this project."

You're listening for specificity and decision logic. Generic answers ("I started with research, then wireframes, then high-fidelity") don't tell you much. Specific answers ("I talked to five power users and found that they were skipping the onboarding because it asked for too much before showing value — so I redesigned it to defer that information until after the first win") tell you everything.

"What were the constraints you were working under?"

All real design work has constraints: timeline, technical limitations, stakeholder requirements, existing design patterns that couldn't be broken. A designer who can name their constraints has been in real working environments. A designer who says "I had full creative freedom" either worked on a concept project or is idealizing their experience.

"What would you do differently now?"

Senior designers are self-critical. They've learned from shipped work and can tell you exactly what they'd change and why. Junior designers tend to defend their choices. Designers who are insecure about their work deflect or say they'd "polish it more."

"How did this perform?"

You don't always get outcomes — sometimes designers leave companies before data comes in, or the work was brand design with no measurable metric. But asking the question reveals whether they think about outcomes at all. "I don't know, I moved to a different company before the launch" is honest. "That's not really something I tracked" is a signal.

"Who else was involved and what was your specific contribution?"

In team portfolios, it's common for designers to present work they contributed to but didn't own. There's nothing wrong with that — design is collaborative — but you want to know what their specific role was. A designer who says "I owned the dashboard redesign" but actually did one screen of a six-person team project is overstating their experience.

---

Red Flags in Portfolios

These aren't automatic disqualifiers, but each one is worth a follow-up question.

Only final screens, no context

A portfolio of 40 beautiful screens with no explanation of problems, users, or decisions. Could be a strong designer who just hasn't written case studies — but it's a documentation red flag, and documentation is part of the job.

No B2B or product work

All consumer apps, brand identity, or marketing design with no SaaS or product work. Ask specifically about B2B experience in the conversation.

Concept projects without shipped work

Redesigning Spotify or reimagining Airbnb as concept projects is common in junior portfolios. These have value as skills demonstrations but they lack the real constraint of shipping to actual users. If most of the portfolio is concept work, the designer hasn't had their work stress-tested.

Vague outcomes

"The redesign improved user satisfaction" or "users responded positively" without any specifics. Real outcomes are specific: activation rate went from 28% to 41%, support tickets dropped, NPS moved.

No evidence of collaboration

Product design is collaborative. Portfolios that present work as entirely solo miss the reality of how product teams function. A designer who can't describe how they worked with engineers, product managers, or stakeholders may struggle in a team environment.

Visual inconsistency without explanation

If the portfolio has work that varies widely in quality — some very strong, some noticeably weaker — ask about it. Sometimes there's a good reason (different briefs, different constraints). Sometimes it indicates inconsistent work quality.

Too polished to be real

Occasionally portfolios have been so heavily refined after the fact that they don't reflect the actual working design — they've been reworked for presentation purposes. Watch for case studies where everything was perfect from the start, every decision was obviously right, and there's no mention of what didn't work. Real product work has friction.

---

What Good Looks Like for B2B SaaS

A portfolio that would strongly signal readiness for B2B SaaS work shows:

• At least 2–3 case studies from SaaS or enterprise software
• Dashboard or data-heavy interfaces with real complexity
• Process documentation: wireframes, iterations, or research summaries
• Clear explanation of user types and their goals
• Honest acknowledgment of constraints and tradeoffs
• Evidence of cross-functional collaboration (with engineers, PMs, or stakeholders)
• Specific outcomes where available

You're not looking for perfection. You're looking for evidence that this person has solved problems similar to yours — and can explain how they did it.

---

The Quick Portfolio Scan (15-Minute Version)

If you're reviewing 20 portfolios and need a fast filter:

1. Do they have case studies, or just screens? If just screens, move on or put in a lower tier.
2. Is there any B2B/SaaS work? If not, flag for follow-up.
3. Pick their strongest case study and read the whole thing. Does it explain the problem, the user, the decision process, and the outcome? Can you understand what they built and why?
4. Look at the quality of the writing. Designers who write clearly think clearly. Poor, jargon-heavy case study writing often correlates with murky thinking.
5. Check the recency. Design tools and best practices change fast. Work from 4+ years ago in a portfolio with nothing more recent is a flag.

This gives you a first-cut signal in 15 minutes per portfolio. Then go deeper with the top 3–5 in a portfolio walkthrough call.

---

Connecting This to the Interview

The portfolio review should directly feed the interview. Pick 1–2 case studies you want to discuss in depth and ask the designer to walk you through them. Listen for decision logic, self-awareness, and specificity.

The best question you can end the portfolio review with: "Is there work you're proudest of that's not in this portfolio, and why isn't it there?" The answer is always interesting — sometimes it's confidential, sometimes the context is worth knowing.

For more on the full hiring process, see how to hire a product designer. If you're not ready to hire full-time, a design subscription service can give you access to senior design capacity without the commitment. If you're evaluating a design agency rather than an individual designer, 15 questions to ask before hiring a design agency covers different ground.

---

Frequently Asked Questions