How to Think Like a User During Testing

The tester knows too much.

They know how the feature is supposed to work. They know which buttons are clickable. They know the data formats the system expects. They navigate the software correctly because they understand it — and in doing so, they miss all the ways real users navigate it incorrectly.

Thinking like a user during testing is a deliberate act of strategic ignorance. You set aside your knowledge of the implementation and ask: what would someone who doesn't know any of this do?

The Knowledge Gap Problem

There's a concept in UX research called the "curse of knowledge" — the difficulty of imagining not knowing something you know. It affects testers constantly.

You know that the email field requires a valid format. A real user might type their email without a domain (

user@

You know the app requires location permission before certain features work. A real user might decline the permission and expect the feature to still partially work, or not understand what to do next.

Every gap between "what a tester knows" and "what a user knows" is a potential source of bugs that pass testing and fail in production.

Techniques for Thinking Like a User

1. Create User Personas

Define 3-4 user types with different skill levels and contexts:

• First-time user: No history, no context, learning as they go
• Infrequent user: Uses the app occasionally, has forgotten how things work
• Power user: Knows the app well, uses advanced features, moves fast
• Frustrated user: Is trying to complete a task that's going wrong

Test through each persona. The first-time user tries things in the wrong order. The infrequent user can't remember their password and can't find the reset link. The frustrated user mashes buttons when something doesn't work.

2. Test With Real Data

Real users have real names: names with apostrophes (O'Brien), names with hyphens (Smith-Jones), names with accents (García), names that are very long. Real addresses have apartment numbers, PO boxes, and ZIP codes that are all digits.

Test with data that represents your actual user base. Sanitized, neat test data hides a category of real-world bugs.

3. Test Out-of-Order Flows

Users don't follow the intended sequence. They:

• Press the back button at unexpected moments
• Skip steps by navigating directly to a URL
• Open the same flow in two tabs simultaneously
• Resubmit forms by pressing back after a successful submission
• Leave the flow for 30 minutes and return

[!WARNING] The happy path test tells you the feature works when used correctly. Users don't always use it correctly. Test the common deviations explicitly — they're where the most user-facing bugs live.

4. Remove Your Expertise

Before testing, write down what you know about the feature that a new user wouldn't know. Then deliberately ignore that knowledge during testing.

You know the search requires at least 3 characters. Test it as if you don't. You know to scroll down to find the submit button. Test it as if you'd never seen the screen.

5. Test Under Real Conditions

Real users test on:

• Small screens with large font sizes
• Slow networks at 8am commute time
• Devices with 15% battery and power saving mode active
• While multitasking (receiving notifications, switching apps)
• In a hurry

Test in these conditions. The bugs that only appear under real-world constraints are the ones that damage user trust.

Reading User Feedback as Testing Input

App store reviews and support tickets are user testing reports. They describe exactly what real users experienced when your test coverage wasn't enough.

"The app freezes when I try to add a second payment method" — that's a test case you missed.

"I can't log in after changing my email on the website" — that's a state synchronization scenario not in your test plan.

Read user feedback regularly and convert it into test cases. It's direct evidence of where your "thinking like a user" failed.

The Mindset Practice

The best user-thinking testers I've worked with have one habit in common: they never say "that's not how it's supposed to be used" when they find a bug.

"Supposed to be" is irrelevant. "Is actually used" is what matters. Every time you think "no user would do that" — that's exactly the thought that lets user-facing bugs through.

Real users do unexpected things. Testing like a user means expecting the unexpected.