The Portfolio Presentation Deck Standard, Graded Before the Review Round

This standard is for anyone with a portfolio review round booked who has to turn written case studies into a live deck and wants to know it will hold up before sharing their screen with the panel. It sets seven pass or fail gates, with separate time limits for a 30-minute slot and a 45 to 60-minute slot. The gates are written so that two reviewers grading the same deck reach the same verdict. It applies to product design and UX research, and also to the marketing, strategy, and operations roles where portfolio-style presentations now show up.

What does the portfolio presentation standard grade?

The standard grades seven gates, and a deck passes only if every gate passes. One failed gate fails the whole deck, because each gate covers a way of losing the round that the other six can't make up for.

The live deck is a different object from the online case study. The panel sees it once, at your pace, against a clock, with interruptions, through a screen share that can break. It's also usually the first real look the panel gets at your work. One hiring team member put it bluntly: "you are lucky if your panel spends even 2 minutes total on your portfolio website." Whatever your website does well, the deck has to do again in the room.

The seven gates:

1. Time fit. The short version runs inside the talking time of a 30-minute slot, and the expanded version runs inside the talking time of a 45 to 60-minute slot. Both are measured on a timed rehearsal.
2. Named ownership. Every decision slide states at least one action in the first person singular.
3. Decisions over screens. In every case, slides that show only final screens never outnumber slides that show a decision.
4. Outcome or reflection. Every case ends on a metric or on a slide answering "what would you have done differently?"
5. Capability mapping. Every case maps to at least one capability stated in the posting, and the case names it.
6. Confidentiality. Every piece of protected work has written permission or a documented masking method, and has passed a check of metadata and internal terms.
7. Screen-share fallback. You have a local file, a PDF, and a view-only link, and you've presented the PDF end to end with Wi-Fi off.

Three terms are used throughout:

• A decision slide shows a trade-off, an alternative you rejected, or the reason you chose your approach.
• A screen slide shows designs or other finished work without that reasoning.
• Talking time is the number of minutes you're expected to present, once the panel's question time is taken out of the calendar slot.

No published source weights these criteria or sets a number for most of them. The thresholds below are my bar, built from what employers and reviewers have published. Each section says where the evidence stops.

How long should a portfolio presentation be?

Your presentation should last as long as the talking time the recruiter gives you, not the calendar slot. In published formats, that's about 30 minutes on one case, or about 30 minutes across two cases inside a 45-minute slot. Build a short version and an expanded version, because the advice online is contradictory and you may not learn which slot you have until late.

Here are the formats employers and candidates have published:

Only the Coinbase and GitLab rows come from the employers themselves. The Meta figure comes from a third-party guide and hasn't been confirmed by Meta. A 2015 internship guide written by Meta says the review covers three or four portfolio projects. That's old and specific to internships, so don't use it as the bar for a full-time role.

Here's how a 45-minute slot is reported to split:

The percentages are derived. Coinbase also says "staying within the time limit is just as important as the content itself." Taken together with the split above, that makes time fit a gate, not a style note.

Time thresholds per slot

• 30-minute slot: one case. GitLab's 1-hour designer interview spends approximately 30 minutes walking through one case. If the brief asks for two cases in 30 minutes, each case gets about half the time it would get at Coinbase's pace. Candidates have reported this ("I had to do 2 case studies in 30 mins for meta"), but nobody has published how often it happens, so ask.
• 45-minute slot: two cases. Spend 10 to 15 minutes on each case, set up context within 3 to 5 minutes, and leave about 10 minutes for questions. This is the shape Coinbase publishes.
• 60-minute slot: two cases in more depth, or a third. Candidate and practitioner reports range from about 45 to 60 minutes for 2 or 3 projects. Leslie Yang's template gives 20 minutes to case study 2 alone.
• No slot stated: draft at 40 minutes. UX Design Institute suggests planning for around 40 minutes. Use that only as a working length until the recruiter answers.

