Mobile version of a website: common mobile UX mistakes

The most common mistakes on the mobile version of a website: small, cramped buttons, awkward forms, tables and text that run off the screen, slow loading, pop-ups covering the content and a phone number that does not open with a single tap. You can spot them by checking the site on a real smartphone through the key scenarios: find a product, make a call, send a request, pay.

In short

• Google mostly evaluates a page by its mobile version, so gaps on smartphones affect search visibility.
• Buttons and links should be large enough and spaced apart so a finger can hit them.
• Forms are cut down to the necessary fields, use the right keyboard types and have autofill turned on.
• Speed and a stable layout matter because of slow networks and less powerful devices.
• Test on real phones and in analytics broken down by device type.

Why the mobile version determines the result

In many niches a large share of visitors comes from smartphones. The share depends on the topic and the audience, so check it in your own analytics, for example in the device type report in Google Analytics.

Google uses mobile-first indexing: to evaluate a page, the search engine mainly uses its mobile version. If the mobile version lacks text, images or markup that the desktop version has, that content can lose weight in search.

For a business the consequences are simple: a page that is awkward on a phone reduces the number of inquiries, can raise the cost per lead from paid traffic and weaken search rankings.

People use a smartphone in a different context than a computer: they hold the phone in one hand, stand in a line or ride public transport, look at the screen in bright light and deal with a weak signal. So the page has to answer the main questions quickly: what is offered, how much it costs, how to get in touch.

Navigation and taps

Size of elements and spacing between them

A finger is less precise than a mouse pointer. Apple and Google guidelines for mobile interfaces recommend interactive elements of roughly 44–48 pixels in each dimension with noticeable spacing between them. Small links in the text, cramped menu items and buttons pressed right against each other lead to accidental taps and frustration.

Menu

A hamburger menu suits a large website, but the most important actions – call, write, open the cart – are better placed in plain sight. The menu should open with one tap, close with a clear button and not cover the screen without need.

Phone and messengers

The phone number is marked up as a link with the tel protocol, so a call starts with a single tap. Links to messengers work the same way. A fixed contact button at the bottom of the screen shortens the path to a conversation, as long as it does not cover the text and the form buttons.

Search and breadcrumbs

On websites with many pages, search and breadcrumbs that show where the visitor is are a great help. The search field should be easy to notice, and the results should stay relevant even when the query has typos.

Carousels, drop-down lists and fixed elements

Carousels whose slides switch only with arrows are inconvenient on a smartphone. Drop-down lists with dozens of items are better replaced with search or groups. Several fixed elements at once – a header, a chat, a cookie banner, a call button – leave very little room on the screen for the content.

Text, images and tables

A few basic rules keep a small screen readable.

• Body text of about 16 pixels: a smaller font forces people to zoom the page.
• Sufficient contrast between text and background, especially in bright light.
• Short paragraphs, subheadings and lists instead of a solid wall of text.
• Images with responsive sizes and space reserved in advance so the layout does not shift while loading.
• Tables with their own horizontal scrolling inside the block or rebuilt as cards; the page as a whole does not scroll sideways.
• Videos without autoplay with sound and with dimensions that fit the screen.

Check pages with large price or specification tables separately: they are the ones that most often run off the screen.

Example: a service page on a smartphone

On a computer the service page has text on the left and a form on the right. On a smartphone the blocks stack one under another, and the form ends up below a long text. The visitor scrolls through several screens and does not see how to send a request. The solution: a short block with the benefits, a request button right after it and a form that the button leads to.

Forms and contact

The form is where inquiries get lost. A good mobile form is short, has labels above the fields that do not disappear while typing and shows errors next to the relevant field.

• The phone field opens a numeric keypad, the e-mail field a keyboard with the @ symbol (the tel and email field types).
• Browser autofill fills in the name, phone and address.
• The phone field accepts a number in any familiar format and does not require typing parentheses and hyphens by hand.
• The submit button is easy to see and does not hide behind the keyboard.
• Spam protection without complicated picture puzzles: invisible checks or simple tasks will do.
• After sending, the person sees a confirmation and understands what happens next.

