Product Designer Portfolio: What Hiring Managers Actually Look For

A product designer portfolio has one job: convince a busy design manager, in a few minutes, that you can take a messy product problem and move a real number. Hiring managers look for three things, in this order: did you understand the user and the business problem, what did you personally decide, and what changed because of it. Polished screens matter, but they are the proof at the end of the story, not the story. The strongest portfolios show three or four focused case studies, each with a clear role, the constraint you worked under, the decision you made, and an honest result. In this guide I break down the structure I use in my own case studies (ViewStats for the team behind MrBeast, Accern, Greenely, Bitgrit), what published hiring managers say they check, a table of sections and common mistakes, and why working builds now beat static mockups.

What a product designer portfolio is actually for

Most designers build their portfolio as an archive: everything they have made, in chronological order, beautifully presented. That is a gallery. A portfolio is closer to a sales page for a very specific buyer, a design manager or founder who has a gap on their team and limited time to fill it.

That buyer is not asking "is this person talented?". They are asking "will this person solve the kind of problems we have, at the level we need, without me holding their hand?". Every case study should answer that question for the job you want next, not the job you had.

This changes what you include. If you want to design AI features, your best AI project goes first, even if it was smaller than your biggest dashboard project. If you want a design engineer role, show the code and the shipped result, not only Figma frames. If you want a lead role, show decisions that involved other people: research you ran, trade-offs you negotiated, a system others used. I explain how these roles differ in what a product designer does.

What hiring managers say they look for

You do not have to guess. Several people who hire designers have written down their criteria, and they agree on more than they disagree.

Leslie Yang, a design manager and former lead product designer who has hired product designers, describes looking for a balance of process, craft, and an understanding of both the user and the business. She recommends three to four case studies focused on the type of work you want to be hired for, each covering the user problem, business goals, research, iterations, visual design and impact, plus your role, team and project length (her hiring manager guide).

Korin Harris, a design recruiter at Figma, writes that recruiters may spend minutes or even seconds on a portfolio, that your work should be one click from the homepage, that each project preview should say the company, your role and the medium, and that flashy carousels and heavy animation get in the way (her recruiter tips on Dribbble).

Put those together and the pattern is clear:

Relevance: the work matches the role.
Ownership: it is obvious what you did versus what the team did.
Thinking: you understood the problem before drawing screens.
Craft: the final work is good enough to ship.
Impact: something measurable or observable changed.
Speed of reading: all of the above is visible in a skim.

The last one is where most portfolios fail. The thinking is there, but it is buried in paragraph nine.

The case study structure I use

Here is the structure behind my ViewStats case study for the team behind MrBeast. It is not the only good structure, but every part earns its place.

1. One line of context. What the product is and who it is for. ViewStats is a creator intelligence platform; I led design across web, mobile, a Chrome extension, the website, growth, AI experiences and the design system. One sentence on the product, one on my scope. A reviewer should know your role before they see a single screen.

2. The insight, not the brief. The brief was "a YouTube analytics platform". The insight was that creators were not asking for more charts. They wanted confidence: what should I make next? That one sentence reframes every screen that follows, and it shows the reviewer you look past the feature list. If your case study has no insight, it is a feature tour.

3. Where the insight came from. Creator interviews, onboarding analytics, Discord community feedback, support requests and internal workshops. Listing your inputs tells the reader your conclusions are earned, and it is honest about the kind of research you could actually do.

4. One problem, told properly. Many creators signed up and never connected their YouTube channel. Funnel analysis plus research showed they did not understand what they would gain. We redesigned onboarding, empty states and contextual prompts around one principle: show value first, ask for trust second. Connection went from 13% to 65%+. That single story is worth more than ten screens of features, and I gave it its own onboarding UX write-up.

5. The hard part. For the AI tools (thumbnail generation, AI titles, thumbnail testing) the hard part was not the interface. It was designing trust. And after launch the tools drew public criticism from artists and thumbnail designers. Including that in a portfolio feels risky. I think it is the most senior thing in the case study, because it shows judgment about consequences, not only pixels.

6. Results, with the denominator. 500,000+ users, 200,000+ extension users, 100,000+ mobile downloads, activation from 13% to 65%+. Numbers that are specific and that you can explain in an interview.

7. Reflection. One or two lines on what you learned. Mine: people rarely want more information; they want clarity. A reflection tells the reviewer how you will think on their product.

Show the constraint, not just the solution

A clean process diagram (research, define, ideate, test) appears in almost every junior portfolio, and hiring managers skip it, because it describes every project and therefore none. What separates portfolios is the constraint you designed around.