A panel deep dive on a single project is reported to usually last 60 to 90 minutes. That's a different round with a different shape, and this standard doesn't grade it.

What this gate proves: you can decide what matters within a limit the panel set. How it lies: the deck "fits 45 minutes" because you timed it against the calendar slot, and then it runs over once 10 minutes of questions come out.

How many case studies to present, and which ones?

Present the number of cases the brief asks for. If it doesn't say, use two for a 45 to 60-minute slot and one for a 30-minute slot: Coinbase recommends two in 45 minutes, and GitLab gives about 30 minutes to one. Choose cases by fit to the posting first and by how much decision evidence they hold second.

Gate 5, capability mapping, comes first because it decides which cases go in. Copy the capability phrases from the posting word for word into a list. Each case you keep must map to at least one of them, and the case's opening slide names it. A case is done when it maps to at least one stated capability.

If you've already tailored your resume to this posting in Refolk, the fit score shows you which of the posting's capabilities your history covers strongly and which it barely touches. Your lead case should land on the strong ones. A thin match is a case to cut or move to the expanded version.

What this gate proves: you read the posting and chose work that answers it. How it lies: the title slide claims the capability, but nothing in the case shows you using it. Graders check by asking: which slide shows this capability being exercised? If there's no answer, the gate fails.

What makes a decision slide pass review?

A decision slide passes when it names what you personally did, shows the alternative you didn't take, and leads to an outcome or reflection by the end of the case. Those three tests are gates 2, 3, and 4, and they follow the criteria panels publish.

Published rubric criteria for portfolio reviews include:

• Craft quality: the finish and skill of the work itself.
• Problem understanding: whether you understood what you were solving.
• Decision quality: "trade-offs, alternatives considered, and reasons for the chosen approach."
• Ownership: "the candidate distinguishes personal contributions."

Drill Bit Labs' UX research rubric uses Clarity, Rigor, Impact, Engagement, and Growth, each scored from 1 (Poor) to 5 (Exceptional). At GitLab, each interviewer must complete a scorecard with pros, cons, and an overall recommendation. None of these sources publishes weights per criterion. What the lists do show is that craft is one criterion among several. Hiring has been described as rewarding candidates who "connect design decisions to business outcomes."

Gate 2: named ownership

Pass: every decision slide has at least one sentence with a first-person action. A slide that only says "we" fails. What it proves: you meet the rubric's ownership criterion. How it lies: "I" appears, but only for things anyone on the team did, like "I attended" or "I was part of." Grader rule: the verb has to be a decision or an action that changed the work, such as chose, cut, tested, argued for, or rewrote.

Gate 3: decisions over screens

Pass: in every case, screen-only slides never outnumber decision slides. Count them per case, not across the whole deck. Interviewers specifically flag decks that are "just a gallery of final screens." No source publishes a ratio, so this bar is mine. A team adopting this standard can raise it but shouldn't lower it. How it lies: a slide titled "Decision" sitting over a final screen. Count a slide only if the trade-off or rejected alternative is actually visible on it.

Gate 4: outcome or reflection

Pass: each case ends on a metric or on a slide answering "what would you have done differently?" What it proves: you judge your work by its results, not by whether it shipped. How it lies: the metric belongs to the team, or it moved for reasons the work didn't cause. Or the reflection is a strength dressed up as a weakness. Grader rule: the reflection has to name one specific thing you'd change.

Who sits on the panel, and does this apply outside design?

Panels are reported as 2 or 3 designers plus an optional engineering or product person, or as a broader team of three to five people. One candidate reported presenting and defending their work for 45 minutes in front of four people. The same seven gates apply to research, marketing, and strategy rounds. Only the definition of a screen slide changes.

The people grading you come from a deep, senior-leaning pool. Here's what Refolk's index of professional profiles shows:

