A demonstration often takes place under favourable conditions. The person presenting it knows the journey. Their account has the right access. The data is ready. If something is missing, they know how to continue.
A user arrives under different conditions: on a phone, with a new account, incomplete information or an expectation the scenario did not anticipate. Moving into everyday use means testing the product against these situations.
AI makes it easier to build a prototype. It can also help prepare and carry out checks. What needs checking still depends on the product and the consequences of an error.
Start before the screen you want to show
When checking a feature, it can be tempting to open the relevant page directly. That leaves out what the user needs to accomplish first: find the entry point, create an account, receive a message or resume a session.
A complete journey starts where the person’s experience begins. It ends when the expected outcome has actually been achieved, including when an external service is involved.
We also need to look at what happens if the journey is interrupted. Does the person understand whether the action succeeded? Can they try again without creating a duplicate? Is the information they already entered preserved? These questions are often more useful than another demonstration of the ideal journey.
Use the future user’s permissions
An administrator account makes testing easier. It can also hide defects because it bypasses restrictions that apply to other people.
We therefore prepare accounts that represent the product’s roles. For each important action, we examine who should be able to perform it and who should be prevented from doing so. This concerns screen visibility, but also actual access to the data and operations behind that screen.
The same reasoning applies to devices. Checking a desktop browser is not enough to establish that a mobile journey works correctly. Simulations are useful for covering configurations quickly; important uses also deserve checking under the expected real conditions.
In our work building with AI, these gaps have led us to make the scenarios we give agents more precise. “Check the screen” leaves too much open. Describing the role, starting point and expected outcome makes the check more useful.
Prepare for what happens when the product fails
Going into production requires the ability to detect a problem and act. Which events need to be observed? Who receives an alert? How can an isolated failure be distinguished from an incident affecting several users?
Monitoring needs to remain proportionate and limit the data collected. A useful error log does not need to expose the entire contents of a user’s document. We need to know what is retained, who can access it and why.
Recovery mechanisms also need preparation. Depending on the product, these may include reverting to a previous version, disabling a feature or restoring data. These mechanisms need checking: having a backup and knowing how to restore the service are two different things.
These considerations inform how we build. Discovering them only after the first incident reduces the options available.
If the product itself uses AI
Software built with agents does not necessarily contain a generative feature. When the product itself uses a model to respond or act, another layer of verification is needed.
Software tests check its rules and integrations. Evaluations of the AI feature examine the quality of its results in representative situations, including errors, ambiguous requests and actions it needs to refuse or submit for approval.
A change of model, instruction or document source can alter behaviour. We need to be able to rerun these cases, observe regressions and monitor results in production. Anthropic describes several forms of agent evaluation, combining automated checks and human assessment according to the task.
The final state deserves particular attention when an agent takes action. Saying that an appointment has been created is not the same as confirming that it exists, at the right time and for the right person. Costs, response times and recovery after failure are also part of service quality.
Choose a manageable first rollout
Checking everything to the same depth before every release would be unrealistic. We can limit the initial scope, restrict the users involved or retain human approval for certain actions.
The choice depends on the consequences of a defect and whether it can be reversed. An internal tool that prepares a draft does not carry the same risks as a feature that changes data or performs an external operation.
Once the product is in use, the situations encountered help us extend the checks. Feedback, errors and difficulties in use inform subsequent improvements.
This is the continuity between our Build digital products and Improve and maintain products offers: prepare for operations while building, then maintain and improve the product based on what actually happens.