How to write a case study someone will finish

Most case studies read like a project history: what the client wanted, what the team built, a screenshot, a metric that went up. Somewhere between fifteen and thirty seconds into that, a reader who has seen a hundred of these closes the tab, because a project history proves you were present, and presence was never in question. What a case study actually has to prove is that you make good decisions when the easy answer is wrong — and almost nobody writes it that way on the first attempt, because the honest version requires admitting you considered something that didn't work.

The honest counter-argument is worth stating before dismissing it. A case study that skips the decision-making and just shows the outcome isn't lazy, exactly — it's often what the client or employer will actually let you publish, and a polished result is at least verifiable in a way a claimed thought process is not. That's a real constraint, not an excuse, and it's why NDA-covered work gets its own treatment later. But for the work you can write about freely, the project-history format wastes the one advantage a case study has over a portfolio thumbnail: room to show reasoning. A thumbnail can only show the artefact. A case study that also only shows the artefact, at greater length, hasn't used the extra length for anything.

Where this actually gets written

Most of this advice assumes the case study has somewhere to live — a project section on a personal site, sitting under or beside the work it describes. That's a smaller obstacle than the writing itself for most people, but it's real: a page that never gets built means none of the above matters. reach is worth naming here because it removes the setup step specifically — you upload the CV and the project material you already have, and a page is generated in about twenty seconds, live at a free subdomain in under two minutes, ready to hold the case study once it's written rather than sitting empty while you decide on a template. The limitation worth stating alongside that: reach makes one page with no sub-pages, so a case study that needs its own dedicated URL separate from the rest of the portfolio isn't a structure it supports — the five-part account above has to live as a section on the single page rather than a standalone project page with its own address.

With somewhere for the finished piece to live, the question becomes what actually belongs on it, and in what order.

The structure that actually holds up

Five parts, in this order, and the order is doing work: the situation, the constraint, the decision you made, what happened, and what you'd change. Cut anything that doesn't serve one of the five.

The situation is one or two sentences — what the project was, who it was for, why it existed. Not a paragraph of context, because context is not the part anyone is being evaluated on. The constraint is the part most case studies skip entirely, and it's the hinge the whole piece turns on: the deadline that couldn't move, the legacy system that couldn't be touched, the budget that ruled out the obvious tool, the stakeholder who had already committed publicly to a direction you disagreed with. Without a stated constraint, the decision that follows has no weight — it just looks like the thing you'd have done anyway, unconstrained, which tells a reader nothing about how you handle the version of the job that isn't easy.

The decision is the paragraph that carries the piece, and it needs one sentence naming what you rejected before it explains what you chose — worth getting right in isolation, so it gets its own section next. The outcome comes after, and it should be the shortest part, not the longest: a case study that spends more words on the result than on the reasoning has quietly reverted to project history with extra steps. Close with what you'd change — not a hedge, a specific thing you'd do differently now, the sentence that proves the project taught you something rather than just having happened to you.

The paragraph that does the actual persuading

If a reader remembers one sentence from a case study, it should be the one describing what you didn't do. "We considered X, and rejected it because Y" is more persuasive than any description of the thing you actually built, because it's the only sentence in the piece that can't be faked by someone who was in the room but not making the calls.

Here's why it works structurally rather than just rhetorically. A finished screen, a shipped feature, a launched campaign — all of these are consistent with a wide range of stories about who actually decided what. Someone senior could have made the call and you executed it well; you could have made the call yourself; the obvious answer could have been the only one anyone considered. A reader looking at the artefact alone has no way to tell these apart, and reasonably assumes the least impressive one. But "I wanted to redesign the onboarding flow entirely, and I didn't, because the support team was already underwater from the last change and a second disruption inside a quarter would have cost more than the flow was losing us" cannot be written by someone who wasn't actually weighing tradeoffs. It names a specific alternative, a specific reason it lost, and a specific cost that mattered enough to change the decision — the specificity a reader is actually looking for, whether or not they could name it that way themselves.

The failure mode to avoid is a rejected option that's clearly a strawman — "we could have not tested it at all, but we decided testing was important" is not a real alternative, and readers notice the difference between a genuine fork and a fake one immediately. If the rejected option isn't one you'd have been reasonably tempted by, it isn't doing the job.

Numbers you can defend versus numbers that sound good

