Optimizing a mobile website for businesses whose customers come from their phones

A pipe has burst, the customer is standing in the basement searching for a business with one hand while the other holds a bucket. He types a search, opens the first usable result and wants to know one thing: will someone come, and how do I reach them? He does not read a company history and does not scroll three screens. He looks for the call button.

This picture is the starting point of this study, and it is a scenario, not a report on a particular project. It stands for businesses whose inquiries come mostly from smartphones: emergency service, repairs, appointment requests from the lunch break, inquiries from the customer's building site. For them, the phone is not the desktop's little brother but the normal case.

Many websites were nevertheless created on a large screen. The designs were approved on a monitor, and on the phone someone “quickly checked whether it fits”. The result fits in the sense of “nothing runs over the edge”, but it is not built for the situation in which it is needed.

Anyone advising businesses of this kind hears the same sentence in variations: on my computer everything looks good. That is true, and it is the core of the problem. When checking, the owner sits in the office, with a good connection and two hands. His customers rarely do. The change of perspective is the first task, even before anything is designed.

The failure patterns are rarely spectacular; they are everyday. The phone number sits as text in the header and cannot be tapped. The navigation has buttons that you only hit on the second try. The contact form demands twelve fields, including two that nobody likes filling in on a phone. When a field is tapped, the on-screen keyboard pushes the submit button out of view.

Then there is the technology in the background. A hero image of several megabytes, three font weights, an embedded video and a chat widget all load even when reception is weak. Anyone searching in a stairwell or out in the countryside has to wait. Mobile coverage is not a constant value; it fluctuates with location and network load.

The tricky part: the business does not see the loss. Visitors who give up leave no message. The enquiries that do arrive come from those who stuck it out, which creates the false impression that everything is running fine. Whether and how much is being lost can only be read from behavior, not from the inbox.

Before we design anything, we clarify three things. First: which situations lead people to the site? Emergency service, appointment requests, price comparison and evening research call for different paths. Second: which contact method does the business actually prefer? A call button only helps if someone picks up. Third: what do the data show, for example in Search Console and web analytics, about the share of mobile visits?

The thumb zone is a rule of thumb from ergonomics. With one-handed use, the thumb comfortably reaches the lower and middle part of the screen, but barely the upper corner opposite the holding hand. This is not a law of nature, since people hold phones differently and devices keep getting larger. Even so, it works as a design principle: important, frequent actions belong in the lower area, rare ones in the upper area.

This gives us an order of information. On a phone, what decides whether a visitor stays or leaves sits above the fold: who you are, where you work, when you can be reached, how to get to you. Everything else follows further down, in the order in which doubts arise. A visitor who does not call usually wants one question answered first.

A simple idea helps here: every page has one main job. The home page of an emergency service should build trust and lead to a call; the service page for maintenance should answer questions and make an appointment possible. When a page tries to do both at once, it loses on the small screen, where there is simply no room for side paths. We name the main job before the first draft.

The usual solution is called responsive design: a grid that shrinks, columns that stack. That is necessary, but not sufficient. If you only stack, you keep the desktop's priorities, just one below the other. A wide header with logo, menu and phone number becomes a tall block that fills the first screen and pushes the most important things down.

Mobile-first reverses the direction of work. The phone version comes first, with what matters there, and then we expand for larger screens. This forces decisions: what is really important, what can go, what belongs at the end? The desktop benefits too, because it is not an overloaded original from which you laboriously cut things.

An alternative would be separate mobile pages or a separate app. We rule out both for small businesses. Two versions double the maintenance, and an app would require an installation where someone in an emergency simply taps. The third option, a Progressive Web App, is worthwhile for returning users, rarely for one-off enquiries. For our scenario, a lean, fast website remains the most suitable route.

A word on automatic mobile plugins that "convert a page to be mobile-friendly". They treat symptoms, for instance by adding scripts, and leave the priorities untouched. Occasionally they are a stopgap, but they do not replace the question of what should come first on the small screen. Where a site builder or CMS dictates templates, we check how far they can be adapted before we commit to anything.

The number of resources also argues for keeping them small. The fewer scripts and widgets, the less can go wrong on a device in the lower price segment. We therefore replace functions with standard browser elements wherever possible: links instead of scripts, form fields instead of custom builds.

The core of the concept is a contact method that works without thinking. The phone number becomes a link that opens the dialer when tapped. Next to it there can be a WhatsApp button, if the business actually answers messages there. Anyone who offers it must also staff it, otherwise it raises an expectation nobody fulfils. That includes stating the hours clearly.

The size of tap targets is an often underestimated lever. As a guideline, roughly 44 by 44 pixels applies; Apple's design guidelines specify 44 points, Google's Material Design 48. The WCAG 2.2 accessibility guidelines require at least 24 pixels at level AA, with spacing from neighbors. We plan for the larger values because thumbs are thicker than mouse pointers and visitors on the move often tap with one hand.

The sticky contact bar at the bottom keeps the call always within reach. It has pitfalls, which we clear up in advance: it must not cover content or the footer, so the page gets matching padding at the bottom. It must sit in front of the on-screen keyboard or hide when a form field is active. And it must not grow taller than necessary, because otherwise barely any reading area remains on small devices.

For the form, every field costs. For an appointment request, name, phone number or email address, a short description and consent to data processing are often enough. Everything else can be clarified in the callback. Where additional details help, such as a postal code for the service area, they appear as optional fields, not as required ones.

Technically, a lot is simpler than it sounds if you use standard elements. A call is a link with tel: and the number in international format. A WhatsApp message runs through a wa.me link with optional suggested text. Both work without a script, without a plugin and without load time. On the desktop, where no phone is at hand, the same link can appear as a text number with a copy helper.

