The Fake Persona Test: I Roleplay as a 69-Year-Old Librarian to Find UX Bugs My Team Misses

I caught a critical signup bug three days before launch by pretending to be a 69-year-old librarian with trust issues.

The bug? If you backspaced in the password field and then tried to paste, the form silently failed validation but didn't tell you why. It just... sat there. Blinking cursor. No error message. No progress.

My team tested it dozens of times. We all used autofill. We all had strong Wi-Fi. We all trusted the interface because we built it.

Edith – my fake persona who double-taps everything and doesn't trust autofill – found it in 4 minutes.

That's what the Fake Persona Test is for. It's a UX testing method designed to break your assumptions by pretending to be users who will definitely break your product.

Your product's worst failures won't show up in analytics. They'll show up in:

• A support ticket from someone who rage-clicked a modal five times

• A one-star review that says "doesn't work" with no details

• The friend who tried your product once and never mentioned it again

• Metrics that show 40% of signups abandon at the same step

Traditional user persona testing creates demographic profiles: "Sarah, 32, Product Manager, uses Slack, values efficiency."

Fake personas are different. They're based on chaos energy, cursed device setups, and the kind of behavior that makes designers cry.

Real personas I've seen:

• "Tech-savvy millennial who values intuitive design"

• "Busy professional who needs mobile-first solutions"

• "Data-driven decision maker who appreciates clean interfaces"

Cool. Everyone is tech-savvy and busy. These personas don't help you find bugs.

Fake personas I actually use:

• Edith (69, double-taps everything, thinks Wi-Fi is aggressive)

• Dennis (47, keyboard shortcuts only, hates modals on principle)

• Joel (34, one hand, crying toddler, 3G connection)

• Reese (21, taps before reading, assumes everything swipes)

These personas find real problems in 10 minutes that real users will hit in production.

It's not real research. It's not a replacement for proper UX testing methods. It's not scientifically valid.

It's a fast, internal tool for breaking out of your team's shared blind spot.

What it is:

• 10-minute roleplay session where you pretend to be your worst user

• Internal chaos test before shipping

• Fast way to spot edge cases you're too close to see

• Free (costs zero dollars, maximum embarrassment)

What it's not:

• Real user research

• Accessibility audit (though it sometimes catches accessibility bugs)

• Replacement for usability testing

• An excuse to skip talking to actual users

Think of it as a 15-minute UX audit where you deliberately make terrible decisions.

👵 Edith, 69, Retired Librarian

Setup:

• iPad Mini (2016) with 2% battery

• Double-taps everything because single-tap "doesn't always work"

• Doesn't trust autofill, Google, QR codes, or cloud storage

• Types passwords letter by letter from a handwritten list

• Thinks Wi-Fi is "a bit aggressive"

What Edith finds: Touch targets too small. Buttons that don't respond to double-tap. Forms that break when you paste. Empty states with no guidance.

Real bug Edith caught: A "Continue" button that only worked if you tapped the exact center. Anywhere else? Nothing. No visual feedback. Just silence. Three days before launch.

🧔 Dennis, 47, Linux Loyalist

Setup:

• Navigates exclusively with keyboard shortcuts

• Refuses cloud storage (local-first or nothing)

• Runs Firefox in safe mode, no extensions

• Hates animations, modals, and "unnecessary" JavaScript

• Reports UI bugs to GitHub even when there's no GitHub

What Dennis finds: Features hidden behind hover states. Keyboard navigation dead ends. Modals you can't escape without a mouse.

Real bug Dennis caught: Entire settings page unusable without mouse. Tab order went: Logo → Search → Footer. Skipped every actual setting. We had no idea because we all used mice.

🧢 Joel, 34, Multitasking Dad

Setup:

• Tapping with one hand, holding toddler with other

• On 3G in a parking lot (or inside Target with terrible signal)

• Phone screen cracked in three places

• Ignores all popups and modals (learned behavior)

• Has 3 minutes maximum before child meltdown

