Portfolio Guide: Build a CV-Supporting Portfolio

The Portfolio Guide rule is simple: the format should match how a recruiter or hiring manager will review the work. A personal website can work well for design, UX, frontend, writing, product, photography, marketing, and freelance work because it gives the reviewer a quick route through selected evidence. A PDF can work better when you need a controlled, offline, or restricted version. A GitHub profile may support engineering roles, but it usually needs a short explanation of which repositories matter and why.

Do not assume that a more elaborate platform will make weak evidence stronger. A simple PDF with three excellent case studies is better than a polished website full of vague project tiles. Equally, a beautiful design portfolio can fail if it does not explain the brief, your role, the decisions you made, and the outcome.

When choosing the format, ask:

• Will the reviewer understand what to click first?
• Does the format load quickly and work on mobile?
• Can the portfolio be opened without a login?
• Can you tailor or reorder pieces for different roles?
• Can restricted work be protected without making the portfolio feel empty?
• Does the format support accessibility basics, such as readable text, headings, link labels, and alt text?

If you use a portfolio website, check practical accessibility guidance. The W3C WCAG 2.2 standard and the GOV.UK accessibility introduction are useful references when you are building or reviewing a public portfolio site. You do not need to become an accessibility specialist to apply the basics: use real text instead of text embedded in images, add descriptive link labels, keep contrast readable, and make sure the main content can be navigated clearly.

Create a shortlist table with five columns: project name, target relevance, your contribution, result or evidence, and risk. Give each project a simple high, medium, or low score.

The risk column is important. Some projects are risky because they are restricted by client permission. Some are risky because they are old and no longer reflect your level. Some are risky because they look good but were mostly done by someone else. Some are risky because they belong to a role direction you no longer want.

Choose the pieces that score highly for relevance and ownership, then decide whether the risk can be managed. If the risk cannot be managed, leave the project out or replace it with a safer version.

For example:

• A UX case study from a live client project may be highly relevant, but needs anonymised screenshots and careful wording.
• A university design project may be older, but still useful if it shows research, iteration, and a strong final outcome.
• A content campaign may need exact figures removed, but can still show the brief, audience, message strategy, and type of result achieved.
• A developer side project may be useful if the code is readable and the readme explains the problem, trade-offs, and next steps.

A portfolio for job application use should feel current even when some work is older. You can do that by adding a short note about what you would improve now. This shows reflection without pretending the project is perfect.

You do not need paid client work to build a useful portfolio. For early-career applicants, career changers, graduates, and candidates returning after a break, a portfolio can include study projects, mock briefs, personal projects, voluntary work, open-source contributions, community projects, competitions, writing samples, process documents, or before-and-after improvements.

The standard in this Portfolio Guide is not whether someone paid you. The standard is whether the sample proves relevant ability. A self-initiated project can be useful when it has a clear brief, constraints, process, and outcome. A mock project becomes weak only when it looks like a generic exercise with no reasoning behind it.

If you are using a personal project, give it a realistic frame. Instead of saying you redesigned a famous app because you liked the brand, explain the user problem you focused on, the assumptions you made, the constraints you set, and how you would test it. If you wrote sample content, explain the audience, goal, channel, and tone. If you built a small web app, explain the stack, feature decisions, accessibility checks, and what you would improve with more time.

Student and early-career applicants can also use external application guidance to understand how portfolios support selection. Prospects gives wider UK careers context around CVs and cover letters, while UCAS portfolio guidance is useful for applicants who are presenting creative or course-related evidence.

Collaborative work is normal. The problem is not collaboration; the problem is unclear ownership.

Instead of writing, We redesigned the checkout journey, write something more specific: I mapped the existing journey, identified four high-friction points from support tickets, drafted revised content for the payment and delivery steps, and worked with the designer to test two versions with five users.

Instead of writing, I supported a campaign launch, explain the work: I wrote three email variants, built the campaign calendar, checked performance after launch, and used the results to recommend a simpler subject-line approach for the next send.

Specific contribution builds trust. It also helps you avoid overclaiming. A hiring manager will usually respect a clear, honest role description more than a grand claim that hides the team effort.

Outcomes do not always need to be large numbers. A useful outcome might be a shipped feature, a clearer user journey, a faster manual process, a published report, improved engagement, fewer support queries, positive feedback, a decision made by stakeholders, or a stronger understanding of what did not work.

