Skip to main content
News Design
Design

Mobile-First Design: Beyond Responsive

Jun, 2024 8 min read • By Michelle, Gravity Projex
Construction has started at Victoria Park and Destination 2045 is running ahead of projections. What Queensland tourism operators should be fixing digitally in 2026, not 2031.

Responsive design solved a layout problem. It did not solve the mobile problem, and the gap between those two things is where most Australian business websites quietly lose money.

Responsive means your site rearranges itself to fit a smaller screen. Columns stack, images scale, the menu collapses. That is genuinely useful, and it has been standard practice for over a decade. It is also the floor, not the ceiling.

Because the person on the phone is not just looking at a smaller version of your website. They are a different person, in a different situation, with different patience.

The context, not the screen

Think about who is actually on your site right now via mobile.

They are standing in a driveway looking at a cracked slab. They are in a car park with two bars of reception. They are on the couch with the TV on, half watching. They are at a job site with dust on the screen and gloves half off. They have been interrupted twice since they opened the page.

Now think about who your desktop visitor is. Sitting down. Two hands. Fast connection. Focused, or at least focused enough.

Responsive design treats these two people as the same person with different screen dimensions. They are not. The mobile visitor has less attention, less bandwidth, less precision in their tapping, and far less tolerance for anything that makes them think.

Mobile-first means designing for that person first, then expanding for the desktop visitor. Not the reverse. The reason the order matters is that constraints force decisions. When you start on a 375 pixel wide screen you have to decide what genuinely matters, because there is no room for anything else. When you start on desktop and shrink, you carry all of your indecision down with you.

What actually breaks on phones

We audit a lot of sites. The failures are not exotic. They are the same handful of things, over and over.

Tap targets that are too small or too close together. The commonly cited guidance is around 44 to 48 pixels as a minimum touch target, with enough spacing that a thumb cannot hit two things at once. Footer link lists are the worst offender: twelve links stacked at 14 pixels with no padding, which on a phone means every tap is a coin flip.

Phone numbers that are not links. If your number is typed as plain text rather than wrapped in a tel link, tapping it does nothing. The visitor then has to memorise it, leave your site, open the dialer and type it in. Most will not. For a service business this single fault costs more enquiries than any design decision on the page.

Forms built for a keyboard. Fourteen fields, no input types set, so the numeric keypad never appears for the phone field and the visitor is typing digits on a letter keyboard. Date pickers that need precision tapping. Dropdowns with forty options. Every extra field is a chance to give up, and on mobile that chance is much higher.

Sticky headers that eat the screen. A fixed header plus a cookie banner plus a chat bubble plus a promotional bar can consume close to half of a phone viewport before any content appears. On desktop this looks like a tidy 80 pixel strip. On a phone it is a wall.

Hover states that do not exist. Anything that reveals itself on hover is invisible on touch. Dropdown menus that need a hover to open, tooltips carrying important information, image captions that appear on mouseover. On a phone that content simply does not exist, and the visitor never knows it was there.

Text sized for a designer’s monitor. Body copy below 16 pixels is hard work on a phone in daylight. Light grey text on white looks refined on a calibrated screen indoors and disappears entirely outside, which is exactly where trades and hospitality customers are.

Media that assumes wifi. An autoplaying hero video is a courtesy on a desktop and a hostile act on a metered mobile connection. Same for uncompressed hero images shipped at full resolution to a phone that needs a fraction of it.

None of these are visible if you test your site by dragging your browser window narrower. You have to hold an actual phone, outdoors, on mobile data.

The thumb zone, honestly

You will see a lot of confident writing about the thumb zone: the idea that because most people hold a phone one-handed, your important controls belong in the lower third of the screen where the thumb naturally rests.

The underlying observation is real. Reaching the top corners of a modern phone one-handed is genuinely awkward, and phones have got taller since the research was first popularised. Bottom-anchored navigation is now common in apps for good reason.

The overclaiming is where it goes wrong. People do not hold phones one way. They switch between one hand, two hands and cradled depending on what they are doing. And the standard top-right hamburger menu is not a usability failure, whatever the design blogs say. It is a convention so established that people find it without thinking, and familiarity beats theoretical ergonomics most of the time.