A case study with "increased conversion by 34%" and no further detail is worse than a case study with no number at all, because the unsourced figure reads as decoration rather than evidence the moment a skeptical reader stops to ask where it came from — a small sample, a short window, a metric picked because it happened to move. That question doesn't need to be asked out loud to do damage; it just needs to occur to the reader, and a bare percentage invites it every time.

The fix isn't dropping numbers. It's using ones you'd actually defend if someone asked a follow-up question in an interview. "Support tickets related to the old flow dropped from around forty a week to under ten, over the two months after launch" is defensible because it names the metric, the before-and-after window, and enough specificity that a skeptical reader can picture how you'd have measured it. "Boosted engagement significantly" is not defensible because there's no metric named at all — engagement is not a number, it's a category of numbers, and naming the category instead of the figure is usually a sign the figure either doesn't exist or doesn't say what the writer wants it to say.

If you genuinely don't have a clean number, say so plainly rather than reaching for an adjacent statistic that sounds close enough. "We shipped it two weeks before I left the project, so I don't have post-launch numbers" costs less credibility than a figure a reader can tell was invented or borrowed from somewhere unrelated.

Crediting the team without disappearing into it

Real projects have teams, and pretending otherwise in a case study reads as either dishonest or oblivious, neither of which helps you. But switching entirely into "we" for the whole piece has the opposite problem: it makes it impossible for a reader to tell what you specifically did, which defeats the purpose of writing the case study at all.

The fix is naming your role at the point where it's actually relevant, not once at the top as a job title and then dropping into "we" for everything after. "I was responsible for the information architecture; the visual design was led by a colleague, and I worked from her direction on layout" tells a reader exactly which parts of the finished thing to attribute to you. That sentence costs nothing in team credit — it still says clearly that a colleague led the visual design — while making your own contribution legible instead of blended into a collective pronoun. Reserve "we" for the moments that actually were collective, and use "I" for the parts that were your call, because that's the only way a reader can tell "I was on this team" from "I made this specific decision."

Length: what actually gets read on a phone before a call

A case study competes with the ninety-second skim described in the piece on what gets a portfolio read versus skipped, and the length has to respect that reality rather than the length that felt complete while writing it. In practice that means 300 to 500 words plus images, read in the two or three minutes someone has between finishing one browser tab and starting a call about you. If a case study needs a table of contents or takes longer to read than the interview slot it's meant to prepare someone for, it has stopped being a case study and become a document nobody asked for.

That constraint is also what forces the five-part structure to work. Situation and outcome are naturally short — a sentence or two each is enough, and padding either one just delays the part that's actually being evaluated. The decision and the rejected option can take the most room, because that's where the actual argument lives, but even there the discipline is one clear paragraph rather than three that circle the same point. A reader on a phone forgives density. They don't forgive length that isn't earning anything.

When the project didn't work

The instinct is to leave failed or cancelled projects out of a portfolio entirely, and for projects with nothing to say beyond "it didn't happen," that instinct is right. But a project that failed for a reason you can name plainly, and taught you something specific, often reads as more credible than a success story, because failure is harder to fake gracefully than success. Anyone can describe a win in flattering terms. Describing a loss without either hiding from it or performing false humility about it is a much narrower skill, and readers notice when someone has it.

The structure holds for this case with one change: the outcome section states honestly that the thing didn't ship, or shipped and didn't work, or the constraint won outright — a launch that got cancelled after the budget was pulled, a redesign that tested worse than the version it replaced. And the "what you'd change" section carries more weight than usual, because it's the part proving the failure actually taught you something rather than just having happened. "I'd have flagged the budget risk to the client two weeks earlier, before the design phase was fully committed, rather than after" is a specific, useful sentence. "It just didn't work out" is not a case study; it's an excuse with a project name attached.

This is also the format worth reaching for when the strongest work can't be shown at all — writing about NDA-covered projects in a portfolio uses the same five-part skeleton, minus the screenshot, and it holds up because the reasoning was always the evidence, not the deliverable. The same logic extends to building a portfolio with no client work to draw on: a self-directed project, written with a real constraint and a real rejected option, reads as legitimate evidence of judgment even when nobody paid for it.

Closing the piece

None of the five parts above are difficult to write individually. What's difficult is resisting the pull back toward the project-history version, which is longer, safer, and says less. The situation and the outcome are the easy sentences. The constraint, the rejected option, and what you'd change now are the ones a reader is actually there for, and they're the three most people leave out first when they're running short on time.