A group project looks impressive but a portfolio viewer cannot tell which work you personally did. This guide focuses on clear information and a low-risk first experiment instead of promises of overnight transformation. Begin by describing the real decision and the people affected by it.
Frame a question worth answering
A plan cannot be evaluated until its purpose is visible. Define the intended user, the problem they experienced recently, and the smallest improvement that would matter. Separate direct observations from assumptions. If money, another person’s time or a legal obligation is involved, treat that as a constraint, not an afterthought.
From idea to small experiment
- Define: Explain the initial problem, audience and constraints. Keep a brief record of what you learned and which questions remain unanswered. Where another person’s data or participation is involved, seek genuine permission.
- Investigate: Name your own tasks and distinguish teammates’ contributions. Keep a brief record of what you learned and which questions remain unanswered. Where another person’s data or participation is involved, seek genuine permission.
- Test: Show one key decision and evidence of iteration. Keep a brief record of what you learned and which questions remain unanswered. Where another person’s data or participation is involved, seek genuine permission.
- Learn: Obtain permission before displaying client or collaborator assets. Keep a brief record of what you learned and which questions remain unanswered. Where another person’s data or participation is involved, seek genuine permission.
A realistic worked scenario
A developer describes the navigation logic they implemented while crediting a teammate for interface design. This imagined example illustrates a decision process, not a case study from an actual customer. Its important feature is a bounded test with a known participant, time frame or measurable outcome. Do not invent success metrics before observing real results.
Choose evidence you can actually collect
Useful evidence might include whether someone could complete a task unaided, whether a participant returned voluntarily, or whether a clarified process avoided a second round of questions. A small pilot may reveal serious design problems, but its results should not be described as a representative survey or proof of market demand. If the evidence is mixed, note that uncertainty directly.
A risk to guard against
Never copy confidential dashboards or claim sole authorship of a team deliverable. Write down the limitation before testing, explain it openly to anyone affected, and stop an experiment that creates a disproportionate burden or privacy concern. The ability to change course is part of responsible planning.
Quick worksheet
- The decision or problem: __________
- What we know from direct observation: __________
- What we are assuming: __________
- One experiment small enough to reverse: __________
- The person responsible for consent and quality: __________
- What would cause us to stop or redesign: __________
- Next review date: __________
What to do when the test fails
Failure is information only when the assumptions and observations are recorded. Do not hide the negative result under a new title or simply repeat the same promotional message. Ask whether the target user had the problem, whether the solution addressed it, and whether the time or money required was justified. Sometimes the sound decision is to end the project.
One useful action today
Draft a case-study outline with a clear personal contribution statement. Share the smallest version with an appropriate collaborator, not a broad audience. Revise it once based on actual feedback.
Continue with our free decision and learning tools and practical guides. Independent practical article. Examples are illustrative, and legal or professional obligations should be verified where relevant.
Credit your real contribution in a portfolio story
A strong case study is not a gallery of screenshots alone. Describe the challenge, your responsibilities, the people involved, the design or technical decisions, the result you can verify and what you would improve. If you collaborated with developers, researchers or designers, distinguish what each person contributed rather than implying you personally built everything.
Suppose a student helped improve a prototype marketplace with two teammates. The case study might say: “I mapped the seller-upload journey, interviewed three volunteer testers and drafted accessibility acceptance criteria. A teammate built the payment mockup; another created the visual brand.” If there are no measured conversion results, describe the deliverable and qualitative test observations without inventing revenue or percentage improvements.
Publish only what you have permission to share
Remove secrets, unreleased product details, private customer information and copyrighted material you are not authorized to display. If your work is governed by an employment or client agreement, confirm what can be shown. Screenshots should be readable, have descriptive alternative text and avoid exposing personal profiles.
Include a small “Lessons and limitations” section. Credible hiring managers can value sound judgment and teamwork more than exaggerated metrics. Explore related skill-building through Learning Paths.
