Write a Portfolio Case Study That Shows Your Decisions

State the problem before showing the output

Begin with the audience and the difficulty they faced. For example: A volunteer team was collecting event registrations in several separate lists, making it hard to know which version to use at check-in. The case study's question is how to create a clearer working record. Avoid presenting a solution as inevitable. A reader should understand why the work was needed before being asked to admire the final spreadsheet or page.

Define your role and the boundaries

Explain whether the project was paid, voluntary, academic or self-directed. Name your responsibilities and distinguish them from those of a team or supervisor. Include the time frame and relevant constraints, such as an existing tool or a fixed event date. If you only redesigned a sample process without access to real users, say so. Clear boundaries make a modest project more credible than an impressive description with an ambiguous role.

Show the information that shaped your choices

Describe the material you reviewed and how you identified the main issue. In the fictional example, you might compare the fields in three sample lists and find inconsistent spelling and duplicate records. Explain the limitation: a sample exercise does not establish how a live organization would behave. When real research exists, summarize it accurately and protect participants. Do not invent interviews, testing sessions or survey results to make a case study sound complete.

Explain two or three important decisions

For each decision, show the alternative and the reason for choosing it. A single shared record might be easier to maintain than separate daily files; a status column might distinguish confirmed registrations from open questions. Include a small annotated image or a short text example if useful, but explain what the reader should notice. A case study is not a complete activity log, so select decisions that reveal your judgment.

Describe the result and its limitations

If the tool was used, report what you actually observed. If it was only a prototype, describe what it makes possible and what still needs testing. For example: The sample record groups attendee names, confirmation status and unanswered questions in one view; it has not been tested at a live event. Do not translate your own impression into a business result or fabricate a percentage improvement. An honest limitation identifies the next useful step.

Package the work for a real reader

Use clear headings, a short opening summary and a visible explanation of your contribution. Test links and remove private information from screenshots, document properties and filenames. If you cannot share client work, ask permission or build a new fictional sample rather than lightly disguising restricted material. End with a concise reflection: what you would keep, what you would change and what evidence you would collect before expanding the solution.

Your working checklist

Checkmarks stay in this browser when storage is available. They do not submit a form or complete a booking.

• A project you have permission to discuss.
• Notes on the problem, constraints and decisions.
• Safe work samples using public or fictional information.

Put it into practice

1. Write a problem statement and role statement before selecting screenshots. Confirm whether the project was real client work, voluntary work, coursework or an independent exercise.
2. Choose three decisions that explain your contribution, then gather the supporting notes or safe sample artifacts. Remove claims of research or testing that did not occur.
3. Describe the outcome using only observed evidence and identify the limits. If the project is a prototype, explain what would need to be tested before real use.
4. Publish a readable draft, check it as an outside visitor and remove private data. Ask a reader to explain your role and strongest decision after reviewing the page.

Common questions