BEGINNER GUIDE

How to Write a Portfolio Case Study: Brief, Decisions and Results

Turn one project into an honest portfolio case study by connecting its brief, decisions, evidence and limitations, with an annotated fictional example.

A portfolio case study helps someone understand what you were asked to do, what you decided and what the available evidence shows. It is more useful than a gallery of screenshots because it makes your contribution inspectable. It is also more credible when it states what the project cannot prove.

In this guide

Use the broader guide to build freelance portfolio without clients if you are building your first collection. Before writing the case study, choose portfolio projects for freelance services so you have one bounded project with a clear task and deliverable. This guide focuses on telling that project’s story accurately.

Open with the task and your role

Give the reader the context in a few sentences: who the work was for, what problem it addressed, which deliverable you owned and the constraints that mattered. If the project is fictional, say so near the beginning. If you worked with others, identify your contribution instead of using “we” to imply responsibility for everything.

A useful opening for a practice project is: “I created a spreadsheet cleanup and summary exercise using six synthetic order rows. I defined the cleaning rules, built the summary and checked the totals. There was no client, live business dataset or commercial outcome.” This is specific without apologising for being a practice sample.

Explain what completion meant. GOV.UK’s user-story guidance treats acceptance criteria as checkable outcomes. For the spreadsheet example, completion means preserving the input, identifying duplicates and missing values, and reconciling the reported total with the included records. It does not mean proving a business became more profitable.

Build the case around decisions and evidence

A two-column case-study spread connects brief, decision, result and limitation to six input rows, an unresolved quantity record and a checked USD 160 regional total.
Connect a portfolio narrative to inspectable evidence — This fictional spreadsheet case demonstrates work and checking without inventing a client or commercial result. Use the enlarged view, then swipe or use arrow keys to inspect details. View full-size infographic.
Read the text version: Connect a portfolio narrative to inspectable evidence
Brief
Summarise Complete orders by region from six synthetic rows.
Decision
Keep a missing quantity unresolved rather than treating it as zero. Show O105 in a review table.
Result
Provide the clean table, review table and checked summary: North USD 100, South USD 60, total USD 160.
Limit
No real client benefit or commercial outcome was measured.

The accompanying input, rule and calculation make the narrative inspectable.

SectionReader’s questionUseful material
BriefWhat was the task?Purpose, inputs, deliverable and acceptance criteria
ConstraintsWhat shaped the work?Data limits, time, tools, access and exclusions
DecisionsWhy did you choose this approach?One or two meaningful alternatives and reasons
EvidenceWhat can I inspect?Sample files, relevant views, calculations or actual test records
ResultWhat was completed or observed?A precise account of the finished output and checks
Limits and next stepWhat remains uncertain?Unresolved issues, untested conditions and the next useful check

Do not narrate every click. Choose the decisions that reveal judgment: how you handled a conflicting record, why you changed a task flow, or how you defined the handover. A tool list can provide context, but it does not explain why the work is useful.

Worked example: a synthetic spreadsheet case

The fictional brief asks for complete-order value by region. The input contains an exact duplicate, a pending order and a complete order with a missing quantity. The analyst keeps the raw file, removes the exact duplicate under a documented rule and places the missing quantity in a review table.

The important decision is not “I used a spreadsheet.” It is: “I treated missing quantity as unresolved rather than zero, so the summary would not hide uncertainty.” Show the affected row and the rule. Explain that a conflicting duplicate would require investigation rather than automatic deletion.

The result is a checked summary of three complete synthetic orders, with a total of USD 160. North contributes USD 100 and South USD 60. The case can show the three included records and the arithmetic. It cannot claim increased revenue, time saved for a real client or satisfaction from people who never used it.

A concise result paragraph might read: “The final sample contains a clean working table, a review table and a regional summary. The included values reconcile to USD 160. One pending order is outside the reporting rule and one quantity remains unresolved. This is an invented dataset used to demonstrate the method.”

Match the strength of the claim to the evidence

