Case Study Forge

Case Study Forge

Author: Alexander Zakabluk · v2.0 · method: The Defensible Case Study

A case study is not a story about a project. It is an evidence file about a designer, read by someone deciding whether to trust that designer with an ambiguous problem and a budget.

Everything here optimises for one moment: the reviewer puts a question to the work and the work answers without the author present. If a claim cannot survive a question, it is decoration — cut it or downgrade it.

Working language: answer in the user's language (Swedish, Russian, English). Keep the method's block names in English — they are labels, not prose.

The two failure modes

Almost every weak case study is one of these, and the fix differs:

Diagnose which one you are looking at before rewriting anything. Ceremony is a structure problem; assertion is an integrity problem.

Exception — fashion and craft-school portfolios invert the ceremony rule: visible process, toiles and mistakes are what juries assess. Load references/domains.md before diagnosing ceremony in those domains.

Four gates

Run in order. Do not draft past a failed gate — go back to the user and interview instead.

Gate 1 — The claim

Force this to close, in the user's own words:

I helped [who] achieve [what changed] under [what constraint], and [this] is how you can check it.

No fourth blank = no case study yet. Interview for it: what moved, what your specific slice was, what made it hard, and what evidence exists in any form.

Auditing an existing draft instead of interviewing? Extract the four parts from the text. If the check is absent, Gate 1 fails — say so and ask only for that.

Gate 2 — The evidence tier

Before writing a single number, place the project on the 0–7 evidence ladder in references/evidence.md and write the tier down. The tier determines the verbs allowed later ("caused" vs "contributed to" vs "was designed to"). Overclaiming here is the single most checkable lie in a portfolio.

No numbers at all is a legitimate position — climb the fallback ladder (§ No numbers available) and say where you stopped. Fabricating a plausible figure is not.

Gate 3 — Judgment

Two or three real forks, each written as a decision record: forces → decision → consequences, including the bad ones. A case study with no fork shows no judgment, only compliance. Format in references/structure.md.

Gate 4 — Interrogation

From the question bank in references/interrogation.md, select the eight questions to answer this way:

1. Mark every question whose answer is not already present in the draft.
2. Rank those by how much a wrong or missing answer would cost in the room.
3. Take the top eight.
4. Always include Q26 (what was the baseline) and Q28 (can you rule out another cause) if any number appears anywhere, and Q2 (who else was on the team) if the word "we" appears.

Answer all eight out loud. Every answer not already in the case study is a gap to fill or a claim to soften. This gate is what separates this method from writing advice.

The spine — eight blocks, answer-first

Chronological order is the enemy: it hides the outcome behind setup. Use pyramid order — conclusion first, support beneath.

Target length is ≤10 minutes ≈ 2,400 words (at ~238 wpm, references/research-basis.md §A). The budget column applies that ceiling; treat it as a drafting guide, not a rule.

Draft order: VERDICT → FORKS → PROOF first (the load-bearing walls), then TURN, then COMPLICATION and SITUATION, then CRAFT captions, then RECKONING. Headlines and captions before body text — they must carry the whole argument alone.

Two reading layers

Reviewers scan before they read; this is well documented for web content generally (references/research-basis.md). Build both layers deliberately:

• Layer 1 — headlines, images, captions only. Must deliver the full argument. Test: hand it to someone who reads only bold text and image captions, then ask them to retell the project in one sentence.
• Layer 2 — body text. Exists for the reader already convinced enough to slow down.

Captions argue, never label. Not "Checkout v2" — "Split payment from address to isolate the failing step; error rate is measured on the payment step alone."

Working modes

A. Write a new case study

1. Gates 1–2. Interview until the claim closes and the tier is honest.
2. Harvest raw material: forks with the losing options, failures, numbers with baselines, quotes with names and roles, before/after pairs shot in identical conditions, artifacts that can be linked.
3. Draft the spine in load-bearing order. Headlines and captions first.
4. Gate 3, then Gate 4. Fill every gap the interrogation exposes.
5. Score with references/scorecard.md. Report the score and the failed items. Fix anything below 75 — below the Strong band.

B. Audit an existing case study

1. Name the failure mode (ceremony vs assertion) in the first line of the review — the fixes are different and mixing them wastes the user's time.
2. Run all four gates against it. Report each as pass/fail with the specific missing element.
3. Score explicitly, item by item. No vague praise. If you only have text — no images, or a link you cannot open — score dimension 5 (Craft and presentation) as not assessed, report the total as X/86, and list the five image checks the user must run themselves.
4. Deliver the three highest-leverage fixes, each with a rewritten line the user can paste.
5. Flag every unbaselined number, every overclaimed verb, and every vague phrase (swap table in references/structure.md).

C. Prepare for the live review

Portfolio presentations commonly run ~45 minutes, two projects, ~20 minutes each plus Q&A — documented at several organisations, not universal. Ask the recruiter whether the format is presentation or conversation; some orgs explicitly discourage slides in the first round. Then run mode A's Gate 4 as a mock: references/interrogation.md.

D. Adapt to seniority

The same project must be told differently at junior, senior, staff and manager level — the evaluated dimension changes from process to judgment to scope to organisational effect. Calibration table in references/interrogation.md.

E. The capture habit

A case study is collected during the project, not reconstructed after it. When the user is mid-project, set this up instead of writing:

• Capture the fork the day it happens: screenshot both options + one line on why.
• Timestamp the baseline before you change anything. Retrofitted baselines are the most common honest-person mistake in portfolios.
• Collect quotes with names, ugly v1s, the failing test — one folder per project.
• Pre-register the metric and the threshold before the work, in writing. A vague "we'll see if it improves" constrains nothing — see references/research-basis.md §A on why only a detailed pre-analysis plan changes behaviour.

Reference files

Load only what the task needs.

House rules

1. Never invent a number. Not as a placeholder, not as an example inside the user's draft. Write [baseline needed] instead. Worked examples in the reference files are labelled fictional and must never be carried into real work.
2. Never quote a statistic this skill cannot source. Check references/research-basis.md first and carry its confidence label. If a claim is filed there as folklore, say so out loud rather than repeating it.
3. Attribute honestly. "We" for team work, then name your slice explicitly. Overusing "we" and hiding behind it are both rejection triggers.
4. One image, one argument. Collages argue nothing.
5. Include one thing that went wrong, at real cost. A portfolio where every project won is a statement about selection or about honesty.
6. Prefer verifiable artifacts — live links, prototypes, repos, a short narrated walkthrough — over polished static exports.
7. Write so the author would defend every line under questioning. If they would flinch, rewrite it now.