Ask a developer if a feature works, and they'll tell you, honestly, yes. Ask whoever defined what the feature should do if it matches what was asked for, and they'll tell you, just as honestly, yes. Ask an actual user if the feature makes sense, though, and you might get a completely different answer. That third question is the one I spend most of my time on, because of where I sit in the process.

Say we're looking at a fairly ordinary feature: a form where a user updates their account details. The developer builds it, and everything checks out. Fields save correctly, validation works, the database updates as expected. Whoever defined the requirement reviews it against the documentation: does the form let someone update their name, email, and password? Yes. Sorted, approved, moving on.

Sitting in the user's seat

Then I open it. Not just to check that the code does what it's meant to, but to actually sit in the seat of someone encountering this thing for the first time, the way a real user eventually will. And that's when a few things start to stand out that nobody else noticed, not because anyone was sloppy, but because from where they were standing, there was no reason to.

The save button, for instance, works perfectly. Click it, and the update goes through. But nothing on the screen changes. No confirmation, no loading state, nothing. The developer knows it worked because they can see it in the database. I don't have that luxury, so I experience exactly what a user would: staring at a screen that looks like nothing happened, wondering if I need to try again.

Or the password field. Reject an entry, and it says: "Password does not meet policy requirements." Fair enough, technically true, but completely useless if you don't already know what the policy is. How many characters? What type? Which symbols? The developer knows because they wrote the rule. I didn't, and neither did the person using the form.

This is the part I'm there for that almost nobody else is. Not because I'm more careful or skilled than the developer, but because I'm usually the first person touching the feature without already knowing how it works. It's a bit of an odd skill when you think about it: the value is in not understanding the thing already, in experiencing it the way someone with zero context would. Which, I reckon, is what makes me the user's advocate before the users have even turned up. I'm arguing their corner at the one point in the process where nobody else really can.

Broken versus confusing

That's also why it helps to draw a line between two very different kinds of problems: something being properly broken, and something being confusing but perfectly functional. A broken feature makes itself known: an error, a crash, something obviously gone wrong. A confusing one doesn't make a peep. The code runs fine. Every functional test passes. The only way you catch it is by actually experiencing it the way the user will, rather than the way you already know it to work.

Bring me in before the code exists

Timing matters here too, more than people probably realise. If I only see this form the week before launch, all I can really do is flag the confirmation message and the password error as fixes to squeeze in later. Useful, sure, but reactive. If I'm in on the requirements before a single line of code exists, I get to ask the more useful question early: what actually happens on screen after someone hits save? What do they see if their password's rejected? Bring me in from the start, and you get a lot more of that, simply because the questions get asked before they're expensive to answer.

None of this is about catching what someone else missed because they are careless. It's a blind spot that exists no matter how good everyone on the team is, because once you know exactly how something works, it takes real effort to un-know it, to set that understanding aside and experience the thing fresh. That's the bit I do: I know how it all works, arguably better than the user ever will, but I deliberately put myself in their shoes. My value, in that very specific sense, comes from seeing the system through the user's eyes even though I already know what's going on behind it.