Two agencies are pitching your new site. One promises a responsive build. The other proposes an adaptive design with tailored layouts for phone, tablet, and desktop. Both decks show three polished mockups, and both sound sensible.
In broad terms, a responsive site is one page that keeps rearranging itself as the window gets wider or narrower. An adaptive site, in its most common industry sense, is a small set of fixed layouts, and visitors get whichever one the site picks for their screen size.
Before you choose between responsive and adaptive, find out what visitors will actually receive and how the team will keep it up to date. The words alone won’t tell you, because “adaptive” doesn’t mean the same thing to everyone. This guide helps you compare the proposals. If the site is already built and you need to review it, the pre-launch checklist is the better starting point.
Ask These Five Questions About Any Proposal
Use this card in the pitch meeting or in your reply to the proposal. Each question turns a label into something the team can show you.
- “What do you mean by responsive or adaptive here?” The answer should describe the design approach, not repeat the label.
- “What happens at widths between the ones in your mockups?” You want to know how the site behaves beyond the presentation views.
- “Which content and tasks change between layouts?” Any differences should be intentional, not accidental omissions.
- “If we update a promotion or a form, what has to change, and who handles it?” Ask whether the update is made once or separately for each layout.
- “What will you show us before we approve it?” Agree on the evidence, such as a working page you can open at several widths.
Compare the answers on coverage and upkeep. Neither label is a benefit on its own.
Why “Adaptive” Needs Defining First
The term has two competing meanings, and Smashing Magazine once described the definitions of responsive and adaptive design as “manyfold.”
Meaning one: a set of fixed layouts. This is the common industry sense. The Interaction Design Foundation describes adaptive design as using multiple fixed layout sizes, where the system detects the browser size and selects the most appropriate layout. A related version picks the layout on the server by detecting the device. Google calls that version dynamic serving.
Meaning two: adapting to what the visitor’s browser can do. Aaron Gustafson, who wrote the book “Adaptive Web Design,” uses the term for interfaces that adapt to the user’s capabilities, in both form and function. In his sense, adaptive is another name for progressive enhancement, and responsive design can be part of it.
This guide uses the first meaning, because it is the common industry sense. If a team uses the word differently, question one on the card will bring that out.
Responsive design can also switch layouts at set widths, called breakpoints, which the breakpoints guide explains. The difference is that a responsive layout keeps adjusting between those switches, while a fixed-layout design holds each adaptive layout steady until the next one takes over.
Can You Tell the Difference by Looking?
Sometimes, but not reliably. A few screenshots at common sizes can look the same either way.
Behavior between sizes is the more useful clue. Narrow an ordinary desktop browser window slowly. On a responsive page, content tends to stretch and rewrap continuously, with occasional larger rearrangements. On a fixed-layout page, the design tends to hold still and then jump to the next layout, sometimes leaving empty space or a squeeze just before the jump.
Even then, treat what you see as a reason to ask the team, not as proof of how the site is built.
Watch for Layouts Chosen by Device Type
Some sites pick their layout from the type of browser or device rather than the width of the window. That is a different kind of adaptive behavior, and it changes how you review the page.
Two familiar builders document this. Wix’s supported devices page says sites built in the classic Wix Editor send smartphones a separate mobile version, while tablets get the desktop version. Squarespace’s help page on how sites appear on mobile devices also describes, for some site versions, detecting a mobile operating system to apply mobile styles.
A width-based preview can miss this. Online Website Previewer changes the width, not the browser the site sees, so sites that choose their layout from the browser type keep serving their desktop version. If the phone frame still shows the desktop layout, that may be what is happening. Ask the team how the site decides which layout to serve, and check that page on a real phone. The guide to what a phone preview shows and what to check on a real phone covers that second check.
What Happens Outside the Example Sizes?
Proposals show the layouts the team designed. Your visitors arrive with whatever window they happen to have.
With fixed layouts, a window that falls between two designed sizes still gets one of them, even if it fits that window poorly. The Interaction Design Foundation notes that devices that fall between breakpoints may not get an ideal layout. Ask the team to identify the range each layout covers and demonstrate the page just inside and just outside those edges.
With a responsive build, the layout fills those gaps, but that doesn’t make every in-between width good. Ask to see the in-between widths too, especially where a pricing table, a form, or a product grid has the least room.
What Each Approach Means for Updates
This is where the choice becomes a workload question for your team as well as a design one.
Google’s developer documentation calls responsive design the easiest design pattern to implement and maintain. It serves the same page code at the same address to every device. With separately designed layouts, ask whether a new promotion, a pricing change, or a form update has to be made once or once per layout. Ask who checks that the layouts still match after each update.
Fixed layouts can still be the right call. A team might want precise control over a complex screen, or a phone experience that intentionally differs. If so, ask what visitor need justifies the separate layouts and who will maintain them.
Decide on Evidence, Not Labels
Bring the five questions to each proposal and compare the answers side by side. The stronger proposal is the one that shows how the site behaves beyond its mockups and gives you a clear update process.
Whichever approach you choose, it doesn’t settle whether the page works well for a potential customer on a phone. That question belongs to the responsive vs mobile-friendly guide. When the build is ready, take the five answers into your review and check that the site does what the proposal promised.
