A portfolio can help a beginner show a real ability before they have a long professional history. But a glossy mock-up is not the same thing as evidence that you solved a problem. A strong case study explains the situation, your role, how you worked, what the outcome really was and what you would change. This guide is for students, career changers and self-taught creators building a trustworthy portfolio without inventing clients or results.
Choose a project relevant to the work you want
Start with a university assignment, prototype, volunteer activity, independent app or small research project. Ask what skill it demonstrates that a prospective employer or collaborator needs. A visually impressive project may be less relevant than a modest one with clear reasoning and documentation. Do not present group coursework as if you built every part yourself. If a project used a tutorial, say which parts came from that resource and what you modified. Relevance and honesty help readers understand the level of your actual experience.
State the problem and constraints in plain language
Describe who the project was for, what outcome you hoped to achieve and what limits you faced. Was it a two-week class assignment, a voluntary website refresh or a conceptual design with no live users? These details are not embarrassing; they make your decisions understandable. Mention available resources, timeline, accessibility requirements and any applicable scope restrictions. Do not claim to have solved a market-wide issue when you tested a prototype only with classmates. A reviewer should be able to understand the project without learning all its technical jargon.
Explain your own contribution and decision-making
Use a few clear stages: initial question, options considered, key decision, implementation and evaluation. Show relevant artifacts, such as a wireframe, query, anonymized spreadsheet, short diagram or before-and-after navigation sketch. Explain why you chose one approach over another. If a teammate wrote half the code, acknowledge shared work while describing your portion. Avoid leaking client data, student records, passwords or source code you are not allowed to publish. Screenshots should not reveal private user information.
Show the outcome without manufactured success
Did the prototype run? Were the tests completed? What did the feedback show, and what remains unverified? Numbers can strengthen a case study when real, but do not invent percentage improvements, market demand or revenue. If the project failed to meet an objective, explain the reason and lesson. A junior applicant who notices a limitation and proposes a sensible next test may show more maturity than someone who writes ‘100% success’ with no measurement method. Keep opinions separate from observed results.
Make the case study easy to scan and accessible
Use an informative title, a brief opening summary, three to five meaningful headings and images with text descriptions. Make tables readable on mobile and avoid putting essential evidence in tiny screenshots. Explain acronyms and give links clear labels. A PDF may be suitable for some applications, but an accessible webpage or readable text version can be easier to review. Include a link to working code or a demonstration only when it is secure, stable enough to share and clearly described. Broken or permission-restricted links undermine the work.
End with one specific learning and next iteration
What would you test with more time, better data or genuine users? Distinguish this future plan from work you already completed. A reflection might explain that the first layout was confusing, so the next version would test two navigation labels on mobile. That shows thoughtful iteration without overclaiming. Update your portfolio when you improve the project, and remove outdated screenshots or inaccurate descriptions. Select a few meaningful case studies instead of posting every experiment as a polished success story.
A realistic example
A student has built a food-planning prototype with friends. The case study begins with the problem of planning meals from available ingredients, describes the student’s role designing the search interface, shows an annotated wireframe and explains how test participants found one label confusing. It ends with a revised design and a plan for additional testing. The student does not claim the app has active paying customers because it has not been launched. The case study shows real design reasoning even without a commercial result.
Seven-step checklist
- Pick a project relevant to the target role
- State whether it was coursework, volunteering or independent work
- Explain the problem, audience and constraints
- Show your personal contribution and decisions
- Document real results and limitations
- Use accessible images and descriptive links
- Finish with a realistic next iteration
Frequently asked questions
Can I include unfinished projects?
Yes, if you clearly describe the stage, current limitations and what you actually completed.
Should I show a client logo?
Only when you have appropriate permission and the use does not imply an endorsement that does not exist.
Do I need impressive statistics?
No. Clear evidence and honest evaluation matter more than fabricated performance metrics.
Related Better Lifestyle guides
Continue with Entry-level CV from projects or Test a business idea. Or explore the Practical Guides Library for more free reading.
Sources and editorial note
- Harvard career services: resumes, CVs and cover letters
- W3C accessibility guidance for informative images
General educational information. Worked examples and checklists were created for this article; they are not measured outcomes. Follow local safety guidance and seek qualified support for health, legal or financial matters when needed. Edited October 2026. Read our editorial and advertising standards.
