I spent a Saturday last spring reviewing 40 portfolios for a mid-level product design opening. By the twelfth one, I had a system: open, scroll for ten seconds, decide. Thirty-one never made it past those ten seconds, not because the work was bad, but because I couldn't tell what problem any of it solved. If your portfolio has to sell something, the pricing page layouts guide covers the section that decides it.
That stack taught me more about hiring than three years on the other side of the table ever did.
TL;DR: Hiring managers increasingly expect AI fluency as a baseline (73% see growing need for it in candidates, Figma 2026), which means polished mockups alone no longer catch anyone's eye. What separates a callback from a rejection is process: fewer case studies, shown deeper, with a stated problem and outcome.
How Many Case Studies Does a Portfolio Actually Need?
Three to five. That's it. I know that feels thin if you've been told to "show range," but range is exactly what gets you rejected in ten seconds. A reviewer scanning twelve thumbnails can't tell a strong project from a filler one until they click in, and by then they've already formed an opinion about your judgment from the sheer number of tiles.
Fewer projects, built out properly, does two things a big grid never does. It signals you know which of your own work is actually worth showing, and it gives the reviewer enough to evaluate instead of forcing them to guess from a caption. I've cut a portfolio from nine projects to four and gotten more interview requests the following month, not fewer. A hiring manager with limited time per applicant will always reward depth they can verify over breadth they have to take on faith.
What Does a Strong Case Study Structure Look Like?
Problem, process, decisions, outcome, in that order, no exceptions. Skip the problem statement and your process reads as arbitrary. Skip the decisions and it reads as luck. Skip the outcome and the whole thing reads as an exercise, not real work.
Concretely:
- Problem: one or two sentences, plain language, no jargon. What was broken and for whom?
- Process: the messy middle. Sketches that got rejected, a research finding that changed direction, a stakeholder pushback you had to work through. This is the part most portfolios skip entirely, and it's the part that actually proves you can design under real constraints.
- Decisions: why this layout and not the other three you tried. What tradeoff did you accept, and why was it the right one given the constraints you had?
- Outcome: a number if you have one, a qualitative result if you don't. "Reduced onboarding drop-off by 18%" beats "the client was happy" every time, but even "usability testing showed users completed the task twice as fast" is worth stating plainly.
If you're also pricing your freelance work off the back of a stronger portfolio, the freelance rate guide is worth a read; designers who can point to a stated outcome consistently price higher than those who can't back a number with a case study.
| Section | What it covers | Why skipping it hurts |
|---|---|---|
| Problem | One or two plain-language sentences on what was broken and for whom | Without it, your process reads as arbitrary |
| Process | The messy middle: rejected sketches, research that changed direction, stakeholder pushback | Most portfolios skip this, and it's the part that proves real design work |
| Decisions | Why this layout and not the other three, and what tradeoff you accepted | Without it, your outcome reads as luck |
| Outcome | A number if you have one, a qualitative result if you don't | Without it, the whole case study reads as an exercise |
What Gets a Portfolio Rejected Within Seconds?
Three things, repeatedly, across every stack I've reviewed. A homepage with no clear read on what you do, which forces a reviewer to hunt instead of scan. Case studies opening with a finished screen and zero context, which reads as a gallery, not a body of work. And typos or broken links in the first paragraph, which quietly signals the rest wasn't checked either.
None of these are skill problems. They're editing problems, fixable in an afternoon without redesigning a single screen.
Has AI Changed What Actually Gets Noticed in a Portfolio?
Yes, and not in the direction most people assume. Anyone can generate a clean mockup in minutes now, so a polished screen by itself carries less signal than it did three years ago. What can't be generated as easily is the reasoning behind it: why you rejected the obvious layout, what a testing session revealed, how you argued for a decision a stakeholder initially pushed back on.
Figma's 2026 hiring research backs this up directly: 73% of hiring managers say they see a growing need for AI tool proficiency in candidates, and 56% report rising demand specifically for senior hires who can direct that tooling with judgment, versus just 25% hiring for junior roles where that judgment is still being built (Figma, 2026). Read that carefully and the message isn't "learn the tools." It's "the tools are assumed, so show me what you bring on top of them."
Don't hide your AI use, either. If a generative tool helped you iterate faster, say so, then spend the case study on which variation you picked and why. That's the part a tool still can't do for you.
Should You Rebuild Your Whole Portfolio or Just Fix What's There?
Fix what's there, almost always. A full rebuild is the move people reach for when they're avoiding the harder task: rewriting the text around work they've already done. I've seen designers spend six weekends redoing a site's visuals when the real blocker was that no case study stated a problem in its first sentence.
Start smaller. Pick your three strongest projects and write one sentence per project stating the outcome, then see how that single change reads before touching anything else. Is your best work visible on the first screen a reviewer sees, or buried behind two weaker projects kept out of habit? That question alone reorders most portfolios for the better, and it costs an afternoon, not a rebuild.
