How to Test an AI-Generated Responsive Design

Change the layout when the content needs it

Start with a narrow width, a middle width and a wide width, then drag between them. Look for the point where navigation crowds, a heading becomes awkward or a summary blocks the main task. Those failures tell you where a layout rule needs to change.

Our suggested trial widths are 320, 768 and 1440 CSS pixels. They are practical sample points, not an exhaustive device matrix or universal breakpoint standard. MDN explains the responsive techniques behind flexible layouts and media queries.

References: MDN: responsive web design

Stress the content before approving the composition

Replace short placeholders with a long client name, a localized label and a large number. Add enough rows to make scrolling necessary. Then remove every row and inspect the empty state. A layout that works only with its initial sample content is fragile.

In a narrow invoice list, the client and amount may deserve the first line, with dates moved below. In a comparison table, preserving columns inside a labeled scrolling region may serve readers better than turning every cell into a tall stack.

Test interaction and enlarged text

Use the keyboard to open navigation, submit a form and dismiss a dialog. Increase browser zoom and text size, checking whether sticky controls obscure the current field. Inspect validation messages after submission rather than only the untouched form.

WCAG's reflow guidance is a useful reference for evaluating content that needs to remain readable without unnecessary two-dimensional scrolling. A few viewport checks are only part of an accessibility review.

References: W3C: WCAG 2.2 quick reference

Distinguish a viewport preview from a device test

A phone-shaped frame does not reproduce a phone's browser engine, virtual keyboard, touch behavior or operating system. Licuse's preview uses logical CSS viewports in Chromium; its device frames and safe-area guides are approximations. Test the running output in the browsers and devices your audience uses.

Record the viewport, browser, state and expected behavior with each defect. This gives a designer or coding agent a reproducible correction instead of a vague instruction to fix mobile.

Viewport: 375 × 667 CSS pixels.
State: invalid email after form submission.
Observed: sticky footer covers the error and retry action.
Expected: error remains readable; focused field and retry are reachable.
Recheck: keyboard navigation, enlarged text and a real phone browser.