Stop Asking Users to "Have a Look": The UAT Lesson I Learned the Hard Way

I still remember the migration project that taught me this lesson. It was a healthcare system overhaul, data, workflows, everything. We spent four months rebuilding the database, testing the ETL pipeline obsessively, and felt genuinely confident about go-live. Then we sent the sandbox to the client with a message that basically said: "It's ready. Let us know if anything looks weird."

Silence. Complete radio silence for two weeks.

When feedback finally came back, it was chaos. Records were missing visit history. Documents weren't linked properly. Nobody had actually tested anything thoroughly because we'd given them nothing specific to test. Looking back, I realized we'd made the classic mistake: we treated UAT like a favor we were asking, not a structured validation gate that needed to be engineered.

That's when I read something that completely reframed how I approach this stage now, and I want to break down why it's changed the way I think about client relationships entirely.

The Psychology of Getting Actual Responses

There's a real difference between "please look around" and "open client record 47382, verify the visit history for 2023 matches the old system, and tell me by Thursday if anything is missing." The first gets ignored. The second gets done.

This isn't magic. It's backed by behavioral psychology research on implementation intentions, basically, when you convert a vague goal into a specific time, place, and action, people actually follow through. I've seen this repeatedly: when I give clients a concrete checklist with named records and specific verification steps, they complete it. When I ask them to "validate the data migration," they disappear.

The implication is huge. Every request I make during UAT now has three elements: a named action, specific records, and a deadline. Not because I'm being bossy, but because clarity drives compliance.

Who Actually Tests Matters More Than You Think

Here's something I got wrong for years: I thought UAT success depended on having the right people in the room, managers, stakeholders, IT leadership. Makes sense, right? More seniority means more authority to sign off.

Wrong. The scheduler who uses the system daily will spot a broken visit type in four seconds that a VP never will. The data entry clerk knows what a malformed record looks like because they've entered thousands of them.

This is why I now ask clients at kickoff to name two or three power users by name, and I explicitly warn them that these people need protected time. Testing squeezed into gaps between actual work doesn't happen. It just doesn't. And if you're not willing to pull these people off their normal responsibilities, you're not actually committed to validating the migration.

Build the Test Pack Yourself

I used to ask clients to define what they wanted tested. "What records are important to you? What checks matter?" Seemed reasonable. It wasn't.

Now I build a deliberate test pack: ten to twenty records chosen specifically to represent different scenarios. A simple record. A complex one with many documents. One from the exception list. One that was de-duplicated. I write the specific check for each one in language they use, not technical jargon.

The critical insight here: de-duplicated records go in intentionally. Those are where a wrong merge decision causes the most damage, and only the client's staff can confirm the decision was correct. Testing the happy path is useless. Testing the edge cases that matter is what UAT actually is.

Define "Pass" Before You Start

This one prevents arguments. I now send an email before UAT starts that restates exactly what "acceptable" means: the records match the field map we signed. Not that the new system works exactly like the old one. Not that new data appeared. Just that the migration met the contract.

Then when I respond to findings, I explicitly bucket them: genuine defect (I fix it), agreed difference (I explain it), out of scope (we discuss). No ambiguity.

My Take on This Approach

Honestly, this whole framework changes how I think about UAT from a testing phase to a communication and risk management exercise. The technical part, whether the data actually migrated correctly, that's already done by the time UAT starts. What UAT really does is ensure the client's staff, who understand their domain better than anyone, can confirm the outcome matches their expectations.

The hardest part is resisting the pressure to move forward on silence. No email back isn't approval. It's the single most common way a migration turns into a dispute months later. I now always close UAT with a summary email: what we tested, what we found, what we fixed, and an explicit ask: "Does this meet your expectations?" I copy the contract signer too, not as a threat, as insurance that there's a paper trail.

Next Move

The next time you're preparing UAT, try this: Instead of a vague testing invite, build a specific test pack with named records and explicit checks. Then tell me what happens. Does clarity actually change the response rate? I'm betting it does.

Source: This post was inspired by "Stage 6: User Acceptance Testing" by Dev.to. Read the original article