Design students in a live UI/UX critique session at Agile Design School — online design course with placement support

HomeBlog › Career Guide

How to Build a Portfolio That Gets Interview Calls

How to build a UI/UX portfolio that gets interview calls — how many projects, the anatomy of a strong case study, and the mistakes that kill applications.

By Agile Design School Editorial · Published 10 July 2026 · 16 min read · Category: Career Guide

Key takeaways

  • Most rejected applications are not a skills problem — they are a portfolio-communication problem. Recruiters and hiring managers report spending well under a minute on an initial scan of most portfolios.
  • Three to five deep, well-reasoned case studies consistently outperform ten shallow ones. Depth signals judgment; volume alone signals output.
  • A strong case study shows the problem, the research, the decisions you rejected and why, and a real outcome — not just a gallery of final screens.
  • Including one honest limitation or what-you'd-do-differently is one of the highest-signal things you can put in a portfolio, and one of the rarest.
  • Platform choice (Notion, a personal site, Behance) matters far less than most candidates think. Structure and reasoning matter far more than which tool hosts them.

Why strong designers still get skipped

Plenty of genuinely capable designers send out dozens of applications and hear nothing back — not because their skills are lacking, but because their portfolio fails to communicate those skills in the small window of attention a hiring manager actually gives it. Recruiters and hiring managers reviewing an initial batch of applications commonly report spending well under a minute on a first pass through most portfolios. In that window, a portfolio either makes your thinking legible fast, or it doesn't — and a surprising number of strong designers lose the opportunity right there, before their actual craft is ever properly seen.

This article is about closing that gap: what a portfolio actually needs to do, the structure that reliably communicates judgment quickly, the mistakes that quietly cost interviews, and how to decide what to include.

What a portfolio actually needs to do

A portfolio is not a gallery. Its job is to answer three questions as fast as possible for a stranger skimming quickly: what problem were you solving, what did you actually decide and why, and did it work. A beautiful set of final screens with no visible reasoning behind them answers none of these — which is why visually impressive portfolios still get passed over constantly. The screens are the evidence. The reasoning is the actual product being evaluated.

Fewer projects, more depth

Three to five deep, well-documented case studies consistently outperform ten shallow ones. This runs against instinct — more work feels like it should demonstrate more capability — but a hiring manager is not counting your output, they are judging your decision-making, and ten shallow projects simply do not show enough of any single decision to judge it properly. Five deep projects, each showing a real problem worked through to a real conclusion, tell a hiring manager far more about how you think than twice as many polished-but-thin ones.

If you genuinely have more than five strong projects, the discipline is choosing rather than including everything — pick the three to five most relevant to the type of role you're applying for, and hold the rest in reserve to mention if it comes up in conversation.

The anatomy of a strong case study

The shape that reliably works, across almost every strong portfolio we've reviewed, follows a consistent structure:

The problem, stated in one or two sentences

Not "I redesigned X app," but the actual problem — what was broken, for whom, and why it mattered. A vague opening line is the fastest way to lose a reader's attention in the first five seconds.

The research, briefly but specifically

Who did you talk to, what did you learn, what surprised you. Even a small, honest research effort — five interviews, a short usability test — outweighs an invented persona with no real people behind it.

The decisions, including the ones you rejected

This is the single most under-used section in weak portfolios. Showing two or three directions you considered, and the specific reasoning for the one you chose, demonstrates judgment in a way that a single polished final screen never can.

The outcome, stated honestly

A real metric if you have one, a qualitative result if you don't, or an honest "this is what I'd test next" if the project never shipped. Vague outcomes ("users loved it") read as unverified and slightly hollow. Specific ones, even modest ones, read as credible.

Show reasoning, not just screens

The gap between a portfolio that gets interviews and one that doesn't is rarely the visual quality of the final screens — it is whether the reasoning behind them is visible at all. A screen with a one-line caption explaining why a particular layout was chosen over an alternative teaches a reader more about your thinking in five seconds than ten unexplained screens do in five minutes.

Include one honest limitation

Naming a real limitation, a metric that didn't move as expected, or a decision you'd make differently with what you know now is one of the highest-signal things you can put in a portfolio — and one of the rarest, because it feels risky to include. It isn't. Interviewers actively look for self-awareness and growth, and a portfolio that reads as flawless from start to finish often reads as unreflective rather than impressive.