The practical version is simpler. Put your primary action somewhere the thumb can reach without a grip change. A persistent call button pinned to the bottom of the screen on a trades site will outperform the same button in the header, not because of thumb geometry but because it is always there at the moment of decision. Keep the hamburger where people expect it. Do not move a convention just to be clever.

Container queries, and the thing the old version of this article got wrong

An earlier version of this post described adaptive design as using container queries. That conflated two unrelated ideas, so here is the correct version.

Adaptive design is an approach where you serve distinct layouts at set breakpoints, rather than fluidly scaling one layout. It predates container queries by years.

Container queries are a CSS feature, broadly supported across modern browsers since 2023. They let a component respond to the width of its own container rather than the width of the whole viewport. A testimonial card can look one way in a narrow sidebar and another way in a wide main column, on the same page, at the same viewport width, without you writing viewport breakpoints for every context.

That matters because it changes where the responsibility sits. With viewport media queries, the page has to know about every component. With container queries, each component knows how to look after itself, and you can drop it anywhere. For anyone building a component library, which is how we build, it is the more useful of the two ideas by a wide margin.

The practical mobile benefit is real but indirect: fewer breakpoint hacks means less CSS, less fragility, and fewer of those layouts that work at 375 and 768 but fall apart at 430.

The numbers Google actually measures

Core Web Vitals are the metrics Google uses to judge real-world experience, and they are overwhelmingly a mobile story because most visits are mobile.

There are three, and the thresholds for a good score are:

Largest Contentful Paint under 2.5 seconds. How long until the main content is visible. Usually your hero image or headline.

Interaction to Next Paint under 200 milliseconds. How quickly the page visibly responds when someone taps something. This replaced First Input Delay in March 2024, so any guide still referring to FID is out of date. It is also the metric most sites fail, because it is the one that exposes heavy JavaScript.

Cumulative Layout Shift under 0.1. How much the page jumps around while loading. Caused by images without declared dimensions, fonts swapping late, and ad or banner slots inserting themselves after render.

Here is the part that catches people out. These are field metrics, not lab metrics. Google grades you on the Chrome User Experience Report at the 75th percentile across a rolling 28 day window. In plain terms, three quarters of your real visitors have to get a good result. Your site being fast on your laptop on the office fibre connection is irrelevant. What counts is the fourth-slowest visitor in every four, typically someone on a mid-range Android on patchy mobile data.

That is also why a perfect score in your browser dev tools can sit alongside a failure in Search Console, and why fixes take several weeks to show up: the 28 day window has to roll over before the change is reflected.

If you want to check your own site, PageSpeed Insights shows you both the lab result and the field data where enough real traffic exists. Look at the field data. Ignore the score out of 100, which is a lab number and is not what Google ranks on.

Progressive Web Apps: usually not your answer

Progressive Web App technology lets people install your website to their home screen, with offline access and push notifications, without you building a native app.

It is a genuinely good technology and it is a poor fit for most small businesses.

PWAs earn their keep when people come back repeatedly and habitually. A booking platform, a customer portal, a tool someone uses weekly. If your site is a brochure that a customer visits twice before they call you, nobody is installing it, and building for offline access solves a problem that does not exist.

We build portals for our clients where that repeat usage is real. For a concreter or a café, the same effort spent on load speed and a working enquiry form will return far more. Be suspicious of anyone selling you a PWA for a five page website.

Where to start

If you do nothing else from this article, do these four things this week.

Open your site on your own phone, outdoors, on mobile data rather than wifi. Try to complete the main action you want a customer to complete. Time it.

Tap your phone number. If nothing happens, that is your highest priority fix.

Send yourself a test enquiry through your own form. A surprising proportion of the sites we audit have forms that have been silently failing for months.

Run your homepage through PageSpeed Insights and look only at the field data section. If Interaction to Next Paint is failing, you have a JavaScript problem, and that usually means a page builder or a stack of plugins rather than anything you can fix with a caching setting.

Responsive design got your site onto the small screen. Everything after that is the actual work.

Ready to Launch Your Digital Presence?

Let's discuss how Gravity Projex can help accelerate your business growth.

Launch Projex