You open the prototype and see that something does not work the way you pictured. The usual reaction is to ask the AI to "make the screen better". To give useful feedback on an AI-built app, you need to locate the problem and describe its effect on use.
Feedback can combine text, voice, images and examples. Each format makes a different part of the experience visible. The easier it is to recognize the expected behavior, the clearer the evaluation of the next version.
Show the situation where the problem appears
In a project dashboard, a manager changes a delivery date, but the summary keeps the old deadline. The fix can be described precisely: the change must show up in the detail view and in the summary.
An annotated screenshot points to the elements. A short description explains the sequence of actions. If the problem is a rule, include a concrete case and the expected result. Avoid mixing many changes: separate the bug that blocks use, the visual preference and the new feature.
Review in five moves
- Explain the intention behind the screen, using voice if that is easier.
- Pick the main function that needs to improve.
- Test the change in an environment separate from the version the team uses.
- Show exactly where the experience departs from what you expected, with notes or examples.
- Check the full path after the fix, because solving one point can affect another.
These moves are a review practice that does not depend on any product. A simple form can record the situation, the behavior observed and the expected result.
For leaders, learning to give this kind of feedback brings business intent closer to implementation. You do not need to describe the code to explain what the user needs to be able to do. In AI Thinking by Dani Hayoshi, this clarity separates a cosmetic improvement from a change that solves the problem. See also What a first AI-built tool needs to prove.
Dani Hayoshi is the author of AI Thinking. Her work connects artificial intelligence, education and entrepreneurship. About Dani.