The Portfolio Case Study Teardown, One Project Cut to a 60-Second Read

This guide is for anyone who sends a portfolio link with applications and has one project they are proud of, written up at a length nobody screening applications will read. It takes a single shipped project from its raw records through four cuts to a published case study page. That page has role, team, and outcome in the top screen, decisions in place of process, three or fewer artefacts, an access setting that works from the resume link, and a timed 60-second cold read by someone outside your discipline. It covers only the written screening page. The presentation deck and the decision about publishing work under an NDA are separate jobs.

How long do hiring managers spend on a portfolio?

Only one published figure comes with a stated method: an average of about 55 seconds per application, and that includes reading the cover letter. Your case study page gets less than that. Every other number you will see either has no stated sample or can't be traced to any study.

Here is what is actually published, with the method behind each figure:

How to read the table:

• Presentum invited 16 hiring managers from different companies to evaluate 243 applications. The 55 seconds covered reading a cover letter and viewing a portfolio website. It is the only figure here with a method you can inspect.
• ADPList splits review times as 54% taking 5 to 10 minutes, 35% about 5 minutes, and 11% about 10 minutes. It also says the average case study takes about 20 minutes to read. No sample is given for either claim.
• Suelyn Yu's under-2-minute figure is one practitioner's observation from her own hiring at Opower. It's useful as a single first-hand account. It isn't a measurement.
• The 6 to 8 second figure is everywhere in design hiring writing, and even the people who repeat it say they could not find a rigorous study behind it.

Here is what follows from the one figure with a method. NN/g recommends 3 to 5 detailed case studies. ADPList says a case study takes about 20 minutes to read. If a reviewer spends 55 seconds on a whole application, those two pieces of advice cannot both describe what happens at screening. The likely unit of evaluation is the first screen of one case study, usually the first one the reviewer clicks. This is an inference, not a measurement. Time spent per case study has not been published. Still, it's the safest assumption to design for, and the rest of this guide follows from it.

Nobody has published what reviewers check first, either. NN/g surveyed 204 UX professionals who hire, and it reports that expectations differ between designers and researchers and between junior and senior roles. The detailed breakdown sits in a video rather than an article. Secondary summaries put it this way: juniors are judged on process, seniors on scope and influence. A circulating claim that "80% prioritize problem-solving" could not be traced to NN/g. Leave it out.

The worked example: one project, one over-long draft

The example is a composite built only from details the sources publish, so you can check every figure in it. You run the same passes on your own project. The project is ordinary on purpose: a redesigned task flow that shipped.

The raw facts, as they would sit in the records:

• Role and team. Sole UX designer on an Agile team of 3 developers, a product owner, and a scrum master. This is NN/g's own example of a role statement.
• Evidence of outcome. A before-and-after usability test. Before the redesign, 2 of 5 participants completed the task. After it, 5 of 5 did.
• Evidence of adoption. Engineering shipped the design unchanged.

Both kinds of evidence come from mnml's list of outcomes that hold up without hard business metrics.

The first draft was the usual one: chronological and process-heavy. It opened with a paragraph on the design problem, which is what UXfolio's advice says to do. Then it walked through research, with a photo of an affinity diagram (a wall of sticky notes grouped by theme), and moved on to personas, a journey map, wireframes, and final screens. The test result and the "shipped unchanged" line sat on the last screen. The page was behind a Squarespace page password, inside a site that also had a site-wide password. The candidate gave the password in a custom question on the application form.

That draft makes all three classic wrong turns at once:

1. The outcome is buried at the bottom. In a 55-second application review, the reviewer may never scroll that far.
2. Process diagrams pad the page. The sticky-note photo looks rigorous and tells a non-specialist nothing.
3. Nobody received the password. The form question turned out to be private, and the session timed out, which is covered below.

Before any cutting, do the inventory. For each claim in the draft, find the document behind it. In the example, the 2 of 5 and 5 of 5 figures come from the test notes. "Shipped unchanged" comes from the ticket and the sign-off. The team composition comes from the project brief. If a claim has no document, it either gets softened to what you can show or it comes off the page. An interviewer who asks "how did you measure that?" should get a real answer.

Portfolio case study structure: role, team, and outcome in the top screen

The top screen should state four things: your role, the team, the duration, and one outcome line. The top screen is whatever shows on a laptop before the reader scrolls. Everything else on the page supports those four lines. If you take one rule from this guide, take this one.

NN/g's guidance for researchers says to state your role clearly and say which parts you were directly responsible for. It also says to focus case studies on impact. In the example, the header pass moved the test result and the "shipped unchanged" line from the last screen to directly under the project title. The role line went from a vague "UX design" to the full NN/g-style statement. The original problem paragraph shrank to one line that sits under the outcome.

Where the sources disagree on order

The sources split on order. UXfolio says to start with a brief description of the design problem, which is chronological. Pathunbound's Lola Jiang example puts the result first. For a screening page, I side with result first. The reader may not reach a third paragraph, and a problem statement means nothing to them until they know it was solved. Keep the problem, but as a single line below the outcome. If you're junior, remember that the secondary summaries of NN/g's survey say juniors are judged on process. That is an argument for a strong decisions section further down. It isn't a reason to lead with process.