That's 3.7 US designers for every UK designer, and 8.0 US designers for every US researcher. In the UK sample, 13 of 25 profiles were in London. The US designer sample included people at Palantir Technologies, Microsoft, Threads, and Runway. The US researcher sample included Google, Meta, and Microsoft.

What follows for you: researchers should expect to present to senior peers who make the same calls themselves. That's where gates 3 and 4 get tested hardest. The samples are small, so treat this as a reason to prepare for senior questioning, not as a measured fact about any particular panel.

Rounds outside design

Portfolio interviews are reported to be "making its way into marketing, business, strategy, and even operations roles." For product marketing managers, the final round "often involves a presentation, usually a product launch plan or messaging proposal." These claims are qualitative. No survey or posting count has been published. To apply the gates:

• Screen slide equivalent: a finished asset shown without the choice behind it, such as an ad, a landing page, a report page, or a plan's summary table.
• Decision slide equivalent: a segment, channel, message, or method you chose, set against the option you rejected and why.
• Gates 1, 5, 6, and 7: unchanged.

How to handle confidential work in a live deck

Every piece of protected work needs written permission or a documented masking method before it goes in the deck. Showing it live doesn't make it private. As one guide puts it, "private disclosure is still disclosure," and "you have no control over what the hiring company and its agents could do with the content."

The documented methods:

1. Written permission from the former employer or client, kept on file.
2. Generalization method: describe the problem and decisions without client-identifying specifics.
3. Strategic content masking: hide or replace data, names, and identifying content.
4. Design recreation: rebuild the work with invented content that keeps the decision visible.
5. Secure portfolio access: gated, controlled access instead of an open file.
6. Labelled stand-in project: a substitute project, clearly labelled as one, that shows the same skill.

Here's what isn't established: no employer prep page found says which of these methods it accepts. You can check locally. Ask the recruiter in your brief email whether masked or recreated work is acceptable, and keep the answer.

What this gate proves: the panel can trust you with their own confidential work. How it lies: the slides look clean, but the exported PDF still has the client's name in its file properties, or a layer name gives away the internal project name.

How to build and grade the deck, step by step

Work through seven steps in order, from the written brief to a tested fallback. Each step has a done condition that maps to one or more gates. The first conversion from written case studies to a deck can take weeks, so start early.

Sources disagree on the order. The Crit puts getting the brief first. Another candidate advises starting the deck "well before you get to the portfolio presentation part," before any brief exists. I resolve it this way: build the core deck early, because conversion is slow, and finalize the short and expanded versions only once the brief is in writing.

Edit hard in step 3. One candidate reported "97 total slides with 34 of them hidden, so a total of 63 slides for a 45m presentation." Slide count isn't a gate, but a count like that is usually a sign that gate 1 or gate 3 is about to fail.

Briefs can also carry topic limits. Coinbase, for example, allows a maximum of two slides on your motivation for crypto. Treat any limit like that as part of the time gate.

Hi [name],

Thanks for setting up the portfolio review for the [role] position on [date]. So I can fit the format exactly, could you confirm four things?

1. How many minutes I should plan to present, after any time the panel wants for questions.
2. Who will be on the panel, by role.
3. How many case studies the team would like to see.
4. Whether questions should wait until the end or come during the walkthrough.

One more: some of my strongest work is under NDA. Is a masked or recreated version of that work acceptable to the team?

Thank you,
[your name]

How portfolio decks fail the review round

Most decks that fail looked like passes to the person who built them. Each failure below comes with its false pass, the version that fools the presenter, and the check that catches it.

1. Time fit against the wrong clock. The candidate times the deck against the calendar slot. False pass: the deck "fits 45 minutes," then runs over once 10 minutes of Q&A come out. Check: time a rehearsal with interruptions against the talking time the recruiter stated in writing. Coinbase says plainly that staying within the limit matters as much as the content.

2. Ownership hidden behind "we." The slides narrate the team's project. False pass: the presenter says "I" out loud while the slides say "we," and the reviewer grades the slides. Check: every decision slide has a written first-person action whose verb changed the work.

