DSN-12 · SEC. 06 Design & UI

Stress-Test a Layout With Real Content, Not Just Resize

Break every breakpoint with the ugliest real content you have before calling a layout responsive.

FORMAT: workflow
DIFFICULTY: intermediate
TIME: 15 min
TOOLS: claude-code · cursor
MODELS: any
COPIES: 0 so far

When to use this

A component or page looks fine at the viewport widths you happened to test, but you haven't tried it with a long name, an empty list, a huge number, or a right-to-left string. Use this before merging any new layout, not after a user reports it broken.

The pattern

Pastes as plain text

Stress-test the component or page I changed most recently (or the one I name in my next
message) for responsive and content-edge-case breakage. Do not just
resize the viewport and eyeball it — actively substitute adversarial content into every
dynamic field and re-check at each breakpoint.

BREAKPOINTS: test at minimum 375px (small mobile), 768px (tablet), 1024px (small desktop),
and 1920px (large desktop).

CONTENT CASES — for every dynamic text or data field, temporarily substitute:
1. The longest realistic real value (e.g. a 60-character user name, a long email address)
   and confirm it wraps or truncates instead of overflowing its container or pushing
   siblings out of position.
2. A single-character or empty value, and confirm layout doesn't collapse or look broken
   with nothing there.
3. A number at the extreme (e.g. "1,204,392" instead of "12") if the field shows counts,
   and confirm it doesn't break a fixed-width badge or button.
4. Right-to-left text (e.g. an Arabic or Hebrew string) if the app supports or might someday
   support non-LTR locales, and confirm the layout doesn't visually break even if full RTL
   isn't implemented yet.

At each of the 4 breakpoints, run through all 4 content cases. Report only actual failures:
overflow, overlap, truncated-without-ellipsis, or illegible text. For each failure, name the
exact CSS property causing it (fixed width, missing min-width: 0 on a flex child, no
text-overflow, etc.) and fix it.

Real example output

Component: PatternCard (used in /patterns grid)

375px:
- Long title case: "Turn a Rough Brand Brief Into a Design System the Agent Can Apply
  Consistently" — FAIL: overflows the card, pushes the difficulty badge off the bottom edge.
  Cause: title has no line-clamp, card has fixed height 180px.
  Fix: added line-clamp-2 to title, changed card to min-height instead of fixed height.
- Empty summary: FAIL: card renders with a large blank gap where summary would be.
  Fix: summary now falls back to first line of pattern body, capped at 100 chars.

768px / 1024px / 1920px:
- Long title: PASS after fix (line-clamp-2 holds at all widths).
- Numeric badge (est_time "45 min" vs a hypothetical "180 min"): PASS, badge is
  auto-width with padding, not fixed.
- RTL test string: PASS, card uses logical properties (padding-inline, not padding-left),
  no visual break even though the site isn't RTL yet.

1 component, 2 real failures found and fixed, all others passed at all 4 breakpoints.

Why it works

Resizing a viewport with the same three seed rows of demo data hides almost every real-world layout bug, because production content is rarely as short and uniform as placeholder text. Forcing the longest, shortest, and most extreme values through the same breakpoints surfaces the actual failure modes — overflow, collapse, truncation — before a real user's data does it for you in production.