# Case Study Forge > Build, restructure or audit portfolio case studies that survive interrogation — UI/UX, product, branding, design systems, fashion and motion. Runs the Defensible Case Study method — answer-first structure, forks documented as decision records, a declared evidence tier instead of invented metrics, an internal FAQ, and a weighted 100-point scorecard tied to real design-hiring rubrics. Use when the user asks to write a case study, review or fix a portfolio piece, structure a project story, strengthen or sanity-check impact numbers, prepare for a portfolio review or design interview, adapt a case study to a seniority level, or says "skriv ett case study", "granska min portfolio", "portfolio review", "case study feedback", "мой кейс слабый", "как описать проект". Also use before any project write-up meant for a hiring manager, jury, client or promo packet. - Skill: `zkblk/case-study-forge` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add zkblk/case-study-forge` - Raw SKILL.md: https://api.skillmd.com/api/skills/zkblk/case-study-forge/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - License: MIT - Author: zkblk (https://skillmd.com/u/zkblk) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/zkblk/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: | Failure | Looks like | Fix | |---|---|---| | **Ceremony** | Method theatre, double-diamond diagrams, persona wallpaper, chronological march from kickoff to launch. Documents that work happened. | Cut to decisions. Move to answer-first order. Every artifact must earn its place by making one argument. | | **Assertion** | Confident claims with nothing behind them. "+40% engagement." "Seamless experience." "Users loved it." | Declare the evidence tier honestly (`references/evidence.md`). A tier-2 claim stated as tier-7 destroys every other number on the page. | 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. | # | Block | Job | Budget | |---|---|---|---| | 1 | **VERDICT** | Outcome, your role, the constraint, and the check — in two lines plus one strong image. Spoil the ending deliberately. | ~240 w | | 2 | **SITUATION** | Who, what, when, team, your slice. Low-context: a stranger can act on it without asking. | ~170 w | | 3 | **COMPLICATION** | What was actually at risk, and the appetite — the time/money box that shaped the solution space. | ~215 w | | 4 | **TURN** | The one thing you learned that invalidated the obvious plan. Not a research dump — the reframe, in a sentence. | ~265 w | | 5 | **FORKS** | 2–3 decision records with real trade-offs, the option you killed, and your No-Gos. Where judgment lives. | ~480 w | | 6 | **CRAFT** | The solution shown large, with captions that argue. States, edge cases, the constraint made visible. | ~290 w | | 7 | **PROOF** | Evidence at the declared tier: baseline, delta, window, n, design, your contribution. Plus what didn't move. | ~410 w | | 8 | **RECKONING** | Internal FAQ (the hardest questions asked of yourself), what you'd redo, what it changed in how you work. | ~330 w | **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. | File | Load when | |---|---| | `references/structure.md` | Drafting. Decision-record format, No-Gos, narrative turn, vague-phrase swap table, caption patterns. | | `references/evidence.md` | Any number appears, or none exists. Evidence tiers 0–7, reporting checklist, confidence verbs, no-numbers ladder, stats traps. | | `references/interrogation.md` | Gate 4, interview prep, seniority calibration. 36 real interviewer questions and the internal FAQ pattern. | | `references/domains.md` | Non-generic work: UX/product, branding, design systems, fashion, motion. | | `references/scorecard.md` | Scoring or auditing. 30 weighted items across 8 dimensions. | | `references/research-basis.md` | **Before stating any external statistic or benchmark** — including the SUS and sample-size figures in `evidence.md`. Also when the user asks "says who?". Carries the confidence label that must travel with every quote. | | `assets/case-study-template.md` | The user wants a blank to fill in. | --- ## 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.