A career-change portfolio should answer a small question: can you perform a relevant task and explain your decisions? It cannot turn a practice exercise into professional experience. The strongest starting sample is often modest enough to finish, inspect and discuss. It shows where your existing experience helps and where you still need supervision or training.
Begin with a task that appears in the actual work
Use occupation descriptions and role requirements to identify one observable task. O*NET's skills resources help connect a skill to occupations worth exploring; they do not certify that you can do the work. A task might be organizing a messy dataset, writing a short support guide or preparing a project handover. “Become a data analyst” is not a usable project brief.
Ask what a competent reviewer would inspect. A dashboard without clear input assumptions may be less useful than a small, well-documented analysis. A polished help page is stronger when you can explain who it serves and how you checked that the instructions work. Choose the task before the software or visual theme.
Write a brief with a boundary
State the intended user, input, output and completion test. For a hypothetical operations sample: use a synthetic stock list, identify missing or inconsistent fields, produce an exception report and explain what would need a human decision. Label the data as synthetic and do not imply that the exercise improved a real company's operations.
Define what is out of scope. You might exclude production deployment, financial recommendations or handling private customer information. A boundary gives you a way to finish and prevents a practice exercise becoming months of unfocused work. Use the 90-day evidence budget to see whether the task fits your actual available hours.
Use material you are allowed to show
Create original or synthetic inputs, or use public material whose terms permit your intended use. Publicly visible does not automatically mean unrestricted. Do not export your employer's files, client lists or internal screenshots for a personal portfolio. Permission to use information in your job is not the same as permission to publish it.
If a previous project is confidential, describe the general kind of problem without revealing its protected details, and create a separate original demonstration. Obtain appropriate permission before showing anything that belongs to another person or organization. When in doubt, leave it out and explain the limitation in the interview.
Show the reasoning, not only the final artifact
Keep a short decision log: the question you were trying to answer, the alternatives you considered, what you checked and what remains uncertain. Include a before-and-after view only when the comparison is meaningful and the material is safe to publish.
Do not invent a performance improvement. If you have not measured a real outcome, say what the sample demonstrates instead: consistent formatting, a tested calculation or a clear handover. CareerOneStop distinguishes technical and transferable workplace skills; your commentary can show both without claiming an employment result that did not occur.
Ask for feedback that can change the sample
Ask a relevant person whether they are willing to review a small artifact. Give them the brief and two specific questions, such as whether the output is understandable and which error would make it unusable. Respect a refusal or lack of response. A reviewer is not automatically a reference, mentor or hiring contact.
Record feedback, make a limited revision and explain what changed. Do not keep revising indefinitely to avoid applying or making a decision. A sample can be useful even when feedback shows that the target task is not a good fit for you. That is evidence, not a failed identity change.
A worked sample brief: a support handover
Here is a fictional practice brief, not a client story. Imagine that a small team needs a handover guide for a recurring support question. Create an original, non-sensitive process such as explaining how to submit a repair request for an imaginary shared workspace. The output is a one-page guide and a short list of unresolved questions.
Set three checks: a reader can identify the first action, can tell which information is needed and can see when to escalate. Ask a willing reviewer to follow the instructions using fictional details. Record where they hesitate. Your result is not “reduced support costs”; it is a tested revision to an original guide. The evidence you can show is the brief, the first draft, the feedback and the revised version. This small packet is easier to discuss than a polished page with no explanation of how it was checked.
Prepare an honest explanation
Use a simple structure: “This is an independent practice project. I chose this task because it appears in the work I am researching. Here is what I did, what I checked and what I would need to learn before doing it in a real organization.”
Add the sample to your evidence card only with its practice status intact. Then compare it with the requirements audit. One artifact may support one requirement while leaving several others unanswered. The portfolio becomes useful when it makes that distinction visible, not when it disguises the gaps.
Evidence to gather next
- Choose one target task, not an entire profession.
- Write an original brief using public or synthetic material.
- Record feedback and distinguish practice from paid work.
A question worth separating
Can a practice project go in my portfolio?
Yes, if you label it as practice and have permission to show all included material. Explain the brief, your own contribution and its limitations. Never present a fictional organization as a paying client or an exercise as paid employment.