Four claim-to-evidence connections distinguish a report artifact, a reconciled calculation, task research and business measurement with causal interpretation; the synthetic case supports only the first two.
Match each portfolio claim to its evidence — The wording of a claim determines what evidence is required. A polished report cannot substitute for measured user or business outcomes. Use the enlarged view, then swipe or use arrow keys to inspect details. View full-size infographic.
Read the text version: Match each portfolio claim to its evidence
ClaimEvidence needed
I produced a report.The report itself.
The total matches the stated rule.The input, inclusion rule and calculation check.
People completed the task more easily.Appropriate observations or research.
The change improved sales.Relevant business measurement and a defensible interpretation of cause.

The synthetic spreadsheet case supports the first two claims, not user or commercial outcomes.

“I produced a report” needs the report. “The total matches the stated rule” needs the input, rule and calculation check. “People completed the task more easily” needs appropriate observations or research. “The change improved sales” needs relevant business measurement and a defensible interpretation of cause. These are different claims, not interchangeable ways to describe a polished output.

GOV.UK’s usability-testing guidance describes observing people attempt tasks. If your project involved such sessions, report who participated in broad relevant terms, what they attempted, what was observed and the limitations of the sample. Do not turn an informal comment into a measured usability result.

When no outcome measurement exists, state the completed deliverable and the checks actually performed. You can also describe a hypothesis for future evaluation, clearly labelled as a hypothesis. Honest limits make it easier for a reader to understand where your evidence ends.

Choose visuals that explain a decision

Use a screenshot, diagram or table because it answers a question. Annotate the relevant portion and explain what changed. A before-and-after comparison is useful only when the versions are genuinely related and the annotation identifies the reason for the change. Keep text readable and provide a text explanation of important information.

For the spreadsheet case, show the duplicate and unresolved row beside the cleaning rule, then the reconciled summary. For a design case, show a task state and the observation that motivated a revision. For a technical case, show a boundary or test result rather than a wall of code unrelated to the claim.

Confirm that you have permission to display client material. Remove confidential details without changing the meaning of the evidence. If permission is unavailable, use a clearly described synthetic reconstruction or choose another project. Follow the guide to show portfolio work honestly when labelling sources, roles and practice work.

Copy the annotated case-study template

Project label: real client, personal project or fictional practice. Task: the reader or buyer problem. My role: exactly what you owned. Inputs and constraints: what was available and excluded. Completion criteria: observable checks agreed or defined before the work.

Decision one: the problem, alternatives and chosen approach. Evidence: the file, view or test that supports the explanation. Result: completed outputs and actual observations. Limit: what was not tested or measured. Next step: the most useful improvement or validation.

  • Can every numerical claim be traced to a source or calculation?
  • Does the opening make the project’s status and your role clear?
  • Are fictional data and illustrative observations labelled where they appear?
  • Does each visual explain something the prose alone makes harder to inspect?
  • Have you separated output quality from commercial outcomes?
  • Can a reader identify the service capability this project demonstrates?

Make the case study useful to a prospective buyer

End by connecting the demonstrated work to a bounded capability. For the example, that might be organising a small permitted dataset and producing a checked summary under agreed rules. It does not automatically qualify the analyst for financial auditing, forecasting or an enterprise data migration.

When you have a coherent offer, use the guide to write a freelance service page to connect the case study with the service. Keep the case focused on the work and evidence. A reader should finish knowing what you can show, how you think and which responsibilities still need separate discussion.

Frequently asked questions

Can a fictional project have a strong case study?

Yes. It can show a clear brief, original work, thoughtful decisions and actual checks. Label the project and data as fictional, and avoid inventing a client, testimonial or commercial result.

How long should a case study be?

Use enough detail to explain the task, your role, key decisions, evidence and limits. Remove activity that does not help a reader assess the work. A narrow project usually needs a narrower narrative than a complex collaborative one.

What if I have no business results to report?

Report the deliverables and checks you actually completed. State that business outcomes were not measured. You can propose a future evaluation, but do not turn that proposal into a claimed result.

Should I show every step of my process?

No. Select decisions that explain how you handled an important constraint or uncertainty. A long sequence of software actions is less useful than one well-supported explanation of why you chose an approach.

Can I use a client screenshot after removing the name?

Removing a name may not be sufficient. Obtain the appropriate permission and consider whether the remaining content is confidential or identifiable. If necessary, use a clearly labelled synthetic example instead.

How do I describe team work honestly?

Identify the shared context and then state your own responsibilities, outputs and decisions. Credit other contributors appropriately. Do not imply that a complete product or outcome was solely your work when it was not.