Name the behaviour before the device

Ask a concrete question: when does the navigation wrap, where does a sidebar move, or how does a long title fit? Then vary the available width while keeping the page content and state stable. Device labels such as “mobile” and “desktop” are too broad to describe those changes.

MDN describes responsive design as a collection of flexible layout techniques, including media queries that apply changes at breakpoints. web.dev recommends choosing breakpoints around the content rather than popular device sizes. For reference work, that suggests watching where the content needs a different arrangement.[1][2]

Separate changes you observe from rules you would choose for your own design. A sidebar that moves below an article is visible. Whether that happens because of a viewport media query, a container query or another implementation detail is a different question.

Keep the capture conditions attached

Record enough context to repeat the observation. If the content changes between captures, you may be comparing different inputs as well as different widths. Use the same title, item count, open menu and signed-in state where practical. Note any condition you cannot hold constant.

• Source: page URL, date and the specific region being studied.
• Viewport: width and height in CSS pixels, plus browser zoom.
• Environment: browser, operating system and whether Device Mode was used.
• Content: text length, visible item count and any open or selected state.
• Change: what moved, wrapped, disappeared or became scrollable.
• Limit: what you could not reproduce or inspect.

Capture either side of a meaningful change

Start wide enough to see the complete arrangement, then narrow the viewport until the behaviour you care about changes. Capture the last arrangement before the change and the first one after it. Keep a third capture only if it answers a different question, such as how the narrow layout handles a long title.

Chrome describes Device Mode as an approximation of a mobile device. It still runs the page on your desktop; it does not reproduce every aspect of mobile hardware. Use it to inspect layout, then use a real device when the question involves device-specific behaviour.[3]

Also note whether you saved the visible viewport or a full-page screenshot. Chrome offers both. A full-page image can document vertical content, but it is not the same view a person sees without scrolling.[3]

Worked example: a sidebar moves below an article

This example is fictional. In a reference study, the sidebar sits beside the article at a viewport width of 840 CSS pixels. At 832 CSS pixels it sits below. The title and sidebar content are unchanged, browser zoom is recorded as 100%, and both observations come from the same desktop browser.

The defensible note is “the arrangement changed between these two observed widths”. It is not “the site has a breakpoint at 836px”. The exact rule is unknown without further inspection. That distinction matters when a developer or AI coding agent turns the note into an implementation.

• Observed: the sidebar follows the article at the narrower recorded width.
• Preserved: heading order and sidebar content appear unchanged in the two captures.
• Unknown: intermediate widths, source CSS and real-device keyboard behaviour.
• Proposed for our design: move secondary material after the article when the main column becomes too narrow for its content.
• Check next: a long heading, increased text size and the narrowest supported layout.

Review content and access, not only the silhouette

W3C's reflow guidance concerns retaining content and functionality at narrow viewing widths without unnecessary two-directional scrolling. It allows exceptions for material that genuinely needs a two-dimensional layout. A wide table is not a blanket excuse for the rest of a page to overflow.[4]

Use that guidance to identify what needs closer checking: clipped controls, missing information or a reading order that no longer makes sense. A screenshot comparison is a starting record, not a complete accessibility assessment. You still need to exercise the implementation.

When passing the reference to an AI coding agent, include the observation, the unknowns and your proposed rule as separate statements. Keep the screenshot as evidence, not a specification of CSS it cannot reveal.[5]