# The Presentation Round, One Project Positioned and Defended

*You can take one of your own projects, cut it to read at your target level, and defend those cuts against the probes that follow.*

- Canonical URL: https://www.refolk.ai/candidates/guides/presentation-round-project-positioned
- Pillar: Positioning and materials
- Format: Teardown
- Published: 2026-08-27
- Last reviewed: 2026-08-27
- Reading time: 18 min

You have a portfolio or work-sample presentation booked, and you need to decide how to frame one specific project so it reads at your target level, then hold that framing when the panel starts pushing. This guide is for anyone building that presentation - product and UX designers most directly, but the positioning logic carries to any work-sample walkthrough. Instead of a generic deck template, I carry one project all the way through the forks that decide the level read, including the two wrong turns that made it read junior, so you can follow along on your own case.

The worked example is a checkout redesign. I will keep re-cutting the same project, show the intermediate versions, and mark where each one lands on the junior-to-senior read. By the end you should be able to run your own project through the same decisions.

## What the presentation round actually is, and how much time you get

A presentation round is a scheduled block, usually toward the middle or end of the loop, where you walk a panel through your own work and then take questions. The dominant format is a full hour: roughly 5 minutes for intro and setup, 45 minutes presenting, and 10 to 15 minutes of Q&A. If nobody tells you the length, plan to present for around 40 minutes and leave room for questions.

That envelope changes by format, and the format changes what you build. Screens run shorter and interruptive - 30 to 45 minutes for a walk-through, with the panel breaking in. Academic committee formats stretch to 75 minutes with structured Q&A. Confirm which one you are in before you build anything.

| Format | Total | Present | Q&A |
|---|---|---|---|
| Onsite panel | ~60 min | 45 min | 10-15 min |
| Screen / interruptive | 30-45 min | short cut | interspersed |
| Academic committee | 75 min | 30 min | 15+15 min |

The number that governs everything is not on that table. Reviewers spend at most 2 to 3 minutes per portfolio in a scan, and that scan instinct carries into the live read. Your first two slides set the level before you have said much. Everything in this guide is really about spending those first two slides well.

**2-3 min - Time reviewers spend per portfolio in a scan**

The same instinct governs the live read, so your first two slides set the level before you speak.

## Which project to present, and how many

Present one main case study deeply, with a backup ready, rather than your entire portfolio. Interviewers prefer depth over quantity, and the fastest way to fail is to cram three or four deep dives into a 45-minute slot so none of them is deep.

The selection is a curation problem before it is a presentation problem. Pick three to five projects that match the role's core requirements, then rank them by relevance to that role - not by recency, and not by how proud you are of the visuals. A documented workflow: use one project to prove judgment, one to show range, and one backup in case the panel wants depth somewhere you did not plan to go.

Counts differ by company, so confirm rather than assume. Some panels want exactly one main case study. Zalando expects two detailed case studies in its design deep dive. Broader curation advice lands at three to five standout, role-relevant projects to bring, from which you lead with one.

The backup is not filler. A real rejection case came from a candidate who could only talk about one project across a five-year career - the panel read thin range and passed. So the third piece exists to survive a probe, not to occupy time.

> **Watch out:** The recruiter's suggested project is not automatically your lead
>
> When a recruiter suggests a project, weigh it against your ranked list. Whether to override that suggestion is not something public guidance settles, so treat it as your call: lead with the project you can defend deepest at your target level, and keep the recruiter's suggestion as your range piece if it is not that.

For our worked example, I have three candidates: a checkout redesign at a mid-size retailer, a design-system contribution, and a zero-to-one onboarding flow. The checkout project has a measured outcome and a real trade-off, so it becomes the anchor. The onboarding flow shows range and becomes the backup. Everything below re-cuts the checkout project.

## The opening fork: what slide one says

Slide one should state the problem in business terms and name the outcome, because the panel reads your level from that slide before you have earned any benefit of the doubt. There are two defensible openings and one that fails.

