The Universal Structure¶

A Structure, Not a Template¶

The structure presented in this document applies across disciplines, project types, and stages of portfolio development. It has been built from the six elements defined in What a Case Study Is and organised into a sequence that serves both the writer and the reader.

It is not a template.

A template says: write this sentence, then this sentence, then these bullet points. A structure says: cover these ideas, in roughly this order, in whatever form serves your project and your reader best.

The difference matters because a portfolio full of entries that follow an identical format reads like a form filled in, not like a portfolio built by a thinking professional. Use the structure as an organising logic — not as a mould to pour your project into.

The Universal Case Study Structure¶

Section Ⅰ — The Opening Frame¶

What it does:
Orients the reader in under sixty seconds. Establishes what the project was, when it happened, and what your role within it was.

What it contains:

◆ the project name or a working title
◇ the context — what kind of project, for what kind of client, purpose, or audience
◆ when it happened and how long it ran
◇ your role — specifically, not generically

What it avoids:

◆ extensive background that belongs in a report, not a case study
◇ academic framing — module codes, assessment criteria, grade achieved
◆ claims about the project's importance before demonstrating it
◇ technology lists — these belong later, in context, not as an opening statement

Calibration:
Two to four sentences. The opening frame is not where the interesting material lives — it is the minimal context that makes the interesting material intelligible.

Section Ⅱ — The Problem¶

What it does:
Establishes what the project was trying to solve and why it was worth solving. This is the ground from which every subsequent decision and outcome is evaluated.

What it contains:

◆ the specific problem — not the general domain, but the specific situation that required intervention
◇ the constraints that shaped the problem — technical, resource, user, organisational, or time constraints
◆ who the problem affected and why it mattered to them
◇ what success looked like — what would be different if the project worked

What it avoids:

◆ generic framing — "the client needed a better system" is not a problem statement
◇ the solution introduced before the problem is established
◆ academic problem framing that assumes the reader knows the module context

Calibration:
Three to six sentences. The problem section should be specific enough that a reader outside your discipline understands what the project was responding to and why it mattered.

Section Ⅲ — Your Approach and Key Decisions¶

What it does:
Communicates how you engaged with the problem — not a comprehensive account of every step, but the decisions that most significantly shaped the direction and outcome of the work.

What it contains:

◆ the overall approach or methodology, briefly stated
◇ two to four key decisions, each with: - what was decided
- what the alternative was
- why this path was chosen
- what the accepted trade-off was
◆ any significant changes in direction — pivots, revisions, rethinks — and what prompted them

What it avoids:

◆ a chronological walkthrough of everything that happened
◇ decision descriptions without reasoning — "we used React" is not a decision, "we chose React over Vue because..." is
◆ only successful decisions — the decisions that were revised are often the most interesting

Calibration:
This is typically the longest section — 150 to 350 words depending on the project's complexity. The depth here is what distinguishes a case study from a project description. Do not rush it, and do not thin it out.

Section Ⅳ — What Was Difficult¶

What it does:
Demonstrates professional engagement with real conditions — the problems encountered, the unexpected constraints, the things that did not work the way they were intended to.

What it contains:

◆ one to three specific difficulties — not vague challenges, but named, specific problems
◇ what you did in response to each
◆ what changed in the project as a result
◇ what you understand now that you did not understand before the difficulty

What it avoids:

◆ difficulty presented without resolution or learning — a problem that had no consequence and produced no insight does not belong here
◇ difficulty framed as an excuse for outcomes
◆ a comprehensive list of everything that went wrong — select the difficulties that produced the most significant learning or the most significant change

Calibration:
80 to 200 words. Difficulty documented with specificity and honesty is one of the most compelling elements of a case study. It is also one of the easiest to underwrite — resist the temptation to make it shorter than the material deserves.

Section Ⅴ — The Outcome¶

What it does:
Grounds the case study in what was actually produced — the verifiable, real output of the project — and connects it back to the problem stated at the beginning.

What it contains:

◆ what was produced or delivered — specifically
◇ links to artefacts — repositories, deployed systems, design files, publications, reports — where these can be shared publicly
◆ an honest assessment of how well the outcome addressed the original problem
◇ quantitative evidence where it exists and is meaningful — not fabricated metrics, but real data if available

What it avoids:

◆ claiming success that cannot be evidenced
◇ omitting the gap between intended and actual outcome when a gap exists
◆ outcome statements that are generic — "the client was satisfied" tells a reader nothing; "the client reported a 40% reduction in missed deadlines after three months of use" tells them something

Calibration:
60 to 150 words. The outcome section should be honest and brief — it is not a celebration of the project but an honest account of what the work produced.

Section Ⅵ — Reflection¶

What it does:
Positions the project within your professional development — what it changed in your understanding, your approach, or your capability. This is the element that most clearly communicates growth over time.

What it contains:

◆ what you would do differently, starting the project with what you know now
◇ what the project changed in how you approach this type of problem
◆ what you understand now that you did not before
◇ where this project fits in the larger arc of your developing practice

What it avoids:

◆ generic reflection — "I learned a lot", "I improved my teamwork skills"
◇ reflection that does not connect to specific events in the case study
◆ false resolution — claiming learning from difficulty before the difficulty has been honestly acknowledged

Calibration:
60 to 150 words. Reflection should be specific enough that it could only have been written about this project — not borrowed from a generic reflective writing template and applied to any project indiscriminately.

Assembling the Structure¶

The six sections above form a natural arc:

┌─────────────────────┐ → ┌─────────────────────┐ → ┌─────────────────────┐
│    Opening Frame    │ → │       Problem       │ → │ Approach & Decisions│
└─────────────────────┘   └─────────────────────┘   └─────────────────────┘
                                                               │
                                                               ↓
┌─────────────────────┐   ┌─────────────────────┐   ┌─────────────────────┐
│      Reflection     │ ← │       Outcome       │ ← │      Difficulty     │
└─────────────────────┘   └─────────────────────┘   └─────────────────────┘

This arc — context, problem, engagement, difficulty, outcome, learning — mirrors the structure of real professional work. It is familiar to experienced readers not because it is a template they recognise, but because it reflects how problems are actually navigated.

A case study that follows this arc does not feel formulaic. It feels like an account of real work — which, when done well, is exactly what it is.

Supporting Material — What Goes In, What Goes Out¶

The prose of a case study is supported — not replaced — by visual and linked material.

What belongs inline or directly adjacent to the case study:

◆ one to three visuals that illustrate a specific decision or outcome — a before-and-after interface comparison, an architecture diagram, a research finding visualised, a prototype screenshot
◇ a link to the primary artefact — the repository, the published report, the deployed system
◆ brief captions that explain what each visual shows and why it is there

What belongs linked rather than included:

◆ full technical documentation or implementation details
◇ complete reports or academic submissions
◆ all screenshots from the project — select one or two, link to the rest
◇ extended background or literature context

The discipline of keeping supporting material lean reflects the same principle as the case study itself: select what serves the reader. A gallery of twenty screenshots does not make a case study more impressive — it makes it harder to read.

Adapting the Structure for Length and Context¶

The universal structure can be compressed or expanded depending on where the case study lives and who is reading it.

The same underlying case study — written fully in the master portfolio — can be adapted to every context in this table without being rewritten from scratch. The work is done once, at full depth. Everything else is selective compression.

Continue to Weak, Mid-Level, and Strong →