User acceptance testing is product work

A feature can behave exactly as specified and still fail to support the work it was meant to improve. The button responds. The record saves. The confirmation appears. Then the person using it asks how they are supposed to correct yesterday's mistake, or why the next person in the process cannot see the information they need.

That is why I see user acceptance testing as part of product work. It is a chance to compare our decisions with an actual task before we make a release commitment. The point is to discover whether the experience is usable in context, and to make a deliberate decision about the gaps that remain.

Start with a person trying to finish something

An acceptance session needs a useful scenario. A list of interface elements is rarely enough. Asking someone to create an invoice is better than asking them to click the invoice button, but it still leaves important context unstated. Is this their first invoice? Does the client already exist? Has the work been tracked in the product? Does the amount need to be corrected before sending?

At Spera, the product connected clients, projects, time tracking, invoicing, and payments. My responsibilities included user interviews, requirements, backlog priorities, release planning, and user acceptance testing. The relationships between those areas made the complete workflow important. A successful action in one part of the product could still create confusion in the next.

For a similar product today, I would write scenarios around outcomes people recognize. A professional should be able to prepare an invoice from completed work, verify it, and understand its status afterward. That is a stronger basis for acceptance than confirming that separate screens are present.

Give the awkward cases room in the plan

The normal path is usually the easiest one to demonstrate. It is also the path the team has seen most often. Acceptance testing becomes more useful when it includes situations that interrupt the neat sequence: missing information, a duplicate record, a canceled action, or a person returning to unfinished work.

Imagine an inquiry management tool where a staff member begins a response and then gets interrupted. On returning, they need to know whether anything was sent. A vague status creates a practical risk of duplicate contact or missed follow-up. The test should examine that uncertainty directly, rather than stopping once a draft can be entered.

The examples should come from discovery and the people who perform the work. I have conducted UAT with staff as part of internal platform work at Hoopes Vision. Their operational knowledge matters because product and engineering teams do not automatically know which exceptions are routine in somebody else's day.

Observe before explaining

When I am close to a design, it is easy to explain it while someone is trying to use it. That can turn an acceptance session into a guided demonstration. The person finishes the task, but the team has learned less about whether the interface makes sense on its own.

I would give the person the scenario, let them attempt it, and note where they hesitate or form an incorrect expectation. If they need help, the help should be recorded. A completed task with several hints tells a different story from a completed task with no intervention.

There is still room for conversation. After the attempt, I want to understand why a person expected something different. Perhaps the label conflicts with the terminology in their organization. Perhaps the design hides information needed for a decision. Their explanation can reveal the underlying product issue more clearly than a simple pass or fail.

Separate a finding from its proposed solution

A participant may say that a screen needs a new button. That request is valuable, but the product finding might be broader: they cannot tell whether a payment was processed, they need a way to recover from an error, or they lack permission to complete a task.

I would record the observed problem, the scenario, and its consequence before settling on an interface change. This gives designers and engineers room to find the best response. It also prevents a collection of reasonable local requests from becoming an inconsistent product.

The Scrum Guide describes the Definition of Done as a shared account of the quality required for an increment. A particular acceptance scenario adds context about a specific behavior. Keeping both visible helps a team avoid treating a convincing demonstration as the whole standard for completed work.

AI features need a different kind of acceptance evidence

For a conventional form, many expected results can be stated precisely. AI-generated text introduces variation. A single pleasing answer is weak evidence that a feature will perform well across the situations people bring to it.

If I were evaluating an AI summary feature, I would prepare examples with different kinds of input. Some would be clear. Others would contain missing information, conflicting notes, or irrelevant text. The review would ask whether the summary preserved the important facts, made unsupported additions, and allowed a person to check the source. These are proposed evaluation cases, not claims about a feature I have already shipped.

I would also test the surrounding experience. Can someone reject the summary without losing the original? Is it obvious when the system could not produce a useful result? Who sees the result next? Acceptance includes those handoffs because users experience the whole workflow, not an isolated model output.

Turn findings into a release decision

Testing creates work only when the findings have a route into a decision. I would give each issue a clear owner and a statement of its effect on the intended use. A cosmetic mismatch, a confusing label, and a task-blocking failure should not disappear into one undifferentiated list.

The team can then decide what must change before release, what can be addressed afterward, and whether an operating limit needs to be explained. Deferring an issue should include a reason. If a workaround requires staff effort, somebody needs to agree that the effort is realistic.

At Pesci Sports, my work connected requirements, prototypes, engineering coordination, and UAT across a fan-facing application and administration platform. That combination reinforced the value of treating acceptance as a bridge between product intent and delivery. The release decision should reflect the people who will rely on both sides of the system.

Reuse what testing teaches

A good acceptance scenario has value beyond one release. It records a task and the behavior that supports it. When the workflow changes, the team has a concrete way to check whether the new design still serves the original need.

I would keep those scenarios readable enough for product, operations, and engineering to use together. They do not all need to become automated tests, and manual acceptance should not pretend to replace specialist technical testing. Each form of verification answers a different question.

What matters to me is the connection between them. We should be able to explain the intended outcome, show the evidence for it, and name the unresolved limits. UAT helps make that explanation credible because it brings the reality of somebody's work into the release conversation.