At Accern, a no-code NLP platform for finance, I was the first design hire. Our users were large finance enterprises, and few were available for testing. So research ran through the customer success team: interviews, a usability survey, four personas, an empathy map, how-might-we statements, an impact and feasibility matrix, storyboards and sketches. The interesting part of that case study is not the list of methods. It is that the normal path (talk to users) was blocked, and the work still had to be grounded. The published results were +200% retention and 82% fewer support tasks.

At Greenely, the Swedish energy app, the constraint was the opposite. Users were very reachable: a Facebook group of 2,000+ members, and people who knocked on the office door to complain or ask for features. I was the sole product designer. The challenge was turning a flood of opinions into priorities, and adding Mixpanel so we measured instead of guessing.

Two very different research situations. Either one tells a hiring manager more about how you work than a generic double-diamond graphic.

How to show impact without lying

Every hiring guide says "show metrics", and that pressure produces a lot of fiction. Reviewers can tell. A junior designer claiming they "increased revenue 300%" on a project with fifteen people raises a flag, not a hand.

Rules I follow:

Use the number the team actually measured, and say it was a team result. "Channel connection went from 13% to 65%+ after the onboarding redesign" is true and lets me explain my part.
If you have no number, describe the observable change. "Users navigate without customer success help" is a result. So is "the sales team started using the prototype in demos".
Never invent a number to fill a template. An honest "we did not measure this, here is what I would track" reads as more senior than a made-up percentage.
Be ready to explain the denominator. If you say 65%, know 65% of what.

The same applies to scope. "Led design" and "contributed to" are different claims. Use the one that will survive a reference call.

Product designer portfolio sections, compared

Here is how I would weigh each part of a portfolio, what a reviewer is checking when they reach it, and the mistake that costs the most.

Section	What the reviewer is checking	Common mistake
Home page intro	Who you are, what level, what kind of work you want	A clever tagline that says nothing about the role
Project previews	Company, your role, medium, at a glance	Pretty thumbnails with no label; reviewer has to click to learn basics
Case study opening	Context and your scope in two sentences	Three paragraphs of company history before the problem
Problem and insight	Do you look past the brief?	Restating the feature request as the problem
Research	Is the work grounded, and how?	A generic process diagram copied across every project
Decisions and iterations	What you chose, what you rejected, why	Only final screens, no alternatives
Final design	Craft, systems thinking, detail	Device mockups so small the UI is unreadable
Results	Impact and honesty	Inflated or unexplainable numbers
Reflection	Judgment and growth	Skipping it, or a generic "I learned a lot"
About and contact	Can I reach you, are you real?	No email, no CV, broken links

Working builds beat mockups now

This is the part of portfolio advice that changed the most in the last two years. When anyone can generate a polished screen in minutes, a static mockup proves less than it used to. What still proves a lot: a thing that works.

At ViewStats my role expanded from lead product designer into design engineer. I worked in the codebase with Cursor, Claude Code, React, TypeScript and GitHub: designed, prototyped, built React components, opened pull requests and reviewed implementation. In a portfolio, a link to a shipped feature or a short screen recording of the real product says more than a perfect Figma frame.

That is also why my AI design experiments are playable builds, not shots. You can freeze a card and tap the ice three times to shatter it in the Payno card experiment, or watch 3D gummy bears land on a live scale in the Haribo configurator. Each one is built with tools like Figma, Claude, the Figma MCP, SwiftUI, WebGL, three.js and physics engines, with motion and sound designed in. For a reviewer, the question "can this person actually ship interaction?" is answered in ten seconds of play.

You do not need to become an engineer to use this. Even a clickable prototype that runs on a phone, or a short recording of a micro-interaction with sound, moves you ahead of a stack of static screens. If you want to go further, I wrote about how to become a design engineer, starting with one pull request.

One caveat. A side project is not a substitute for product thinking. Ten beautiful experiments with no user, no problem and no decision still read as a dribbble feed. Pair them with at least two real product case studies.

What the best product designer portfolios have in common

People search for "best product designer portfolios" to find something to copy. I would not copy any single site. Look instead for the traits the strong ones share:

A clear point of view in the first line. Not "I design delightful experiences", but the kind of products and problems the person is good at.
Fewer, deeper projects. Three or four case studies, each with a real insight. Not twelve thumbnails.
Readable in a skim. Headings that tell the story on their own, short paragraphs, big visuals with captions.
Honest scope. "I owned onboarding and the AI tools; the dashboard was a team effort."
Something alive. A prototype, a video, an interaction you can try. Proof that the person cares about how things feel, not only how they look.
Personality, used sparingly. A distinctive detail people remember, without making the portfolio harder to read.

On that last point, I value being distinctive and taking risks, and I think a portfolio is a good place to show it. But Korin Harris's advice holds: if the animation slows down the reviewer, it costs you. Put the playful part where it does not block the case studies.

