User confusion is real

User Acceptance Testing (UAT), User Testing, User Research, Quality Assurance (QA) Testing, oh my! So many terms — it’s no wonder they tend to get confused with one another.

Here’s a quick read to help clarify the differences, use cases and common mistakes with each one.

User Acceptance Testing (UAT)

• This is most often done near the end of a software project. During UAT, a product owner or business stakeholder will review a near finished product and compare it to what was asked for. Usually, what was asked for was documented in some sort of requirements specification much earlier. The name is misleading. User Acceptance Testing is often confused with User Testing — something very different. UAT often doesn’t involve end users. If a project has been done well, users were involved much earlier in the process and the insights from User Tests informed the requirements. A common mistake teams make is holding UAT sessions with business stakeholders that have not been involved in or aware of a project’s components prior to that UAT meeting. A common mistake business stakeholders make is viewing a final UAT meeting as their opportunity to weigh in on an experience. If done well, the team has researched with users early and often, tested and validated ideas early and often and demonstrated to business stakeholders if and how the users’ needs align with the business needs.

User Testing

• This should be done very early on in a project and continuously throughout all phases of a project. During User Testing, the team will test versions of an idea with real users (aka: people who may actually use the product or service). User Testing can and should be done with rough, early versions of a project. That may mean using a paper prototype to test ideas about an experience that might eventually exist in a digital format. As the team learns more through testing, the prototype will become more refined and begin to look more like what the finished experience will look like. A common mistake teams make is waiting to conduct user tests until the experience is too refined. By then the team will have invested time, money and emotional attachment against ideas that users may not have needed in the first place. It can be hard to change directions at this point.

User Research

• This should be done continuously. It’s important to research and learn about your users’ experiences before, during and after you build products and services. Users change over time and its important for teams to continuously validate that a given product or service meets users needs. User Testing is one component of User Research, but there are many others which may include ethnography, user interviews, surveys and more. A common mistake teams make is applying the same research tactics regardless of the learning goal or phase of the project. For more on when and how to apply research methods, check out this post.

Quality Assurance (QA) Testing

• This most often applies to software and should be done continuously throughout the build phase of a project. Similar to UAT, most QA testing is geared towards ensuring that what was built matches what was documented in a project’s requirements. It’s slightly different because it is often done continuously whereas UAT might be a final step at the end of a project before launch. QA often involves the writing of “test cases” that a QA team or an automated system will carry out routinely. These may include functional tests (ie: does this button work on all devices as it was intended to?) or scenario based tests (ie: how does the system respond when more than 1000 questions come in at the same time?).

Whatever project you are working on, be sure to learn about your users’ needs and experiences early and often to ensure you build something useful and needed in the end. Good luck!