The first defensible approach is solution-first: introduce the solution up front, because humans have limited patience and giving the panel an expectation of where you landed helps them follow the rest. The second is result-first: open with the job-relevant result, then show the process, then close with what you would do differently. Both front-load the thing that reads senior. The rule they share is anti-chronological - most employers prefer your favorite project first because they want to see what energizes you, so refrain from chronological order and instead build an order that communicates your highest level of skill.

Here are the two wrong turns I actually took on the checkout project before I found the version that held.

### Wrong turn one: the tooling-led open

My first cut opened on process. Slide one was the Double Diamond, slide two a persona named Sally, slide three the Figma prototype. It looked complete. It read junior. A tooling-led open proves you know the tools, which the panel already assumes, and it spends the 2-to-3-minute scan window on the one thing that carries no level signal. The biggest difference between a junior and a senior portfolio is business impact, not visual quality, and this open led with neither.

### Wrong turn two: the feature-count open

The second cut fixed the tooling problem but not the level. Slide one became "I designed a new checkout flow - here are the wireframes, the UI kit, and the final screens." That is a component list. It says "I can make UI." For a large project it actually buries the scope, because a complete-looking inventory of deliverables hides the decisions that made the project hard.

### The open that survived

The version that held opened with the outcome and the stakes: "Guest-checkout friction was driving a 12% cart-abandonment gap on mobile. I led the redesign that closed it." That is a business outcome and a specific contribution. Compare the junior message "here are the wireframes, UI kit, and final screens" to the senior message "reduced cart abandonment by 12% by removing guest-checkout friction." Same project, same visuals, different level read.

#### The level read of your opening slide

Horizontal axis runs from Process-led to Impact-led. Vertical axis runs from Solo framing to Team framing.

| Quadrant | What it means |
| --- | --- |
| Tooling-led, solo | Reads most junior; cut this open entirely |
| Impact-led, solo | Strong outcome but reads as an individual contributor; add the team |
| Process-led, team | Collaborative but no result; attach a measured outcome |
| Impact-led, team | The senior read; lead here and defend it in Q&A |

*What you lead with, on two axes, decides whether the panel reads junior or senior before you speak.*

## Cutting the project for level

Level is read from what you cut, not what you add. The documented junior-to-senior gap is business impact versus process, so adding polish cannot fix a feature-count narrative - only cutting the process beats and foregrounding decisions can. Go through the deck and, for every slide, ask whether it answers "what did I decide and what did it change" or only "what tool did I use." Cut the second kind.

The table below is the re-cut of the checkout project, slide by slide, showing what each beat signals and what I did with it.

| Slide beat | Level it reads | Cut or keep |
|---|---|---|
| Double Diamond diagram | Junior (process) | Cut |
| Persona "Sally" | Junior (tooling) | Cut |
| Wireframes / UI kit inventory | Junior (feature-count) | Cut to one summary slide |
| Guest-checkout friction hypothesis | Senior (decision) | Keep, lead |
| 12% abandonment before/after | Senior (impact) | Keep, foreground |
| Trade-off: speed vs account capture | Senior (judgment) | Keep, defend |

Four cuts and two promotions turned the same body of work from a UI showcase into a judgment case. Notice what stayed: the hypothesis, the metric, and the trade-off. Those three are the spine of a senior read.

Two more level signals hide in the framing rather than the slides. The first is solo versus team. A junior portfolio looks like solo work - "I did the research, I did the UI, I did the testing" - while a senior portfolio highlights teamwork, because companies hire seniors to lead teams. On the checkout project I named the researcher who ran the usability sessions and the engineer who flagged the auth constraint, then stated my specific contribution: I owned the flow decisions and the trade-off call. The second is metrics. The most important difference between senior and junior is that a senior designer measures the success of the solution, while juniors over-focus on the UX process. If you cannot state what changed and how it was measured, the panel reads junior no matter how the deck looks.

