Start with the question your reader wants answered
A portfolio case study should help someone understand how you work, not just admire what you made. A potential client, collaborator or hiring manager may want to know what needed to change, what constraints you faced, what you contributed and whether the result addressed the original need. Write for that reader rather than treating the case study as a chronological record of every meeting and draft.
Before drafting, collect the project brief, relevant notes, early concepts, feedback, final deliverables and any approved information about the outcome. Then write a one-sentence summary: “A small team needed a clearer way to explain its services, so I redesigned the service pages and created a reusable page template.” This sentence gives you a thread to follow. If a detail does not help explain the problem, your decisions or the result, it probably does not need much space.
Define the problem and your role
Open with enough context for a reader who has never heard of the project. Describe who the work was for, what the audience needed and what was not working. Distinguish the request from the underlying problem when you can. “The client asked for a new homepage” describes an assignment; “Visitors struggled to tell which service fit their needs” explains why the assignment mattered. If you did not verify the underlying problem, present it as the team's concern or working assumption rather than a proven finding.
Next, make your responsibilities unmistakable. Name the deliverables you owned, the stages you participated in and the people or disciplines you worked with. For a group project, “I wrote the content outline and built the prototype; another team member led the visual design” is more informative than “we created a website.” Students can do the same for classroom work, including the scope and constraints of the assignment. Clear attribution makes your contribution easier to assess without minimizing the team.
Show the decisions that shaped the work
The middle of a case study should connect actions to reasons. Choose two or three decisions that reveal your approach: how you narrowed the scope, selected a direction, responded to feedback or handled a constraint. For example, a freelancer designing a brochure might explain that the client needed something staff could update, so the final layout used a simple template rather than highly customized pages. A student might describe how limited testing time led them to focus on the most important user task first.
Use process images only when they help tell that story. A sketch, draft, content map or before-and-after view can make a decision easier to understand, but add a short explanation of what the reader should notice. Avoid presenting every iteration as a smooth progression toward an inevitable answer. If an early idea did not work, briefly explain what you learned and what changed. That is often more useful than a gallery of polished screens with no account of how they came to be.
Describe the outcome with appropriate evidence
State what was delivered and what happened after delivery, keeping those points separate. “We launched a set of five page templates” is a deliverable. “The team now uses them to publish new pages” is an outcome, if you know that it happened. If you have permission to share relevant feedback, observations or measurements, explain what they indicate without claiming that your work alone caused a change. Give the reader enough context to understand the evidence, including any limits that matter.
Not every project has measurable results. A concept project may never launch; a recent handoff may not have follow-up information. In those cases, say so plainly and discuss what the finished work made possible, what was validated during review or what remains untested. Do not invent a success metric to complete the story. You can end with a short reflection on what you would improve next time, especially if it shows how the outcome informed your thinking.
Edit for clarity, permission and easy scanning
Once the full story is written, check whether a reader can find the essentials quickly: problem, role, approach, deliverables and outcome. Give each part a clear heading, place the strongest relevant image near its explanation and define any specialized terms. Captions can identify what an image shows and why it matters. If the project was completed by a small team, a compact role summary near the top can prevent confusion throughout the piece.
Finally, review what you are allowed to share. Remove private client details, unpublished work, personal information and internal feedback unless you have permission to include them. Where necessary, use an approved excerpt or describe a constraint in general terms. A strong case study does not depend on revealing everything. It gives an honest, selective account of a real problem, the choices you made and the outcome you can support.
