A UX research portfolio is a short set of case studies, usually two or three, each telling the story of one study from the question to the product decision it changed. Hiring managers use it to judge how you choose a method, how you work with a team and whether your findings lead anywhere.
The examples below are outlines, not finished portfolios. Each shows the order of the sections and what goes in them, so you can lay your own study over the same frame. If you are still deciding whether UX research is the field for you, start with how to become a UX researcher.
Hiring managers decide from the first case study
A hiring manager screening research portfolios often has dozens to read for one opening. Most read the opening of the first case study, look for the outcome and decide from there whether to read on. That decides how you order and open the whole portfolio.
Put your strongest study first, even if it is not your most recent. Open it with a short summary of three or four lines: the question, the method, the finding and what the team did about it. A reader who stops there should still know what you did.
What hiring managers skim for, in roughly the order they look:
- The outcome: what changed in the product, the roadmap or the team’s plan because of the study.
- Your role: what you did yourself and what the team did, said plainly.
- The reason for the method: why interviews and not a survey, why eight participants and not twenty.
- The constraints: the time, budget or access you had, and how you worked within them.
- The writing: whether your findings are clear enough to hand to a product manager.
A case study follows the same seven parts every time
Use one structure across all your case studies, so a reader learns where to look after the first one. The order below works for almost any study.
- Start with the problem: what the team needed to know and why it mattered to the business or the people using the product. One paragraph is enough.
- Say what your role was: whether you led the study, ran it with a designer or supported a senior researcher, how big the team was and who you worked with most.
- Name the method and explain why it fit the question. The reason is the part interviewers probe most, so write it out instead of naming the method and moving on.
- List the constraints, such as two weeks instead of six, no access to real customers or a participant pool of internal staff. Constraints explain your choices and show judgment.
- Give three to five findings, each one sentence long with evidence under it, such as a quote, a clip transcript or a count of how many participants did something.
- Say what changed: the design that shipped, the feature that was cut, the roadmap item that moved. If the team didn’t act on it, say why and what you did next.
- End with what you would do differently, in one or two lessons. This part shows you can review your own work.
Images carry a lot of the weight: the discussion guide’s first page, a photo of the affinity map, a before and after of the screen that changed, a chart from the survey. Caption each one with what it shows, since many readers skim the images and skip the text between them.
Work under NDA can stay in the portfolio if you change the details
Most research is confidential, and most researchers still show it. Describe the decision and the method, and change or remove the details that identify the product, the customers or the data.
- Rename the product and the company: “a payments app for small businesses” instead of the brand.
- Rebuild screens as simple wireframes, or blur them, instead of using real screenshots.
- Round or remove numbers that reveal business data, such as revenue, conversion rates or customer counts. Participant counts are usually fine.
- Paraphrase participant quotes and strip anything that could identify a person.
- Leave out unreleased features entirely if the company hasn’t launched them.
When in doubt, check your contract or ask your former manager what you may show. If a study can’t be shown at all, write a short version that describes the type of problem and the method, and offer to walk through it in more detail in an interview.
Pick the format that opens fastest on a phone
The format matters far less than how quickly a reader reaches the first finding. Recruiters often open portfolio links on a phone between calls.
| Format | Works well when | Watch out for |
|---|---|---|
| Simple website (Squarespace, Framer, Webflow, Wix) | You want one link for each application and room for images | Templates built for visual designers, with slow galleries and little room for text |
| An application asks for an attachment, or you tailor the order for each job | File size; keep it under 10 MB so it opens on a phone | |
| Notion or Google Docs page | You want to publish fast and update often | Default layouts can look unfinished; add a cover image and clear headings |
| Slide deck | You are preparing the presentation round | Slides without a speaker read thin; keep a written version for screening |
Many researchers keep two versions: a written site or PDF for screening, and a slide deck for the portfolio presentation in the interview loop.
Three example case study outlines
These outlines are made up for illustration. Each one shows how the seven parts fit a different level of experience.
Example 1: a junior researcher’s usability test of a public app
People abandon a city’s parking app before paying, and the app’s reviews complain about the payment screen. A career changer runs the study alone, with no access to the app’s team or its data. They choose a moderated usability test with six participants, because the question is whether people can finish one task, and watching them try answers that faster than a survey. Participants come from friends of friends, screened for driving in the city.
Four of the six miss the zone number on the street sign, and the app asks for it first. The case study ends with a redesigned first screen that detects the zone from the phone’s location, tested with three new participants. The lesson section says they would recruit strangers next time, since two participants guessed what the study was about.
Example 2: a mid-level researcher’s interview study that changed a roadmap
A team plans to build team accounts for a note-taking product, and nobody knows how teams share notes today. The researcher leads the study with a product designer and presents it to the product lead. They run twelve remote interviews with people who share notes at work, plus a short screener survey, because the team needs to understand current behavior before choosing features. They have three weeks, and the sales team wants the feature that quarter.
Most sharing happens by copying notes into chat, and permissions matter less to people than search across shared notes. The team ships shared search first and moves permissions to the next quarter. In hindsight, the researcher would include two administrators who manage the tool for their company, since that view surfaced late, in sales calls.
Example 3: a senior researcher’s mixed-methods study across teams
Three product teams disagree about why new customers stop using the product in their first month. The researcher designs the study, runs it with a junior researcher and a data analyst, and leads the workshop where the teams agree on priorities. Product analytics show where new customers drop off, and fifteen interviews with people who left at each point show why. Customers who leave are hard to recruit, so the team offers a larger incentive and accepts a lower response rate.
The biggest drop comes at an import step, and most people who left expected the product to bring in their old data for them. One team takes ownership of import, and all three teams share one metric for it. The researcher would set up that metric before the study next time, so the result could be tracked from the first day.
The senior example adds work across several teams, a method chosen from data and a change to how the company works, which is what moves a portfolio from mid-level to senior.
Show research skills the hiring team needs, beyond the study
Research jobs differ, and a portfolio can lean toward the one you want. A job at a company with a design team that already runs its own tests wants to see you plan a research program and teach others. A job at a startup with no researchers wants to see you get answers fast with little budget. A quantitative role wants analysis and a clear chart.
Read the job description for the methods and the words it repeats, then pick the case studies that show those. Reordering your case studies for each application takes ten minutes and changes what the reader sees first.
Writing samples help too. A short research report, a one-page findings summary or a published article about a study shows how you write for a team, which is most of what a researcher does after the sessions end. UX writing jobs and UX and product design jobs use many of the same skills, and some researchers apply across all three.
If you have no case studies yet, the UX researcher guide covers ways to run real studies before your first research job. The open UX research jobs show which methods employers ask for today.
