The AI Learning Hub Journal

Test With Someone Who Is Not You

You cannot test your own thing — you know too muchyour testing confirms your intentions; only another person walks the paths you route aroundTHE PATHS YOU CANNOT SEEYOUFINISHA STRANGERyour route bends around the broken parts —automatically, and invisibly to youHOW TO WATCH PROPERLY1 · give a task, not a tour — "book yourself a slot for Tuesday"2 · then say nothing at all3 · note every pause and hover — each one marks a design problem4 · do not rescue them — rescuing destroys the data you came for5 · afterwards ask: "what did you expect to happen there?"the silence is where all the findings areMAKE HONESTY EASY — FRAME IT AS A FAULT HUNT"tell me every annoying thing — I need to find what is broken" — and pick someone like your real user"IT WAS FINE" — SAID AFTER TWENTY SECONDS HUNTING FOR THE BUTTONpeople are polite; their hands are not — when words and hands disagree, believe the handsHAND IT OVER, GIVE A TASK, AND BE QUIETten silent minutes watching someone else teaches more than a day of your own clicking
You dodge your own broken paths without noticing — hand it to someone else, give them a task, and stay silent while they try.

You Cannot Test Your Own Thing

You know where to click. You know the form wants the date in a particular way. You know which button is the real one, and you unconsciously avoid the three things that do not work. None of this is available to anyone else, and none of it is visible to you. The knowledge is invisible from the inside. That is exactly why your own testing is close to worthless, except for confirming that the parts you built do what you meant. The only cure is to watch someone else use it. Not describe it to them. Not demo it. Hand it over and be quiet.

  • You avoid your own broken paths without noticing you are doing it
  • Your testing confirms your intentions, not the experience
  • Only another person can walk the paths you unconsciously route around
  • Hand it over rather than demonstrating it

How to Watch Properly

Give them a task, not a tour. "Book yourself a slot for next Tuesday" — and then say nothing at all. The silence is the hard part, and it is where all the information is. Every moment they hesitate, hover, or ask "do I press this?" is a design problem you cannot see. Do not explain. Do not rescue them. Do not say "you just need to click the little one at the top". Write down where they paused. Ten minutes of this will teach you more than a day of your own clicking. Afterwards, ask what they expected to happen at the moment they hesitated. That is usually more useful than asking what they thought of it.

  • Give a task, then stay silent — the silence is where the findings are
  • Every hesitation marks something unclear; note it rather than explaining it
  • Do not rescue them; rescuing destroys the only data you came for
  • Afterwards ask what they expected at each pause, not what they thought overall

Pick Someone Who Will Be Honest

Your friends will be kind, and kindness is the enemy here. Try to find someone who resembles the actual user. Then set the framing to make criticism easy: "I need to find what is broken, so tell me every annoying thing." If you only have friends available, ask for specifics rather than opinions. "Where did you hesitate?" gets more truth than "what do you think?". Watch what they do rather than trusting what they say. People are polite, and their hands are not. Someone who says it was fine, while spending twenty seconds hunting for a button, has told you two different things. The hands are the one to believe.

  • Frame it as hunting for faults so criticism is the helpful response
  • Ask "where did you hesitate?" rather than "what did you think?"
  • Watch behaviour rather than trusting reported opinions
  • When words and hands disagree, believe the hands

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.