Your Portfolio Doesn't Need Ten Case Studies, It Needs Three Good Ones

A portfolio built around ten case studies, each covering a project in the same shallow amount of detail, quietly hands the reviewer a job they didn't ask for: figuring out which of the ten actually matters. Most reviewers won't do that job. They'll skim the first two, form an impression from those, and treat the remaining eight as background noise that confirms whatever conclusion the first two already produced. Volume, in other words, doesn't multiply the impression a portfolio makes. It just adds more material that the reviewer will mostly never reach.

There's a subtler cost to this beyond wasted reviewer attention: a portfolio with ten shallow entries often reads, fairly or not, as evidence that the person who built it hasn't exercised much judgment about their own work. Including everything is easier than deciding what's actually worth showing, and reviewers notice the difference between a portfolio that was curated with a point of view and one that was simply accumulated over time, project after project, without much editing along the way. The instinct to leave nothing out is understandable. It rarely serves the person who has it.

Three case studies, done properly, means something specific: each one actually walks through the messy real process - the constraints that shaped the work, the direction that didn't pan out, the reasoning that led to the final decision - rather than presenting a clean before-and-after with the reasoning quietly edited out. That's a meaningfully different document from the convention a lot of portfolios default to, which tends to show a tidy initial problem statement followed immediately by a polished final solution, with everything that happened in between compressed into a single vague sentence about 'iterating based on feedback.'

Picture two versions of the same underlying project. The shallow version shows the final polished flow, a couple of supporting screens, and a metric that improved. The deep version walks through an initial direction that seemed promising and turned out to be wrong, explains specifically why it didn't work, describes a real tradeoff weighed against stakeholders who wanted something different, and lands on the final direction with an actual argument for why it beat a real alternative rather than just being the one that happened to ship. The underlying project might be identical. What a reviewer learns about the designer from each version is not.

The core thing this reframes is what a case study is actually supposed to prove. It isn't proving that the outcome was good - plenty of good outcomes happen for reasons that have very little to do with the designer's process: favorable timing, a market tailwind, a competitor stumbling, an engineering team that happened to execute flawlessly regardless of the spec's quality. A case study's real job is proving that the process that led to the outcome was sound, and specifically that it would likely produce good decisions again on a completely different problem, under different constraints, with different unknowns.

This is exactly the signal a hiring team actually needs, and it's worth being explicit about why. The specific project in a portfolio will almost never be the specific project a new hire faces on the job - the domain will differ, the constraints will differ, the stakeholders will be different people entirely. What transfers from a portfolio project to a new job isn't the solution. It's the judgment behind how the solution got made. A case study that only shows the polished outcome gives a reviewer no way to evaluate the one thing that will actually matter once the hire starts.

A fair pushback: doesn't a strong outcome or a good metric matter at all, then? It does - it's real supporting evidence, and nobody's arguing outcomes are irrelevant. But a good outcome sitting on top of a thin, unexamined process is a weaker signal than the same good outcome sitting on top of a process that's been honestly and specifically walked through. A detailed process section usually makes it fairly easy to tell the difference between a result that reflects sound judgment and one that reflects a lucky bounce, and reviewers who've seen enough portfolios get reasonably good at spotting which is which.

In practice, this means being willing to write about a genuine wrong turn without spinning it into something embarrassing to hide. Describing why an initial direction seemed right, what specifically revealed it wasn't, and what changed as a result isn't a liability in a case study - it's frequently the most convincing part of one, because it's the section that's hardest to fake and most directly answers the question a reviewer actually has: how does this person think when their first idea doesn't work.

This also implies a fairly clean selection criterion for what belongs in a portfolio at all: if a project doesn't have an interesting decision buried somewhere in it - a real tradeoff, a wrong turn worth explaining, a constraint that forced a genuinely hard call - it probably doesn't belong in the portfolio, no matter how polished the final visuals turned out to be. A beautifully executed project with no interesting decision to walk through mostly just demonstrates craft, which is necessary but, on its own, no longer differentiates much at this point in the review.

The resistance to this usually comes from two places: reluctance to leave out work that took real time and effort to produce, and a nagging worry that three case studies will look thin next to a competitor's ten. Both worries get the actual dynamic backwards. Cutting a project that took a long time doesn't erase the effort that went into it - it just keeps it out of the one document where it would otherwise dilute the stronger work sitting next to it. And thinness isn't really about count; a portfolio of three case studies that each demonstrate real judgment reads as more substantial, not less, than ten that don't.

It's worth being clear that three is a direction, not a rule carved in stone - a portfolio with two genuinely strong, deeply told case studies is stronger than one padded to three with a weaker third project just to hit a round number, and someone with four excellent stories shouldn't cut a good one purely for symmetry. The number matters less than the standard behind it: every project included should earn its place on the strength of the decision it lets a reviewer see, and the count should follow from how many projects actually clear that bar, not the other way around.

A portfolio isn't an archive of everything a designer has ever produced, and treating it like one is the root of most of these problems. It's an argument, made through a small number of carefully chosen examples, about how a specific person thinks through a hard problem when the answer isn't obvious in advance. Every case study included should be doing work in service of that argument. The ones that are just there because they exist, however polished, are worth cutting - not because the work was bad, but because a stronger, tighter argument is worth more than a longer inventory.