Yes, preparing early for UAT pays off handsomely; but it has to be the right preparation, and the suggestions here can easily inadvertently undermine UAT effectiveness.

Project managers, analysts, developers, and even professional testers are highly unlikely to understand how to do effective UAT, so relying on their guidance almost always leads UAT astray.

Most organizations treat UAT as another test that the system was implemented as designed. In fact, UAT should be testing that what the development process thought they should create in fact is what the business/users/stakeholders need. That takes a considerably different perspective and different test planning/design techniques from those that people are accustomed to.

Merely asking the business/users to design acceptance tests without suitable guidance on how to do it well invariably misses the mark, tying up time and resources, and giving only the illusion of having tested thoroughly. When users say they do not have time to participate in designing and executing UAT, it is an unconscious indicator that the UAT is not focusing on the right stuff.

Moreover, relying on UAT as the main, or even sole, testing assures finding too few of the defects and finding them too late when they are too hard to fix. Effective UAT represents double-checking systems which already have been double-checked during development by both developers and independent professional testers.

Proactive User Acceptance Testing? combines requirements-based tests with tests based on special techniques for guiding users in identifying five types of Proactive User Acceptance Criteria. As a by-product, these also reveal wrong and overlooked requirements that traditional requirements-based tests do not detect.

These methods need to be applied before the product/system is designed and then coupled with the design to produce executable acceptance tests for execution after the product/system has been created.