A portfolio case study should help a reader understand what you contributed and why the work took its final form. Screenshots can show the result, but they rarely explain the constraints, alternatives and decisions that shaped it. Start by gathering evidence of the work before choosing a presentation template. Then build a narrative that is accurate about your role, clear about what was observed and honest about what remains unknown. This guide is an editorial writing method, not a claim about how any named designer on this site completed a project.
Nielsen Norman Group's guidance on UX design portfolios emphasizes showing the design process and the reasoning behind work, rather than relying only on polished final screens. The approach below develops that broad principle into a practical editing sequence. It does not promise hiring results or prescribe a single case-study structure. A useful case study can be short or detailed, provided the reader can connect its claims with the evidence you actually have.
Define your role before describing the project
Write down what you personally did, what collaborators did and which decisions belonged to someone else. Use specific verbs: drafted the interview guide, produced the interaction prototype, synthesized workshop notes or implemented the layout. Broad claims such as designed the entire experience can conceal important distinctions. If responsibilities changed during the project, describe the change. A reader should not have to infer individual ownership from a team deliverable displayed under one person's name.
Record the project's context without disclosing confidential information. Identify whether it was professional work, a class assignment, a personal exploration or an unsolicited concept. Those contexts support different kinds of claims. A speculative redesign can demonstrate careful reasoning, but it should not be presented as commissioned work or as a product that reached users. Put that distinction near the beginning rather than burying it in a caption after a reader has formed the wrong impression.
Collect artifacts with their dates and purpose
Gather the material that supports the story: sketches, requirements, prototypes, feedback, decision notes and final outputs. For each artifact, note when it was created and what it was used for. An early exploration and a final specification may look similar once placed in a clean portfolio layout. Their purpose is what makes them evidence. Keep the original records separate from any presentation copies you crop, annotate or simplify for publication.
Remove or redact private information before placing an artifact in a public draft. Check names, addresses, account details, internal comments and hidden layers. If you cannot publish a source artifact, explain the limitation and use an accurately labelled abstraction where appropriate. Do not recreate a fictional research result merely to fill a visual gap. An honest text explanation of a constraint is more useful than a polished diagram that implies evidence you cannot substantiate.
Select a decision that carries the story
Choose a decision that reveals something meaningful about your contribution. It might concern how to group information, which task to prioritize or why a proposed interaction was removed. State the alternatives considered and the constraints that mattered. Avoid listing every workshop or design method as though completing activities were itself the outcome. The reader needs to understand how the work changed the available choices and why the final direction was selected.
Keep the decision specific enough to show tradeoffs. Saying the interface became simpler is less informative than explaining that two similar actions were separated because they led to different consequences. If the evidence was incomplete, say so. A decision made under time or access constraints can still demonstrate judgment when those constraints are visible. Retrospective certainty is not required, and it often makes a case study less believable than an account of the actual uncertainty.
Connect each claim with the right evidence
Different claims need different support. A screenshot can demonstrate that a label changed, but it cannot establish that the change improved retention. A research note can describe what participants did in a particular session, but it does not automatically explain behavior across an entire customer base. Before writing a result, identify the source that supports it and the limits of that source. If there is no evidence for a claim, remove it or frame it as an intended outcome.
Separate observations from interpretation in your working draft. A participant's action belongs in one category; your explanation of why it happened belongs in another. Preserve uncertainty where multiple explanations are plausible. This discipline can make the final prose more direct: you can state what was observed clearly, then explain the inference without pretending it is a measured fact. It also makes the case study easier to update if later evidence changes the interpretation.
Use numbers only when their meaning is clear
If a project includes a measured result, record the metric's definition, time period, source and relevant comparison. Check whether you are reporting a count, a percentage or a relative change. Do not invent a performance figure because portfolio examples commonly include one. A project without reliable outcome data can still show the quality of a design decision, the deliverable produced and the questions left for a future evaluation. State those contributions on their own terms.
Avoid assigning the full credit for a business result to one interface change when several things changed together. If attribution is uncertain, describe the result and the limitation separately. Where you cannot share an exact figure, do not substitute a made-up range. Explain the confidentiality constraint or omit the number. Readers benefit from a modest claim they can interpret more than from an impressive statistic whose origin and meaning are impossible to establish.
Make before-and-after images answer a question
A visual comparison should show a relevant difference, not merely decorate the page. Use consistent crops and enough context for the reader to understand the task. Caption what changed and why it matters to the decision being discussed. If the images come from different stages or contain different sample content, make that clear. Otherwise, the reader may attribute a visible difference to the design when it actually comes from the example data or the presentation treatment.
Keep text readable in the published image and provide an explanation outside the image for important information. A long screenshot reduced to a narrow column may be visually impressive while conveying very little. Consider showing one relevant section at a useful size and linking the surrounding narrative to it. Do not claim the visual proves usability on its own. It is evidence of the artifact; the evidence about how people used it belongs in the accompanying account.
Test the story with a fictional project
Imagine a personal concept for a library booking interface. The designer reorganizes the availability display and produces an interactive prototype, but has not tested it with library users. An accurate case study can explain the assumed task, the competing layouts and the rationale for the chosen display. It can also identify the questions a future study should examine. It cannot honestly claim reduced booking errors or increased satisfaction without evidence that those outcomes occurred.
If the concept later receives a small exploratory review, the case study can add the actual observations, participant context and limitations. It should not retroactively turn the original assumptions into validated requirements. Versioning the story matters because evidence accumulates over time. A dated note about what changed in the case study helps distinguish the original design from a later interpretation. The fictional example illustrates an editorial boundary, not a prescribed research design or a promised outcome.
Finish with contribution, limitations and next steps
End by stating what was delivered, what the evidence supports and what remains unresolved. A useful next step should follow from a real uncertainty rather than from a generic plan to do more research. If a project ended before evaluation, say what evaluation would need to examine and why. If the work shipped, distinguish the shipped artifact from later ideas that appear only in the portfolio. This keeps the conclusion aligned with the rest of the evidence.
The portfolio and the editorial blog serve different purposes; new guides are not attributed to the historical portfolio owner. See the editorial policy for that distinction. When preparing your own case study, prioritize a clear account of responsibility and reasoning. A reader should leave knowing what you did, why you did it and how confidently the available evidence supports the result you describe.