The secret final stage of delivering great products

In a fast-moving world of development, User Acceptance Testing (UAT) is your last best chance to talk about whether what’s being developed meets users’ needs.

Jack Moore
Product Coalition
Published in
5 min readJul 19, 2019

--

Photo by John Schnobrich on Unsplash

The average developer on my team works on between 3 and 6 tickets per 2-week sprint. Whether right or not, this inevitably leads to rushing. Great engineers are ambitious, and our teams are constantly working on getting something exciting out the door to a customer or user who really needs it.

As anybody working with a talented engineering team can tell you, crystal-clear acceptance criteria, great designs, and comprehensive suites of Quality Assurance (QA) tests, don’t always result in product that will satisfy customers. Maybe looking at the end result makes obvious some need for functionality that wasn’t obvious before, or perhaps development has introduced some bug that hasn’t been caught by QA.

The goal of building great products is to change someone’s world. We’re solving problems which are experienced by real people, servicing a user in pain, and so we must hold that person at the center of what we do. Though all of our steps should be steeped in user empathy, it is generally difficult to include a user point-of-view in every step of the process (though there are ways).

How, then, do we ensure that the things that we put out are likely to make users happy?

User Acceptance Testing

UAT, as it’s usually abbreviated, is the final stage-gate between the development and deployment of code. It’s an opportunity for the user’s voice to be heard without the risk of a stink being raised towards a production system.

Some systems, Extreme Programming for example, talk about building up a suite of Acceptance Tests from your customers — outputs that they expect to see from your product. Other systems attempt to actually put a user behind the wheel of a pre-deployment version of your product. If you can afford either of these options with the time afforded your team, by all means go for it, but that’s not the Productful Conversation that we’re talking about today.

--

--

A product person looking to figure out all the ways software can improve peoples’ lives