Mobile operation — what really irritates on a phone and how to fix it

Mobile operation — what really irritates on a phone and how to fix it
Table of contents 11 sections

What really sets mobile operation apart from desktop

A mobile website is not a shrunken desktop version. It is its own operating world with different physical conditions. Anyone who does not accept that builds sites that load on the phone but are practically not usable.

Three hard differences.

First, input precision. A mouse pointer hits a single pixel. A thumb hits an area of about 9 by 9 millimetres — that is between 40 and 50 pixels, depending on screen resolution. Any control smaller than that costs failed attempts.

Second, input geometry. On the desktop the hand sits on the mouse and moves a pointer across every screen area. On the phone, one hand holds the device and a single thumb reaches about three quarters of the screen surface comfortably. The upper edge of the screen, especially the upper left corner for right-handers, is the most uncomfortable zone overall.

Third, the input feel. A click is a precise event the mouse registers unambiguously. A tap is a brief touch the browser has to interpret. If the browser is unsure whether it was a tap, a double tap, or a swipe, the response is delayed — and the site feels sluggish.

Stefan, a plumbing and heating contractor in Carinthia with 14 employees, set up his first website via a hosting provider that included the note "fully responsive". Three months later came the sober realisation: his contact form was barely usable on the phone — the input fields were too small for the thumb, the send button sat above comfortable thumb reach, and on completion the keyboard appeared and covered the confirmation message. How many enquiries he lost through this cannot be quantified — but after a web designer had fixed these three points, noticeably more enquiries came via mobile than before.

Touch targets — the magic 44-pixel limit

Apple has defined in its Human Interface Guidelines for over ten years the minimum measure for tappable elements: 44 by 44 pixels. Google Material Design recommends 48 by 48 dp. The WCAG recommendation is in the same range[1].

What does that mean practically. A button or link to be operated on the phone needs a hit area of at least this size — even if the visible text is smaller. The surrounding padding can be set generously by the designer so the tappable area is larger without the layout suffering.

Three common violations of this rule.

First, text links in body text. A single linked word in the middle of a paragraph almost never meets the 44-pixel limit. Rule of thumb: linked words in body text should have at least 18 pixels font size on the phone and a vertical hit area extending beyond that.

Second, icon buttons without padding. A 24-pixel search symbol without surrounding hit area is a lottery on the phone. Padding of 10 to 12 pixels in each direction solves that.

Third, controls too close together. If three buttons stand next to each other but have overlapping hit zones, you regularly tap the wrong one. Minimum distance between controls: 8 pixels.

Thumb reach — where controls belong

The thumb zone is a sketch from mobile UX research showing which screen areas are comfortably reachable with the thumb in normal one-hand operation. It looks different for right-handers than for left-handers, but the basic pattern is the same.

The lower half of the screen is the comfort zone. Here belong actions tapped frequently — call button, primary call-to-action, main menu access. The upper half is the reach zone, accessible but uncomfortable. Here goes information the thumb touches less often — logo, search field, breadcrumb navigation.

Practical consequences.

Sticky call button at the bottom edge of the screen. For service businesses with telephone-driven business that is probably the most effective mobile adaptation overall. Effort: minimal. Effect: measurably more calls.

Primary call-to-action in the main content — i.e. "Start booking", "Send enquiry", "Start configuration" — belongs in the lower half of the screen. Anyone hiding the main CTA top right invites mis-taps and clicking away.

Secondary actions — newsletter, social links, language switch — can sit at the top. Anyone tapping next to them has done no damage.

Font sizes and readability on a small screen

A font that works at 14 pixels on the desktop is often too small on the phone. Three font sizes that carry in practice.

Body text at least 16 pixels, better 17 or 18. Anything below is hard to read from the thumb-holding-distance, and browsers then often automatically zoom the text — which destroys the layout.

Headings proportional. An H1 between 24 and 32 pixels, an H2 between 20 and 26 pixels. Anyone without this hierarchy has no reading orientation on the phone.

