How to tell the difference, and when to bring both into your projects
In the world of User Experience Research, there’s often some confusion surrounding the difference between User Studies (and user research in general) and User Acceptance Testing (UAT).
In the early days of UX Research, it was often assumed UAT was enough. Once the product was up and running in a QA web development environment, the product owner would ask real users to try it out. This process was usually a last step before release, to make sure there were no show-stopping issues or bugs.
The downside to this approach is obvious: getting input from your users at the last possible step is a sure-fire way to build something few people will want (or even understand how) to use. And all too often, development teams who had not done any prior user testing would have to delay or cancel releases, while they fixed those show-stoppers or re-coded entire sections of the project.
The Power of User Research
Fortunately, things have gotten better. Product teams began to realize it was far better to get input from real users much earlier in the process, to help guide design and development.
Modern User Research methodologies, like unmoderated user testing, were born out of the need to get early, critical feedback. Researchers use these simple studies to lay important groundwork for understanding several crucial pieces of information:
- how users interact with systems
- what they expect out of new products
- to develop a baseline of behavior and assumptions
- determine success metrics
- test new concepts and hypotheses
- find any weaknesses in early concepts and designs
If user studies are done too late, like the UAT phase, significant time and energy has already been spent developing a solution before a problem is truly understood and a solution properly vetted. It’s only through early user research that product teams can identify problems, test solutions and iterate.
Test Early, Test Often
As companies move away from waterfall as their development process and embrace more Agile methods, frequent user testing and analysis becomes even more crucial.
Often in Agile development, User Studies are now woven into a project’s 1- or 2-week Sprint cycle, with real users getting to experience prototypes or concepts of user interfaces while the development and design teams work on other areas of site or application (Agile UX).
This allows for constant iteration of a design, and if real users operating in a natural environment are able to find problems with a confusing layout or poor navigation, for example, teams can add those issues to the project’s backlog (work to be done) and incorporate them into future development cycles.
Teams make changes, then test those assumptions again. When the project is close to release, teams will then perform UAT on a near-final product to make sure it meets all the stated objectives, is compatible with other systems, and that major flaws have been resolved.
User Studies and UAT work hand-in-hand toward ensuring teams create good sites and software that deliver real value, but neither can replace the other.
