Begin one level above the AI task
Consider an assistant that drafts replies for a customer support team. A natural starting point is to ask whether the drafts are accurate, relevant, and well written. Those questions matter. The broader job is to resolve a customer request with an appropriate outcome and a reasonable amount of effort.
The draft sits inside that job. Someone may need to find an order, interpret an exception, check a policy, correct the response, approve a refund, and update another system. Improving the draft changes only part of the work. The product succeeds when the resulting workflow helps people complete the job.
Establish a useful baseline
Before building, examine a small set of real cases. Follow each one from its trigger to its accepted outcome. Record where time goes, which judgments require expertise, how mistakes are discovered, and what happens after a correction. Include routine cases and situations that make the work difficult.
This baseline gives an experiment something concrete to improve. For the support assistant, it might include time to resolution, reviewer effort, avoidable corrections, and whether the customer needs to contact the team again. The relevant measures depend on the workflow and the decision being made.
Separate the claims you need to test
A product can produce valid text, apply policy correctly, help an agent finish a case, and reduce overall effort. Each is a different claim. A test of policy accuracy can support the second claim. It cannot establish the others without observing the conditions that make them true.
Build an evaluation around the next decision. If the question is whether to change retrieval, compare the relevant behavior under controlled conditions. If the question is whether the assistant helps the team, observe people using it to complete representative cases. Record the limits of each finding alongside its result.
Look for the work that moved
An AI intervention can move effort between steps. Faster drafting may increase the volume waiting for review. A helpful summary may still require opening every source. Automation may remove repetitive entry while creating a queue of ambiguous exceptions.
Follow these changes through the workflow. Include review, corrections, coordination, model and infrastructure costs, and recovery from mistakes. A useful improvement should survive this fuller account. When a new constraint appears, it becomes the next design question rather than an inconvenient detail to exclude from the measurement.
Keep the evidence close to the decision
Preserve the cases, system version, criteria, and observations behind a comparison. A single average can conceal an important difference between routine work and exceptions. Review those groups separately when that distinction affects what users can rely on.
The next step may be a wider release, a narrower promise, another experiment, or a different solution. The purpose of evaluation is to make that choice better. Start with one job, one meaningful decision, and enough evidence to see whether the work actually improved.