The Portfolio Case Study, From a Raw Project to a Published Write-Up

This guide carries one ordinary project from scattered files to a published case study. It is for anyone building or rebuilding a portfolio who has a real project in hand and does not know what to keep, what to cut, or where to start. By the end you will have a write-up that leads with the outcome, states the problem, isolates your own decisions, and survives a five-minute skim.

Most guides give you a section list or a gallery of polished examples. Neither helps when you are staring at a folder of screenshots and a half-remembered Slack thread. So I am going to run one worked example the whole way through, showing the intermediate drafts and the wrong turns, so you can follow along on your own project as you read.

The running example: a checkout redesign for a mid-size retailer, referred to here as Company X. Cart abandonment was high, the brief said "make checkout better", and you were one of two designers. That is the messy raw material. Watch what happens to it.

What a hiring manager actually does with your case study

A hiring manager skims. On a first pass through a portfolio they spend two to three minutes, and a significant number make up their minds in the first thirty seconds. One vendor puts the combined resume-plus-portfolio glance at about 55 seconds. So the case study is not read the way you wrote it. It is scanned top to bottom, once, fast.

That single fact reorders everything else in this guide. If the reviewer decides in thirty seconds, the outcome cannot be two scrolls down. If they scan rather than read, the story has to survive being reduced to headings and captions. And if they stop after the third case study, a fourth weak one is not generosity, it is dilution.

The published CV numbers come from a tracked 2023 study in which 114 experienced recruiters each reviewed three CVs; the shortest view was 12 seconds and the longest 2 minutes 27 seconds. Portfolios get a little more, but not much, and the thirty-second decision point is the one to design around.

There is one place this advice flips. Academic and report formats, like the CDC's case-study guide, stay chronological because their reader is grading reasoning, not scanning. The order you choose maps to your audience's time budget, not to taste. A hiring manager's budget is short, so you lead with the end.

Fix the claim before you write a word

The single most useful move is to decide, up front, the one result the study proves. Get the claim right and the rest almost writes itself, because the claim tells you which result leads, which details stay, and which you cut.

Back to Company X. The raw material offered three possible claims:

1. "I redesigned the checkout flow." This is a description, not a result. It says what you did, so what.
2. "Cart abandonment dropped." Better, but vague. Dropped from what to what?
3. "Cut checkout abandonment from 68% to 41% by removing the forced account-creation step." That is a claim. It names the outcome, the before number, the after number, and the specific decision behind it.

The documented headline formula is outcome verb plus specific number plus customer name plus brief context: "reduced", "increased", "cut", "doubled", "saved", then a number, then a named customer, then a line of situation. Applied here:

Cut Company X's checkout abandonment from 68% to 41% by removing forced account creation

Structure: [outcome verb] + [before to after number] + [the one decision] + [who it was for]

Notice the wrong turn built into claim 1. It is the trap most case studies fall into, and it is worth naming: describing activity instead of change. "Our AI agent shipped 600 blog posts" is useless because you did that, so what, what changed for whoever paid for it. The fix is not more adjectives. It is a before, an after, and a delta.

The skeleton: PAR, STAR, and where each maps

Underneath every portfolio case study is the same arc: problem, then solution, then result. Three interview frameworks name the same shape, and any of them works as your private extraction tool. STAR, which DDI created in 1974 for its Targeted Selection interviewing system, stands for Situation, Task, Action, Result. CAR trims the fat to Context, Action, Result. PAR is Problem, Action, Result, and it leads with a problem, which works well when your impact came from fixing something, exactly like the Company X abandonment problem.

Here is how the framework maps onto the sections a reviewer actually sees.

The critical rule about the framework: keep it hidden. STAR fails the moment you recite the four letters out loud, and the same is true on a page. The reader should see a decision narrative, not four labeled boxes marked Situation, Task, Action, Result. Use the skeleton to extract; delete the scaffolding before you publish.

For the running example, PAR is the right fit because the value came from fixing something. Problem: abandonment was 68% and the checkout forced account creation. Action: you tested a guest-checkout path against the account-required one. Result: abandonment fell to 41%. That is the whole spine, and it took three sentences.

