What a case study adds
A portfolio entry can be as small as a title, a picture and a line. A case study goes further: it tells the story of one project in enough detail that a reader can follow your thinking. Employers and collaborators often care less about the finished object than about how you got there, what you decided and what you would do differently.
This article is about writing one entry in depth. The question of which projects to include and how to organise the portfolio as a whole belongs to the broader topic of the engineering portfolio, so here we focus on the writing itself.
Pick a project you can explain
Choose a project where you can answer specific questions about your own part. You need to remember, or have records of, the constraints, the options considered and the evidence for the result. If you lack notes, reconstruct what you can from files, commit history, emails and drawings, and be clear about anything you are reconstructing from memory.
Check you are allowed to publish the material. Work for employers and clients is often confidential. Get permission, or describe the problem in general terms, change identifying details where appropriate and leave out proprietary data.
A workable structure
Most good case studies follow a similar arc. Use headings so readers can skim.
- Summary. Two or three sentences: what the project was, your role and the outcome. Many readers stop here, so make it count.
- The problem. What needed solving, for whom, and why it was hard. Include the key requirements and constraints such as budget, size, time, materials or interfaces.
- Your role. State clearly what you did and what others did. Team size, duration and your responsibilities help the reader calibrate.
- Approach and decisions. The options you considered, how you chose between them and what you gave up. This is the heart of the piece.
- Work and evidence. Sketches, diagrams, code excerpts, drawings, test setups and measurements that support the story.
- Results. What happened, measured against the original requirements where possible.
- Reflection. What worked, what did not and what you would change.
You do not need every section for every project. A small project may need only four short ones.
Describing decisions
Decisions are what separate a case study from a photo gallery. For each significant decision, say:
- what the choice was,
- what alternatives you considered,
- what criteria mattered,
- what you chose and why,
- what trade-off you accepted.
A simple example, labelled as an illustration: “I considered a lower-cost microcontroller and a larger one with more memory. The project needed to log data for several hours, and I was not sure of the final data format, so I chose the larger one and accepted the higher cost and slightly higher power use.” The reader can see the reasoning without needing to know the specifics.
Where you used a structured method, such as decision matrices, a risk list or a root cause analysis after a fault, mention it briefly and show a small piece of it instead of the whole document. Likewise, a brief nod to the engineering design process you followed can help a reader place your work.
Evidence over adjectives
Words like “robust,” “efficient” and “innovative” mean little without support. Replace them with observations:
- Instead of “the design was robust,” describe what you tested: “I dropped the enclosure from desk height five times onto a hard floor; the housing cracked at one corner after the fourth drop, so I thickened that wall.”
- Instead of “the code was efficient,” show a comparison you measured: the method, the tool and the numbers you recorded.
When you include data, give units and conditions, label graphs, and be clear about the number of samples. Do not present small test results as proof of more than they can show. A statement like “in my bench tests, with this setup” is honest and still persuasive. If you did data visualization to present results, keep the charts plain and legible.
Being honest about results and credit
Honesty makes the case study more credible, not less.
- Credit others. Name teammates’ contributions in general terms and avoid implying you did all the work.
- Report the real outcome. If the project missed a target, say which and why. Unmet goals with a clear analysis are a legitimate and often instructive case study.
- Distinguish prototype from product. A bench prototype is not a certified design. Where safety, regulation or standards are relevant, say what was and was not verified, and do not suggest that a student or hobby project is suitable for use in safety-critical settings.
- Do not alter data. If you tidy a graph or drop a failed run, note it.
- Be careful with claims about impact. Only state benefits you know about, in the terms you can support.
Reflection is the place to be candid. “I underestimated the time needed for testing, and in the next project I would build the test plan at the start” tells a reader something useful about how you learn.
Writing style
- Write for a smart reader outside your specialty. Define terms the first time. A recruiter, a manager and an engineer may all read the same page.
- Use short paragraphs and concrete verbs.
- Use the first person for your work. “I measured…” is clearer than a passive construction that hides who did what. Use “we” for shared work.
- Keep it compact. Between 400 and 800 words plus images is usually enough for a single case study, with links to deeper material if you want to offer it.
- Have someone read it. Ask a colleague unfamiliar with the project to say what they understood. Their questions show where the write-up is unclear. Good technical writing is mostly about answering the reader’s likely questions before they ask.
Keeping records as you go
The easiest case studies are written from notes made during the project. A habit of recording decisions, test results and photographs as they happen saves hours later. Even a brief log with dates is enough, and decision records and tidy engineering notes make a project much easier to describe afterward.
Common pitfalls
- Starting with the solution, not the problem.
- Listing features without explaining choices.
- Hiding failures.
- Unlabelled images and graphs.
- Too much jargon, or too much detail on minor points.
- Leaving your own role unclear in a team project.
- Publishing material that is confidential or belongs to someone else.
A case study does not have to describe an impressive project. A modest one, explained clearly and honestly, shows the habits that matter in practice: defining the problem, weighing options, testing and learning from the result.