How to review a design portfolio when you are not a designer

Why is the best-looking portfolio often the wrong signal?

Because portfolio craft and product craft are different skills, and the market rewards the first one heavily. A striking case study with animated mock-ups on a dark background demonstrates that the candidate can produce a striking case study. It is weak evidence that they can make a claims form less painful for people who use it under pressure.

There is also a survivorship problem. Portfolios show the work that went well, on projects with budget, at companies with a brand worth putting on a slide. The most instructive projects, the constrained ones, the rescues, the legacy systems, rarely photograph well and often cannot be shown at all for confidentiality reasons.

So treat visual quality as a threshold rather than a ranking. It should be good enough that you would not be embarrassed by it, and beyond that point it should not move a hiring decision. The ranking comes from the reasoning.

What should you read first?

The constraints. Every real project had them: a deadline, a legacy database, a regulator, a stubborn stakeholder, a browser that had to be supported, a language the interface had to be translated into. A case study that mentions none of these is describing a project that did not happen or a designer who did not notice.

Then read for the decision that went against the obvious. Strong candidates will describe a point where the pleasing option lost to something more useful: a step added to a flow because people were making an irreversible mistake, a beautiful chart replaced by a table because the users were reading exact figures. That kind of story is very hard to fabricate.

Then read for what happened afterwards. Anyone can show a redesign. Fewer can tell you what changed once it shipped, whether support tickets moved, what they got wrong, and what they would do differently. Absence of outcomes is not disqualifying, because plenty of employers never measure anything, but the candidate should be able to say so plainly rather than implying results they do not have.

How do you tell what they personally did?

Ask, and then ask again about a specific screen. Design work is collaborative and portfolios use we for good reasons, but a candidate should be able to point at a particular element and say what they decided, who disagreed and how it was resolved. Vagueness here is the single strongest negative signal available to a non-designer.

Ask what existed before they arrived. On team projects a great deal of the visible quality comes from a design system that was already in place, and a candidate who worked inside a mature system has been given most of the typography, spacing and components. That is not a fault, but it changes what the work demonstrates, and honest candidates volunteer it.

Ask what the engineers said. Anyone who has shipped will have stories of an interaction that was too expensive to build, a state nobody had designed, a discussion about performance. A portfolio that reads as though designs went straight from a file to production describes a proposal rather than a product.

What should you look at in the artefacts themselves?

Look for the unglamorous states, because they are where practitioners separate from presenters. Anyone can design the screen with three perfect cards. The evidence of experience is the empty state, the error, the loading state, the version with one item, the version with four hundred, the long name that wraps to three lines, and the form after somebody has entered something invalid.

Count the screens in a case study. Real product work generates dozens of variants, and a case study with four hero images is likely to be a summary of somebody else's project or a concept piece. Ask to see the working file, not the presentation, and see whether the mess of a real project is in it.

Does the portfolio still matter when work is confidential?

It matters less than people fear, and pushing candidates to show protected work is a bad sign about your own organisation. Enterprise, defence, health and finance designers frequently cannot show anything, and the strongest of them will offer a redacted walkthrough or talk through the decisions without the artefacts.

In that situation shift the assessment to a conversation about a problem you actually have. Describe a real screen, give the constraints honestly and ask how they would approach it, including what they would need to find out first. This is more informative than any portfolio and takes twenty minutes.

Whether they ask questions before answering is most of the signal. A candidate who starts proposing a layout within a minute of hearing a problem is showing you exactly how they will behave on your project.

What can you decide in thirty minutes?

Pick one project from the portfolio and go deep on it rather than touring all six. Ask what the goal was, what constrained it, what they personally decided, what they got wrong and what happened after launch. Five questions, one project, and the answers will separate authors from assemblers well before the half hour is up.

The test to apply to yourself afterwards: could you now explain their design decision to a colleague, and does it make sense to you as a person who understands the business problem. If you cannot, either the reasoning was not there or it was not communicated, and communication is a substantial part of the job you are hiring for.

Keep in mind what a portfolio can never show. It cannot tell you whether someone takes feedback well, keeps a commitment, or writes a clear message when the deadline is at risk. Those come from references and from a short paid piece of real work, which is why neither should be skipped on the strength of impressive slides.