Portfolio mistakes that cost interviews

A short list, because these are fixable in an afternoon:

No role statement. If the reviewer cannot tell what you did, they assume less.
Leading with your oldest work because the brand was famous. Recency and relevance beat logos.
Passwords on everything. NDAs are real, but a portfolio where every project is locked gets skipped. More on this in the FAQ.
Walls of text. Long write-ups are fine as a linked PDF or a second page. The first pass has to be skimmable.
Unreadable visuals. Tiny screens in tilted device frames. Show the UI large enough to judge craft.
Typos. Harris points out spelling errors get noticed fast. A product designer is also a writer.
No contact path. Email visible, a CV link, and a way to book a call.

Where to build it: Framer, Webflow, Notion or PDF

The tool matters less than people think, but it is a fair question. My own site, the one you are reading, runs on Webflow, with experiments hosted separately as live builds. Framer is fast and popular with product designers. Notion portfolios are quick to set up and easy to update, at the cost of looking like everyone else's. A PDF is still useful for applications that ask for one and for long-form case studies.

If you are choosing between the two most common site builders, I compared them in Framer vs Webflow. My short advice: pick the one that lets you update a case study in ten minutes, because a portfolio you dread editing goes stale.

Avoid relying only on gallery platforms. Yang notes they do not make clear what you personally did, which is exactly the question a hiring manager is trying to answer.

Using AI on your portfolio, honestly

AI is useful for portfolio work in boring ways: tightening a case study draft, catching typos, generating alt text, turning a long write-up into a skimmable summary, or helping you build a working prototype you could not have coded alone. Those are good uses.

Where it hurts: generated "process artifacts" that never existed, invented personas presented as research, or a case study written so smoothly that it no longer sounds like you. Reviewers ask follow-up questions in interviews, and anything you cannot explain in your own words becomes a liability. I wrote more about where AI fits and where it does not in will AI replace product designers.

If you are junior or switching careers

You will not have a 13% to 65% story yet, and that is fine. Hiring managers adjust for level. What they still want to see is how you think.

Early in my career I was the only designer at Bitgrit, an AI and data-science community of 30,000+ engineers. The Bitgrit case study is built on modest research: 7 user interviews, a survey of 20 people, 3 personas, affinity mapping, and a UI kit that grew into a design system. Small numbers, honestly reported, with a clear line from what users said (fair rewards, learning, showing hidden skills) to what was designed. That is a perfectly good case study.

If you have no client work, pick a real product you use, find one real problem with it, talk to five people who use it, and redesign that one flow. Then build it, even roughly. One deep, honest project beats three shallow concept redesigns. For the bigger career question, I shared my view in is product design a good career.

Go deeper

Related guides on the role and the work behind a portfolio:

Product designer vs UX designer, and why ownership is the difference.
What a design engineer is in software, if you want your portfolio to show code.
Enterprise UX design, a full story from the Accern work.
Dashboard UX best practices, a single-decision case study from ViewStats.

FAQ: product designer portfolio

How many case studies should a product designer portfolio have?

Three or four is the range published hiring managers recommend, and I agree with it. Fewer than three makes it hard to see range. More than five usually means some are weak, and reviewers judge you by your weakest visible project.

What if my best work is under NDA?

Parts of my own case studies are under NDA, so this is a real constraint. Write about the problem, the constraint, the decision and the type of result without confidential details. Blur or rebuild sensitive screens with dummy data. Offer a password-protected deep dive for interviews, but keep at least one or two case studies fully public so the first skim works.

Should a product designer portfolio include code?

It is not required for most product designer roles. It is a strong advantage for design engineer roles and for startups that want designers who ship. A link to a shipped component, a pull request description, or a working prototype is enough; you do not need a GitHub full of projects.

How long should a product design case study be?

Long enough to tell one problem properly, short enough to skim in two or three minutes. Use headings that tell the story on their own, keep paragraphs short, and move extra detail into a linked document. If a section does not change what the reviewer thinks of you, cut it.

Is a product designer portfolio different from a UX portfolio?

Mostly in emphasis. A UX portfolio leans on research and flows. A product designer portfolio should also show business context, trade-offs with engineering and product, and outcomes after launch, because the role owns the result, not only the experience.

A simple next step

Open your portfolio and give it the reviewer test: set a two-minute timer, start on the home page, and see if a stranger could answer four questions before it rings. What role do you want? What did you personally do on your best project? What was the insight? What changed? Fix whatever stops them. And if you are on the other side, a founder looking for a senior designer who can show all four with shipped work, you can browse my product design work or hire a product designer and we can talk about your product.