When you have numbers, use them carefully. Do not invent metrics. Do not imply that you alone caused a result when several factors were involved. If the figure is sensitive, use a broader phrase such as contributed to improved completion rates or helped the team identify a recurring support issue.

If there was no measurable result, explain the quality of the output and the learning. For example: The project did not go live, but the prototype helped the team compare two routes and choose a simpler onboarding flow. That is still useful evidence if the role values product thinking.

A portfolio is often skimmed. Use headings, short paragraphs, captions, and bullets. Put the core story near the top. Avoid making the reviewer scroll through twenty process images before they know what the project was about.

For a long case study, add a short summary at the start:

Project: onboarding flow redesign for a subscription app. Role: UX/UI designer responsible for journey mapping, wireframes, prototype, and usability test plan. Outcome: simpler first-use route and clearer handover notes for development.

That kind of summary lets the reviewer decide whether to keep reading. It also helps when the portfolio link is opened quickly during shortlisting.

A weak safe summary says: Worked on a confidential project for a client.

A stronger version says: Supported a B2B onboarding project for a regulated service. I mapped the existing sign-up journey, identified where users needed clearer guidance, and drafted revised screen content for the first three steps. The final recommendations helped the team agree a simpler route for development.

That version does not reveal the client. It still shows sector context, work type, contribution, and value.

You can also use a short note on the portfolio page: Some project names and details have been removed or adapted to respect client permissions. That reassures the reviewer that any missing detail is intentional.

A portfolio link works best when the CV gives a reason to open it. Your profile, skills, and experience bullets should point towards the evidence the portfolio contains.

If your profile says you are a UX designer with strengths in research and accessible product journeys, the portfolio should show research and accessible product journeys. If your CV says you are a content marketer with search-led writing and campaign reporting experience, the portfolio should not lead with unrelated creative writing samples.

Use CV structure to decide where the link belongs, CV personal statement examples to align the opening profile, skills on CV to select the right evidence, and work experience on CV to connect portfolio outcomes to employment history. If you are rewriting the whole application, start with how to write a CV, then use this Portfolio Guide to strengthen the proof behind it.

If you are worried about automated screening, keep your CV readable and text-based. A portfolio can carry visual or project evidence, but your CV still needs clear job titles, skills, dates, and achievements. The ATS-friendly CV guide can help you keep the CV searchable while the portfolio carries the deeper examples.

Show the problem, users, constraints, options considered, decisions made, and final outcome. Include enough process to prove your judgement, but avoid turning every case study into a long diary. Hiring teams often want to see how you frame problems, collaborate, handle ambiguity, and respond to evidence.

A strong UX portfolio might include one end-to-end case study, one focused research or usability example, and one smaller interaction or design-system improvement. If you are junior, use study or self-initiated projects, but make the brief realistic.

Do not rely only on screenshots. Show the live project where possible, link to code when appropriate, and explain technical decisions. Mention accessibility, responsiveness, performance, API handling, testing, reusable components, and trade-offs. A short readme can be as important as the finished page.

If the code is old, say what you would refactor now. That honesty can show growth. If the project is private, describe the feature, stack, constraints, and your contribution without exposing restricted code.

Choose samples that match the writing the job needs. A content designer may need flows, help content, audits, and before-and-after examples. A copywriter may need ads, landing pages, emails, scripts, and campaign concepts. A content marketer may need articles, search strategy, reports, and distribution results.

Explain the audience, brief, channel, constraints, and outcome. Do not just upload finished copy. The reviewer needs to see that you can write for a purpose, not just write neatly.

For roles where the output is not always visual, use project summaries, artefacts, frameworks, presentation excerpts, roadmap examples, discovery notes, or anonymised delivery case studies. Focus on decisions, alignment, prioritisation, risk, stakeholder management, and outcomes.

A product portfolio should not pretend you designed every screen. A project portfolio should not expose restricted plans. Show how you helped people make decisions and deliver work.

Curation matters. Put your strongest and most relevant work first. Group work by type, client, medium, or direction. Explain enough context for the viewer to understand the brief, but let visual quality do some of the work.

If you want commercial work, show pieces that look commercially usable. If you want editorial work, show editorial thinking. If you want animation or motion design work, make reels short, labelled, and easy to play.