“The button is wrong” is hard to act on. “After submitting, the notice on a narrow display appears on the right, outside the form” already supplies an action, a state and a visible deviation. A screenshot becomes valuable when it complements this kind of description.
ChatGPT supports images as context, including screenshots and diagrams. The documentation recommends naming the relevant area, the desired result and the limits of the question. Our own example consists of two artificial views of a form. No actual image analysis or fix was carried out for it.
The images must show comparable states
Image A shows an empty registration form, image B the state after entering data and submitting. The window width stays the same. A deliberately built-in problem concerns the notice below the button. This makes it clear which change lies between the two images.
Describe the order explicitly. Two similar-looking attachments without an explanation make it tempting to treat differences as arbitrary design preferences. Remove personal details if they are not needed for the technical question. Invented field contents are enough to start with.
Separate the visible observation from the technical hypothesis
The image may show that a line is cut off. Whether a fixed width, a line break, a different font or a parent element is responsible does not yet follow from that. A useful answer should keep these levels apart.
Compare the two form views I created myself.
A: before input. B: after submitting, same window width.
Look at the notice below the button.
1. Describe only visible differences.
2. State the expected behaviour from my description.
3. Mark technical causes explicitly as guesses.
4. Suggest a small next checking step.This brief of our own does not yet ask for a complete code fix. A specific follow-up question about the associated HTML or the relevant CSS rule can be more helpful than a confident change to a suspected cause.
A bug report is a small contract about a state
Keep the initial state, the action, the expectation and the actual observation together. Add the window width and, where relevant, the input content. This allows a second person to try to recreate exactly the same state. That is a stronger basis than a single sentence about a “broken” screen.
Starting point: empty sample form at a fixed narrow width.
Action: enter example data, then submit.
Expected: notice remains fully readable below the button.
Observed: notice extends sideways beyond the form area.
Open: which specific rule causes the overflow?This is an illustrative finding for the planned pattern, not a record of an application that was observed. It is precisely this labelling that prevents a plausible bug description from later being passed on as a product bug that was actually reproduced.
Change only one condition at a time
A next step could recreate the identical state using the keyboard or look at the associated rule. If you change browser, width, data and content at the same time, it remains unclear which difference had an effect. So when comparing, keep the conditions recognisably the same as far as possible.
Then return the new observation as further evidence. “At the same width, the line is fully visible after this change” is more concrete than “works now”. A real fix also includes checking other sensible states, such as a longer notice text.
A partial view stays a partial view
A screenshot does not automatically show the document structure, a server response or the complete keyboard path. Nor does it prove accessibility as a whole. For these questions you need suitable additional observations of the actual work.
The strength of a visual handover lies in its precision: people and AI talk about the same spot, the same state and the same expectation. A useful next step follows from the question that is still open. A change of product or a blanket repair button is not a prerequisite for this.
Sources and documentation status: 25 October 2026.
