How to Write a Portfolio Case Study (With a Six-Part Template)

Ask a freelancer why they have not written a case study and you get one of three answers: they do not have time, they do not have permission, or they do not know what goes in one. The third is the real blocker, and it is the easiest to fix.

A case study is not a project description with more words. It is a specific argument — here is a problem that looked like yours, here is how I thought about it, here is what happened — and it is the single highest-converting page most freelance portfolios can have. It is also the page almost nobody writes, which is precisely why writing one moves you ahead of the field.

This guide gives you a six-part skeleton with word budgets, shows the sentence-level difference between describing activity and presenting evidence, and covers the two things that stop people finishing: missing numbers and NDAs.

What a case study is for

A project card answers "can you do this kind of work". A case study answers a different and more valuable question: "what will it be like to have you working on my problem?"

That distinction drives every decision below. The reader is not evaluating the finished artefact — they can already see that in the screenshot. They are evaluating your judgement: whether you understood what was actually wrong, whether you chose sensibly under constraint, and whether you are honest about how it went.

Which means the interesting content is not the outcome. It is the decisions. A case study where everything went smoothly and the client was delighted is a brochure. A case study where you explain the trade-off you were unsure about is a demonstration of expertise.

The six-part skeleton

Use this structure. It maps onto how the reader wants to receive the information, and the word budgets keep you out of the two failure modes — the two-paragraph summary that proves nothing, and the four-thousand-word design epic nobody finishes.

Roughly 700 to 1,100 words in total. Long enough to be evidence, short enough to be read.

1. Context — 60 to 90 words

Client, sector, your role, timeframe, team size. Four lines, delivered flatly, no scene-setting. Role and team size carry most of the weight in the disciplines where everything is delivered collectively — it is the line an architecture portfolio is most often caught out on, because a spread with no credit reads as a claim to the whole project.

Resist the urge to open with atmosphere. "In the summer of 2025, a small team with a big dream approached me…" costs the reader attention they were going to spend on your thinking. Say who, what and when, then move.

2. The problem — 100 to 150 words

State what was broken in the client's own terms, then add the constraint you were working inside.

The constraint is what most people leave out, and it is what makes the rest of the case study legible. "Rebuild the checkout" is a task. "Rebuild the checkout without touching the payment provider, in three weeks, before Black Friday" is a problem — and every decision you made afterwards now has a reason a reader can evaluate.

3. What you did — 250 to 400 words

The two or three moves that actually mattered. Not a chronology.

The strongest instinct to resist here is completeness. You did forty things; three of them changed the outcome. Writing all forty buries the three. If a step could be removed without changing the result, remove it from the write-up.

Include artefacts where they add information — a before-and-after pair, a diagram, a snippet of the schema. Where the change is physical the pairing carries almost the whole argument, which is why it is the backbone of an interior design portfolio. Skip the artefacts that only demonstrate that you followed a process. Nobody has ever been hired on the strength of a photograph of sticky notes.

4. The hard decision — 150 to 250 words

This is the section that gets you hired, and the one most people skip.

Pick the choice you were least certain about. Name the options you were weighing, the constraint that made it difficult, what you chose, and why. If you got it wrong, say so and say what you did about it.

This works because it is unfakeable. Anyone can claim a good outcome; only someone who was there can describe the fork in the road convincingly. It is also the closest a reader can get to sitting in a meeting with you, which is exactly what they are trying to imagine.

5. The outcome — 80 to 120 words

A number if you have one. A named quote if you do not. Something concrete either way.

Be honest about attribution. "Sign-ups rose 24% in the quarter after launch, alongside a paid campaign that started the same month" is more credible than a bare "sign-ups rose 24%", not less — because it shows you understand what your work can and cannot claim credit for. Readers who have been burned by consultants notice this immediately.

6. What you would change — 40 to 60 words

One honest sentence about what you would do differently.

Every experienced person has this. Including it signals that you evaluate your own work, which is a thing clients desperately want and can rarely verify in advance. Keep it short and specific — "I would have tested the empty state with real users before building it" — and do not turn it into false modesty.

Turning activity into evidence

Most weak case studies are not badly structured. They are structured correctly and written vaguely. The fix happens at sentence level.

Left column: what you did. Right column: why it mattered and what changed.

