Vitrine — Responsive Art Direction

The default responsive layout is: take the desktop columns and stack them. It always fits and is rarely right. A hero image that sat beside the headline ends up a screen below it. A two-plan pricing table becomes a long scroll where the second plan is never seen. A dashboard's sidebar takes the whole first screen. Responsive art direction means deciding, for each width, what the page should be there.

Purpose

Produce a deliberate composition at phone, tablet and desktop widths, where every important element has a decided role at each width, and the most important thing is still the most visible.

Use when

Building a new page or section that has images, multiple columns, or a strong first screen.
A phone layout "works" but feels like the desktop page squeezed.
Reviewing a design that was only drawn at desktop width.

Don't use when

You're looking for defects (overflow, tiny text, small targets). Use /responsive-audit first; this skill assumes nothing is broken.
The section is a simple single column of text. Stacking is the right answer there.

Inputs

The desktop design, or the current page, captured at 390, 768, 1280 and 1920 (/screenshot-iteration has the script).
The one thing each section must communicate. If you don't know it, you can't decide what survives on a phone.
The real content: actual image crops, real text lengths, real data. Placeholder text hides the problems.

Process

1. Rank each section's elements

For every section, list its elements and rank them: what must be seen first, what supports it, what's optional. On a phone, the first item gets the first screen.

2. Decide each element's behaviour, per width

For every element, choose one behaviour at each width:

Behaviour	When it's right	Example
Stays	It's essential and fits.	A headline, the primary action.
Moves	Its position served a desktop layout, not the content.	An image beside the text goes below it, or above it if it carries the message.
Re-crops	The subject still matters, the frame doesn't fit.	A wide hero image cropped to the subject, not just scaled down.
Shrinks	It's supporting, and smaller still reads.	A decorative illustration at 70% width.
Recomposes	The arrangement itself must change.	A 3-column feature grid becomes a swipeable row, a table becomes stacked rows, a sidebar becomes a menu.
Disappears	It's decoration, or duplicates something else on the page.	A second illustration, a background flourish, a repeated call to action.

Write this down as a small table per section before touching the CSS.

3. Set type and density per width

Type: the largest headline should still be dramatic on a phone, but measure it: no single word should be cut, and two to three lines is the usual maximum. Use clamp() with a real minimum.
Density: phones need fewer things per screen, not the same things smaller. Cut secondary text, merge small items, and give the remaining ones room.
Spacing: vertical gaps between sections shrink less than you'd think; cramped sections read as one.

4. Check touch and reach

Interactive targets at least 44×44px, with space between neighbours.
Primary actions within thumb reach on the first screen when they matter.
Nothing important only on hover.

5. Check the in-between width

Tablet (around 768) is where most layouts fail: too wide for the phone layout, too narrow for the desktop one. Decide it on purpose. Often the right answer is the phone layout with more room, or a two-column version of something that's three columns on desktop.

6. Capture and judge

Capture all four widths and check one question at each: is the most important thing still the most visible? Then run /responsive-audit for defects.

Acceptance criteria

Every section has a written behaviour (stays, moves, re-crops, shrinks, recomposes, disappears) for its key elements at phone and tablet.
At 390 wide, each section's most important element is visible without scrolling past something less important.
Images are cropped for each width where the subject matters, not only scaled.
No headline word breaks mid-word; touch targets are at least 44px.
The 768 layout was designed, not inherited.

Common failure modes

Stack by default. Every multi-column section becomes a single column in source order, regardless of importance.
Shrink everything. The desktop composition at 40% scale: tiny type, tiny images, the same number of elements.
Hiding content that matters to save space, instead of recomposing it.
Keeping decoration that only worked at desktop width: an illustration that now sits alone between two sections.
Forgetting tablet: the phone layout stretched to 768, or the desktop layout crushed to it.
Testing with placeholder content, so real names, prices and translations break the layout later.

Final self-review

Did I decide each key element's behaviour at phone and tablet, rather than letting it stack?
Is the most important thing visible first at 390?
Did the images get crops, not just smaller sizes?
Does 768 look designed?
Did I run /responsive-audit afterwards for defects?

Copyable instruction

Art-direct this layout for phone and tablet; don't just stack the desktop columns.
1. Capture it at 390, 768, 1280 and 1920 wide.
2. For each section, rank its elements: what must be seen first, what supports it, what's optional.
3. For each key element, decide its behaviour at phone and tablet: stays, moves, re-crops,
   shrinks, recomposes (e.g. grid to row, table to stacked rows) or disappears. Write it down first.
4. Set headline size, density and spacing per width; phones get fewer things, not smaller things.
5. Keep touch targets at least 44px and nothing important hover-only.
6. Design 768 on purpose.
Verify by capturing again: at each width the most important thing must be the most visible.