Line spacing at least 1.5 times font size. With 16-pixel text, line spacing of 24 pixels, better 26. Tighter lines are strenuous on a small screen and lead to "losing" the line just read.

Plus the discipline of line length. On the desktop 70 characters per line are pleasant, on the phone 35 to 50 characters are the right measure. That usually arises from the smartphone format by itself — but on sites with a fixed layout width that is "squeezed" on the phone, readability is destroyed.

What never works: fonts under 14 pixels as mandatory reading content. If you place data-protection notices or disclaimers in 11-pixel font, that has nothing to do with operation but with the wish that no one reads it — and browsers are increasingly interpreting that as an anti-pattern.

Forms on the phone — the discipline many underestimate

A form sequence that runs pleasantly on the desktop can become a hurdle on the phone. Three common problems.

First, wrong keyboard types. Anyone defining a phone-number field as a regular text field gets the full keyboard on the phone instead of the digit keyboard. Per enquiry three additional seconds of typing, multiplied by the number of fields — that adds up to frustration. The remedy: inputmode="tel", inputmode="email", inputmode="numeric" as an attribute. Effort: zero, effect noticeable.

Second, confirmation messages above the virtual keyboard. When a success message appears after sending but sits below the displayed keyboard, the user does not see it. Consequence: they think the send did not work and press again. That triggers double submissions and confuses everyone involved.

Third, mandatory fields that are not recognisable. On the phone space is tight — the usual small asterisk to the right of the field label is often hardly visible. Better: the word "required" or "optional" in its own line under the field.

Tap instead of hover — what no hover state means

On the desktop, hover effects signal clickability. You move over a button, the button changes colour, you know it is clickable. On the phone this advance confirmation does not exist — the tap is immediately the event.

That has consequences for the design. Six rules of thumb.

Clickability must be recognisable visually from the resting state. A button looks like a button, a link is recognisable as a link — without a mouse having to move over it.

Two different controls need optically clearly recognisable differences. Primary button and secondary button must not look so similar that on the phone it is not recognisable which is the main action.

Confirmation feedback has to be triggered by the tap itself, not by a preceding hover state. A short colour change on tap, a brief animation, a slight ripple effect — that gives the response that hover gives on the desktop.

Mobile dropdowns work technically differently from desktop dropdowns. Anyone passing a classic hover dropdown unchanged through to mobile has an operating problem. More on this specific aspect is in the article on navigation and menu structures.

Fixed controls — call button and the like

Three fixed controls that bring value on most SME mobile sites.

Sticky header. The logo plus main menu access at the top, always visible. Prerequisite: a slim header of 50 to 60 pixels height; otherwise it eats content surface.

Sticky call button at the bottom edge. A small surface with a phone symbol and "Call" text. For service industries with a high call rate, the most effective mobile adaptation overall — the way to the call is always a thumb-tap away, instead of having to be searched for.

Breadcrumb navigation or back arrow. For sites with nesting of at least three levels, a hint where you are — without having to use the browser's forward/back arrow.

What should not be a fixed control: a permanently displayed newsletter banner, a chat bubble that permanently occupies the lower right corner, a cookie banner that covers half the screen surface. These three elements are regularly named in mobile studies as the most disturbing factors.

Eight typical mobile layout mistakes

From around 60 mobile audits, eight recurring problems emerge.

One. Tables that work on the desktop are unusable on the phone. Remedy: convert to vertical lists on the phone, each row as its own block.

Two. Images with fixed width are cropped on the phone. Remedy: max-width: 100% as CSS standard for every image.

Three. Pop-ups that fill the whole screen surface without a recognisable close button. Remedy: close button with a clear symbol, at least 44 pixels hit area, recognisable at the top right.

Four. Clickable phone numbers not set up as tel: links. Remedy: all phone numbers as tel: links so a tap starts the call directly.

Five. Email addresses not set up as mailto: links. Remedy: analogously, mailto: link opens the mail app.

Six. Location details that do not function as a map link. Remedy: address plus "Open in maps" link that starts the standard map app.

Seven. Texts with minimum width that overflow left and right on the phone. Remedy: no fixed CSS widths in pixels, but percentages or relative units.

