Key takeaways
- The brief must name the behaviour — fluid rules, designed states, or both — before pixels start.
- Adaptive is a set of designed layouts; responsive is a set of rules that reflow content.
- Content priority by viewport is a decision, not something CSS guesses.
The client asked for a responsive site. The designer delivered three fixed comps and called the middle one "tablet."
That mismatch ships every week. Responsive design is a rule set — grids, type scales, images — that reflow as the viewport changes. Adaptive design is a set of designed states — often fixed widths — chosen for specific contexts. Both are valid. They are not the same purchase. If the brief uses the wrong word, you will argue in QA about whether a cropped hero was a bug or a plan.
Creating a mobile-friendly website is the outcome both approaches serve. The distinction changes how you specify content priority, how many layouts you pay for, and how the build behaves between breakpoints.
Name the behaviour in the brief
Before style tiles, write one line:
This site will ___ as the viewport narrows.
- Reflow (responsive): Columns stack, type scales, images swap by rule — not by a new comp for every width.
- Switch (adaptive): Distinct layouts at named breakpoints — navigation, hero, and modules may reorder by design, not only by flow.
- Hybrid: Fluid body with adaptive shells — common for marketing sites with a complex header and simpler content.
If the line stays blank, the developer will guess. Guessing is how desktop comps become mobile crops.
Compare constraints, not buzzwords
| Question | Responsive bias | Adaptive bias |
|---|---|---|
| How many layouts you buy | Fewer comps; more rules | More comps; explicit states |
| Content priority | Order in the document often drives mobile | Each breakpoint can reorder by design |
| Between breakpoints | Layout breathes continuously | Layout may hold until the next threshold |
| Maintenance | Change a rule once | Change each designed state |
| Performance | One HTML path; CSS does the work | Watch duplicate assets and conditional loading |
| Best when | Long pages, editorial, many templates | Tools, dashboards, dense nav patterns |
Neither row wins forever. A five-page marketing site is usually responsive with a designed header. An enterprise app with a data table and a collapsed rail is often adaptive at the shell.
How to build for the web in 2026 already treats the stack as secondary to ownership and exit. Layout behaviour belongs in the same conversation: who decides what moves when the phone rotates?
Content priority is a product decision
CSS cannot invent priority. Product has to rank what survives on a narrow screen.
Run a content priority workshop before comps:
1. List modules on the homepage or template — hero, proof, services, form, footer promos. 2. Mark must, should, hide on small, replace with link for each module. 3. Name the one action that must stay above the fold on mobile. 4. Decide whether secondary modules collapse into accordions, tabs, or leave the page.
Adaptive teams draw this as three distinct comps. Responsive teams encode it as order, display rules, and component variants. Skip the workshop and you get a hamburger menu hiding the business — the failure mobile navigation patterns warns about when everything goes behind one icon.
Device and context still matter
"Mobile first" is not "phone only." Breakpoints should follow content stress, not device catalogues.
Test these contexts in the brief:
- Narrow phone, large phone, small tablet, laptop, ultra-wide
- Keyboard-open forms on mobile
- Zoom to 200% — reflow must not trap the primary action
- Landscape video embeds and tables that need scroll or redesign
- Print stylesheets if buyers still PDF your spec pages
MDN's Responsive design documentation describes fluid grids and media queries as tools — not as a mandate to avoid designed states. Use the doc to align vocabulary with engineering.
When stakeholders say "make the tablet comp look like desktop, just smaller," you are being asked for adaptive cropping — not responsive priority. Name that in writing so QA knows which behaviour is intentional.
Run the constraint matrix before sign-off
Near the close, score the project honestly.
| Signal | Responsive fit | Adaptive fit |
|---|---|---|
| Marketing site, mostly editorial | Strong | Optional header only |
| Configurator or app-like UI | Partial | Strong |
| Frequent content edits by non-designers | Strong — rules survive | Risky — many states to update |
| Strict brand layouts at exact widths | Moderate | Strong |
| Team can maintain design tokens | Strong | Strong with documentation |
If two adaptive states differ only by cropping a hero, you are paying for comps that responsive rules would handle. If responsive reflow hides the primary action at every width, you needed an adaptive shell decision — not another media query.
Hybrid projects should document which regions are rule-driven and which are designed states in the same component library. Developers should not infer adaptive behaviour from a single desktop comp and a Figma comment that says "stack on mobile."
What you can specify alone — and what needs a build team
You can run the priority workshop, name hybrid behaviour, and refuse a brief that says only "make it responsive." You can test zoom and keyboard paths before launch.
What stays unfinished is the system: tokens, components, QA across breakpoints, and a full website someone will stand behind. Web design and web development share one brief when layout behaviour is part of the offer — not a surprise in handoff.
CLICK.BLUE has shipped responsive and adaptive sites since 2014 — more than a hundred websites, more than fifty businesses. If the next argument is about what moves on a phone, get started with the behaviour named before the first comp.
