What I Actually Look At in a Portfolio Review

The fastest way to lose me isn’t a bad case study. It’s a homepage that makes me guess what you actually do.

I used to open portfolio links in a queue, one browser tab bleeding into the next, during every active recruiting push. Ten seconds on the homepage. Two or three minutes per case study if it earned them. By the time I got to case study three, I wasn’t reading anymore in the way designers imagine a “portfolio review” happening. I was pattern-matching, fast, against a very short list of things that told me whether to keep going or close the tab.

I spent eight years as a technical recruiter before I became a designer. Now I’m a senior product designer myself, sitting on the other side of design reviews, sometimes handed a stack of portfolio links before a hiring push starts. That’s a different vantage point than the post I wrote about building a portfolio, which is about construction: theme, structure, personal statement. This one is about what happens after you hit publish, when someone you’ve never met opens the link and decides, in about the time it takes to microwave coffee, whether you’re worth a second read.

Naming the limit up front: this is my pattern, built from hundreds of candidate screens as a recruiter and however many portfolios I’ve looked at since as a practicing designer. It’s not a universal law. Every hiring manager weighs things a little differently. But the pattern holds often enough that I’d bet on it before I’d bet on generic “portfolio tips” advice that could have been written by anyone.

The first ten seconds are a recruiter screen, not a design review

Here’s what nobody tells junior designers: your portfolio gets read by two completely different people, in two completely different modes, and most portfolios are only built for the second one.

The recruiter screen comes first. A recruiter isn’t judging your Figma craft. They’re matching you against a requisition, fast, and looking for a reason they can defend passing you along. Does the homepage say what role and level you’re going for, in plain language, above the fold? Can they tell in ten seconds whether you’re a junior generalist or a senior specialist? Is there an obvious red flag, a dead link, an unclear title, a case study that never says what you actually shipped, that would make them hesitate to put your name in front of a hiring manager?

None of that is about whether your work is good. It’s about whether your portfolio makes it easy to say yes on their behalf.

The design review comes second, once you’ve cleared that first gate. That’s where craft, solutions, and depth actually get evaluated; where a design lead reads the case study the way you hoped everyone would from the start. Most portfolio advice online is written entirely for this second audience. It skips the gate you have to clear first.

I build my own case studies knowing both readers are coming. The opening line of each one states the outcome before the process, because that’s what survives a ten-second scan. The presentation structure I use in interviews follows the same logic: problem and outcome up front, tactics and evidence for whoever sticks around.

Once you clear the recruiter, three different designers are reading you

“A design lead” is doing a lot of work in that last sentence. Clear the recruiter screen and you’re not reading for one type of design lead. You’re reading for three, and each one is running a check the other two don’t care about.

The first is the technical designer. They’re not reading your case study yet. They’re testing the portfolio itself the way they’d test a shipped product: does the layout hold at a 375px viewport, is the spacing scale actually a scale or just whatever felt right in the moment, did somebody forget to compress that hero image before it shipped. This reader can tell you’re a strong storyteller and still hesitate, because the site itself reads unfinished.

The second is the senior designer, and this is the reader the rest of this piece is written for. Storytelling and case study depth come before anything else for them, and the next section walks through the five specific things I’m checking when I’m the one in that seat. Craft still matters to this reader. It’s just not the first thing they’re checking.

The third is the designer who’s already opened two hundred portfolios that hiring season and is reading yours to answer one question: is there a reason to remember this. Competence isn’t the bar by the time a portfolio reaches this reader; most of what survives the first two checks is competent. The bar is whether yours reads as a specific person with a specific point of view, or as the fortieth portfolio built from the same three-act structure and the same stock photo of someone pointing at a whiteboard. Sameness is what this reader is actually screening against, not skill.

I’m describing these as three separate people because that’s how it felt from inside the hiring loops I’ve sat in, not because a company always assigns three separate reviewers to your file. Sometimes it’s one person running all three checks in a single sitting. But the checks stay separate, and a portfolio that only passes one of them doesn’t make it through. A technical designer forgives thin storytelling if the craft holds up. A senior designer forgives a rough mobile breakpoint if the case study earns its place. Neither forgives sameness.

The five things I check once as a designer, not a recruiter

By the time a portfolio survives the recruiter’s screen, it lands with someone like me: a designer inside a hiring loop, sitting with three or four tabs open before a Monday debrief. I’ve sat through enough of these now, across enough hiring pushes, that it doesn’t feel like reading anymore. It’s five checks, run in roughly this order, whether I mean to or not.

The first is whether the case study shows a problem becoming a solution. Not a mood board. Not a list of deliverables dressed up as a narrative. I want to see the moment the problem got named, before the screens show up, and I want the decision that follows to trace back to it. If I can’t restate the problem in one sentence by the end, the structure failed no matter how the final work looks.

The second is whether the portfolio tells me who this designer is, across projects, not just within one. A single strong case study proves you can execute. Three of them with no throughline connecting how you think or what you care about just prove you can execute three times. I’m reading for a point of view that survives contact with more than one project.

