The Portfolio Case Study, One Project Carried to a Skimmable Page

You have one finished project and a folder of raw files, notes, and screenshots. This guide carries that single project end to end into a case study page a recruiter will actually read instead of scroll past, with a working overview box, a stated role, a framed problem, and an outcome you can defend. It is for job seekers writing or rewriting a portfolio, and it follows one worked example through the bloated first draft, the recruiter-scan test, the ownership rewrite, and the awkward outcome section when no clean number exists - wrong turns included, so you can follow along on your own project.

I will use a running example: a checkout redesign done on a small team. Yours will differ in domain, but the forks are the same.

Who reads a case study, and what they do in the first minute

A recruiter scans your case study, they do not read it, and they are matching you against a requisition rather than admiring your craft. That single fact decides the whole structure. The first pass is a filter: the reviewer is looking for a reason they can defend passing you along, fast.

Reported time budgets vary. One source cites 2 to 5 minutes for a full portfolio review; another cites roughly 7 seconds for the initial scan before a reader decides whether to slow down. Treat both as true at different depths. You get a few seconds to earn the few minutes.

The practical consequence: you are not writing an essay for a reader who will absorb it linearly. You are building a page that answers "what role, what level, what shipped" at a glance, then rewards a second, slower pass with the evidence behind the claim. Every decision in this guide serves that order.

A recruiter is a filter, not a fan, so the page must hand them a reason to say yes.

The section set, and how long the page should be

Use the near-universal template of five sections - Context, Problem, Process, Solution, Outcome - and target a 3 to 4 minute read, roughly 600 to 1,200 words plus visuals. That is the spine. Everything else is trimming and labeling.

There is no single canonical length, and the published guidance splits into two bands. Knowing where sources land keeps you from writing to the wrong target.

The "under 500 words" figure you may have seen elsewhere is not well supported; the weight of the sources sits at 600 to 1,200 words or a 3 to 4 minute read. Pick the time-based rule as your real constraint, because a word count tempts padding and a reading time does not. If your page takes five minutes to read, something is not earning its place.

A second near-universal rule: quality over quantity. Two to four strong case studies beat a pile of thin ones. This guide gets one project right; apply it again for the next.

The overview box: Role, Goal, Key Outcome

Put a box at the very top of the page that answers three things upfront - your Role, the Goal, and the Key Outcome. When a recruiter clicks a project, this is what should immediately appear, before any hero image or scrollable narrative. It exists because the reader is a filter working in minutes.

Here is the box for the checkout example, after the rewrites described later in this guide.

Role: Product designer. I owned research and the checkout flow redesign; engineering and a PM were on the team.
Goal: Reduce checkout abandonment on mobile for returning customers.
Key Outcome: Redesign shipped to 100% of mobile users; task-completion in usability testing rose from 1/5 to 4/5.
Context: 6-week project, 2023, live e-commerce product.

The common failure is a box that is present but hollow: it lists Role, Goal, and Outcome, but the Outcome line says something like "improved the experience." That is not an outcome a stranger can repeat. The test is blunt - can someone who has never seen your work state what shipped in seven seconds from this box alone? If not, the box fails the recruiter screen even though it looks complete.

The worked example: from bloated draft to skimmable page

Start messy, then cut. The reliable sequence is to dump your raw points into a plain document, draft all five sections knowing the draft will be bloated, then test and trim - not to write tidy prose the first time. This section walks the checkout project through that sequence so you can run it on yours.

The raw dump

Before any layout, I wrote the brief, what I did, and what changed into a plain doc. No images, no headings, just thought. This matters because writing content to fit a design produces padding; writing content first and fitting design to it produces a case study. For the checkout project the dump was about 900 words of unstructured notes, including three dead ends I later cut.

The first draft, and why it bloated

I filled Context, Problem, Process, Solution, Outcome against the template. The draft ran to roughly 1,900 words. Two things bloated it. First, the Process section narrated every meeting. Second, the Outcome section hedged because the redesign had only just shipped and I had no post-launch conversion data yet. I left a placeholder: "early signs are positive." That placeholder is a trap I will return to.

The draft reading fine on a careful read hid two failures that only the next two passes exposed.

Run the recruiter-scan test

Read only your headings and captions, ignoring the body prose entirely, and check whether that skim alone conveys your role, the problem, and the outcome. If someone scrolls through and reads only the headlines and captions, they should still understand the project. This test catches bloat that a normal read-through misses, because good prose hides a weak skeleton.

On the checkout draft, my headings were section labels: "Context," "Research," "Design," "Results." Read alone, they told a reader nothing. Nobody skimming "Research / Design / Results" learns what I found or built. So I rewrote the headings to state findings, not stages:

• "Returning mobile users abandoned checkout at the address step" replaced "Research."
• "I cut the flow from five screens to three" replaced "Design."
• "Task completion rose from 1 in 5 to 4 in 5 in testing" replaced "Results."

Now the skim carries the argument. This is the single highest-leverage edit on the page, because it matches how the page is actually consumed.

Resolve every "we" into what you owned

State what you personally owned in one specific line, then credit the team film-style. "I ran the research and designed the checkout flow" is useful; "I collaborated cross-functionally" is not. This is especially important on team projects, because a reviewer who sees a list of names with no roles gets suspicious about what you actually did.

The checkout draft was full of "we." We researched, we iterated, we shipped. That reads as either a solo claim in disguise or a vague gesture, and both hurt. The fix is two moves. First, convert each "we" into either "I" with a specific verb or an explicit team action. Second, add a credit line.

