Documenting Different Project Types¶

One Structure, Many Forms¶

The universal structure from The Universal Structure applies across all disciplines. The six elements — context, problem, decisions, difficulty, outcome, reflection — are present in some form in every strong case study, regardless of what kind of project produced it.

What changes across project types is the emphasis, vocabulary, and evidence that each element draws on.

A technical implementation project foregrounds architectural decisions and system behaviour under real conditions. A design project foregrounds research insights and iteration evidence. A research-led project foregrounds methodology and what the findings can honestly claim. An education project foregrounds the learning design reasoning and the ethical dimensions of working with people.

This document addresses those differences — not to create separate templates for each discipline, but to help you recognise which elements of the universal structure your project type foregrounds, and where the specificity most matters for your field.

Technical Implementation Projects¶

Software development, systems engineering, backend and full-stack projects

What the structure foregrounds¶

Problem: The specific operational or user problem being addressed — not the technical specification, but the real-world situation that required a technical solution. The best technical case studies are written so that a non-technical reader can understand what was wrong and why it mattered, before the technical response is described.

Decisions: Architectural and design choices with their alternatives and trade-offs. Framework selection, database choice, API design, authentication approach, deployment strategy — any decision where alternatives genuinely existed and the outcome is different for how you decided. The reasoning is the important part, not the decision itself.

Difficulty: System behaviour under real conditions — bugs diagnosed in production, integration failures, performance problems under load, security considerations surfaced late. Technical difficulty is most compelling when it is specific: what failed, what the diagnostic process was, what the root cause turned out to be.

Outcome: A deployed system, a repository with documentation, a working prototype. Link outward — the repository exists and a reader can examine it. Performance data, adoption metrics, or user feedback, where available and accurate.

Reflection: What the project changed in your understanding of the technical domain — not what new tools you used, but what new understanding you have about system design, architecture, or engineering practice that you would apply differently next time.

What makes technical case studies weak¶

◆ technology lists presented as decisions
◇ outcomes claimed without links or evidence
◆ difficulty described vaguely — "we had debugging issues"
◇ reflection that lists skills rather than insights

Design and UX Projects¶

Interface design, user experience, product design, interaction design

What the structure foregrounds¶

Problem: The human need behind the design challenge — who the users are, what they are trying to accomplish, what currently prevents them from doing so. Design case studies that lead with the user context rather than the aesthetic brief establish the criteria against which every subsequent decision can be evaluated.

Decisions: Design choices informed by research and iteration. What the research revealed and how it changed the direction. What was tried and revised. What constraints — accessibility, technical, business — shaped the final approach and how those constraints were negotiated. The most compelling design decisions are those where the research contradicted an initial assumption.

Difficulty: The gap between what was designed and how it was actually used. Usability testing findings that required revision. Constraints that forced creative solutions. Stakeholder requirements that conflicted with user needs and how that tension was resolved.

Outcome: A prototype, a delivered interface, a design system, a set of tested flows. Where a Figma prototype or live implementation exists, link to it — a reader who can interact with the design understands it differently from a reader who can only see screenshots. Show early and late versions where they demonstrate meaningful iteration.

Reflection: What the project changed in your approach to research, to iteration, or to the relationship between research evidence and design decisions. The most instructive design reflections are those that connect to a specific moment where the evidence contradicted the assumption.

What makes design case studies weak¶

◆ leading with aesthetics rather than with the human problem
◇ showing only polished finals with no iteration evidence
◆ claiming user-centred design without showing what the users said
◇ reflection on visual style rather than on process and learning

Research-Led Projects¶

Data science, AI and machine learning, quantitative and qualitative research, applied science

What the structure foregrounds¶

Problem: The research question or hypothesis — stated precisely, in a form that makes the scope and the criteria for a useful answer clear. The best research case studies frame the question in a way that a reader outside the specific discipline can understand why it is worth asking.

Decisions: Methodological choices — why this dataset, why this analytical approach, why this model architecture over alternatives. Research methodology decisions have the same structure as technical decisions: alternatives existed, a path was chosen for reasons that can be explained, and trade-offs were accepted. These reasoning chains are what a research case study must surface.

Difficulty: The honest account of what the data, the model, or the methodology could not do — not as a failure, but as a boundary clearly identified. Negative results, unexpected distributions, model limitations, and scope constraints are all legitimate and important content in a research case study. Claiming more than the evidence supports is the most serious integrity failure in research documentation.

Outcome: What the research found, at what confidence level, under what conditions. Links to notebooks, published reports, datasets (where shareable), or repositories. The outcome section of a research case study requires precision — findings stated accurately, not impressively.

Reflection: What the project changed in your understanding of the domain, the methodology, or the relationship between the research question and the evidence it generated. Research reflection often centres on what the project revealed about what the next question should be.