> Adding polish cannot fix a feature-count narrative; only cutting the process beats and leading with the decision can.

Ground the audience before you go deep. Spend three to five minutes on the company's customer base and revenue model, how success was measured, and your specific role. A stranger in the room should understand what was at stake before you show a single screen. This is the "set the scene" beat of the story frame: introduce the character (you), the scene (the organization, the problem, the team), and the conflict (the problems you worked on).

## The probes that follow, by role type

The Q&A is where the same walkthrough passes or fails, because a decision stated without a defense reads as a guess even when it is correct. The dominant probe is "why" - be ready to explain the reason behind every decision and to answer constraint questions like "why didn't you do X?" What else gets probed depends on the discipline.

| Role type | What the panel probes |
|---|---|
| Brand / graphic | Systems, typography, visual hierarchy, cross-channel translation |
| UX / product | User problems, research inputs, testing, iteration, usability vs stakeholder trade-offs |
| Copy | Message strategy and audience |
| Creative director / marketing lead | Team leadership, prioritization, budget, revenue impact |

Across disciplines the questions split two ways. Behavioral probes cover soft skills, collaboration in the product trio, conflict, and ambiguity. Technical probes cover terminology, design process, and tool mastery. For the checkout project I expected the UX/product row: why remove guest checkout, what did testing show, and what did the trade-off cost the business in captured accounts.