The third is whether I can tell, right away, what type of designer I’m looking at. Product-minded or brand-minded. Zero-to-one or scaled systems. Research-heavy or execution-heavy. I don’t need every box checked. I need enough signal that I’m not guessing which req to file you under. Portfolios that read as generically competent at everything usually read as strong at nothing.

The fourth is whether it holds my attention past the first case study. This is the one skill I can’t teach in a blog post. Pacing, the willingness to cut a paragraph that isn’t earning its place, images that carry information instead of decorating the page. A portfolio that’s technically well-organized but a slog to read loses to one that’s a little rougher and genuinely engaging.

The fifth is whether there are strong opinions anywhere in the case studies. A designer who tells me what they’d do differently, what they pushed back on, what they think the industry gets wrong, is showing me judgment. A designer who narrates events without ever taking a position is showing me a diary. I’m hiring for the former.

None of these five are about visual polish. They’re about whether I can tell, from the outside, that a real person made real decisions and would defend them.

The two things that kill a case study before I finish reading it

Vague ownership, and talking about the “process” instead of the outcome. I see both constantly, and they’re the fastest way to make me close a tab.

“We redesigned the onboarding flow.” “Our team ran a round of usability testing.” “The product saw a lift in retention.” I read sentences like these constantly, and every single one makes me stop and ask the same question: what did you do?

This isn’t about stripping credit from collaborators. Design is a team sport, and a case study that pretends otherwise reads as either naive or dishonest. But there’s a real difference between “the team did X” and “I did X, as part of a team that also did Y and Z.” A reviewer can’t credit you for a decision they can’t find. If I can’t tell whether you ran the usability test, synthesized it, or just sat in on it, I have to assume the least, because that’s the safe read.

The fix isn’t complicated. Name your specific contribution in the first sentence of each section: the research question you framed, the flow you redesigned, the metric you moved. Then talk about the team. It costs you nothing to be specific, and specificity is the entire signal a stranger has to work with.

Vague (avoid)	Specific (use instead)
“We redesigned the onboarding flow."	"I redesigned the account-setup step after it showed the highest drop-off in the funnel."
"Our team ran a round of usability testing."	"I moderated five usability sessions and wrote the synthesis; two other designers observed."
"The product saw a lift in retention."	"The change I shipped moved 30-day retention from 41% to 53%."
"We explored several directions."	"I designed three directions, the team picked one, and I built it out."
"Collaborated with stakeholders on the strategy."	"I pushed back on the stakeholder’s request to keep the paywall above the fold and won.”

Designers who talk about process instead of outcome are just as easy to lose. A case study that reads like a diary of what happened, without ever naming the number that mattered, is a case study that doesn’t earn a second read. I don’t care how many rounds of testing you ran if you can’t tell me what changed because of them. I don’t care how many flows you redesigned if you can’t tell me which one actually shipped and what it did for the business. I don’t care how many stakeholders you talked to if you can’t tell me what decision you made that they didn’t want.

What actually earns a second read

A number. A decision. A trade-off you’d make differently.

Outcomes are what make a case study memorable instead of generic. Cutting a patient scheduling flow’s completion time in half, or turning a subscription cancellation flow into a retention driver that saved real revenue, tells me something a paragraph of process description never will. It tells me you know what mattered and you can prove you moved it. I hold my own case studies to that bar. If I can’t name the number, I go find it before I publish.

But the number alone isn’t what makes a portfolio trustworthy. What makes it trustworthy is a visible trade-off. Every real project has one: a constraint you didn’t get to fully solve, a stakeholder who wanted something you talked them out of, a version one that shipped worse than you wanted because the timeline didn’t allow for better. A portfolio with zero visible friction anywhere doesn’t read as accomplished. It reads as edited.

The designers who tell me what went sideways, and what they’d do differently next time, are the ones I remember a week later.

You cannot fake a trade-off you never named. You cannot manufacture specificity after the fact with better adjectives. You can only go back into the project and find the actual decision, the actual number, the actual thing you’d change, and put it on the page.

Reflective Coda

If I could leave one note on every portfolio I’ve ever screened, it wouldn’t be about typography or case study count. It would be this: I am not looking for a flawless project. I have never once believed a flawless project was real. I am looking for evidence that you can think clearly about your own work, own the parts that didn’t go the way you planned, and tell me what you learned from it.

That’s a lower bar than most designers think, and a harder one than most designers clear. Polish is available to anyone with enough time and a template. Clarity about what you actually did, and honesty about what you’d change, isn’t something you can buy. It’s the one thing a reviewer can’t get anywhere else but from you.

The fastest way to lose me is still a homepage that makes me guess what you do. But the fastest way to win me was never a perfect portfolio. It’s a case study that names its number, owns its trade-off, and trusts me to respect the mess instead of hiding it. If you want a second pair of eyes on whether yours does that, I offer paid portfolio reviews built on exactly this framework.