What a hiring manager reads in the first ninety seconds
I have been on the reviewing side of about four hundred portfolios, mostly for product design roles at companies of thirty to five hundred people. The uncomfortable truth is that the first pass is fast. Ninety seconds is generous.
That is not because reviewers are lazy or the work does not deserve better. It is because a hiring manager is looking at forty portfolios in an afternoon, around their actual job, and they are trying to answer one narrow question before they invest real attention.
The question is: can this person tell me what they decided and why. Almost everything that gets a portfolio through the first pass is in service of answering it quickly.
Here is what actually happens in those ninety seconds, in order, because knowing the sequence tells you where to spend your effort.
Seconds one to ten: is this a designer
The home page loads and the reviewer makes a fast, mostly unconscious judgement about craft. Typography, spacing, hierarchy. It is not fair and it is not deep, but a portfolio is the one artefact where you controlled every decision, so it gets read as a work sample whether or not you intended it that way.
This is also the cheapest thing to fix. Set your body text at a comfortable size, keep your line length near sixty-five characters, use one type scale consistently, and give things room. Most portfolios that read as junior read that way because of spacing, not because of the work.
Seconds ten to thirty: what kind of designer
The reviewer is now scanning for fit against a role they have in their head. Product or brand. Systems or research. Consumer or enterprise. If they cannot place you in fifteen seconds, the most common outcome is not rejection, it is deferral, and deferral means never.
One sentence near the top, in plain words, saying what you do and who for, will do more than any amount of case study depth. It feels reductive to write. It is not reductive, it is navigational.
Seconds thirty to ninety: one case study, scanned
They open one project, usually the first, and they do not read it. They scan headings, look at two or three images, and read the outcome if they can find it in under five seconds.
So the structure has to survive scanning. Headings that say what happened rather than labelling a phase. Discovery tells me nothing. Three days riding with technicians set the constraints tells me a great deal, and it tells me even if it is the only line I read.
Write your case study so that somebody reading only the headings still gets the argument. That reader is not hypothetical. That reader is most of them.
What consistently fails
- Process theatre. Eleven screenshots of sticky notes with no decision attached to any of them.
- The unbroken success narrative. Every project going perfectly reads as a project that was not examined.
- Outcome as adjective. Users loved it is not an outcome. Drop-off fell from 61% to 34% is.
- No stated role. On a team project I need to know what was yours, and vagueness reads as concealment even when it is modesty.
- Fourteen projects. Six good ones beat fourteen, and three excellent ones beat six.
What consistently works
Name a constraint and show what you did inside it. Budget, timeline, technical limitation, a stakeholder who would not move. Constraints are where design judgement is visible, and unconstrained work reads as decoration regardless of how good it looks.
Show one thing that did not work. A prototype that failed testing, a direction abandoned in week three and why. It costs you nothing, because everyone knows real work is like this, and it signals that you evaluate your own decisions rather than defending them.
And give me a number wherever an honest one exists. Not because numbers prove design quality, but because a designer who knows what happened after launch is a designer who stayed to find out.