It helps to offer several ways to get in touch: a form, a call and a messenger. Some people dislike talking on the phone, others do not want to fill in fields, so a choice of channel raises the chance of getting an inquiry.

Speed and elements on top of the page

Speed

Mobile networks can be unstable, and devices differ in power. Large images, heavy fonts and third-party scripts slow a page down. In its public recommendations Google highlights the Core Web Vitals metrics: how fast the main content appears (LCP), responsiveness to user actions (INP) and layout stability (CLS). Their values are shown in PageSpeed Insights and in Search Console.

• Compress images and specify their dimensions.
• Defer loading of images located below the first screen.
• Limit the number of fonts and their weights.
• Turn off scripts that bring no benefit.
• Check the speed after every new widget.

Banners and pop-ups

Cookie banners, subscription prompts and promotional pop-ups that cover the screen keep people from reading the page to the end. Google's public recommendations state that intrusive pop-ups after a visit from search can worsen the page's evaluation. Make the banner compact, with a close button that is easy to tap, and do not show the subscription prompt right after the page opens.

How to check the mobile version and where to start fixing

1. Open the main pages on two or three real smartphones with different screen sizes.
2. Go through the key scenarios: home page, catalog or service, form, payment, call.
3. Use the browser's device mode for a quick overview, keeping in mind that it does not replace a real phone.
4. Run PageSpeed Insights and review the Core Web Vitals report in Search Console.
5. Compare conversion on smartphones and computers in analytics; a sharp gap points to a problem.

Order of fixes

It is convenient to record the results as a short list: page, problem, priority. First fix whatever gets in the way of a request or a payment, then the most visited pages according to analytics, next the errors that break the look of a page, and finally the minor improvements to text and spacing.

Common mistakes

• The design is made for desktop, and the mobile version is added at the end, when it is too late to change the structure.
• Testing only in a browser emulator on a new flagship phone.
• Part of the text and images is hidden on the mobile version, although it is there on desktop.
• Chats, widgets and analytics are added without checking their impact on speed.
• Device data in analytics is ignored: decisions are made by impression.
• The check is not repeated after an update of the theme, plugins or cookie banner.
• The subscription pop-up appears right after the page opens, even before the first scroll.
• The call and request buttons are only at the bottom of a long page.

Questions and answers

Does a website need a separate mobile version?

Usually no. The modern approach is responsive design: one address and one set of content that rearranges itself to the screen size. A separate mobile version at a different address complicates maintenance and SEO.

How do I check whether a website is convenient on a smartphone?

Open the main pages on a real phone and go through the key scenarios. In addition, use PageSpeed Insights, the Core Web Vitals report in Search Console and URL inspection. Google's set of tools changes, so check against the current help documentation.

What font size should I choose for the mobile version?

For body text about 16 pixels usually works, for captions and notes a little less, with sufficient contrast. Check readability on a real device in different lighting.

Is a hamburger menu always necessary?

No. For a small website with a few sections visible navigation will do. A hamburger makes sense when there are many items; the most important actions still go in plain sight.

How is the mobile version related to advertising?

Paid ads often lead to pages that people open on a smartphone. If the page is awkward, you pay for the click and nobody fills in the form. Before launching ads, check the landing page on a phone.

Conclusion

The mobile version determines whether a person sends a request from a phone. Start with the main scenarios: find what is needed, make a call, fill in a form, pay – and fix what gets in the way the most. After changes, check the website on a phone again: theme and plugin updates often break the mobile layout. Measure the result by conversion on smartphones. LightSEO is a digital agency from Mukachevo that has been building websites and online stores and doing SEO since 2015, so it can help check your mobile version. Technical problems that affect visibility are uncovered by a website SEO audit. A new responsive website can be ordered as a turnkey corporate website.

Read also

• Request form on a website: how to raise conversion without tricks
• Microcopy on a website: buttons, hints, messages
• Website accessibility for all users: the basics and WCAG