What Joel finds: Slow-loading states with no feedback. Forms that don't save progress. Back buttons that lose data. Mobile interfaces that require two hands.

Real bug Joel caught: Form submission took 8 seconds on slow connection. No loading state. No feedback. Joel would tap "Submit" three times, get frustrated, leave. We tested on office Wi-Fi. Never saw it.

🤳 Reese, 21, Hyper-Tapper

Setup:

• Phone with 67 apps, 4 unread texts, 0 organizational system

• Taps everything before reading anything

• Assumes all interfaces swipe (even when they don't)

• Quits mid-flow if something "feels off"

• Notifications permanently on Do Not Disturb

What Reese finds: Interfaces that punish exploration. Buttons that do unexpected things. Onboarding flows that require reading instructions. Anything that takes more than 30 seconds to "get."

Real bug Reese caught: Tapping a project card opened edit mode instead of view mode. No undo. No confirmation. Just instant edit state. Reese would accidentally rename projects, get confused, quit. We never tap-tested. We always clicked carefully.

If your team is using research as a delay mechanism rather than a compass, this post on the UX Iceberg problem explains why.

Over two years of running these tests before launches, here's what I've found:

As Edith:

• 7 password field bugs (paste breaking, double-tap issues)

• 4 touch target problems (buttons too small or overlapping)

• 3 form validation failures (errors not displaying)

• One politeness problem (modal asking "Are you sure?" three times)

As Dennis:

• 5 keyboard navigation dead ends

• 3 modal traps (can't escape without mouse)

• 2 features completely hidden to keyboard users

• 1 settings page where Tab key did nothing

As Joel:

• 8 slow-loading states with no feedback

• 4 forms that didn't save on connection failure

• 2 back buttons that lost all data

• 1 checkout flow that required both hands to complete

As Reese:

• 6 accidental actions (tapping wrong thing, no undo)

• 4 swipe gestures that didn't work but should have

• 3 interfaces where exploring broke things

• 2 hidden features that required reading docs

Total: 42 bugs caught before users found them.

Average time to find each bug: 12 minutes.

Step 1: Pick a live flow

Onboarding, checkout, settings, pricing page, whatever you're about to ship.

Step 2: Choose a persona

Pick the one that scares you most. Usually Edith or Joel.

Step 3: Get into character

Actually change your browser settings. Use an old device if you have one. Turn on slow 3G simulation. Make it real.

Step 4: Narrate out loud as that person

"Edith is confused why this button isn't responding." "Dennis is looking for the keyboard shortcut to close this modal." "Joel's toddler just grabbed the phone. Joel is trying to tap Submit with his thumb."

Step 5: Note where it breaks

Confusion, frustration, dead ends, unexpected behavior, anything that makes you think "wait, what?"

Step 6: Fix one thing

Don't try to fix everything. Pick the worst bug. Ship a fix. Run the test again next week.

Want to add AI to the research workflow? Here is the AI research process I actually use.

The Fake Persona Test will not give you:

• Statistically significant data

• Deep user insights

• Strategic product direction

• Research you can present to stakeholders

It will give you:

• Quick bug catches before launch

• Empathy for edge case users

• Obvious fixes you were too close to see

• Better questions for real user research

What to do with findings:

Severity 1 (Ship-blockers): Forms that silently fail, keyboard traps, data loss – fix before launch.

Severity 2 (Annoying but not fatal): Confusing labels, slow loading, unclear feedback – add to backlog, fix in next sprint.

Severity 3 (Polish): Touch targets slightly small, animations slow on old devices – nice to fix but not urgent.

This isn't a replacement for proper product design process. It's a fast sanity check.

While you're waiting for research budget – or before the next sprint review – the Fake Persona Test breaks your team's shared blind spot.

If your SaaS product only works for people like you, it doesn't work.

The next Edith, Dennis, Reese, or Joel who touches your interface isn't imaginary. They're real. They're tired. They're busy. They're about to hit the wrong button.

If they still make it through? Then maybe you're doing something right.

If this kind of testing sounds useful, here is how I approach UX design — and how that extends to full product design.