A practical junior UX portfolio checklist.

Choose projects for a purpose, not a target count

Start with the kind of work you want to discuss: interaction design, research, visual systems, or a combination. Select projects that give you concrete decisions to explain in that area. There is no universal project count that makes a portfolio ready. One understandable project is a better starting point than several nearly identical stories that hide your contribution. Keep unfinished work when its status and learning value are clear.

Make an inventory with the project type, your contribution, available evidence, and sharing restrictions. Avoid choosing solely by the attractiveness of the final screens. The strongest candidate for inclusion may be the one where you can explain a constraint and a considered trade-off.

Make the opening answer practical questions

A project opening should identify the setting, the task, your role, collaborators, and the current status. Distinguish classroom or independent work from employment. If a team produced the project, specify which decisions you owned and which you supported. You do not need an inflated title to describe a useful contribution. Replace a paragraph of tool names with a short explanation of what you were responsible for deciding.

Check the story at two reading depths

First read only the headings, captions, and summaries. They should reveal the main question, an important decision, and the status of the result. Then read the full narrative and check that the evidence supports those summaries. Avoid forcing readers through every workshop artifact. Keep a diagram because it explains a decision, not because a design process diagram says that stage should exist.

For each included artifact, ask whether a reader can identify its purpose without hearing you present it. Remove repeated screens or explain the specific difference. Keep detailed supporting material separate from the main argument when it interrupts the story.

• Label observations, interpretations, and assumptions distinctly throughout the project.
• Include a relevant alternative and explain why it was not selected.
• Describe limitations beside the claim rather than hiding them in a footer.

Review the portfolio as an interface

Open the shared version, not just the design file. Test navigation using the keyboard and check that focus remains visible. Try a narrow viewport, enlarged text, and a slower connection. Read screen annotations without zooming into a decorative device mockup. Provide text explanations for meaningful diagrams and avoid putting the entire case study inside images. Give links descriptive names so their destinations are understandable outside the surrounding paragraph.

Check contact links and downloads from a signed-out session. Make sure the intended reader can open the project without requesting access. Automated accessibility checks can help identify some problems but cannot certify the portfolio as compliant. Combine them with manual review, and record limitations you have not yet resolved.

Run a permission check and prioritise the last fixes

Verify permission for employer work, participant material, screenshots, fonts, and other assets. A password does not override a confidentiality agreement. Do not share raw research notes or ask a reviewer to handle sensitive information. When permission is unclear, describe an allowed aspect of your role or omit the project. Never replace withheld evidence with invented testimonials or outcomes.

Ask a peer to tell you what they understood: the problem, your contribution, and the strongest supported decision. Their response is feedback about your communication, not hiring validation. Sort fixes into blockers, clarity improvements, and optional polish. Repair inaccessible content, broken links, and misleading claims first. Keep a dated review list so you know what changed before your next application. A finished checklist cannot promise interviews or an offer.