The Presentation Round, One Project Positioned and Defended

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.

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.

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.

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.

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.

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.

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.

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: 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.

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.

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?

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:

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.

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 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.

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.