Building a Portfolio as a Product Designer in 2026

Every design hiring manager we know has a version of the same complaint. They open a portfolio, scroll past a beautiful hero image, read three paragraphs about the “design thinking process”, see a grid of polished mockups and close the tab without knowing what the designer actually did.

Portfolios have changed a lot over the past few years. Recruiters now expect to see evidence of judgement, collaboration and outcomes, not just visual craft. AI tools can produce a clean interface in seconds, so a pretty screen on its own proves very little. What still stands out is the story of how you got there and why you made the choices you did.

This guide covers what to include, how to structure a case study and how to present your work in an interview.

How hiring managers actually review portfolios

We surveyed 85 design leads who hired at least one product designer between January and June 2026. Their habits were strikingly similar.

Review stage	Median time spent	What they look for	Share who stop here
Landing page	45 seconds	Role, seniority, two or three project titles	22%
First case study, skim	2 minutes	Problem, your role, outcome	31%
First case study, full read	6 minutes	Decisions, trade-offs, collaboration	18%
Second case study	4 minutes	Range, consistency	29%

Put simply, nearly a quarter of reviewers decide from your landing page alone, and more than half have made up their minds within three minutes. Your portfolio needs to work at every one of those depths.

Choosing what to include

Most designers include too much. Three strong case studies beat eight average ones, and two can be enough if they are substantial. When deciding what makes the cut, ask yourself three questions about each project:

1. Did I make decisions that changed the outcome?
   • If the answer is “I executed someone else’s design”, it’s probably not a lead case study.
   • Supporting work can still go in a short “other projects” section.
2. Can I explain the result?
   • Metrics are great: conversion up 14%, support tickets down by a third.
   • Qualitative outcomes count too, such as a feature that changed how a team worked.
3. Does it show something the other projects don’t?
   • Aim for range: one deep systems project, one fast product iteration, one piece of research-led work.

Unglamorous projects are often the best ones

Designers tend to showcase consumer apps with bright visuals. Hiring managers, though, are frequently looking for people who can untangle complex internal tools, admin dashboards and enterprise workflows. A case study about redesigning a 15-year-old scheduling system, with real constraints and messy stakeholders, can be far more persuasive than another concept for a meditation app.

Structuring a case study

A good case study reads like a short, well-edited story. It does not need to document every step you took, only the ones that mattered. We recommend this outline, which most reviewers can skim in two minutes and read properly in six.

case_study:
  title: "Rebuilding checkout for repeat customers"
  summary: "Cut checkout time for returning buyers from 94s to 41s."
  role: "Lead product designer (team of 1 PM, 4 engineers)"
  timeline: "Feb 2025 - Jul 2025, 22 weeks"
  sections:
    - problem: "What was broken, for whom, and how we knew"
    - constraints: "Legacy payment API, no new backend work until Q3"
    - process:
        - research: "12 customer interviews, funnel analysis"
        - exploration: "3 directions, 1 tested with 40 users"
        - decision: "Why we chose saved-card-first over one-page checkout"
    - outcome: "Conversion +8.5%, support tickets about payment -31%"
    - reflection: "What I'd change, what I learned"

Lead with the summary

Write a one-sentence summary at the top of each case study that a reviewer could repeat to a colleague. “Cut checkout time for returning buyers from 94 seconds to 41” is memorable. “A holistic redesign of the e-commerce experience” is not.

Be clear about your role

State your title, the team around you and what you personally owned. Reviewers are wary of portfolios that say “we” throughout without ever clarifying who did what. It is perfectly fine to say that a researcher ran the interviews and you synthesised them, or that an engineer suggested the solution you ended up refining.

Show the decision, not just the deliverable

The most valuable part of any case study is the moment where you chose between options. Show two or three directions you explored, explain the trade-offs and say why you picked one. Include the direction you rejected and what convinced you. This is where reviewers learn how you think.

“I can teach someone our design system in a week. I can’t teach them to notice that the real problem is three steps upstream from the screen they were asked to fix. That’s what I’m scanning for in every case study.”

Sofia Lindqvist, Head of Design at Harbourline

Write for people who skim

Most reviewers will not read your case study from top to bottom on the first pass. Make it easy for them to pick up the thread at any point. Use descriptive headings (“Why we dropped the one-page checkout” rather than “Iteration 2”), keep paragraphs to three or four sentences and put a short caption under every image that explains what it shows and why it matters.

Captions are underrated. A screenshot of a flow diagram means little on its own, but a caption such as “The original flow had 11 steps; testing showed 40% of users abandoned at step 7” tells the reviewer exactly what to look at. If someone reads only your headings and captions, they should still understand roughly what happened.

Finally, cut ruthlessly. Most first drafts of case studies run to 2,500 words or more. The finished version should usually land between 800 and 1,200, with images doing the rest of the work.

Format and presentation

There is no single right format, but there are a few that consistently work well.

• A personal website gives you full control and is still the most common choice. Hosting plus a custom domain costs roughly $10–$20 a month, or about €120–€240 a year. Keep it fast, readable on mobile and easy to move around.
• A PDF deck of 10–15 pages is useful for applications that ask for an upload, and for companies that review offline.
• A design-tool file, for example a shared board in Figma or Penpot, works well for showing process artefacts but shouldn’t replace a written narrative.

Whatever you choose, make sure it loads in under 3 seconds on a normal connection. Compress your images. A 40 MB hero video is a good way to lose reviewers before they’ve read a word.

Protecting confidential work

Many designers can’t show their best work because of NDAs. That shouldn’t stop you. Blur or redraw sensitive screens, replace real data with realistic placeholders and focus on the process rather than the final UI. Most companies are fine with this if you ask. If in doubt, check with your former manager before publishing, and note on the page that the work has been adapted.

Presenting your portfolio in an interview

Many design loops include a 45–60 minute portfolio presentation. Treat it differently from the website.

• Choose one or two projects, not your whole portfolio.
• Spend about 20% of your time on context, 60% on process and decisions, and 20% on outcomes and reflection.
• Prepare for interruptions. Interviewers will ask questions; leave at least 10 minutes for them.
• Practise out loud at least twice, ideally with someone who doesn’t know the project.

Arrive with a short backup version, roughly 15 minutes long, in case the schedule slips. It happens more often than you’d think, especially in loops that span several time zones, as we discussed in our piece on remote-first hiring.

A timeline for building or refreshing your portfolio

If you’re starting from scratch or haven’t updated your portfolio since 2024, give yourself four to six weeks. Here is a schedule that works for most people with a full-time job:

• Week 1: list every project from the last three years and shortlist three.
• Weeks 2–3: write rough drafts of each case study, words first, visuals later.
• Week 4: add visuals, cut the text by a third, and write the summaries.
• Week 5: ask two designers and one non-designer to review it.
• Week 6: fix what they found and publish.

Block out two evenings a week, for instance 19:00–21:00 on Tuesdays and Thursdays, and protect that time. Portfolios rarely get finished in one long weekend.

Next steps

Once your portfolio is live, put it to work. Browse open product designer roles on HireWise, where mid-level salaries currently range from about $115,000 to $150,000 in the US and €58,000 to €78,000 in Western Europe, including our current Product Designer listing and the Junior Product Designer opening for people earlier in their careers. Add your portfolio link to your profile so recruiters can find it without asking, and if you’d like a second opinion, the HireWise team occasionally reviews portfolios at our community events.

A strong portfolio doesn’t need to be long, flashy or perfect. It needs to make it easy for a busy person to understand what you did, why it mattered and how you think. Get those three things right and the rest is polish.