In the form, a few attributes control the comfort. The field type tel opens the numeric keypad, email the keyboard with the at sign, and autocomplete lets the device suggest name and address. The font size in input fields should be at least 16 pixels, otherwise Safari on the iPhone zooms in when tapped and wrecks the layout. Error messages appear at the field, not collected at the top, where they are out of sight.

For the sticky bar we use position: fixed at the bottom edge, the safe-area spacing env(safe-area-inset-bottom) for devices with a gesture bar, and a matching padding-bottom at the end of the page. We specify heights in dvh instead of vh, because on mobile browsers the address bar slides in and out and vh therefore pushes content behind the bar. Anchor jumps get scroll-margin so headings do not end up under the bar.

For load time we aim at the Core Web Vitals thresholds: LCP up to 2.5 seconds, INP up to 200 milliseconds, CLS up to 0.1. We load the largest visible element, usually the main image, early and at an appropriate size, with srcset for different widths and modern formats such as WebP or AVIF. Images below the first screen load lazily, the main image does not. We limit fonts to what is necessary and serve them ourselves.

Special cases only show up on real devices. The most common: the form is clean on the desktop, but on the phone the keyboard pushes the submit button out of view, and the visitor keeps searching until they give up. The remedy is a page layout that scrolls the active field into the visible area when a field is focused, and a sticky bar that hides while the user is typing.

Second, weak reception. If the connection drops during submission, the text someone has just laboriously typed is lost. We therefore keep the entries in the form until submission is confirmed, and report clearly if sending fails. The note "You can also call us directly" belongs next to the error message, not in the footer.

Third, cookie notices and pop-ups. A banner that covers half the screen also covers the call button. We design the consent prompt to be slim and have it appear so that the contact methods remain reachable, as far as the chosen solution allows. A legal assessment remains a matter for the data protection review, but a note on this tension belongs in the concept.

Fourth, the interplay with local search. Someone who arrives at the website from the Google Business Profile has often already seen the opening hours and the number. The page should keep this information consistent and not lengthen the path to directions or to the call. Contradictory hours between the profile and the website cost trust and bring calls at inconvenient times.

And finally, the variety of devices. An older Android device with little storage, an iPhone with large text in the system settings, a device in dark mode: each of these can strain the layout differently. We therefore test with enlarged system font and with a throttled connection, not just with the newest device on Wi-Fi.

An improved mobile experience cannot be quantified across the board, and we therefore name no percentages. The realistic expectation is that fewer visitors fail at hurdles: more taps on the call button, more completed forms, fewer abandonments at input fields. How large the effect is depends on the starting point, the offering and the demand.

Measurement works with events. A click on the tel: link, on the WhatsApp button and on form submission are recorded as goals, separated by device type. If you use web analytics, you should first clarify whether consent is required for it, and consider privacy-friendly solutions. In addition, the Search Console's experience report shows whether the pages reach the Core Web Vitals thresholds.

A call click is not the same as a call. Someone who taps the button and hangs up has pressed it but achieved nothing. That is why it is worth reconciling with the business: how many calls actually come through, how many are missed, and at what times? Sometimes the biggest lever is not on the website but in the fact that nobody picks up in the evening.

Allow several weeks for the evaluation, and for seasonal trades also a comparison with the previous year. Individual days say little, because weather, holidays and promotions shift the volume. What cannot be promised: a certain number of enquiries or a better position in search. Improving usability creates preconditions; it does not control demand itself.

First: test on real devices, not only in the browser emulator. The device view in the developer tools shows sizes, but neither the feel of the tap targets, nor the behavior of the keyboard, nor the gesture bar. Two to three real devices of different age and operating system uncover most of the errors. That includes a test on the move, on mobile data instead of Wi-Fi.

Second: throttle the connection when testing. Lighthouse and PageSpeed Insights simulate a slow mobile network and a weaker device. The lab values are only a guide; the field data in the Search Console report show reality. If the two differ strongly, it is worth looking at third-party scripts that do not load in the lab but cost time for real visitors.

Third: fewer elements, but larger ones. A menu with four clear entries beats one with nine. A button labeled "Call now" beats an icon without text. Contrasts should be readable even in sunlight, because a phone outdoors is often used under poor conditions. These decisions are hardly expensive, but they have to be made.

Fourth: maintain the site with the phone in mind. New images that a staff member uploads should be automatically brought to a suitable size, otherwise the load time grows with every update. This belongs in the editorial workflow, not only in the build. A simple checklist after every major change is enough.

If your customers come from their phones, the mobile website is your presence, not an add-on. That does not mean it has to be elaborate. A clear first screen, a call button within thumb reach, sufficiently large tap targets, a short form and lean delivery achieve more than a profusion of animations and widgets that get stuck on the device.

The improvements are measurable, but cannot be promised. They remove hurdles on the way to the enquiry; they do not create demand. Anyone who knows this can plan soberly: first the contact methods, then the speed, then the fine-tuning. And anyone who keeps an eye on the business recognizes that even the best page is useless if nobody answers the phone.

To put the effort in perspective: for a small website with a few pages, a revision along these lines is doable in a manageable time, because it is about priorities and contact methods, not new content. It gets bigger with many templates, custom software or connections to booking systems. We state the scope after an initial review, not before.

The next step is small. Take your phone, go into a room with weak reception and try to contact your own business. Count how many taps and seconds it takes until the phone rings. If that is sluggish, the website deserves a look. We are happy to look at it together and will tell you honestly what is worthwhile.