Interview Insights · UI UX Designer
Why Every UI UX Designer Should Practice Explaining Their Portfolio Aloud
Quick summary — UI UX portfolio talk
In a portfolio review, how you talk through the work matters as much as the work on screen. Most UI UX hiring includes a portfolio presentation where you share your screen and walk a panel through one or two case studies. Candidates who rehearse it aloud sound like designers explaining decisions. Candidates who do not end up reading their own slides, scrolling through every screen, or getting thrown off by the first interruption. Practising aloud fixes timing, order, your role in team work and how you handle questions.
In this guide you will learn:
- Why a written portfolio and a spoken one need different structures
- A ten-minute talk track for one case study
- How to explain your role honestly in group or college projects
- How to handle interruptions and tough questions mid-presentation
- A rehearsal plan with timing and self-review points
SECTION 01Why your portfolio reads well but presents badly
A written case study is designed for skimming. The reader controls the pace, jumps to the images and skips the text. A live portfolio review flips that. The panel cannot skip ahead, you control the pace, and every second you spend scrolling past screens is a second they are waiting for the point.
This is why a portfolio that looks impressive on Behance often presents poorly. Long scroll pages, dozens of screens and paragraphs of process text all work against you when shared on a call. You need a talk track: a planned spoken path through the work that picks the moments worth stopping on and skips the rest.
| Written portfolio habit | Why it fails live | Spoken alternative | What to prepare |
|---|---|---|---|
| Long single scroll page | Endless scrolling looks unplanned | Jump to 4 or 5 marked sections | Anchors or a short slide version |
| Every screen shown | Panel loses the thread | Show 3 key screens, offer the rest | A 'key screens' frame in Figma |
| Process text paragraphs | You end up reading aloud | Say it, let the image support you | Speaker notes, not slide text |
| Process steps in order | Research-define-ideate sounds generic | Lead with the problem and your key decision | One-line problem statement |
Candidate (reading from screen):
"Project overview. This project is a redesign of a
library app. The goal of the project was to improve the
user experience. My process included research, define,
ideate, prototype and test. In the research phase I
conducted user interviews..."
(Panel can read faster than the candidate speaks.
Nothing new is added by speaking.)Candidate (slide shows one before/after image):
"Students at my college could not tell whether a book was
actually on the shelf or just listed. That one problem
caused most of the complaints I heard.
I was the only designer, working with two developer
classmates. I want to show you two decisions: how we
showed real availability, and why I removed the search
filters most people expected me to add."The second opening gives the panel three things in under thirty seconds: the problem, the candidate's role and a preview of what is coming. They now know what to listen for.
SECTION 02A ten-minute talk track for one case study
Most portfolio rounds give you somewhere between a few minutes and half an hour, often for one or two projects. Ask beforehand if you can. Then plan around a ten-minute version of your strongest case study, because you can stretch it or cut it from there.
The structure below puts most of your time on decisions, which is what panels care about most. Research and outcome still matter, but they are the frame, not the picture. Rehearse with a timer, because nearly everyone underestimates how long they talk about the beginning.
| Segment | Time | What you show | What you say |
|---|---|---|---|
| Hook | 0:00-1:00 | One hero image of the final design | Product, user, problem in three sentences |
| Context and role | 1:00-3:00 | One research artefact, team diagram | Evidence for the problem, exactly what you did |
| Decision 1 | 3:00-5:30 | Before and after, or two options | What you chose, what you rejected, why |
| Decision 2 and outcome | 5:30-10:00 | Prototype or test result, final flow | Second trade-off, result, what you would change |
TALK TRACK - library availability app (10 min)
[0:00] HOOK
'Students could not tell if a book was on the shelf.'
Show final book page with live availability badge.
[1:00] CONTEXT + ROLE
Survey and 6 hallway interviews (my own study).
Me: research, flows, UI. Two classmates: front end.
[3:00] DECISION 1 - availability badge
Option A: text 'Available' (testers ignored it)
Option B: shelf location + 'On shelf / Issued' badge
Chose B. Rejected colour-only status for accessibility.
[5:30] DECISION 2 - removed advanced filters
Testers used search box, rarely filters.
Kept 2 filters, moved rest behind 'More'.
[8:00] OUTCOME
Retest: testers found availability faster.
Would change: add reserve flow, test with staff.IF THE PANEL SAYS 'YOU HAVE 5 MINUTES'
[0:00] Hook (40 sec)
[0:40] Role in one sentence (20 sec)
[1:00] Decision 1 only (2 min)
[3:00] Outcome + one learning (1 min)
[4:00] 'Happy to go into the filter
decision or the research if useful.' (stop)
Rule: when cutting, drop Decision 2 first,
never drop your role or the trade-off.Having a five-minute cut ready is underrated. Panels run late, and the candidate who calmly says 'I will show you the shortest version' looks far more senior than the one who rushes through everything.
SECTION 03Explaining your role and handling interruptions
Two moments break unprepared presenters. The first is 'what exactly did you do?' in a group or college project. Saying 'we' for everything makes the panel suspect you did very little. Saying 'I' for everything makes them suspect you are taking credit for others. The honest middle is to be specific: name what you owned, what you shared and what others did.
The second moment is the interruption. Panels often stop you mid-flow to ask a question, challenge a decision or ask to see something else. This is a good sign, because it means they are engaged. But if you have only rehearsed a smooth monologue, you lose your place. Practise with someone who interrupts you on purpose.
| Interruption | Panic response | Calm response | Then |
|---|---|---|---|
| 'Wait, why that colour?' | Long defence of the palette | Short reason tied to contrast or brand | 'Shall I continue with the flow?' |
| 'Can you show the old version?' | Scrolls around searching | Opens a prepared before/after frame | Return to where you stopped |
| 'Did you test this?' | Claims testing that was thin | States exactly what was tested and with whom | Mention what you would test next |
| 'We are short on time' | Talks faster | Switches to the five-minute cut | Offer details afterwards |
ROLE STATEMENT FORMULA
'This was a team of [N]. I owned [specific parts].
I worked with [person/role] on [shared part].
[Others] handled [their parts].'
Example:
'This was a team of four for a college project.
I owned user interviews, the information architecture and
the final UI in Figma. I worked with one teammate on the
usability test script. The other two built the front end
in React and handled the database.'
Then use 'I' for your parts and 'we' for shared ones,
consistently, for the rest of the talk.INTERRUPTION DRILL (with a friend)
Friend gets this list and uses 3 at random,
at random moments during your 10-minute talk:
- 'Why is this button here?'
- 'What did the developer think of this?'
- 'Show me the version you rejected.'
- 'How many people did you test with?'
- 'Skip to the end, please.'
- 'What would you do with more time?'
Score yourself after:
[ ] Answered in under 30 seconds
[ ] Found the right screen quickly
[ ] Returned to the talk without restartingBefore every portfolio round, open each Figma file or case study page and check that the screens you might be asked about are one click away. Searching through frames while the panel waits is the most avoidable mistake in design interviews.
SECTION 04Portfolio presentation rehearsal plan
Run this plan in the week before your portfolio round. It covers technical setup, timed rehearsal and a self-review. Do the full rehearsal at least three times, and once with someone who interrupts you.
SCREEN SHARE SETUP (day before)
[ ] Close chat apps, turn off notifications
[ ] One browser window, only portfolio tabs open
[ ] Figma file cleaned: key screens in one 'Present' page
[ ] Before/after and rejected options ready as frames
[ ] Zoom level checked so text is readable when shared
[ ] Offline PDF backup in case the link fails
[ ] Water, charger, quiet room
[ ] Test share with a friend: can they read the labels?TIMED REHEARSAL (3 runs)
Run 1: Full 10-minute version, timer visible.
Note where you go over. Usually the hook and context.
Run 2: Same, but record video of your screen and voice.
Watch it at normal speed. Count how often you scroll
without speaking, and how often you read slide text.
Run 3: 5-minute cut, then a friend interrupts 3 times.
After each run, write one change. Apply it before
the next run.SELF-REVIEW AFTER EACH RUN
Did I state the problem in the first minute? Y / N
Did I clearly say what I personally did? Y / N
Did I name at least one rejected option? Y / N
Did I read any slide text word for word? Y / N
Longest silent scroll (seconds): ______
Time spent on decisions vs total: ____ / ____
The sentence I want to say better next time:
__________________________________________SECTION 05Habits that make you a stronger portfolio presenter
Strong presenters are not born confident. They prepare a few things that remove most of the risk.
- Lead with the problem — Your first sentence should be about a user problem, not the name of the design method you used.
- Make a presenting page — Build a separate Figma page or short slide set for live use, with only the frames you plan to show, in order.
- Speak about trade-offs — Every key decision should come with one thing you gave up. That is the clearest signal of real design judgement.
- Keep testing claims modest — Say exactly how many people you tested with and how. Panels respect a small honest test far more than vague claims.
- Pause after each decision — A short pause invites questions at natural points, so interruptions come where you are ready for them.
SECTION 06Interview Q&A — UI UX portfolio talk
Q1Can you walk us through your strongest case study?
Open with the user problem in one or two sentences, then your role. Spend most of the time on two key decisions, each with the option you rejected and why. Close with the result and what you would change. Offer to go deeper into any part.
Q2What exactly was your contribution to this team project?
Give a clear role statement: team size, what you owned, what you shared and what others did. For example, owning interviews, information architecture and the final UI, while classmates built the front end. Then stay consistent with 'I' and 'we'.
Q3Why did you choose this project to present?
Explain that it shows the kind of problem you want to solve and includes real trade-offs. Mention what makes it relevant to the company's product, such as a similar user type or a similar flow like booking or checkout.
Q4What would you do differently if you redid this project?
Name one or two specific changes, such as testing with a more representative group or designing an error state you missed. This shows reflection. Avoid saying 'nothing' or listing only visual polish.
Q5How did you know the design worked?
Describe the evidence you actually have: a retest with a few users, faster task completion in your sessions, or feedback from a real stakeholder. If you have no data after launch, say so and explain what you would measure.
SECTION 07Test yourself — UI UX portfolio talk quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
How long should a UX portfolio presentation be?
It depends on the company, so ask in advance. Prepare a ten-minute version of your best case study and a five-minute cut. Leave time for questions, which are often the most important part of the round.
How many case studies should I present in a UI UX interview?
Usually one or two. One case study explained well, with clear decisions and trade-offs, is stronger than three rushed ones. Keep others ready in case the panel asks.
Should I use slides or my portfolio website to present?
Either works, but a short presenting version is safer than scrolling a long web page. Many designers use a dedicated Figma page or a slide set and keep the full case study as a backup.
How do I present a group project in a UX portfolio?
State the team size and exactly what you owned, what you shared and what others did. Use 'I' for your own parts and 'we' for shared work, and keep that consistent throughout.
What do interviewers look for in a portfolio review?
They look for clear problem framing, evidence behind decisions, honest trade-offs, a clear account of your role and how you respond to questions. Visual quality matters, but reasoning usually decides the round.
Where can I practise UI UX Designer interview answers with expert feedback?
Yes. Uncodemy's UI/UX Design Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise UI UX Designer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Present your portfolio like a working designer
Our UI/UX Design Training Course includes real case study projects and repeated mock portfolio reviews, so you rehearse your talk track before the real panel.
Talk to a counsellor for current fees- Case study building
- Mock portfolio reviews
- Figma prototyping
- Weekday & weekend batches