My role: I owned the usability research and the checkout flow redesign across three iterations.
Team: 1 engineer (built the flow), 1 PM (set scope and the abandonment target), 1 content designer (microcopy).

Be honest about scope: did you do all the work solo or was it a team effort, and what specifically was your contribution? Overstating involvement damages credibility if it surfaces in the interview, and it usually does, because the natural follow-up is "walk me through that decision" and you cannot walk through one you did not make.

This is where materials work gets slow, because resolving ownership and keeping it consistent with your resume is tedious to do by hand. Refolk writes your resume from your own history and tailors it per posting, which keeps the role line on the case study, the resume, and the cover letter saying the same thing about what you owned.

The outcome section when no clean metric exists

Connect the work to a verifiable result, behavior, decision, or learning, and never invent a metric to make the story sound complete. When a clean number does not exist, you substitute evidence; you do not fabricate one. A real public portfolio spec states the rule plainly: if the author cannot provide a real figure, that entry simply keeps no metrics.

This is where my checkout placeholder - "early signs are positive" - had to go. I had no post-launch conversion number. What I did have was usability testing. So I used a directional, before-after frame: turning "users found checkout confusing" into "4 of 5 users failed to complete checkout before the redesign, and 4 of 5 completed it after." That is a real measurement with a stated method, not a conjured percentage.

The acceptable substitutes, in order of preference when a headline metric is missing:

If the project was speculative or academic, label the status explicitly and imply nothing. State the assignment, sponsor, team, timeline, and implementation status, and say which constraints came from the brief and which you defined. Do not imply a redesign was requested, adopted, or shipped when it was speculative. A conceptual project can show judgment but cannot prove market or operational impact, and that is fine - "not shipped" is not a weakness when the work still shows problem framing, evidence, prioritization, and measurement judgment.

The reframe that saves people here: a missing metric is a labeling problem, not a weakness. The failure is implying adoption, not the absence of a KPI.

How this goes wrong: failure modes and false positives

Most case studies fail in a handful of predictable ways, and each has a false positive that looks fine until you apply the specific check. Run these against your page before you call it done.

• Overview box present but hollow. Looks fine: a box with Role, Goal, Outcome. Fails when the Outcome line is vague. Check: can a stranger state what shipped in seven seconds from the box alone?
• Ownership inflation. Looks fine: "led end-to-end" on a team project. Fails under questioning. Check: can you name the other disciplines and what each did? If not, you are overclaiming.
• Fabricated or borrowed metrics. Looks fine: a clean percentage. Fails when you cannot reproduce it. Check: can you state the measurement method? A public benchmark average is not your result.
• Speculative work dressed as shipped. Looks fine: "redesign increased conversions." Fails when it was never shipped. Check: is implementation status labeled, and does the page imply nothing was adopted?
• Wall of text that reads fine but does not skim. Looks fine: strong prose. Fails the skim. Check: read only headings - do they state findings, or just stage names?
• Generic filename. Looks fine locally: portfolio_final_v3.pdf. Fails weeks later. Check: does the filename contain your name and role so it is searchable in an inbox or ATS?
• Portfolio URL in an ATS file field. Looks fine when you paste it. Fails silently. Check: the ATS parses files, not URLs - did you upload the PDF?
• Padding to hit a word count. Looks fine: a full 1,500 words. Fails the value test. Check: does every sentence carry a decision or evidence? If a sentence were cut, is anything lost?

The skim failure and the ownership failure are the two that most often survive a self-review, because the writer knows the full story and reads it into thin headings and vague "we" language that a stranger cannot. Hand the page to someone who was not on the project and ask them to read only the headings aloud. What they cannot say, the page does not communicate.

The procedure, start to finish

Here is the full sequence for one project, with rough time budgets so you can block it in an afternoon. It matches the worked example above.

Note the two forks where sources disagree. Some put the raw text dump before any design, others start from the template skeleton; the dump-first order is safer because it prevents writing to fit a layout. And some move the final design above the process while chronological-story sources keep the outcome last. Resolve the second fork with the skim test, not a rule.

Package and name the files so they are findable

Keep a clean single-column PDF for applications and ATS uploads, generate a web version from the same content for sharing, and name the PDF so a recruiter can retrieve it later. Recruiters re-find candidates by searching their inbox and ATS text weeks after the first contact, which makes the filename retrieval infrastructure, not an afterthought.

Use the pattern FirstName-LastName-Role, with dashes rather than spaces so the name does not become %20-encoded in a portal URL. "resume.pdf" and "portfolio_final_v3.pdf" are invisible in a search weeks later.

On channel: an ATS generally will not crawl a portfolio URL, because these systems are built to parse uploaded files, not to visit links. Upload the PDF or DOCX to the application form, and put the web link on your resume, profile, and email signature where a human will click it. Pasting a site link into a field that expects a file is a silent failure.

Keep it current, and use the positioning gap

Revisit the outcome section whenever real data arrives, because the strongest version of the checkout case study is the one updated with a post-launch number once you have one that is genuinely yours. Re-run the skim test after any edit, since a change to the body often weakens a heading you forgot to update.

There is a positioning signal worth knowing. In Refolk's index, the case-study skill is concentrated and thin at senior level.

number: 0
label: US "Senior" designers tagged with Portfolio Management plus Case Studies in Refolk's index
note: Likely a tagging habit, not an absence of senior designers - which means a strong senior case study page is an uncontested signal.