3. A gallery of final screens. The deck shows outputs, not choices. False pass: the screens are polished enough that the presenter mistakes craft for evidence. Craft is one rubric criterion out of several, and decision quality is separate. Check: count, per case, the slides with a visible trade-off or rejected alternative against the screen-only slides.

4. The website scroll. A hiring manager lists "literally a website walkthrough" as a common mistake. False pass: the website is good, so scrolling it feels efficient. It hands pacing to the page layout, and it fails gate 7 the moment the connection drops. Check: the thing you present is a slide deck, not a URL.

5. Leaky confidentiality. A blurred logo still identifies the client through layout and copy. False pass: the slides look clean on screen. Check: open the exported file's metadata, read the layer names, and search for internal terms and codenames.

6. A fallback that depends on the thing that failed. The backup is a Figma prototype or a cloud link, and both need live internet. People report prototypes that didn't run smoothly on weak internet, fumbling to find files, and accidentally showing personal browser tabs. Nobody has published how often each happens. Check: present the PDF with Wi-Fi off, and have someone watch the shared view for stray tabs.

7. The case that ends on the solution. The last slide is the shipped design. False pass: the story feels complete because the work shipped. Check: the final slide of each case is a metric or an answer to "what would you have done differently?"

A deck that passes on your own laptop has passed nothing; grade it on the shared view, with the Wi-Fi off.

Two of these failures are worth naming as the ones reviewers most often disagree on, which is why the grading rules above are written so tightly. On ownership, graders split over whether an "I" sentence counts. The verb rule settles it. On decisions over screens, graders split over whether a captioned screen counts as a decision. The visible trade-off rule settles that.

The grading sheet and pre-share checklist

Use one grading sheet per deck, scored independently by two people, and treat any gate they disagree on as a fail until it's fixed. Worksignal recommends two reviewers when portfolio evidence decides who advances, and that applies just as much to your own pre-review.

Deck: [file name and version]
Role and posting: [title, employer]
Stated talking time: [minutes, from recruiter in writing]

Gate 1 Time fit
  Short version, timed with interruptions: [mm:ss] vs 30-minute talking time  PASS / FAIL
  Expanded version, timed with interruptions: [mm:ss] vs 45-60 talking time  PASS / FAIL
Gate 2 Named ownership
  Decision slides lacking a first-person action that changed the work: [slide numbers or none]  PASS / FAIL
Gate 3 Decisions over screens
  Case 1: decision slides [n] / screen-only slides [n]  PASS / FAIL
  Case 2: decision slides [n] / screen-only slides [n]  PASS / FAIL
Gate 4 Outcome or reflection
  Case 1 final slide: metric / reflection / neither  PASS / FAIL
  Case 2 final slide: metric / reflection / neither  PASS / FAIL
Gate 5 Capability mapping
  Case 1 maps to: "[quoted capability]" shown on slide [n]  PASS / FAIL
  Case 2 maps to: "[quoted capability]" shown on slide [n]  PASS / FAIL
Gate 6 Confidentiality
  Protected items: [list]  Method per item: [permission / generalized / masked / recreated / secure access / stand-in]
  Metadata, layer names, internal terms checked  PASS / FAIL
Gate 7 Screen-share fallback
  Local file / PDF / view-only link present; PDF presented with Wi-Fi off  PASS / FAIL

Verdict: PASS only if all seven gates pass.
Reviewer: [name]  Date: [date]

Keeping the deck current

Grade the deck again for every round, not just once. The brief changes from employer to employer, so gates 1 and 5 change with it. Keep one core deck and rebuild only the case selection and versions for each posting. When you add a new case, run it through gates 2, 3, 4, and 6 before it goes in the core, so the core deck always passes on its own. Published formats change too. Re-check an employer's own interview guide when you book the round, because the numbers in the tables above are a snapshot of what each source said, and employers update them.