Frame the real problem, not the brief

A case study that opens with "the client wanted X" fails the first thirty seconds. Every study needs a one-paragraph framing of the actual problem behind the brief. The brief is what someone asked for; the problem is why they asked.

Company X's brief said "make checkout better". The wrong turn is to repeat that. The real problem, once you dug into the analytics, was that two-thirds of users hit a wall at forced account creation and left. That is the paragraph that earns the next thirty seconds:

Company X ran a two-step checkout that required an account before payment. Analytics showed 68% of carts were abandoned, and session recordings put the drop-off at the account screen. The team had assumed the friction was payment options; the data said it was the account wall. My constraint: the loyalty team needed account sign-ups, so I could not simply delete the step.

That last sentence is doing real work. Constraints are what make the decisions that follow interesting. Without the loyalty-team tension, "add guest checkout" is obvious. With it, your choice becomes a judgment call worth reading.

Isolate your decisions, wrong turns included

Decisions are the unit of value, not visuals. The diagnostic that decides pass or fail is simple: after reading, can a reviewer name a specific decision you made? If not, the case study has failed. So this section carries more weight than any polished screen.

For each fork, write three things: the options, the one you chose, and why. Include the wrong turns. Do not hide challenges or mistakes, because showing how you responded often demonstrates more growth than a flawless project ever could.

The Company X decision log, extracted:

1. First attempt, wrong turn. I tried making the account step optional with a small "skip" link. Usability testing showed people did not see it. Kept the failure in the write-up because the recovery is the point.
2. The real decision. I split the flow so guest checkout was the default path and account creation became a one-tap add-on after payment. This satisfied the loyalty team's sign-up goal without the wall.
3. The trade-off. Guest orders lose some analytics linkage. I chose the abandonment win over the tracking completeness and said so.

Beauty raises the reviewer's expectations without supplying any evidence; only a named decision pays that expectation off.

Write these in the first person. The failure mode here is "we" with no role, which hides your contribution and lets the reviewer credit the team. Keep "we" for genuinely shared context and switch to "I" the moment you describe a choice that was yours.

Once you have your decision narrative, it helps to see how designers who write clearly about trade-offs actually frame theirs. That is a searchable population, not a guess.

The procedure, start to finish

Here is the whole sequence, from the folder of scattered files to a published study, with time estimates. This is the machine-readable version of everything above.

One ordering note to reconcile before you draft, not after. Portfolio and marketing guidance says lead with the outcome; the CDC's academic guide says start at the beginning and summarize in chronological order. They are not in conflict once you know your reader. If the reviewer is scanning and deciding in thirty seconds, lead with the result. If the reader is grading your reasoning end to end, chronology is fine. For a hiring portfolio, lead with the result.

Refolk writes your resume from your own history and scores how well you fit each posting, which is the same discipline you are applying here: lead with what changed, not what you touched. The case study is the long-form version of that fit.

The results block: make the number scannable

A results section should be a table or stat cards, not a paragraph. Give each metric the name, the before number, the after number, and the percentage or absolute change. A reviewer who is scanning will read a table; they will skip a paragraph of prose that hides the numbers inside sentences.

For Company X:

That third row is the honest one. It shows the loyalty team's goal survived, which pre-empts the obvious objection. A results block that only reports the win looks like a sales sheet; one that reports the trade-off looks like judgment.

When you genuinely cannot show a metric, show the decision that produced it. Process and judgment substitute for numbers, and percentages substitute for absolutes. That is the bridge to the NDA problem.

When the project is under NDA

An NDA-safe case study does not reveal secrets, it reveals judgment. That is the load-bearing move, and it loses less than you fear, because a good study should not be metric-dense in the first place.

The documented substitutes, in order of how often you will reach for them:

• Placeholder the client. Replace the company, product, or service with "Company X" or "Product Y", and omit or change specific features and data.
• Relative, not absolute. Use percentages if you must talk about numerical metrics. "Cut abandonment by 40%" is safer than "from 68% to 41%" and still credible.
• Role and method in general terms. Focus on what you did and how, using anonymized examples, hypothetical framings, and abstract visuals.
• Get sign-off. Write the full study, leave out sensitive metrics and tools, and send it to the client for written approval. Record that approval.

There is an upside most people miss. Refusing to leak reads as reliability. It pays to come across as trustworthy, and any good recruiter prefers that over someone who might give away a former employer's secrets. Handled well, the NDA constraint raises perceived trust rather than lowering perceived depth.

How this goes wrong

Most failed case studies fail in one of a handful of predictable ways. Each one looks fine on the surface, which is exactly why it slips through. Here is the field guide, with the false positive that fools people and the check that catches it.

• Gallery with no decisions. Looks polished; the false positive is beautiful screens. Screenshots show outcomes but rarely explain decisions. Check: can a reviewer name one decision after reading? If not, add the decision layer.
• Process worship. Reads thorough; the false positive is a complete research-to-prototype timeline. The UX process is widely known, so reciting research, ideation, and prototyping rarely adds value. Check: does it flag the moment new information changed direction, or just list phases?
• Vague result. Sounds impressive; the false positive is "shipped X". Check: does it give the name, before, after, and delta? If it only says what you did, so what.
• Over-anonymized NDA study. Feels safe; the false positive is a disguised client a palette still identifies. Check: could a competitor name the client?
• Too many or uneven studies. Feels generous; the false positive is eight case studies. Eight half-finished studies is weaker than three properly developed ones. Check: does every study read at the same depth?
• Buried outcome. Feels like good storytelling; the false positive is a chronological build-up. Check: is the result on the first screen, or two scrolls down?
• Wall of text. Looks rigorous; the false positive is a thorough essay. Blocks of text with no visuals make the study look like a chore. Check: does a caption carry the story where prose would?
• "We" with no role. Sounds collaborative; the false positive hides your contribution. Check: is there a first-person "I" on every decision?

The early-career version of the gallery trap deserves its own mention: fake redesigns of well-known apps with no real users, constraints, or brief. They fail because they have no problem to frame and no constraint to make the decisions interesting. One real client project, even a small one, beats three concept redesigns.

Cut to the skim, then trim the set

The last two moves are about the reader who never fully reads. First, make the captions carry the story: if someone scrolls through and reads only your one or two sentence captions, they should still understand the project. Rewrite each caption as a claim, not a label. "Checkout screen v2" is a label. "Guest checkout became the default, cutting the account wall" is a caption that survives the skim.

Then trim the whole portfolio. Keep three to five studies of consistent depth. Reviewers stop reading after the third, and for senior roles three is often better than five. A portfolio of seven to ten signals that you have not worked out which work is strongest, because the weak studies dilute the strong ones the reviewer already stopped reading. Removing one misaligned project usually improves clarity more than adding a new one.

Consistency of depth matters as much as count. When studies vary wildly, one ten-minute read and one one-minute read, the inconsistency signals a candidate who does not know what they are presenting. Bring every study to the same length and rigor.

Keeping it current and why the market matters

Rework the claim whenever the project produces a new number or you learn a harder constraint. A case study is not frozen; the abandonment figure for Company X might improve after a later release, and updating the headline keeps the study honest without a rewrite.

The market also shapes how much a differentiated case study matters. In Refolk's index the pools differ sharply by title and geography.

The US "UX Designer" pool is 4.58 times the UK's. Within the US, title choice compounds it:

Product Designer outnumbers UX Designer 1.91 to 1 in the US pool. The larger the pool you are competing in, the more the reviewer relies on the thirty-second skim to filter, and the more a single sharp, decision-led case study earns its place. In a smaller market a thinner portfolio survives; in a large one, the trimming and the result-first order are not optional. Re-check your target market's pool size when you decide how hard to invest, and if you use Refolk to score your fit against a posting, treat a large candidate pool as a signal to sharpen the claim, not to add another study.