Case Study Writer

---
name: case-study-writer
description: Turn supplied product-design evidence into a concise, credible portfolio case study or interview narrative. Trigger on "write my UX case study", "improve this portfolio project", or "structure this design story". Preserve real ownership, uncertainty, and confidentiality. Do not invent research, metrics, quotes, outcomes, or a linear process.
metadata:
  argument-hint: "[project notes, artifacts, role, audience, and outcomes]"
---

# Case Study Writer

Write a decision story, not a process diary. Show what changed in the team's understanding, what the author specifically contributed, why key choices were made, and what evidence supports the result.

## 1. Define audience and format

Identify:

- target role, seniority, company type, and reviewer needs;
- format: portfolio page, interview deck, PDF, application excerpt, or verbal walkthrough;
- expected reading time and confidentiality constraints;
- competencies the project can genuinely demonstrate.

Optimize the same evidence differently for a recruiter scan, hiring-manager review, craft critique, and cross-functional interview. Do not make one page carry every detail.

## 2. Build an evidence ledger

Read [references/evidence-and-claims.md](references/evidence-and-claims.md). Extract only what is supported:

`Claim | Evidence | Source | Author's role | Confidence | Confidentiality | Visual candidate`

Separate:

- direct contribution from team contribution;
- observed user evidence from stakeholder opinion;
- shipped outcome from prototype result;
- measured result from directional signal;
- fact from interpretation and retrospective learning.

Ask for missing material when it changes credibility. If it remains unavailable, write around the gap transparently.

## 3. Find the narrative spine

Use:

`Context -> Tension -> Evidence -> Decision -> Change -> Outcome -> Learning`

The tension should be a real conflict or uncertainty: competing user goals, technical limits, harmful existing behavior, ambiguous data, organizational constraint, or a failed first approach. The decision must show judgment, not merely sequence.

Draft one sentence:

`We needed to help [user] achieve [goal] despite [constraint]; evidence showed [insight], so I/we [decision], resulting in [supported outcome or learning].`

If this sentence is weak, do not begin polishing prose.

## 4. Select proof

Choose visuals that make a claim inspectable:

- before/after states with the changed decision annotated;
- journey, flow, or information architecture where structure changed;
- research evidence with method and sample context;
- rejected directions with decision criteria;
- prototype or usability evidence linked to iteration;
- final behavior, edge states, and responsive implementation;
- outcome chart with baseline, period, and attribution caveat.

Avoid galleries of unlabeled screens. Every visual needs a caption that states what it proves and why it mattered.

## 5. Write the story

Read [references/story-architecture.md](references/story-architecture.md). Lead with outcome and role, then reveal enough process to explain the decisions. Use plain language, concrete verbs, and short sections.

Prefer:

`I redesigned the exception workflow and facilitated two usability rounds; the product manager owned prioritization and two engineers implemented the release.`

Avoid:

`We leveraged a human-centered framework to deliver an intuitive best-in-class experience.`

Use `I` for the author's contribution and `we` for team decisions. Do not erase collaborators or hide individual ownership.

## 6. Handle outcomes honestly

Use the strongest truthful outcome class:

1. shipped user or business result with baseline and period;
2. observed task improvement in evaluative research;
3. implementation or operational result;
4. stakeholder or adoption signal;
5. validated learning and next decision;
6. unresolved outcome with a credible measurement plan.

Do not claim causality from a before/after metric without controlling other changes. Do not turn `users liked it` into `improved usability`.

## 7. Produce the case study

For a complete input-to-output demonstration, read [references/worked-example.md](references/worked-example.md). Use it to calibrate claim strength, narrative compression, attribution, and visual proof; never import its fictional project facts.

Return:

### Project card

`One-line outcome | Role | Team | Duration | Platform | Status`

### Executive summary

In 80 to 140 words, cover context, contribution, pivotal decision, and supported result.

### Full narrative

Use only the sections needed:

- Context and stakes
- My role and constraints
- What we learned
- Decisions and tradeoffs
- Iteration and validation
- Shipped experience or final direction
- Outcomes
- Reflection and next step

### Visual plan

`Placement | Artifact | Claim proved | Caption | Redaction or recreation needed`

### Evidence notes

List missing proof, attribution limits, and confidentiality transformations.

### Alternate cuts

Provide a 30-second summary and a 5-minute interview outline when useful.

## Editing pass

- Put the strongest evidence in the first screen or first minute.
- Remove generic design-process narration.
- Replace adjectives with evidence or a concrete decision.
- Cut repeated problem statements and repeated final screens.
- Explain one or two meaningful tradeoffs deeply.
- Make the author's contribution unmistakable without overstating it.
- Verify every number, quote, date, and outcome.
- Keep confidential transformations honest and clearly labeled.

## Quality bar

- the reader understands the problem, role, decision, and result quickly;
- every major claim has evidence or an explicit limitation;
- artifacts prove decisions rather than decorate the page;
- process appears only where it changed understanding or direction;
- team and individual contributions are accurately attributed;
- outcomes distinguish correlation, research evidence, and shipped impact;
- reflection reveals changed judgment, not a ceremonial lesson.