The test is simple. Read a sentence and ask: could another freelancer have written this about a different project? If yes, it is doing no work. "I redesigned the checkout flow" passes that test — thousands of people could write it. "Checkout was losing people at the address step, so I cut it from four fields to two and moved payment first" could only be written about one project by one person.

Three reliable ways to get specific:

• Name the number. Fields removed, seconds saved, tickets avoided, percentage moved.
• Name the alternative you rejected. "We considered a third-party widget, but it would have taken the user off-domain mid-payment."
• Quote someone. A real sentence from a real client, attributed, beats any adjective you could write about yourself.

When you do not have numbers

This stops more case studies than NDAs do. The client never shared analytics, or the project was a rebrand, or you shipped and moved on. Three honest routes out:

Ask, even now. A short email — "I'm writing up our project, do you have the before-and-after numbers for the booking flow?" — succeeds more often than people expect. Clients generally like being written about, and it is a low-cost way to reopen a conversation with a past client.

Use the numbers you do control. You may not know revenue, but you know the build: eleven fields became four, page weight fell from 4.2 MB to 900 KB, the deploy that took forty minutes takes six. These are real, verifiable and yours to publish.

Use a qualitative outcome, attributed. "The support team stopped receiving questions about the returns policy" is a genuine result. Get the client to say it in their own words and quote them.

What you must not do is invent a plausible-looking percentage. Beyond the obvious problem, invented numbers have a tell — they are round, unattributed, and uniformly flattering — and any reader who has commissioned work before is calibrated to spot them.

What to do about NDAs

Confidentiality restricts what you can name, rarely what you can discuss. Most of a case study's value survives anonymisation, because the value was in the reasoning.

• Anonymise the client by sector and size: "a mid-size logistics company", "a Series A healthtech startup".
• Describe the problem structurally rather than showing the interface. You can explain a broken onboarding flow without a single screenshot.
• Redact or rebuild visuals. Blur real data, or redraw the layout with placeholder content.
• Ask. A surprising number of clients will say yes to being named if you show them the draft. Ask after a successful delivery, and put the request in writing.

Check the actual contract rather than assuming. Some NDAs restrict only specific technical details; some prohibit naming the client but permit describing the work; a few prohibit everything. Knowing which one you signed takes five minutes and decides how you write.

How many do you need?

One good one beats three thin ones, and one is enough to change how your portfolio performs. If you write more, make them cover different kinds of problem rather than three variations of the same job — the point of a second case study is to widen the range of clients who can see themselves in your work.

Two or three is a comfortable ceiling for most freelancers. Past that you are maintaining a library.

How to interview yourself when you cannot remember the details

Most case studies are written months after the project ended, by which point the specifics have gone soft. The details are recoverable, and it takes about half an hour with the right prompts.

Start with the artefacts rather than your memory. Search your email for the client's name and read the first week of the thread — the original brief is almost always in there, in the client's own words, which is exactly what section two needs. Then read the last week, where the outcome usually surfaces. If it was a code project, skim the commit history and the pull request discussions; arguments in PR comments are where the interesting decisions live. For design work, open the version history in Figma and look for the point where the direction changed.

Then answer these six questions in writing, quickly, without editing:

• What did the client say was wrong, in their words, before you knew anything?
• What turned out to be actually wrong?
• What could you not change — budget, timeline, an existing system, a person?
• What was the moment you were least sure what to do?
• What did you do instead of the obvious thing, and why?
• What do you know now that you did not know then?

Question two is the one that usually produces the case study's spine, because the gap between the stated problem and the real problem is the demonstration of expertise. Question four produces section four, which is the part that gets you hired. Those six answers are also exactly what a drafting tool needs: our portfolio content generator turns notes of that shape into a problem, approach and outcome draft you can then cut back.

A worked example

Here is the skeleton filled in, compressed. The project is invented, but the shape is the point.

Context. Ledgerly, a six-person B2B invoicing startup. I was the sole designer, working three days a week for seven weeks alongside two in-house engineers. Engaged in March 2026 to fix onboarding before a funding round.

The problem. The team's framing was "our onboarding is confusing". The data said something narrower: 62% of signups completed account creation, and 19% ever sent an invoice. Everyone was getting in; almost nobody was reaching the point where the product did anything for them. The constraint was that the accounting integrations could not be touched — they were mid-certification with two providers, and any change would have restarted a six-week review.

