Interview Insights · UI UX Designer
What Separates a Memorized Answer From Real UI UX Designer Skill
Quick summary — Memorized vs real UX
A memorized answer stops at the definition. Real skill keeps working when I change the question. Many UI UX candidates prepare by memorising definitions: design thinking stages, Gestalt principles and laws such as Fitts's, Hick's and Jakob's law. That is a fine start, but it is not what I am hiring. I follow every definition with an application question, then a twist that changes the user or the constraint. A candidate with real skill moves easily from words to screens. A candidate who memorised gets stuck at the second question, or applies the concept wrongly.
In this guide you will learn:
- The signs of a memorized answer I listen for in UI UX interviews
- How to apply Fitts's, Hick's and Jakob's law to real screens
- Why Miller's law is often misused, and what to say instead
- How twist questions work, and how to handle them calmly
- A practice method that turns definitions into skill
SECTION 01How a memorized UI UX answer gives itself away
Memorized answers have a sound. They are fluent, a bit too fast, and use exactly the words from popular articles. 'Design thinking is a human-centred, iterative process with five stages: empathise, define, ideate, prototype and test.' Nothing in that sentence is wrong. The problem is what comes next.
When I ask 'Tell me where your last project went back from testing to define', a memorizer often freezes or repeats the stages. Someone who has actually done it tells me what the test showed, which assumption broke, and how the problem statement changed. Real experience comes with specific, slightly messy details.
| Signal | Memorized version | Real-skill version | What I conclude |
|---|---|---|---|
| Speed and tone | Fast, flat, article-like wording | Slower, own words, some pauses | Fluency alone is not evidence |
| Examples | Generic: 'for example, an e-commerce app' | Their own project with a specific screen | Specifics suggest lived experience |
| Order | Stages in perfect sequence | Stages that looped back after tests | Real processes are not linear |
| Limits | Concept always applies | Knows when the rule does not fit | Depth includes knowing exceptions |
Q: What is design thinking?
A: Design thinking is a human-centred, iterative
approach with five stages: empathise, define,
ideate, prototype and test. It helps solve
complex problems creatively.
Q: Where did your last project loop back?
A: Um... we followed all five stages.
First we empathised with users, then
we defined the problem...Q: What is design thinking?
A: To me it's: understand the people, frame the
right problem, try options cheaply, and test.
Q: Where did your last project loop back?
A: In my library app, I first defined the problem
as 'students can't find books'. In testing,
they found books fine; they just didn't know
if copies were available. So I went back and
rewrote the problem as availability, not search.
The final design added a live 'copies left' badge.The lived answer even redefines design thinking in plain words. That is a strong sign of understanding, because you can only paraphrase comfortably what you truly know.
SECTION 02The application test: using UX laws on a real screen
My favourite follow-up after a definition is simple: 'Show me where that applies on this screen.' I might open a checkout page, a settings menu or the candidate's own design. This is where memorized knowledge breaks, because applying a law means noticing it in a messy real layout and deciding what to change.
The laws below come up often in UI UX interviews. Know the definition, but more importantly, know one concrete change each one suggests. Also know the common misuse. Miller's law, about short-term memory holding roughly seven items, is often wrongly used to argue that menus must have seven items or fewer. People scan menus; they do not memorise them.
| Law | Short definition | Applied on a real screen | Common misuse |
|---|---|---|---|
| Fitts's law | Time to hit a target depends on its size and distance | Make 'Pay' a full-width button near the thumb on mobile | Making every button huge, losing hierarchy |
| Hick's law | Decision time rises as the number of choices grows | Group 14 filter options into 4 labelled categories | Removing useful options instead of organising them |
| Jakob's law | Users expect your site to work like others they know | Keep the cart icon top-right as on most shopping apps | Using it to block every new idea |
| Miller's law | Short-term memory holds a limited number of items | Chunk a 12-digit number as 4-4-4 for easier entry | Claiming menus must have max 7 items |
SCREEN: Mobile checkout
Before:
- 'Pay now' is a small text link, top-right
- 'Cancel' is a large button at the bottom
Applying Fitts's law:
- The main action should be the largest, easiest
target, close to where the thumb rests.
After:
- 'Pay now': full-width button, bottom of screen,
48px tall
- 'Cancel': smaller text button above it
- Enough spacing so users don't hit Cancel
by mistakeSCREEN: Product filters (14 checkboxes in one list)
Applying Hick's law:
- Too many flat choices slow the decision.
- Don't delete filters; organise them.
After:
Price (range slider)
Brand (top 5 + 'See all')
Size (chips: S M L XL)
More (collapsed: material, rating, offers)
Also: show result count on the Apply button,
e.g. 'Show 38 results', so users see the effect.Notice that neither answer simply repeats a definition. Each one names the screen, the problem, the change and a detail that shows care, like spacing between Pay and Cancel.
SECTION 03The twist test: change the user, keep the skill
After the application, I twist the scenario. 'Now the users are mostly above sixty.' 'Now it must work on a slow 3G connection.' 'Now it needs Hindi and Tamil.' 'Now the user is in bright sunlight with one hand on a scooter handle.' A memorized answer has no slot for these. Real skill adapts, because it is built on understanding why the original design worked.
The goal is not a perfect answer. It is a visible, reasonable chain: what changes for this user, which part of my design breaks, and what I would change first. Saying 'I would test this with older users' is good, but only after you have reasoned about what you expect to find.
| Twist | What changes for users | Design response | What I'd test |
|---|---|---|---|
| Older users | Smaller targets harder to tap, small text harder to read | Larger type and targets, clear labels, fewer gestures | Can they finish checkout without help? |
| Slow network | Long waits, failed loads | Skeleton screens, cached data, light images, retry options | Does the app feel usable on throttled 3G? |
| Multiple languages | Longer words, different scripts | Flexible auto layout, no text in images, test longest labels | Does any label overflow or truncate badly? |
| One-handed, outdoors | Glare, limited reach | High contrast, key actions in thumb zone, large targets | Can they complete the task one-handed? |
Q: Your checkout now must work for users
above sixty. What changes?
A: 'First I'd expect two issues: reading small
text and precise tapping. So I'd raise body text
from 14 to 16 or 18, keep buttons at least 48px,
and replace icon-only buttons with icon + label.
I'd also remove swipe-to-delete, because hidden
gestures are hard to discover, and add a visible
Remove button.
Then I'd test with three or four older users,
ideally family members first, and watch where
they hesitate.'FIGMA: making a button survive longer text
Button frame
Auto layout: horizontal
Padding: 12 top/bottom, 16 left/right
Gap: 8 (icon to text)
Width: Hug contents (or Fill container in forms)
Min width: 120
Text layer
Resizing: Auto width
Max lines: 2 (wrap, don't truncate the action)
Test strings:
English: 'Place order'
Longer translation: replace with the
longest real string from the product teamNotice the twist answer starts by predicting the problems before suggesting fixes. That order, from user to problem to change to test, is exactly what the interviewer is listening for.
SECTION 04From definitions to skill: a practice worksheet
Use these three sheets to convert what you have memorised into something you can apply. Do one concept per day rather than ten at once.
CONCEPT TO SCREEN SHEET
Concept: _______________________
My own words (1 sentence): ______
App screen where it applies: _____
What's wrong on that screen: _____
The change I'd make: ____________
A case where the concept doesn't fit:
_________________________________
Do this for: Fitts, Hick, Jakob, Miller,
Gestalt proximity, visibility of system status.TWIST CARDS (write each on a card)
1. Users are above sixty
2. Network is very slow
3. Interface must support Hindi + English
4. User has low vision and uses a screen reader
5. User is outdoors in bright sunlight
6. Only 2 weeks of developer time
Pick one card + one of your projects.
Answer aloud: user -> problem -> change -> test.
Two minutes max per card.LIVED-EXAMPLE BANK
For each concept, one moment from my work:
Design thinking loop: ___________________
A test that changed my design: __________
A time I used fewer choices: ____________
A time I followed a familiar pattern: _____
A time I broke a pattern on purpose: ______
An accessibility fix I made: _____________
No moment yet? Make a small exercise
and create one this week.SECTION 05Habits that keep your answers real
Real skill is built by using concepts on real screens repeatedly. These habits make that part of your routine.
- Paraphrase everything — If you can only explain a concept in the article's exact words, you do not own it yet.
- Spot laws in the wild — Each day, find one UX law at work in an app you use, and note the screen and the effect.
- Learn the exceptions — For every rule, know at least one situation where following it blindly would hurt users.
- Answer with a screen — Whenever possible, point to a real or sketched screen while you explain an idea.
- Welcome the twist — Treat a changed constraint as a chance to show reasoning, and think aloud through user, problem, change and test.
SECTION 06Interview Q&A — Memorized vs real UX
Q1Explain Fitts's law and apply it to a mobile app.
Fitts's law says the time to reach a target depends on its distance and size. On mobile, that means primary actions should be large and close to where the thumb naturally rests. For checkout, I would make Pay a full-width button at the bottom and keep destructive actions smaller and spaced away to prevent mis-taps.
Q2Does Miller's law mean menus should have seven items?
No, that is a common misuse. Miller's work is about short-term memory, how many items we can hold in mind. Menus are scanned, not memorised. The real lesson is chunking: grouping information, like splitting a long number into blocks, so it is easier to process and remember.
Q3When would you break Jakob's law on purpose?
When the familiar pattern clearly harms users or your product's main task is genuinely different. Even then, I would make the new pattern easy to learn, keep surrounding conventions familiar and test it carefully. Breaking convention needs a clear reason and evidence, not just a wish to look different.
Q4How would your design change for users on a slow network?
I would use skeleton screens instead of blank loaders, compress and lazy-load images, cache recent data so screens open instantly, allow actions to queue and retry, and give clear feedback when something fails. Then I would test the app on a throttled connection to see where it feels broken.
Q5Tell me about a principle you learned the hard way.
Use a real example. For instance: 'I hid secondary actions behind a three-dot menu to keep the screen clean. In testing, users never found Edit. I learned that hiding things reduces discoverability, so I moved Edit back to a visible button.' Specific lessons show lived skill.
SECTION 07Test yourself — Memorized vs real UX quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
How do interviewers know if a UI UX answer is memorized?
They ask follow-ups: apply the concept to a real screen, explain where your project used it, or adapt it to a new user or constraint. Memorized answers usually break at the second or third question.
What UX laws should I know for a UI UX interview?
Commonly discussed ones include Fitts's law, Hick's law, Jakob's law, Miller's law and Gestalt principles such as proximity and similarity. Know each definition in your own words, one real application and one common misuse.
What is Jakob's law in UX?
Jakob's law says users spend most of their time on other sites, so they expect yours to work in similar ways. It suggests following familiar conventions, such as cart placement or navigation patterns, unless you have a strong reason not to.
How do I answer UI UX scenario questions in interviews?
Think aloud in a clear order: who the user is, what problem the scenario creates, which part of the design is affected, what you would change first and how you would test it. A reasoned partial answer beats a perfect-sounding script.
Is it okay to memorize UI UX interview answers?
Memorizing definitions is a fine starting point, but always connect each one to your own work and practise applying it to real screens. Interviewers reward application and reasoning, not recitation.
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
Turn UX theory into skill you can show
Our UI/UX Design Training Course teaches UX principles through real screens, critiques and projects, with mock interviews that include application and twist questions.
Talk to a counsellor for current fees- UX laws on real screens
- Scenario and twist practice
- Accessibility and i18n basics
- Mock design interviews