Eight. Fonts not loaded on the phone because they are too large. Remedy: optimise fonts, set font-display: swap, use at most two fonts plus two weights.

What "responsive" actually means — and what it does not

"Responsive" is the most misused term in the mobile discussion. It means technically: the layout adapts to the screen size. It does not mean: operation is optimised.

A responsive site that is unusable on the phone is also responsive. It shrinks dutifully, it does not break columns, it does not throw the layout around — but the operating logic remains a desktop logic. That is the most common weakness of hosting offerings with a "fully responsive" promise.

What a mobile site needs goes beyond responsiveness.

A separate mobile content structure. Which content sits at the top on the phone, which at the bottom, which is folded away. That is a content decision, not a layout decision.

A separate mobile navigation logic. How does the menu work on the phone, what depth makes sense, where is the primary entry point.

A separate mobile operating decision. Which buttons are primary, which secondary, how much padding does each element get.

If you do not actively decide this, you get an "also on the phone" experience that is noticeably distinguishable from a deliberately built mobile experience. For conversion that makes a measurable difference. Mobile operation and mobile performance are two sister disciplines that together produce what visitors perceive as "runs on the phone" — the corresponding performance discipline is in the article on the three-second mark and conversion loss on the phone.

How to test your own mobile operation

Four tests that together take thirty minutes.

Test one, the one-hand test. Open your site on the phone, hold the device in one hand, do three concrete tasks only with the thumb of that hand. Find the call number, start the contact form, open a job opening. If you need the other hand anywhere, you have a mobile operating mistake.

Test two, the thumb-size test. Tap all controls on your home page at least once. If you tap next to it, the control is too small or too close to the neighbouring element.

Test three, the readability test. Read a paragraph on your longest content page once completely. If your eyes lose the line or you have to zoom the text, the font size is too small or line spacing too tight.

Test four, the form test. Fill in your contact form completely and submit. Pay attention to every detail: does the right keyboard come up, is the send button in the thumb area, do you see the confirmation. If one of these three questions is answered with no, you have optimisation potential.

Frequently Asked Questions

What is the ideal touch-target size for mobile controls?

Apple Human Interface Guidelines recommend at least 44 by 44 pixels, Google Material Design 48 by 48 dp. Both values count as industry standard. Smaller controls are technically possible but cost mis-taps — every additional miss reduces conversion and trust in the site.

Which font size should be used at minimum on the phone?

Body text at least 16 pixels, better 17 or 18. Headings proportionally above. Fonts under 14 pixels as mandatory reading content do not work on the phone and are increasingly classified by browsers as an anti-pattern.

Where is the ideal place for a call button on the phone?

At the bottom edge of the screen as a sticky element, with a phone symbol and "Call" text. There the way to the call is always a thumb-tap away. The upper right area of the screen is the second-best position but costs reach effort for the thumb.

Does a "fully responsive" website automatically work well on the phone?

Responsive only means the layout adapts — not that operation is optimised. A responsive site can still be unusable on the phone if touch targets are too small, controls sit in the uncomfortable zone, or forms were not conceived for touch. Responsiveness is the prerequisite, not the outcome.

What are the most common mobile operating mistakes in SME sites?

Controls too small, mandatory fields without recognisable markings, phone numbers without a tel: link, wrong keyboard types in forms, pop-ups without a visible close button, and texts with line spacing too tight. These six hit, in different combinations, a large share of all SME sites not actively optimised for mobile operation.

Should I build a separate mobile site or a responsive site?

A responsive site with its own mobile operating strategy is the better choice in most cases. Separate mobile sites with their own URL (typically m.yourdomain.at) were widespread until 2014 and today count as outdated because they require double maintenance and cause SEO problems. The only exception: very special application sites with a completely different function for mobile and desktop.

What to check now

Do the one-hand test on your own site: hold the phone in one hand and try to perform three concrete tasks with the thumb of that hand. If even one task fails, you have the clearest lever right in front of you — and usually a small adjustment in the control layout triggers measurably more enquiries.

What is the next step?