What I did. Three things mattered. I watched six new users attempt their first invoice on a call, which surfaced that the blocker was not the form but the empty state: users landed on a dashboard with nothing on it and no indication of what to do next. I replaced the empty dashboard with a single prompt to create one invoice, using their own company details pre-filled from signup. And I deferred the integrations setup — previously step two — to after the first invoice was sent, which was possible without touching the integration code itself because it only changed when the setup screen was shown.

The hard decision. The obvious move was to build a guided multi-step wizard, which the founders wanted and which is what competitors do. I argued against it. A wizard would have taken most of the seven weeks, and it optimises for users who need hand-holding through a complex setup — but our recordings showed the opposite problem: users understood invoicing perfectly, they just did not know the product was ready for them. A wizard would have added ceremony to a product whose issue was ceremony. I proposed the single-prompt empty state instead and asked for two weeks to test it before committing to the larger build. If it had not moved the number, we would have had five weeks left to build the wizard. It is the decision I would most want to be judged on, because it was the one where I was least confident.

The outcome. First-invoice completion went from 19% to 44% over the six weeks after launch. The company was also running a new onboarding email sequence during that period, so the redesign does not own all of that movement. The founder's summary: "We stopped losing people in the gap between signing up and understanding what we do."

What I would change. I would have run the six user calls in week one instead of week three. Two of the assumptions I spent the first fortnight designing around did not survive the first conversation.

That is roughly 480 words — shorter than the budget, because a compressed example is easier to read than a full one. Notice what is doing the work: the gap between the stated problem and the real one, a named constraint, a rejected alternative with a reason, an honestly attributed number, and one regret.

Formatting for people who skim

Assume the reader will skim first and read properly only if the skim rewards them.

• Put the outcome near the top. A one-line summary under the title — problem, action, result — lets a skimmer get the whole argument in five seconds and decide to read on.
• Use descriptive subheadings. "Cutting the form from eleven fields to four" tells a skimmer something; "Design phase" does not.
• Keep paragraphs to three or four lines. Dense blocks get skipped on phones regardless of what is in them.
• Caption every image with what it shows and why it is there. Captions are read far more than body text.
• End with a next step. The reader has just finished the most persuasive thing on your site — do not make them navigate back to find your email address.

Case study pages are also the strongest search asset on a portfolio, because they are the only pages containing the language of the problem rather than the language of the job title. Someone searching for "slow Shopify checkout fix" will never find a page that says "Web Developer". Portfolio SEO covers how to make sure those pages get indexed properly.

Frequently asked questions

How long should a portfolio case study be?

Between 700 and 1,100 words for most freelance work. Long enough to show reasoning, short enough that a busy reader finishes it. Design case studies aimed at in-house roles sometimes run longer, but length is not the thing being rewarded.

Can I write a case study for a personal project?

Yes, and it is the best available substitute for client work — provided the project had real users. Without a user there is no constraint, and without a constraint there is no decision worth reading about.

Should I include my design process artefacts?

Only where they carry information the text cannot. One diagram that explains an architecture, yes. Twelve screens of wireframes documenting that you iterate, no. Process artefacts should prove a point, not prove diligence.

What if the project did not go well?

It can still be your strongest case study, if you are clear about what went wrong and what you learned. Be careful not to blame the client in public — a case study that criticises a former client tells every future client exactly how you will talk about them.

Do I need the client's permission?

To name them or show their interface, yes — check your contract and ask in writing. To discuss anonymised work, usually not, but read the agreement rather than assuming.

Where should case studies live on my site?

On their own pages, linked from the relevant project card. Each one is a separate page that can rank for its own problem language, and burying them inside a single long portfolio page wastes that.

---

How we put this guide together

The structure here comes from what we see working on portfolio sites built with Bunfolio, and from the consistent pattern in how experienced reviewers describe reading them: they skim for the decision, not the deliverable. The word budgets are our recommendation, calibrated to what gets finished rather than to any external standard.

Where this guide overlaps with search — the note about case study pages being your strongest indexable asset — it is consistent with Google's guidance on creating helpful, reliable, people-first content, which explicitly values content that demonstrates first-hand experience.

Related reading: how to build a freelance portfolio website that wins clients what hiring managers actually look for in a developer portfolio, and what pages a portfolio website should have.