What Actually Happens in a Design Portfolio Review

Most design hiring managers spend somewhere between three and eight minutes on a first pass through a portfolio -- not the thirty or forty minutes candidates imagine while building it. That gap between expected and actual attention explains why so many strong portfolios fail to land interviews: they're built for a careful reader who doesn't exist at the first-pass stage.

The Real Time Budget

In that first pass, a reviewer is scanning for two things: is this person's work at the level the role requires, and is there anything specific enough to be worth a longer look later. That means the first thirty seconds of your portfolio -- the homepage or the top of your first case study -- carries a disproportionate amount of weight. If a reviewer can't tell what you actually did on a project within the first two lines of a case study, most will move to the next portfolio in the stack rather than dig for it.

Pick Three Projects, Not Ten

A portfolio with ten thin projects reads as less impressive than one with three deep ones, almost universally. Reviewers extrapolate: if you can walk through three projects in real depth -- the constraints, the decisions you made and why, what you'd do differently now -- that depth implies competence across the rest of your work too. Ten shallow projects imply the opposite: that depth isn't something you're used to producing, even if that's not actually true. If you have more than three or four strong projects, pick the ones most relevant to the specific role, not simply your favorites or most recent.

Show the Process, Not Just the Polish

The single biggest gap between junior and senior-reading portfolios is process visibility. A junior portfolio often shows only the final polished screens. A senior-reading portfolio shows the messy middle: three early sketches that didn't work and why, a user research finding that changed the direction, a specific tradeoff between two options and the reasoning behind the choice made. Reviewers are hiring for judgment, and judgment is only visible in the decisions, not in the final artifact. If your case study is entirely "here's the before, here's the after, users loved it," add back in the reasoning that got you from one to the other -- that's the part actually being evaluated.

Include at least one project where the outcome wasn't a clean win. A case study that says "we shipped this, it didn't move the metric we expected, and here's what we learned and changed" reads as more senior than a portfolio full of unambiguous successes, because it shows how you handle the far more common real-world case of an ambiguous result.

The Questions Reviewers Are Actually Asking

Underneath the specific feedback, most reviewers are quietly checking for the same handful of things on every project: did this person work within real constraints (a deadline, a legacy system, limited engineering resources) or only on greenfield ideal conditions; can they explain a decision in terms of tradeoffs rather than just taste; did they collaborate with other functions or work in isolation; and is there any evidence the work actually shipped and had an effect, however modest. You don't need to state these explicitly, but structuring each case study to answer all four, even briefly, will cover what most reviewers are scanning for whether or not they'd phrase it that way themselves.

A portfolio doesn't need to be exhaustive to work. It needs three projects that can survive a follow-up question, because the follow-up question -- not the initial scroll -- is where most hiring decisions actually get made.