[Project name]: [one plain-words line on what changed for users or the business]
Role: [title in the posting's own term], responsible for [the parts you directly owned]
Team: [others by role and count, e.g. 3 developers, a product owner, a scrum master]
Duration: [start month] to [ship month]
Outcome: [what you measured] went from [before] to [after], measured by [method, n]
Trade-off: [what you gave up or ruled out to get there, one line]
Problem: [one line on the situation before the work]

Name the role in the reader's term

Use the job title the market already uses. A recruiter matching your page against a requisition is matching words. In Refolk's index of professional profiles, the most common title in 25-profile samples of each group looks like this:

The samples are small, and I haven't verified why UK naming differs. Even so, the practical move is clear: read the posting and use its term in your role line. A US researcher whose page says "User Researcher" is using the title only 2 of 25 US peers in the sample use. In the UK, "User Researcher" is the most common title. Refolk rewrites the resume for each posting and uses the posting's own terms, which keeps the resume and the case study header saying the same thing.

Cutting process down to decisions and three artefacts

Every process paragraph should either name a decision, including the option you ruled out, or come off the screening page. NN/g says to include candidate solutions and explain the thought process. A decision that names its rejected alternative proves judgement in one sentence. A timeline of activities doesn't prove it at all.

To sort each paragraph and visual in your draft, ask two things. Does it show a decision, or just activity? Could someone outside your field read it?

In the example, the decisions pass made these changes:

• The affinity diagram photo went. ADPList specifically flags sticky notes and tiny text as unhelpful. The one finding it produced became a sentence inside a decision.
• Personas and the journey map moved to an appendix link. They're useful in an interview and add nothing at screening.
• Wireframes became one decision. The section now says which layout was chosen, which alternative was tested and ruled out, and the evidence that settled it. The rejected option is named, not hinted at.

Three or fewer artefacts, each with a caption

The time budget sets the cap: in under a minute, a reviewer can't take in more than a few visuals. Keep the ones that prove a decision or a result. In the example, three survived: the before-and-after screen, the usability result, and the shipped screen. Each caption says what the visual proves, such as "after: 5 of 5 participants completed the task." A caption that only says what the image is ("final UI") doesn't do that job.

Outcome lines without hard metrics

You don't need a revenue number. mnml lists outcomes that work without one:

• Engineering adopted the design unchanged. This proves the work was buildable and trusted. It's misleading when "unchanged" really means "nobody reviewed it".
• Before-and-after task success, for example 2 of 5 participants versus 5 of 5. This proves the change helped real users complete the task. It's misleading when the two tests used different tasks or different kinds of participants.

CraftUp calls a bare "conversion rose 18%", with no users and no rejected options, the weak version of an outcome line. The same rule holds for data, marketing, and product work: name the measurement, the n (the number of people or cases measured), and what you gave up. A data analyst's version might give the before and after of the metric the analysis changed and the method behind it. A marketer's might give a campaign result with the comparison it was judged against. The structure doesn't change.

Should you password protect your portfolio when applying?

Only if the material really needs a gate. When it does, the password goes on the resume next to the link. Passwords on portfolios usually break on logistics rather than security, and the reviewer who gets locked out never tells you. The three settings are public, page password (one shared password on a single page), and gated (the reviewer has to ask you for access).

In the example, the access pass hit all three logistics failures:

1. The password went into a private question. Greenhouse has no standard portfolio-password field. Employers can add custom questions and mark them private. Greenhouse's own documentation says users without permission would see the private question on your profile but can't view your answer. The hiring manager sees that a password exists and can't read it.
2. The session lapsed. On Squarespace, everyone uses the same page password, and the session expires four hours after entry. A reviewer who opens the page in the morning and comes back after lunch hits the prompt again, and the password is in an email they've already archived.
3. There were two prompts. The page sat inside a site that also had a site-wide password, so the reviewer had to get through two gates.

The fix was one page password and no site password, with the password printed on the resume. Squarespace doesn't index password-protected pages, so a gated page also won't turn up in search. That cuts both ways, depending on why you gated it. If the page is on Webflow, check that the site plan is active. On the free plan the password won't apply.

Then test it the way a reviewer would. Open the link from the resume PDF itself, not from your bookmarks, in a logged-out private window. On Squarespace, open it again four or more hours later. When you tailor resumes per posting, this line is easy to drop from one version. Refolk carries it through every tailored resume, so the link and password you tested are the ones each employer receives.

The 60-second cold read

A cold read means handing the page to one person outside your discipline for 60 seconds, then hiding it and asking open questions straight away. The page passes if they can state your role and your result without prompting. It's the last pass, and it's the only one that tests the page instead of your opinion of it.

The method is adapted from the five-second test, a usability method: show a page, hide it, and ask open recall questions immediately. I've stretched the window to 60 seconds to roughly match the one screening time with a published method. Be clear about the limits. No validated 60-second role, team, result, and decision question set has been published. This is a structured self-check, not a research instrument. Five-second-test guidance from Great Question says to keep to 4 or 5 questions and avoid leading ones. Lyssna puts five to ten participants as typically enough for a recall-focused test. You can start with one reader per pass and add more if results disagree. CraftUp's version for product managers asks: can a stranger state your problem, segment, and decision after a two-minute scan?

Setup (say this): "I'll show you a web page for 60 seconds. Read it however you normally would. Then I'll hide it and ask a few questions."
[Start the timer when the page is on screen. Hide it at 60 seconds. Ask immediately.]
1. What was this person's role on the project?
2. Who else worked on it?
3. What happened as a result of the work?
4. What is one choice they made, and what did they not do instead?
5. What, if anything, was confusing?
Pass: answers to 1 and 3 match your header without prompting.
Log: date, reader's field, answers verbatim, pass or fail, what you changed.

In the example, the first cold read was a false pass. The candidate asked, "Were you the lead designer?" The reader said yes. Yes/no questions hand over the answer. The re-run used only the open questions above. The reader got the role and recalled that the redesign "worked better", but couldn't say how. So the outcome line was still too specialist. The revision put the before-and-after figures in plain words in the line itself, and a second reader, again from outside design, stated both role and result.

Why researchers should weight this step most

In Refolk's index there are 16,891 UX/Product Designer profiles and 1,384 UX/User Researcher profiles in the US, and 4,217 and 753 in the UK.

My inference from the ratio, which hasn't been measured: where researchers are this scarce, a researcher's page is more likely to be screened by a designer, a product manager, or a recruiter than by another researcher. That makes a non-specialist cold read the most realistic test of the page. The same reasoning applies to anyone whose discipline is small inside the hiring company, including data, analytics, and specialist marketing roles.

The procedure, step by step

These are the eight steps, in order. By my rough, unsourced estimate, the first pass through all eight takes about half a day, and most of that goes on the inventory and the decisions rewrite. Each step has a done condition, so you know when to move on.

How a case study page goes wrong

Most failures are invisible to the candidate. The reviewer just closes the tab, or never gets onto the page. Each failure below has a check you can run before you send the link.

1. Outcome buried at the bottom. What it looks like: a strong result on the last screen of a chronological page. Why it matters: the one measured screening time, 55 seconds, also covers the cover letter, so anything below the first screen may go unseen. Check: the cold reader states the result without having scrolled.
2. A password nobody received. What it looks like: the password typed into an application form question. Why it matters: in Greenhouse a private custom question can show the hiring manager the question but not your answer. Check: the password is printed on the resume next to the link.
3. The password lapses, or there are two prompts. What it looks like: the page works when you test it and fails for the reviewer later. Why it matters: Squarespace page sessions expire after four hours, and a site password on top of a page password means two gates. Check: reopen the link four or more hours later, and confirm there's only one prompt.
4. The page won't sit behind a password. What it looks like: you set a password in the editor and the live page is open, or the setting is unavailable. Why it matters: Webflow needs a paid Site plan for page and folder passwords, and HubSpot needs Content Hub Professional or Enterprise. Check: open the live URL logged out.
5. Process padding. What it looks like: sticky-note walls, dense diagrams, tiny text. It reads as rigour to you and as noise to a screener. ADPList flags sticky notes and tiny text as unhelpful. Check: a reviewer can name one decision you made.
6. Leading cold-read questions. What it looks like: "Were you the lead?" answered "yes". That's a false pass, because the question supplied the answer. Check: ask only open questions, immediately after the read.
7. Quoting the unsourced 6 to 8 second figure. What it looks like: a page built around a number nobody can trace, or a cover letter that cites it. Check: before using any scan-time figure, find the method behind it.
8. A bare metric. What it looks like: "Conversion rose 18%" with no baseline, no n, and no trade-off. It invites doubt rather than a call. Check: the outcome line names the measurement, the n, and what you gave up.

A ninth risk is a matter of judgement. Some advice holds that reviewers judge a portfolio by its weakest project. UXfolio puts it as hiring managers looking for consistency rather than averaging your work. No published study tests that claim. It's still a sensible reason to cut a weak case study rather than leave it up beside a strong one.

Before you send the link, and keeping it current

The page is done when every item below is true. It stays done only if you re-run the checks whenever something changes. A site edit, a platform plan change, or a new posting with a different job title can each break a page that passed last month.

To keep it current:

• After any site edit, repeat the logged-out private-window test. Template changes and new site-wide settings are how second password prompts creep in.
• When a platform's plans or settings change, check its help page for page passwords. Plan requirements and session behaviour are product decisions and can change. This guide describes how each setting works so you can re-check it, not as a promise that it stays the same.
• When you rewrite the header, run a fresh cold read with a new reader. A reader who has seen the page before will remember it rather than read it.
• For each new posting, check that the title in the role line matches the posting's term, and that the resume version you send still carries the tested link and password.
• When you add a second case study, run the whole procedure on it before linking it. An untested page next to a strong one may be the one a reviewer opens first.