Common portfolio mistakes

Ten generic redesigns with no research behind them

A visual facelift of an existing app, with no interviews, no stated problem, and no reasoning — this reads as a design exercise, not real design thinking, no matter how polished the screens look.

Walls of text or barely any text at all

Both extremes fail. A case study that is all screenshots forces the reader to guess your reasoning. A case study with dense paragraphs under every image tests the same limited attention span this whole article opened with. Short, specific captions next to the right screens beat both.

Outdated projects from years ago

A portfolio anchored entirely on work from three or four years back signals stagnation, even if the work itself was solid. Refresh at least your lead project regularly with your current best thinking.

Broken links and dead prototypes

An unreviewed, months-old portfolio with a broken Figma link or an expired prototype URL undercuts everything else in it. This is a five-minute audit worth doing before every application round.

No clear way to contact you

A surprising number of portfolios bury or omit a direct way to reach the designer. Make your email, LinkedIn and resume link impossible to miss.

Choosing the right platform

Notion, a simple personal website, or a well-organised Behance profile all work, and the platform choice matters far less than most candidates believe. What actually matters is whether the structure inside is clear and whether the writing does the reasoning-work described above. Spend the bulk of your limited preparation time on the case study content itself, not on custom website animations that a reader will forget within seconds of leaving the page.

Tailoring for the role you want

If you're applying to fintech roles, lead with a project that shows trust, security or complex-flow thinking, even if it's a personal project rather than paid work. If you're applying to consumer or e-commerce roles, lead with something that shows funnel and conversion thinking. The same portfolio does not need to lead identically for every application — reordering which case study sits first, based on the role, is a five-minute effort that meaningfully raises your relevance in a reader's first impression.

Where this fits at Agile Design School

Every course we run is built around producing exactly the kind of portfolio described in this article — not as an afterthought at the end, but as the actual spine of the programme. Case studies are built with real research, iterated through live studio critique, and defended in front of an external jury before you graduate — the same kind of scrutiny a real hiring panel will apply, rehearsed before it counts.

Two ways to see this in action:

  1. Book a free 45-minute demo class and watch a real portfolio critique session — the exact process that shapes the case studies described above. Book your free demo class here.
  2. See the full curriculum for the Professional Certificate in UX/UI Design, including how the final portfolio and jury defence are structured month by month.

A strong portfolio is not about talent you either have or don't. It's a structure you can learn, practise, and get critiqued on until it reliably does its job — getting you into the room where the actual interview happens.

Frequently asked questions

How many projects should be in a UX/UI portfolio?
Three to five deep, well-documented case studies consistently outperform ten shallow ones. A hiring manager reviewing your portfolio is trying to judge your reasoning, not your volume of output — and depth is what reveals that. If you have more than five strong projects, choose the three to five that best represent the type of role you're applying for, and hold the rest in reserve to mention if asked.
Should I include personal or unsolicited redesign projects?
Yes, if they include real research and reasoning — no, if they are just a visual facelift of an existing app with no research behind the changes. A well-reasoned personal project, complete with user interviews and a clear rationale for each decision, is often stronger than a shallow real client project. What matters is the depth of thinking shown, not whether the client was real.
Do I need a fancy custom-built portfolio website?
No. Notion, a simple personal site, or even a well-organised Behance profile all work, provided the structure and writing inside are strong. Hiring managers care far more about whether they can quickly understand your problem, process and decisions than about custom animations or a bespoke domain. Spend your limited time on the case study writing, not the website framework.
Should every case study follow the exact same structure?
The core shape should repeat — problem, research, decisions, outcome — because it helps a reader navigate quickly and shows you think in a repeatable, professional process. Small variations in emphasis are fine and even useful (one project might lean harder into research, another into systems work), but wildly inconsistent structure across projects makes a portfolio feel disorganised.
How honest should I be about a project's outcome if it didn't go well?
As honest as you can manage without undermining your own case. Naming a real limitation or a metric that didn't move as expected, followed by what you learned or would do differently, is one of the strongest signals in a portfolio — it shows self-awareness and growth, which most interviewers actively look for and most portfolios avoid entirely.

Learn this properly, not passively.

Live studios, real users, jury-reviewed portfolios — see how the school behind this article teaches.

Book a Free Demo Class

A live 45-minute session · No pressure, no hard sell