Most portfolios are not rejected for weak visual craft. They are rejected in under two minutes for structural problems the designer could have fixed in an afternoon. This is the checklist to run before you send yours anywhere, organised the way a reviewer actually reads.
First impression (the first 30 seconds)
- Your name, role and what you are looking for are readable without scrolling.
- The strongest project is first. Reviewers rarely reach the fourth.
- Three to five projects maximum. Ten projects signal you cannot prioritise.
- The page loads fast and works on a laptop screen, not just your 27-inch monitor.
- A one-line summary under each project tile says what it is and what you did.
Case study structure
- Each case study opens with context: the product, the users, the business problem.
- Your specific role is explicit. "We" throughout a case study hides you.
- The problem is framed before any interface appears.
- You show options you considered and rejected, with reasons. Judgment is the product.
- Constraints are named: timeline, technical limits, stakeholder pressure.
- The outcome is stated honestly, with metrics where you have them and honesty where you do not.
- A reflection closes it: what you would do differently. Seniority signal, cheap to add.
Craft and detail
- Typography is consistent across the portfolio itself. Your portfolio is a design artifact.
- Screens are legible at the size shown, not thumbnails of entire flows.
- Real content in mockups, not lorem ipsum.
- Interaction states appear somewhere: empty, loading, error, edge cases.
- Accessibility gets at least one honest mention backed by evidence in the work.
AI-era signals (what changed since 2023)
- At least one project involves AI, ideally as the core interaction rather than a chatbot bolted onto a corner.
- You address designing for uncertainty: what happens when the model is wrong.
- Your process mentions modern tooling honestly. Teams now assume fluency; showing it beats claiming it.
- Something in the portfolio actually shipped. A live link beats any mockup. If nothing has shipped yet, that is the single highest-leverage gap to close; it is why our mentorship program is built around a shipped capstone rather than fictional briefs.
The rejection triggers
- No unsolicited redesigns of famous apps as your lead project. Reviewers have seen a thousand Spotify redesigns with no real constraints.
- No process theater: walls of sticky-note photos that never connect to a decision.
- No agency-style image dumps with zero narrative.
- No broken links, placeholder pages or "case study coming soon."
- No unexplained gaps between what the title claims and what the work shows.
- Nothing confidential shown without care. Sanitise or get permission; reviewers notice.
How to use this list
Run it yourself first, fixing everything in the first two sections before touching visuals. Then get a second pair of experienced eyes on it: self-review catches structure, but only feedback catches blind spots. That is what mentors are for, and a good mentorship loop is the fastest way to close the gaps you cannot see.
Learners in our AI Product Design Mentorship get portfolio reviews for life, including years after graduating, precisely because the portfolio is never really finished: it evolves with every role you chase.
How reviewers actually move through a portfolio
The checklist above is ordered the way it is because it mirrors the sequence a reviewer follows, and knowing that sequence tells you where your effort is worth spending.
The first pass is roughly thirty seconds and it is a filtering pass, not an evaluating one. The reviewer is answering one question: is this person plausibly at the level we are hiring for? They read your header, glance at project tiles, and form an impression from the visual quality of the portfolio itself. Nothing about your process matters yet.
The second pass is one case study, usually the first one, and usually skimmed rather than read — headings, images, and the last paragraph. The reviewer is looking for whether there is a real problem here and whether you did something non-obvious about it. Most rejections happen at the end of this pass.
The third pass only happens if the first two went well, and it is the one the case study was actually written for: reading properly, looking for judgment, checking whether the outcome claims hold up.
The practical consequence is that effort is badly distributed in most portfolios. People spend weeks polishing the third-pass detail of case study two, when the thing costing them interviews is a first-pass problem — an unclear header, a weak lead project, or a portfolio that loads slowly on a normal laptop.
The three rejections that come up most
"I cannot tell what they did." By a wide margin the most common. The work is good, the case study is thorough, and every sentence says "we". The fix is mechanical: go through each case study and convert your own contributions to "I", leaving "we" for genuinely collective work. It will feel immodest. It reads as clarity.
"Process without decisions." Photographs of workshop walls, affinity maps, journey maps and personas, none of which connect to a choice that was made differently because of them. Artefacts are evidence of activity; reviewers are screening for judgment. For every artefact you show, add the sentence that says what it changed.
"No constraint." Work that appears to have had unlimited time, no stakeholders, no technical limits and no disagreement reads as either unreal or unchallenging. Naming what constrained you — a two-week deadline, a legacy component you could not replace, a stakeholder who wanted something different — makes the work legible as professional practice rather than an exercise.
If you have nothing shipped yet
This is the hardest version of the problem and the most common one for people moving into the field. The honest answer is that the gap is real: a reviewer comparing a candidate with shipped work against one with conceptual projects will usually choose the first, because shipped work carries evidence of constraint, compromise and consequence that a concept cannot.
The workable responses, in rough order of effectiveness:
- Ship something small and real. A tool that solves an actual problem for actual users, however narrow. Ten real users beats a hypothetical million.
- Do constrained work for a real organisation. A local business, a charity, an open-source project. Real stakeholders create real constraints, which is the thing missing from self-directed work.
- Redesign something you use, with the constraints stated. If you must do a conceptual project, make it one where you can articulate why the current design is the way it is, and what you would be trading away. That framing demonstrates judgment; "here is a prettier Spotify" does not.
Running the checklist honestly
Self-review reliably catches structural problems and reliably misses blind spots — you cannot see the thing you assumed. Run the list yourself first, fixing everything in the first two sections before touching any visuals, then get the portfolio in front of someone who hires designers and ask them to tell you where they would have stopped reading. That single question produces more useful feedback than any general request for thoughts.
Learners in our AI Product Design Mentorship get portfolio reviews for life, including years after graduating, because a portfolio is never really finished — it changes with every role you go after.