What makes research case studies weak¶

◆ claiming findings that the evidence does not support
◇ omitting limitations and scope boundaries
◆ methodology described as a sequence of steps rather than as a set of justified choices
◇ reflection that does not engage with what the research could not resolve

Education and Applied Social Projects¶

Intervention design and delivery, practitioner research, community projects, applied social work, education programme development

What the structure foregrounds¶

Problem: The specific gap, need, or challenge in the context where the project operated. Education and social projects often address problems that are complex, contested, and contextually specific — the case study should reflect this specificity rather than abstracting it into generic language. Who was affected, in what context, and what evidence suggested this was a problem worth addressing?

Decisions: The design choices that shaped the intervention or programme — why this approach to the problem rather than alternatives, what the research or theoretical basis was for the design, how participant needs and constraints shaped the final approach. Education case studies that show the connection between theory and practice, between evidence and design, are the most professionally compelling.

Difficulty: Unexpected responses from participants, logistical constraints that required adaptation, ethical considerations that surfaced during implementation, tensions between the programme design and the real conditions of delivery. This is often the richest material in an education or social project — the moment when the designed programme met real people and had to adapt.

Outcome: What was observed, measured, or experienced — with appropriate honesty about what the evidence can and cannot claim. Qualitative evidence from participants, quantitative metrics where available and meaningful, and an honest account of where the project fell short of its intentions.

Reflection: What the project changed in your understanding of the intervention approach, the participant group, or your own practice as an educator or practitioner. Education reflection is most compelling when it is specific to the pedagogical or social dimensions of the work — not generic professional development language, but insight grounded in what this specific project revealed.

Special consideration: Confidentiality and participant protection¶

Education and social projects often involve participants who have not consented to public documentation. Before publishing any case study that involves real participants:

◆ confirm what information can be shared publicly under the project's ethical approval or institutional agreement
◇ describe participant groups without identifying individuals
◆ use aggregated or anonymised evidence rather than individual cases
◇ omit photographs, direct quotes, or identifying details unless explicit public consent was obtained

The ethical standard for what is shared publicly is higher than the standard for what is documented privately. When in doubt, describe at a level of abstraction that is honest about the work without exposing the participants.

Business, Marketing, and Strategy Projects¶

Market research, campaign development, business planning, strategic analysis, consulting projects

What the structure foregrounds¶

Problem: The business, market, or organisational challenge being addressed. Strong business case studies are grounded in evidence — market data, customer research, organisational analysis — rather than in assertion. The problem should be specific enough that a reader understands why a particular strategic response was warranted.

Decisions: Strategic choices and their alternatives — why this market, this segment, this channel, this positioning, this intervention. Business decisions are often made under significant uncertainty, and case studies that acknowledge that uncertainty honestly are more credible than those that retrospectively present every decision as obviously correct.

Difficulty: Assumptions that were tested and revised. Research findings that contradicted the initial strategic direction. Stakeholder constraints that limited the scope of the recommendation. Competitive dynamics that shifted during the project. These are the moments where strategic thinking is most visible.

Outcome: What was recommended, proposed, or delivered — and, where evidence exists, what happened as a result. Business case studies often end at the proposal stage — the project produced a strategy or a campaign, and its implementation was not part of the scope. This is legitimate, but the case study should be clear about the distinction between the deliverable and its outcomes.

Reflection: What the project changed in your understanding of the market, the strategic context, or your own analytical approach. Business reflection is most compelling when it is connected to a specific analytical or strategic decision — not general professional development, but a specific insight about this type of problem.

Mixed-Discipline and Interdisciplinary Projects¶

Many final-year projects cross disciplinary boundaries — a software project with significant UX work, a research project that produces an educational intervention, a business project grounded in data analysis.

For mixed-discipline projects, the case study foregrounds the aspect of the work where your individual contribution was greatest and where the most significant decisions were made. It acknowledges the interdisciplinary nature of the work without trying to document every discipline fully.

The contribution filter from Part Ⅲ — What Belongs applies here with particular force: document what you can speak to specifically and defend in conversation. Acknowledge what was collaborative without claiming it as individually yours.

In Summary¶

The universal structure is universal because the underlying questions it asks — what problem, what decisions, what difficulty, what outcome, what learning — apply to every type of professional project.

What changes across disciplines is the vocabulary of answers.

Technical decisions involve architecture and behaviour under conditions. Design decisions involve research evidence and iteration. Research decisions involve methodology and what evidence can honestly claim. Education decisions involve learning design and ethical practice. Business decisions involve strategic reasoning under uncertainty.

The structure holds. The disciplinary vocabulary gives it its specific texture.