A STAR case-study template you can actually fill in.

I have read a few hundred instructional design portfolios, and the broken ones all break the same way. The case study opens with "I am a passionate, results-driven learning professional," lists eight tools, name-drops six SME meetings, and ends with "the training was very well received." It reads like a job application that wandered onto a project page. By paragraph two the hiring manager has already moved on.

The fix is not better adjectives. It is a skeleton — the same four-part skeleton every strong case study quietly uses, whether the designer names it or not. It is STAR: Situation, Task, Action, Result. Below is the template I actually fill in, field by field, plus the three filler phrases I cut on sight.

A case study is not a list of what you did. It is the story of what changed, and why your decisions caused it.— the whole article in one line

The STAR skeleton, one field at a time.

The reason STAR works is that it forces proof before adjectives. Each field has a job, and when you skip one, reviewers feel the gap even if they can't name it. Here is what each letter is actually asking you for.

Situation — name the pressure.

One sentence of business context beats three paragraphs of industry background. Name the thing that made this project urgent: a compliance deadline, a merger, a product launch, a safety incident rate, customer churn tied to a training gap. Tie it to a date or a window when you can — reviewers use time pressure to judge whether your solution was realistic. And if you can't name the client, keep the pressure concrete anyway. "EU regulatory deadline" reads as real without naming the account; "digital transformation" means nothing.

Task — write the success criteria that existed before you opened Storyline.

Task is an outcome sentence, not a job title. "Reduce time-to-first-call for new reps." "Pass the audit with zero critical findings." "Cut escalations to Tier 2." If you can't state the Task, you are still describing activity, not impact. When priorities conflicted — Legal wanted length, Ops wanted speed — name the trade-off you were hired to balance. If the sponsor changed mid-project, say so: "original ask was awareness; the new VP demanded certification" explains a scope swing that otherwise looks like bad planning.

Action — walk the decisions, not the tool list.

This is where most case studies turn into a tool dump, and it is the most important field to get right. Action is your reasoning: why scenario-based instead of click-next, how you structured practice, how you handled SMEs who disagreed, what you cut when the timeline slipped. Tools appear as evidence of a decision, never as decoration. If you inherited bad source files, say how you refactored the interactions instead of defending the mess. If you ran pilots, say what changed after learners got confused.

Result — anchor to what changed.

Fewer errors, faster proficiency, higher completion, cleaner audit scores, or an honest qualitative signal from managers. If the Result is "launched on time," pair it with why on time mattered — the audit window, the revenue kickoff. If results are still pending, write "pilot passed; full rollout scheduled Q3" instead of going quiet and hoping no one notices.

Fill it in: a worked example.

Templates are easy to nod along to and hard to actually use, so here is the skeleton filled in for a single project — a compliance refresh for frontline staff. Copy the structure, swap in your own facts.

// Keep each field to 1–3 sentences on the public page.
// Save the long version for the interview.

SITUATION: New EU audit deadline; the old 90-minute course had a
             61% completion rate and Risk flagged it as a finding.

TASK:      Pass the audit with zero critical findings and get
             completion above 85% without adding seat time.

ACTION:    Cut the linear deck into role-specific paths; built
             branching scenarios with remediation tied to each
             wrong answer; ran two pilot cohorts and rewrote
             module 3 after learners stalled on the worst screen.

RESULT:    Audit passed, zero critical findings; completion
             moved 61% → 88% in 30 days; seat time down ~35%.

Notice what the Action field is doing: every line is a decision with a reason behind it, and the tools are implied rather than paraded. Notice too that the Result ties each number back to the Task — the audit, the completion target, the no-new-seat-time constraint. That is the difference between a case study and a changelog. For more fully built examples in this shape, see our roundup of instructional design portfolio examples.

The three filler phrases that ruin it.

Even a well-structured STAR can be undone by stock phrases that survive from your resume. These three do the most damage. Ranked by how often I delete them.

The pattern under all three.

Specificity is kindness — it saves the reader work. When you find a weak line, interrogate it with three questions: what did the learner do differently on Monday, who signed off, and what metric moved (or what behavior changed if the metrics were blocked)? And swap the resume verbs for the real ones. Replace "leveraged" with what you actually did: mapped, prototyped, piloted, cut, rewrote. Read the whole thing aloud — if you run out of breath before you reach the Result, your Situation is too long. Tighten until you finish the arc in under ninety seconds.

Metrics when the client locked the data.

The most common reason Result paragraphs go vague is real: the client wouldn't share the numbers. That is fine. You have three honest moves, and none of them require inventing a percentage.

Use ranges or directional improvement."Double-digit reduction in repeat safety incidents" is plenty when Legal blocks the exacts. Describe the direction and the magnitude band without naming a confidential baseline.

Lean on before-and-after behavior."Learners stopped asking Tier 1 to interpret policy exceptions" beats "improved learner confidence" every time. Observable behavior is a Result; invented confidence is not. Just explain how you observed it — sampled manager check-ins, a pilot survey, an on-the-job rubric — so it reads as judgment, not a guess.

Name the L&D and business metrics you do have, and how you collected them. Pre/post knowledge checks, LMS completion and pass rates, help-desk ticket volume, QA defect counts caught before release, ramp time, rework hours. One number plus one quote usually beats five numbers with no story. And if training was one lever among many, say so — credit sharing reads as mature, not weak.

That is the whole template. A skeleton that forces proof before adjectives, an Action field that argues for your decisions, and a Result that ties back to the Task — even when the data is thin. Build two or three case studies this way and they will quietly out-read every portfolio that opens with "passionate learning professional." If you are still deciding how much of this belongs on a page versus a resume, we worked through that split in resume vs. portfolio, and if you want the STAR fields baked into your project pages by default, that is exactly what the Training OS portfolio is built to do.

Frequently asked questions.