Responsive design and mobile first: much more than adapting a website to mobile

Today we practically take it for granted that a website has to work on mobile. The problem is that “working” can mean very different things.

A page can fit inside a phone screen and still be uncomfortable to use. It may have text that is too small, buttons that are difficult to tap, impractical menus, sections appearing in a strange order or elements designed around a mouse that make very little sense when we interact with them using a finger.

That is why, when we talk about responsive design and mobile first, we are not simply talking about making a website smaller. We are talking about designing an experience that can adapt to the available space without losing clarity, functionality or hierarchy.

And although the two concepts are often used together, responsive and mobile first do not mean exactly the same thing.

What it really means for a website to be responsive

Responsive design allows the same website to adapt its layout to different screen sizes and characteristics. A composition that uses several columns on a large monitor can switch to two columns on a tablet and reorganise completely when viewed on a phone.

The idea sounds simple, but a good implementation goes considerably further than having one desktop version, one tablet version and one mobile version.

Today there is an enormous variety of screen sizes, resolutions and aspect ratios. Between a small phone and an ultrawide monitor we have laptops, tablets, foldable devices, browser windows that do not occupy the full screen and countless situations in between. Trying to design a specific version for every one of them would be impossible.

That is why it is more useful to think in terms of flexible interfaces rather than a closed collection of devices.

Content, images, columns, spacing and individual components should be able to reorganise naturally according to the available space. MDN’s documentation on responsive web design explains precisely this approach: building layouts capable of working correctly across different screen sizes and resolutions.

This connects directly with something we already discussed when looking at what a professional website needs today: a website working properly on mobile should no longer be considered an additional feature. It is part of the basic quality of the project.

Responsive and mobile first are not exactly the same thing

Although they are often used almost as synonyms, it is worth separating the two concepts.

Responsive mainly describes the behaviour of the interface: a website that can adapt correctly to different amounts of available space.

Mobile first, on the other hand, describes a way of approaching design and development.

With a more traditional approach, we might begin by building a wide desktop version and then gradually reduce, reposition or remove elements until everything works inside a small screen.

Mobile first approaches the process in the opposite direction. We first build a clear and functional experience for the most limited space and, as more width becomes available, progressively expand what the design can do.

We can introduce additional columns, use broader compositions, increase spacing, change alignments or present secondary information differently once we genuinely have enough room to do so.

MDN uses precisely this idea when explaining media queries and mobile-first design: begin with a layout suitable for narrow screens and progressively add complexity as more space becomes available.

This does not mean designing only for mobile. It means starting with what is essential and expanding the experience afterwards instead of trying to compress it.

The problem with designing for desktop first and shrinking afterwards

Designing initially for a large screen is comfortable because there is plenty of space available. We can use huge images, multiple columns, complete menus, secondary elements and a great deal of information visible at the same time.

The problems appear when we later try to transfer that same composition to a screen only a few centimetres wide.

Suddenly, navigation that worked perfectly no longer fits. Four columns have to become one. A large image occupies almost the entire first screen. Certain controls are too small to use with a finger, and some sections have to change position completely for the content to retain its meaning.

That is when a kind of permanent negotiation with the design begins: what do we hide, what do we reduce, what do we move and what do we leave where it is even though it no longer works particularly well?

The result can easily become a compressed desktop design rather than an interface genuinely designed for mobile.

A mobile-first approach forces us to make some of those decisions earlier. What does the user need to see first? Which action is genuinely important? Which information is secondary? Which elements need enough room to be used comfortably?

The interesting part is that answering those questions well usually improves the desktop version too. Designing within constraints forces us to establish priorities.

A mobile phone is not simply a small monitor

One of the most common mistakes when approaching responsive design is to think only in terms of dimensions.

The experience changes because the way the device is used also changes.

On a computer we usually have a keyboard, a precise pointer and a relatively large screen. On a phone we use our fingers, may be browsing with one hand, walking, standing in bright sunlight, using a mobile connection slower than the fibre connection at home or checking a page for only a few seconds.

All of that directly affects design decisions.

Buttons need sufficiently comfortable tap targets. Forms should avoid unnecessary fields and use appropriate controls. Text needs a size and line length that makes it comfortable to read. Menus have to be easy to open and navigate, and primary actions should remain obvious even when many of the visual possibilities offered by a large screen disappear.

The order of the content changes too. Two sections that appear side by side on desktop will inevitably have to sit one after another when the layout collapses into a single column. Deciding which one comes first stops being a purely aesthetic matter and begins to affect the experience itself.

That is why a good mobile experience cannot be solved simply by adding a handful of media queries at the end of development. It requires thinking about how the interface is actually used.

Breakpoints should respond to the content, not the latest phone model

For years it has been common to work with a fixed list of resolutions: mobile, tablet, laptop and desktop. Those references can still be useful, but treating them as rigid rules makes less and less sense.

A breakpoint should primarily appear when the design needs it.

If two columns begin to become too narrow, that may be the right moment to turn them into one. If navigation no longer has enough space, it may be time to change its behaviour. If a collection of cards begins to lose readability, we can reduce the number of columns.

