The designer portfolio case study that wins the job

A product designer we know got rejected from 14 interviews in a row. Her work was good. Her portfolio was beautiful. She was baffled.

We looked at it together. Six case studies. Each one opened with a hero shot of the final product, then scrolled through user flows, wireframes, a moodboard, and finally the shipped screens. Every one was visually polished. Not one of them told us what she actually did.

That's the problem. Hiring managers don't scroll portfolios to admire them. They scroll to answer a single question: can this person think?

What recruiters read in the first 30 seconds

Watch a hiring manager open a designer's portfolio and you'll see a pattern. They don't start at the top. They scan for three things, in this order:

What was the problem. What did the designer specifically do. What changed because of it.

If those three answers aren't visible within half a minute, most hiring managers move on. They have 40 other portfolios open in tabs.

This is why hero shots kill your case study. A gorgeous final screen tells us nothing about the thinking behind it. We've all seen good-looking screens made by bad designers, and great thinking rendered in ugly Figma. The screen is evidence, not argument.

The four-part structure that works

Here's the frame we recommend to every designer who asks. It's not revolutionary. It is relentlessly applied.

One: the business problem, in one paragraph. Not the design problem. The business problem. "Our onboarding drop-off was 62% and the team had tried three redesigns in 18 months." That sentence tells a hiring manager you understood why the work existed. Most portfolios skip this step entirely and jump to user research.

Two: your specific role, in one sentence. "I was the only designer on a team of four engineers and a PM. I owned research, IA, and visual design; a contractor handled illustration." Be boring and precise. Hiring managers are trained to spot vague ownership claims. "I led the redesign" when you had three peers is a tell.

Three: the thinking, not the artifacts. This is where most portfolios go wrong. You don't need to show every sketch and Figma file. You need to show the two or three decisions that mattered, and why you made them.

A good decision slide looks like: "We considered three models for the onboarding — progressive profiling, single form, and a wizard. We picked wizard because our user research showed 70% of users were first-time buyers who needed guidance. Trade-off: more steps, slower completion. We accepted this for a 30% lift in completion quality."

That is senior thinking made visible. One slide like this is worth ten mockups.

Four: the result, with honest numbers. "Drop-off fell from 62% to 34% over six weeks. Activation lift of 21%. The feature shipped in Q2 2025 and is still in use." If you don't have numbers, say what shipped and what the team learned. Never invent metrics. Hiring managers can smell a fake number from across the room.

A concrete example

Here's a stripped-down case study for a fictional project, following the frame:

Problem: A fintech app had a checking account opening flow with 71% drop-off at identity verification. Support tickets cited confusion about document requirements.

My role: Sole designer. I owned research, flow redesign, and visual design across iOS and Android. Worked with one PM and two engineers over seven weeks.

Key decision: The original flow asked for all documents up front. User interviews (n=8) revealed people didn't have their utility bill handy. I proposed splitting the flow into two sessions, letting users save progress and upload later via email. Engineering pushed back on the save-state complexity. I showed them the research clip of a user rage-quitting, and we aligned on a minimum viable save-state for document upload only.

Result: Drop-off at verification fell from 71% to 28% over two months. Support tickets about the flow dropped 80%. The pattern was adopted by two other teams in the company.

Four paragraphs. No hero shot needed. A hiring manager reading that knows more about this designer than they'd learn from 20 screens.

What to cut

Look at your portfolio right now. For each case study, ask:

Could I cut the moodboard slide and lose nothing? (Yes.) Could I cut the user persona card and lose nothing? (Almost always.) Could I cut three of the five wireframe variations? (Yes.)

Every slide that doesn't show your thinking or your impact is a slide that hides your thinking and your impact. Less is more, but only when the less is the right less.

Takeaway

Your portfolio isn't a gallery. It's a written argument that you're worth hiring. Structure each case study around the business problem, your specific role, the two or three decisions that mattered, and what changed. Cut everything else. The designers who do this get interviews. The ones who pile up pretty screens keep wondering why they don't.