Most UX portfolios fail in the first thirty seconds, and not because the work is bad. They fail because the reader cannot find the thinking. A hiring manager with forty portfolios to review opens yours, scrolls past a hero image, sees a grid of polished screens, and closes the tab without learning how you work.
The strong ones look different. Here is what they do, and how to build one that does the same.
What the best UX portfolios have in common
- They lead with one project. Not a grid of eight. One case study, front and centre, that a reader can finish in five minutes.
- They show decisions, not deliverables. "We considered three navigation models and chose tabs because users switched between two areas constantly" beats a beautiful nav screenshot.
- They show the mess. Sketches, rejected directions, the research wall, the competitor screens that shaped the brief. Process evidence is what separates a designer from someone who can operate Figma.
- They state outcomes honestly. A metric if there is one, a qualitative result if there is not, and what you would change.
- They are short. Every section earns its place. Long scroll is fine; long paragraphs are not.
A structure readers actually follow
- One line on the problem. Who had it and why it mattered.
- Your role and the team. Readers want to know what you did, not what the team did.
- Constraints. Time, tech, legal, budget. Constraints make decisions interesting.
- Research and references. What you learned and what you looked at.
- Options and the decision. Two or three directions, why one won.
- The result. Final screens, then outcomes.
- Reflection. One paragraph on what you would do differently.
The part most designers skip: collecting evidence as you go
The reason portfolios lack process is simple: nobody saved it. Six months later the competitor screenshots are gone, the sketches are on a whiteboard that was wiped, and the rejected directions were deleted from Figma to keep the file light.
Fix it at the source. During every project, save the competitor screens you studied, the patterns you rejected, the analytics chart that changed the brief and the photo of the research wall, all into one library, each with a line on why it mattered. When portfolio time comes, the evidence is already there and searchable. GetRef is built for exactly this: paste a screenshot, it is read and tagged automatically, and a collection per project keeps it all together. See how to build a design library for the system.
Where to look for strong examples
Study portfolios from designers at companies you admire; most link theirs on LinkedIn or personal sites. Bestfolios and similar galleries collect them in one place. Save the ones that stop you, cropped to the section that worked: a clear problem statement, a good options diagram, an honest reflection. Those crops become your swipe file for writing your own.
A checklist before you send it
- Can a reader find your best project in one click?
- Does every case study say what you specifically did?
- Is there at least one rejected direction with a reason?
- Does every image have a caption saying what to notice?
- Does it load in under three seconds on a phone?
Get those five right and your portfolio is already ahead of most of the pile. For the case study itself, read how to write a UX case study.
Common questions
- How many projects should a UX portfolio have?
- Two or three deep case studies beat six shallow ones. Hiring managers usually read one in full and skim the rest, so lead with the project that best shows how you think.
- What do hiring managers look for in a UX portfolio?
- Evidence of judgement: the problem, the constraints, the options you considered, why you chose one, and what happened afterwards. Polished final screens matter less than a clear account of decisions.
- Where should I host my UX portfolio?
- Anywhere that loads fast and is easy to update: Framer, Webflow, Squarespace, Notion or a simple custom site. The platform matters far less than the case studies on it.
