Most portfolio presentations fail on arithmetic before they fail on design.

You have forty-five minutes. Candidates arrive with four projects and a deck of sixty screens, spend nineteen minutes on the first project because it's the one they know best, then compress the remaining three into a montage and lose the last ten minutes to questions about the one they rushed.

The panel doesn't conclude "poor time management". They conclude they didn't see the work — and they're right.

So this is a walkthrough organised around the clock, because the clock is the constraint that actually shapes the round.

45
Minutes, of which roughly 15 are not yours
3
Projects, doing three different jobs
2
Minutes that decide it — the trade-off you name

Where the time actually goes

MinutesWhatNotes
0–2Who you are, in one shapeNot your CV. The kind of designer you are, in two sentences
2–20Project one, in depthThe only project you present fully
20–30Project two, narrowOne decision from it. Nothing else
30–35Project three, as evidenceOften just shown, not walked through
35–45Their questionsAssume they start earlier — they always do

The asymmetry is deliberate and it is the opposite of what most candidates do. One project deep beats three projects even. Depth is the only way a panel can tell your judgement from your team's, and judgement is the thing being hired.

Assume interruptions from minute eight. A deck that only works uninterrupted is a deck that won't survive this room.

Picking the three

Not your three best. Three that do different jobs, so that together they answer the three questions a panel has:

ProjectThe job it doesWhat it needs
One"Can you think?"A real constraint, a decision that was yours, a measurable outcome
Two"Can you do the unglamorous version?"A small, messy, or legacy piece — and why it was hard
Three"Can you make things?"Craft. Often shown silently while you talk over it

Project two is the one candidates omit and the one panels remember. Everyone brings a greenfield redesign. Almost nobody brings the settings page they made 30% less confusing under a two-week deadline with no research budget — and that one is closer to the actual job than the redesign is.

If you only have redesigns, pick the one with the worst constraints and present it as project two.

Project one, worked

Here's the narration for the deep one. The project is a checkout flow, the structure is the same regardless of domain.

The stakes, first sentence. "This is a checkout redesign, and the interesting part isn't the redesign — it's that we shipped a version I argued against, it failed, and the second version worked. I'll spend most of the time on why I was wrong the first time."

Opening with the failure is not humility theatre. It buys you the room's attention for eighteen minutes and it pre-empts the "tell us about something that went wrong" question later.

The constraint, in numbers. "Cart abandonment was 71%. The business wanted it under 60% in a quarter. We had one engineer for six weeks, the payment provider couldn't be changed, and we couldn't touch the account system — which mattered, because forced account creation was the thing everyone assumed was the problem."

What was mine. "I owned the flow and the interaction design. I didn't own the visual system — we had one — and I didn't own the copy, though I pushed hard on two strings and I'll come back to that. The research was two rounds of five unmoderated tests that I wrote and ran myself, because we had no researcher."

Naming what you didn't own is what makes the rest believable. A candidate who implies they owned everything gets probed on the part they clearly didn't, and the whole account loses credibility.

The decision, and the wrong first answer. "The team's theory was account creation. Mine was the address form — eleven fields, and the test sessions showed people slowing down there. So version one collapsed the address form to four fields with a lookup.

It moved abandonment from 71% to 68%. Basically nothing.

What I'd missed is that people weren't abandoning because the form was long. They were abandoning at the form because that's where the total first became real — the delivery cost appeared on the same screen. The form wasn't the problem, it was the place where the problem became visible. I'd optimised the room where the bad news arrived."

Version two, and the trade-off. "So version two moved the delivery cost up, onto the cart page, before anyone entered anything. That's uncomfortable commercially — you're showing the number that loses the sale, earlier, on purpose. It went to 58%.

The trade-off I'd name honestly: we almost certainly lost some people at the cart who would have converted if they'd been further in. We traded those for the people who'd been getting angry at step four. I think that's the right trade and I'd argue for it again, but it is a trade, not a free win."

What I took from it. "I now treat a drop-off point as a symptom until proven otherwise. The screen where people leave is very often not the screen with the problem on it — it's the first screen where the problem is undeniable."

The two minutes that decide the round are the trade-off paragraph. Everything else in that narration — the constraint, the ownership, the metric — is table stakes that strong candidates all clear. Naming what version two cost is what separates a designer who ships from one who presents. Panels have all shipped something with a downside, and they are listening for whether you can see yours.

Projects two and three

Ten minutes for project two, and the discipline is to present one decision, not the project.

"This one's a settings page. I'm showing it because it's the least glamorous thing I've done and it's the work I'd point at if you asked whether I can operate without research. Two weeks, no budget, a page with nineteen toggles that support hated. The one decision worth your time: I grouped by consequence rather than by feature area — what changes what other people see, versus what only changes your own view. That cut support tickets about it by about a third, and it took one afternoon to design and two weeks to argue for."

That's ninety seconds. Spend the remaining eight on their questions about it, because they will have them.

Project three is often best shown rather than presented: put it on screen, say two sentences about what it is, and let it demonstrate craft while you answer whatever they're already asking.

The thing to do with your visuals

Two rules, both about attention.

One screen at a time, and say what to look at. A slide with six screens on it invites everyone to read ahead and stop listening. If you need to show a flow, show the flow, then zoom into the one screen you're discussing.

Show the version you rejected. A before-and-after is worth more than a finished screen, and a rejected direction beside the shipped one is worth more than both. It's the only way a panel can see that a decision was made rather than arrived at.

What panels forget

The chronological walkthrough

“We started with a kickoff, then I did competitive analysis, then user interviews, then wireframes, then a prototype, then we tested, then we shipped.”

Accurate and unmemorable. It describes a process that every designer follows, so it distinguishes nothing. By minute six the panel is waiting for a decision to appear.

What panels quote later

The wrong turn, named

“I optimised the room where the bad news arrived.”

One sentence carrying a real insight, attached to a real number, from a mistake you made. This is what gets repeated in the debrief when three candidates are being compared — and the debrief is where the decision actually happens.

What to cut

Ruthlessly, in this order:

  • The persona slides. Unless a persona changed a decision, it's process evidence.
  • The competitive audit. Same test: did it change what you built?
  • Every screen that isn't part of the decision you're describing.
  • The thank-you slide. Ending on a question you want them to ask is stronger.
  • Any mention of a framework by name. The four moves work best when nobody can hear them — that's covered in the product design interview framework.

If cutting these leaves you short of forty-five minutes, you don't have a length problem. You have one project that needs more depth, and the time should go there.

The other rounds in the loop — the app critique, the design challenge, the craft round — ask different things and catch people who sailed through the walkthrough: Product Designer Interview Questions.

Rehearsing it

Out loud, timed, twice — and the second time, have someone interrupt you at minute eight with "can you go back to why you chose that?" The recovery is the skill. A deck you can leave and return to is a deck that works in the actual room; one you can only deliver in order is a performance that the first real question will break.

Practical target: present project one in eighteen minutes with no slides at all, just talking. If it holds up with nothing on screen, the story is doing the work and the visuals will amplify it. If it collapses without the screens, the screens were carrying a story you hadn't actually written.