This portfolio, treated as a product

A portfolio is often the first design artefact a hiring manager reviews, so it is judged as a product as well as a collection of work. This project applies the same discipline to the portfolio itself that I would apply to any product.

Its users are hiring managers, design leads, recruiters and founders. They arrive with limited time and a specific question: should I talk to this person?

Reviewers want to answer a handful of questions quickly: who is this, what do they work on, how strong is their thinking, how refined is their craft, and how do I get in touch.

Portfolios typically answer with adjectives. The design problem is to replace claims with structure that makes evidence easy to find and quick to judge.

One designer, one build, no client assets supplied at the time of writing. That last constraint shaped the strategy more than any other.

No interviews or observation sessions with reviewers were run for this project. The design rests on working assumptions about how portfolios are reviewed: that reviewers scan before they read, that they look for proof of reasoning, and that friction on the way to contact costs interviews.

These are treated as hypotheses to test, which is why the outcomes section is explicit about what has not been measured.

The problem was framed as two jobs a reviewer is trying to get done, on very different timescales.

Priority one was proof before promises: work appears directly after the hero, and the strongest case study is linked from the hero itself.

Priority two was honesty as a feature. Each case-study section carries an evidence label, so a reader can see at a glance what was conducted, what is a hypothesis, and what was not done.

Priority three was restraint. Motion, colour and decoration are budgeted so they direct attention rather than compete with the content.

A single narrative page for scanning, and dedicated case-study pages for depth. Every page keeps a route to contact within one action.

Interaction effort went into the states a visitor rarely thinks about but always notices.

An editorial voice: a high-contrast serif for argument, a precise sans for interface and a monospace for annotations, on warm paper with a single signal colour. The accent is used for direction and status, never as decoration.

Not yet. Automated and manual accessibility checks were run against the build, but no usability sessions with real reviewers have taken place.

The plan below defines the lightest tests that would answer the most important questions.

Design tokens for colour, type and spacing are defined once as CSS variables and consumed by components, so design intent and implementation share a vocabulary.

Case-study content is typed data rather than hand-written pages, which keeps every case study consistent and makes adding the next one a content task.

The build meets its accessibility and performance intentions, but its main hypothesis, that this structure helps reviewers decide faster, is untested.

Next: run short moderated sessions with hiring managers, add real client or employer case studies as they become shareable, and measure whether visitors reach a contact action.