We do not need to know whether that exact width belongs to an iPhone, a Samsung Galaxy, a particular tablet or a Chrome window that the user has manually resized.

What matters is identifying the point at which the content stops working properly.

This is also the principle described by MDN when explaining media queries: it is more robust to introduce changes when the content or composition itself requires them than to chase an endless list of specific devices.

Responsive also means thinking about images

Images are another good example of why adapting a website should not stop at the layout.

A photograph intended to occupy 1,600 pixels of width on a monitor may not need the same file when it ends up displayed at 350 pixels inside a phone. Always downloading the largest image and then limiting its dimensions with CSS may work visually, but it forces the device to transfer data it may never actually use.

HTML provides mechanisms for supplying different resources according to rendering needs, while a good frontend architecture can combine appropriate dimensions, modern formats and properly prioritised loading.

The benefit works in two directions: the composition adapts better and we avoid making mobile users pay, in both data and download time, for resources intended for a much larger screen.

Responsive design and performance are more closely related than they seem

An interface can be perfectly organised on a mobile screen and still provide a poor experience if it takes too long to load or responds slowly.

On mobile devices, factors such as image weight, the amount of JavaScript executed, fonts, third-party resources and visual stability while the page loads become particularly important.

That is why responsive design and performance should be considered together.

There is little value in creating a visually flawless mobile experience if users have to download several megabytes of unnecessary resources to see it, or wait while the browser processes an application much heavier than it needs to be.

In our article about why a faster website sells more, we explained that speed is not simply a technical metric: it affects the experience, the perception of quality and the likelihood that the user will continue using the page.

And when we want to analyse the problem more precisely, metrics such as LCP, INP and CLS come into play. In our article about Core Web Vitals, we explain how they can be used to diagnose what is actually happening on a website instead of merely chasing a PageSpeed score.

Designing for mobile also means learning how to prioritise resources.

Mobile first does not mean making a simpler website

Another fairly common interpretation is to associate mobile first with removing functionality.

That does not have to be the case.

A complex application can contain a large number of tools and still work perfectly from a phone. The difference lies in how those functions are organised and presented.

On a large screen we can show side navigation, filters, secondary information, primary content and multiple actions simultaneously. On mobile, we may need to distribute those same capabilities through menus, panels, tabs, accordions or contextual controls.

The functionality can remain available; what changes is the way users access it.

In fact, this is one of the differences between simply “making an interface responsive” and genuinely designing it for different contexts. If we only change sizes and hide whatever gets in the way, we will probably lose functionality. If we rethink the interaction, we can preserve it in a much more appropriate form.

What does mobile first have to do with SEO?

The mobile experience is not isolated from search visibility either.

Google uses the mobile version of a page’s content for its indexing and ranking processes, an approach it calls mobile-first indexing. In its documentation on mobile-first indexing, Google explains the importance of ensuring that the mobile version retains the relevant content and elements of the page.

That does not mean there is an SEO trick called “mobile first” that will automatically make a page rank higher on Google.

The practical consequence is much more straightforward: important content, links, relevant images, structured data and the main information on the page should remain available in the mobile experience.

If we build a complete desktop version and then reduce the mobile version until only part of the content remains, we may end up offering a worse experience both to users and to the systems trying to understand the page.

The solution is not to design for Google. It is to avoid treating mobile as a second-class version of the website.

Testing responsive design is much more than opening DevTools and choosing an iPhone

Browser tools make checking different dimensions much easier, but serious responsive validation should go a little further.

Changing the viewport width is useful for identifying many layout problems, but it is also worth actually using the interface: opening the menu, completing forms, pressing buttons, moving through carousels, testing filters, changing screen orientation, checking long content and reviewing what happens with error messages, empty states and dynamic components.

Intermediate widths matter too.

An interface can look perfect at 375 pixels and at 1,440 pixels and break spectacularly at 820. That famous territory where nobody prepared a Figma screenshot but where users somehow still exist.

That is why I prefer to think of responsive design as continuous behaviour rather than three photographs labelled mobile, tablet and desktop.

A good responsive website should not attract attention for being responsive

When everything has been solved properly, the user will probably never even think about it.

They can simply read comfortably, navigate, find what they need, complete a form or use an application regardless of the device they entered from.

That should be the goal.

Today a website can be opened on a small phone, a tablet, a laptop, a huge monitor, a window occupying half the screen or devices we had not even considered when the project was originally designed.

Trying to prepare a separate version for every possibility would be absurd.

Responsive design allows us to build interfaces flexible enough to respond to that reality. And a mobile-first approach helps us do it by beginning with what really matters: content, hierarchy, interaction and functionality.

From there, we can progressively take advantage of all the additional space offered by larger screens.

Because a good responsive website should not feel like a desktop site we somehow managed to squeeze into a phone. It should feel like a properly designed experience, regardless of where you open it.

If you are thinking about creating a new website or have an existing site that does not quite work properly on mobile, we can analyse what is happening and propose a solution suited to the project. Tell us about your project through Tornem’s contact form and let’s talk.