The One Question That Separates Real UI UX Designers From Pretenders

Interview Insights · UI UX Designer

The One Question That Separates Real UI UX Designers From Pretenders

SECTION 01Why 'when did a user prove you wrong?' is so hard to fake

Most interview questions can be prepared with reading. 'What is a persona?' 'What are the Gestalt principles?' 'What is your design process?' All of these have well-known answers. My question is different, because the answer only exists if something actually happened to you.

It also tests attitude. A designer who has been proven wrong and talks about it calmly sees testing as a tool, not a threat. A designer who insists their work has never been wrong either has never tested, or treats every finding as an insult. Neither of those works well in a real product team, where being wrong early is the cheapest way to get it right.

PATTERN 1: Denial
'Honestly, users really liked my designs.
Everyone said it was clean and easy.'

PATTERN 2: Theory
'Design thinking is iterative, so we
always improve based on feedback.'

PATTERN 3: Borrowed story
'In one famous case, a company changed
a button and got more sign-ups...'

None of these contain a user,
a screen or a change made by the candidate.

'In my expense-splitting app, I assumed users
would find Edit inside the three-dot menu on
each expense card.

I tested with five friends. I asked them to
change the amount of a dinner expense.
Three of the five tried tapping the amount
itself, then gave up or deleted the expense.

I changed the card so tapping anywhere opens
the edit sheet, and kept Delete in the menu.

I re-tested with five new people.
All five edited the amount on the first try.'

The real answer is small: five friends, one task, one change. It does not need a big company or a famous product. It needs a real event that you observed and acted on.

SECTION 02The follow-up probes that real answers survive

Even a prepared-sounding answer gets tested with follow-ups. I am not trying to trap anyone. I am checking whether the details hold together the way real memories do. Real stories survive probing easily, often with extra details I did not ask for. Made-up stories get vaguer with each question.

The probes below are the ones I use most. If you have a real story, practise answering each one in a sentence or two. If you notice that you cannot, that tells you which part of your process you skipped, which is useful to know before an interviewer finds out.

Q: What exactly did you ask them to do?
A: 'Change the dinner expense from 1200 to 1500.'

Q: What did they do?
A: 'They tapped the amount. Nothing happened.
   One long-pressed it. Two deleted the expense
   and created a new one.'

Q: Why do you think that happened?
A: 'The amount was large and bold, so it looked
   like the thing to tap. The three-dot icon was
   small and grey, so it looked decorative.'

Q: How did you know the fix worked?
A: 'Five new testers, same task, all succeeded
   on the first tap.'

WHAT USERS SAY vs WHAT USERS DO

Say: 'It's nice, very clean.'
Do : Took four tries to find Edit.
  -> Trust the behaviour.

Say: 'I'd definitely use this feature.'
Do : Never opened it during the task.
  -> Trust the behaviour.

Say: 'It's a bit confusing.'
Do : Tapped the amount, then deleted the card.
  -> The behaviour tells you WHERE and WHY.

In interviews, quote behaviour first.

The 'why do you think that happened?' probe is the one most candidates find hardest. It asks you to connect behaviour to a design cause, such as visual weight or affordance. Practise that step specifically.

SECTION 03No story yet? Earn one with a guerrilla test this week

Many freshers realise, while reading this, that they have never been proven wrong because they have never tested. That is fixable quickly. A guerrilla test is a short, informal usability test with people nearby: classmates, friends, family or people in a college canteen who agree to help for a few minutes. It is not a formal study, and you should never present it as one. But it is real evidence.

Pick your strongest project, write two or three realistic tasks, test with five people and record what they do. You will almost certainly find something you got wrong. Fix it, re-test with new people, and you have your answer to the one question.

GUERRILLA TEST SCRIPT (about 10 minutes each)

Intro:
'Thanks for helping. I'm testing my app design,
not you. There are no wrong answers. Please say
what you're thinking as you go.'

Task 1: 'You had dinner with 2 friends and paid
         1500. Add this expense.'
Task 2: 'Oops, the bill was actually 1800.
         Fix it.'
Task 3: 'Find out how much Riya owes you.'

If they ask for help:
'What would you try if I wasn't here?'

End:
'What was the hardest part?'

RAINBOW SPREADSHEET (one colour per tester)

Observation                 | P1 | P2 | P3 | P4 | P5
----------------------------|----|----|----|----|----
Task 1 done without help    | x  | x  | x  | x  | x
Tapped amount to edit       | x  |    | x  | x  |
Deleted card instead of edit|    |    | x  | x  |
Found Edit in 3-dot menu    |    | x  |    |    | x
Unsure who owes whom        | x  |    |    | x  |

Rows with the most marks = top issues.
Fix the top row first, then re-test
with 5 NEW people.

A rainbow spreadsheet, popularised in UX practice for synthesising usability tests, makes patterns visible at a glance. In an interview, showing a photo of this grid is a powerful piece of evidence that your testing was real.

When you tell this story, be honest about the scale: 'an informal test with five classmates'. Interviewers respect honest small tests far more than inflated claims.

SECTION 04Prepare your answer to the one question

Use these three sheets to build, check and rehearse your answer. If your first sheet is empty, run a guerrilla test before filling the others.

PROVEN-WRONG STORY BUILDER

Project: ______________________________
My assumption: ________________________
Task I gave users: _____________________
What they DID (behaviour): ______________
How many of how many: _________________
Why I think it happened: _______________
What I changed (specific): _____________
How I re-checked: _____________________
Result of re-check: ____________________
What I'd still improve: ________________

PROBE REHEARSAL (friend asks, you answer)

1. What exactly did you ask them to do?
2. What did they do, not say?
3. How many people, and who were they?
4. Why do you think that happened?
5. What else did you consider changing?
6. How did you know the fix worked?
7. What would you test next?

Each answer: 1-2 sentences, specific.
Any answer that turns vague = a gap
to fix with another small test.

HONESTY CHECK BEFORE THE INTERVIEW

[ ] Test size stated truthfully
[ ] Testers described honestly (friends, classmates)
[ ] No numbers I did not actually count
[ ] Behaviour quoted, not just opinions
[ ] Re-test result is real, or I say
    'I haven't re-tested yet'
[ ] I can show notes, photos or the grid

All ticked? Your answer will survive
any follow-up question.

SECTION 05Habits of designers who always have an answer

Designers who answer this question easily are not more talented. They simply test often and keep records. These habits make that automatic.

• Test before you polish — Run a quick test on wireframes or a rough prototype, when being wrong is cheap and fast to fix.
• Write tasks, not questions — Give testers realistic goals to complete instead of asking whether they like the design.
• Watch, don't help — Stay quiet while testers struggle. The struggle is the data you came for.
• Keep your evidence — Save notes, screen recordings with permission, and your rainbow spreadsheet so you can show them later.
• Always re-test the fix — Test the changed design with new people, because a fix can create a new problem.

SECTION 06Interview Q&A — The one UX question

SECTION 07Test yourself — The one UX question quiz

SECTION 08Frequently asked questions

SECTION 09Related reads