Ask me this: `Senior product designers in London who led a checkout or payments redesign with a measurable conversion outcome` - [run the search](https://www.refolk.ai/start?q=Senior%20product%20designers%20in%20London%20who%20led%20a%20checkout%20or%20payments%20redesign%20with%20a%20measurable%20conversion%20outcome).

*Returns people who have run the exact project shape in this teardown, so you can see how peers at your target level frame the same decision and outcome.*

## Holding the framing under Q&A

A strong defense names the choice, gives the reason it fit the requirements, and acknowledges what the choice cost. That third part is the one candidates skip, and it is the one that decides the read.

Naming the cost is a positive signal, not a concession. Acknowledging downsides is one of the strongest positive signals a panel can get, because panels are pricing risk, and a candidate who hides costs reads as someone who will hide them on the job. Defending aggressively or refusing to name a downside signals immaturity. So when the panel asked why I removed guest checkout when it might cost captured accounts, the answer was not a wall. It was: I chose to keep guest checkout and defer account creation to post-purchase, because the requirement was conversion on mobile where friction was killing the funnel; the cost is fewer accounts captured at the moment of purchase, which I mitigated with a one-tap post-purchase account offer.

That answer has the three parts and it also passes the difficulty test: a decision only counts as a difficult trade-off if you could plausibly defend the opposite choice. If keeping guest checkout had no downside, it was not a hard call and does not read as one. Prepare each defense so you could argue the opposite side, because that is what proves the decision was real.

Structure the answers with STAR - Situation, Task, Action, Result - when a probe asks about a challenge or conflict. It keeps you from wandering and lands you on a result, which is where you want every answer to end.

**Decision-defense script**

```
Decision: I chose [the choice] over [the alternative].
Why it fit: The requirement was [business/role requirement], and [the choice] served it by [mechanism].
What it cost: The downside is [specific cost], which I [mitigated by / accepted because].
Opposite case: If I had chosen [the alternative], the argument would be [plausible reason] - which is why this was a genuine call.
```

*Fill one of these per major decision before the round. If you cannot write the third line, you have not made a real trade-off.*

> **Rule:** Every kept decision needs a stated cost
>
> Before the round, write the cost of each major decision out loud. A decision presented with no downside reads as luck, not judgment, and the panel will probe until it finds the cost you left off.

## The procedure, start to finish

Here is the full sequence I ran on the checkout project, from the confirmation call to the dry run. Follow it on your own project in order; each step has a clear done state.

#### Positioning one project, end to end

1. **Confirm format and time** - On one recruiter call, establish whether it is an interruptive screen (30 to 45 min) or an uninterrupted onsite (45 to 60 min), plus panel size. Done when you know minutes, panel size, and interactive vs straight-through.
2. **Select and rank projects** - Pick three to five projects matching the role's core requirements and rank by relevance. Done when you have one anchor, one range piece, and one backup.
3. **Choose the lead and the opening** - Decide solution-first or result-first, and refuse chronological order. Done when slide one states the problem in business terms and the outcome.
4. **Ground the audience** - In three to five minutes, cover the customer base and revenue model, how success was measured, and your role. Done when a stranger knows what was at stake.
5. **Cut for level** - Replace tooling and process beats with decision and impact beats. Done when each kept slide answers what you decided and what it changed.
6. **Build short and long versions** - Prepare a 5 to 10 minute interruptible cut and the full cut. Done when you can drop to the short version on cue.
7. **Prepare the defense** - For each major decision, name the choice, the reason it fit, and its cost. Done when you can plausibly argue the opposite choice.
8. **Dry run** - Run the full presentation two to three times against a clock. Done when timing fits with the Q&A buffer intact.

#### Where the presentation narrows in one hour

| Stage | Figure | Note |
| --- | --- | --- |
| Intro and setup | 5 min | Panel context and your framing |
| Presentation | 45 min | The cut project, impact-led |
| Q&A | 10-15 min | The defense, where the read is decided |

*The block starts wide and ends on the exchange that actually scores you.*

## How this goes wrong

Most failures in this round are level-read failures that happen before the Q&A, plus one that happens during it. Each has a false positive - a reason it feels fine while it is failing - and a local check you can run against your own deck.

- **Feature-count opening buries scope.** Listing wireframes, UI kit, and screens reads junior even on a large project. The false positive is a deck that looks complete. Check: does slide one state a business outcome or a component list?
- **Tooling-led open.** Leading with Figma, the Double Diamond, or personas proves tool literacy, not judgment, and burns the scan window. The false positive is that it feels rigorous. Check: cut every "how I used the tool" beat that has no decision attached.
- **Solo framing on a team project.** "I did the research, the UI, and the testing" reads as silo work. The false positive is that it feels honest. Check: name your collaborators and your specific contribution.
- **No metric of success.** Presenting output without outcome reads junior. The false positive is a strong visual story. Check: can you state what changed and how it was measured?
- **Defending too hard under probe.** Refusing to name a downside signals immaturity. The false positive is that it feels like confidence. Check: state the cost of your choice out loud, unprompted.
- **Over-packing the slot.** Three or four deep dives in 45 minutes makes none deep. The false positive is that more work looks like more value. Check: do your reps finish with the Q&A buffer intact?
- **Recycling the website as the deck.** A read-at-your-pace site is an asynchronous artifact and fails live. The false positive is that the content is already there. Check: build a navigable deck even if told a deck is optional.
- **Fabricated difficult decision.** A hard task with a tidy ending is not a defensible trade-off. The false positive is a clean story. Check: could you plausibly defend the opposite choice?

> **Tip:** The website is not the deck
>
> A portfolio website assumes the reviewer controls the pace. In the room, you control the pace. Build a linear, navigable deck so you never hunt for a screen while the panel waits, even if the recruiter says a website is fine.

## Why the level read is worth this much work

The payoff for getting the level read right scales with how thin the pool is at your target band. In Refolk's index of professional profiles, the US market by current title shows how supply concentrates:

| Current title (US) | People | Ratio vs Product Designer |
|---|---|---|
| Product Designer | 10,790 | 1.00x |
| Senior Product Designer | 8,385 | 0.78x |
| UX Designer | 5,648 | 0.52x |

The senior pool is real and large in the US. But the market rewards senior framing most where supply is thinnest. Refolk's index shows Senior Product Designer at 8,385 in the US against 2,316 in the UK.

| Market | Senior Product Designer | Share of US |
|---|---|---|
| United States | 8,385 | 100% |
| United Kingdom | 2,316 | 27.6% |

A UK candidate who holds a senior-level frame competes in a pool roughly a quarter the size of the US one, which raises the payoff of getting the level read right. The framing work in this guide is where that read is won or lost.

If assembling the raw material feels heavy - reconstructing outcomes, drafting the impact-led framing, tailoring it to a specific posting - [Refolk](/candidates) can build your resume from your own history and tailor it to each role, which gives you the outcome-first language to carry straight into the deck. It also scores how well you fit a posting, so you know which of your three ranked projects best matches the panel you are about to face.

## Before you call it done

Run this checklist against your finished deck and your defense notes. If any item fails, you have a level-read gap the panel will find.

#### Presentation-ready check

- [ ] Slide one states a business outcome, not a component list
- [ ] No tooling or process beat survives without a decision attached
- [ ] Your specific contribution and your collaborators are both named
- [ ] Every kept slide answers what you decided and what it changed
- [ ] Each major decision has a stated cost you say out loud
- [ ] You could plausibly argue the opposite of each major decision
- [ ] You have a 5 to 10 minute interruptible cut ready
- [ ] A backup project is deep enough to survive a probe
- [ ] You built a navigable deck, not a website walk-through
- [ ] Two to three dry runs finished with the Q&A buffer intact

To keep this current, re-run the format-confirmation call for every new loop, because the time envelope and panel size change per company and dictate the short-versus-long cut. Re-rank your three projects against each specific posting rather than reusing a fixed order, since the anchor that reads senior for one role may be only the range piece for another. And after each round, note which probe you could not defend cleanly and write the missing cost into your defense script before the next one.

## Frequently asked questions

### Which project should I present in a portfolio interview?

Lead with the project that best matches the role's core requirements and lets you show judgment, not your most recent or most polished one. Pick three to five relevant projects, rank them by relevance, and make your top choice the anchor. Employers prefer your strongest, favorite project first because they want to see what energizes you, so refrain from chronological order entirely.

### How many projects should I present?

Usually one main case study presented deeply, with a backup ready for probing. Interviewers prefer depth over quantity, and cramming three or four deep dives into a 45-minute slot makes none of them deep. Some panels differ: Zalando expects two detailed case studies. The safe workflow is one anchor to prove judgment, one range piece, and one backup you can go deep on if asked.

### How do I make a project read at senior level instead of junior?

Cut the tooling and process beats and lead with the decision and the measured outcome. The documented junior-to-senior gap is business impact, not visual quality. Replace "here are the wireframes, UI kit, and final screens" with "reduced cart abandonment by 12% by removing guest-checkout friction," name your collaborators and your specific contribution, and make trade-offs explicit rather than implicit.

### How do I defend a design decision when the panel pushes back?

Name the choice, give the reason it fit the requirements, and acknowledge what the choice cost. Defending aggressively or refusing to name downsides signals immaturity, while acknowledging downsides is one of the strongest positive signals because it shows realism. Use STAR to structure the answer, and only present a decision as difficult if you could plausibly defend the opposite choice.

### How long should a portfolio presentation be?

Plan for a full-hour block: roughly 5 minutes of intro and setup, 45 minutes presenting, and 10 to 15 minutes of Q&A. If you are not told the length, plan to present for about 40 minutes and leave time for questions. Screens run shorter, 30 to 45 minutes and often interruptive, so prepare a 5 to 10 minute cut you can drop into.

### Can I just present my portfolio website?

No. A read-at-your-pace website is an asynchronous artifact and fails as a live presentation. Build a navigable deck even if the recruiter says a deck is optional. The website assumes the reviewer controls the pace, but in the room you control the pace, and a site forces you to hunt for slides while the panel waits.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/candidates/guides/presentation-round-project-positioned*