YOUR FIRST UX CASE STUDY / LESSON 6 OF 6
Review the case study and share it responsibly.
Audit truthfulness, permissions, readability, and accessibility, then use a focused peer review to prepare a clear version you are allowed to share.
Read the story as someone outside the project
Put the draft aside briefly, then read only its title, headings, captions, and closing summary. Can a reader identify the problem, your contribution, an important decision, and the current status? Check that Neighbourhood Classes is still labelled as fictional wherever an excerpt might be shared independently. The polished presentation must not imply a real community-centre partnership. Replace unexplained jargon and process labels with plain descriptions. Remove artifacts that repeat a point without adding evidence, and keep the most useful decision easy to find.
Audit claims and permissions before presentation polish
Trace every research or outcome statement to your ledger and the material you are permitted to use. Check dates, authorship, template credits, and asset terms. Do not include raw notes, recordings, contact details, consent forms, or sensitive screenshots in the case study. Removing a name may not prevent identification. Keep unpublished evidence restricted and follow your deletion plan. If a real employer or collaborator has not authorised sharing, do not treat a password or a private link as a substitute for permission.
Check the actual reading experience
Review the exported or published version, not just the source design. Make sure text is readable on a narrow screen and when enlarged. Check headings, link names, keyboard focus, contrast, and text explanations for meaningful images. Test downloads and shared links without your editor account. Automated tools can highlight some issues but cannot certify accessibility compliance; manual checks and appropriate implementation review remain necessary. For a document, inspect selectable text and reading order. Record unresolved problems rather than advertising the work as fully accessible.
Ask a peer about understanding, not approval
Give a reviewer a focused question and let them inspect the case study without a long verbal introduction. Ask what they understood before explaining what you intended. Their response helps you improve communication; it is not proof that the product works or that a hiring team will approve it. Capture feedback as review notes, not as user research.
Release a bounded version and keep the next step small
Sort feedback into misleading claims, access or reading blockers, clarity improvements, and optional polish. Fix the first two categories before sharing more widely. Save a dated version and a short list of remaining questions so later revisions are traceable. You can keep the work local while permissions or accessibility issues are unresolved; public posting is not a requirement for completing the exercise. When ready, share only the authorised version. The result is a practice case study, not a certification, a validated service, or a guarantee of employment.
YOUR TURN / A SMALL, CONCRETE NEXT STEP
Complete a pre-share review
- Audit claims and sharing permissions, then remove private or unsupported material.
- Review the actual export or page on a narrow screen, with enlarged text and keyboard navigation where applicable.
- Ask a peer to explain the project status and one decision without your narration.
- Fix one clarity issue and record unresolved checks before choosing whether to share.
Your deliverable: A reviewed case-study version, a completed self-review checklist, and a dated list of remaining limitations and next steps.
A personal checklist, not an assessment. Mark it when you’re ready.