Mobile site for small businesses: 8 checks before losing a lead
Menu, buttons, forms and attachments: eight mobile tests to ensure visitors can contact you and that their requests actually reach your inbox.
Sur cette page8 sections
To know if your site works on a phone, opening the homepage isn't enough. Instead, try requesting a quote with a photo, calling from a service page, or finding information after returning from the form. This is where you sometimes discover that a site looking very clean in screenshots requires a lot of patience from the person trying to use it.
We often talk about "responsive" design, meaning a layout that adapts to the screen. It is necessary, but it's not the end of the job. A button can fit perfectly within the width of the phone and yet do nothing useful when tapped.
Here are the eight checks I would perform before considering the mobile journey ready.
Also, increase the text size and use the zoom. A person shouldn't lose the contact button just because they need to read larger text. Long addresses, tables, and images must stay within the screen without forcing the user to scroll the entire page from left to right.
It's not about removing your visual identity. It's about not asking the visitor for a reading effort before they've even understood what you offer.
A menu that opens correctly can still hinder the journey if the user doesn't know where they are or how to resume reading. Keep labels that speak to the customer. If someone is looking for your services, they shouldn't have to understand your internal jargon to find them.
The clickable area can be larger than the visible icon. This is useful when you want to keep a clean interface without requiring surgical precision. Le W3C specifically addresses target size and spacing ; in practice, the test should primarily confirm that a tap doesn't trigger the neighbouring link.
Also, look at fixed bars and widgets. A messaging button shouldn't cover the submit button, and a banner shouldn't take up most of the first screen.
A number written in an image or a sentence might be visible without being clickable. And an old address might survive in the footer even if the contact page has been updated. This check takes little time, but it verifies the result, not just the appearance.
If you offer several contact methods, give them explicit labels. Users should know if they are going to call, send a message, or request a quote before touching the button.
A red border isn't enough to explain an error. "Incomplete email address" helps more than "invalid input". Le W3C recommends understandable notifications for both errors and success, so that the user knows where they stand.
Then, do a full submission and check the reception. An on-screen confirmation alone doesn't prove the message reached the right inbox. Also check that you can reply to the sender's address.
Formats and sizes won't necessarily be the same as on your computer. A rejection should indicate what is accepted and what the person can do, without clearing the whole form. During the transfer, it must be clear if the file is still sending or if it has been successfully added.
Then check that the attachment is received and accessible. Displaying a filename in the form is only the start of the journey. A useful check follows this file all the way to where you will work with it.
See what becomes usable first. Can you read the service and open the menu while the rest loads? Does an animation delay an action? Does a large photo shift the contact button during loading?
Les Core Web Vitals provide metrics to understand these issues. But before the score, there is a simple question: at the moment the person decides to contact you, does the site let them?
Try another phone, a different text size, and if possible, another browser. We aren't looking for an identical copy of the designer's screen. We are looking for a journey that retains its meaning with less space and different usage conditions.
Note the location, the action, and the result: "on this service, the button is hidden by the widget" will be much more useful than "the mobile version is weird". This allows for fixing a component and repeating the same test, rather than discussing a general impression.
Another person and another screen help spot hesitations that the designer no longer notices.
A few localised flaws don't necessarily justify a redesign. You can often start with the broken link, the wrong image size, or the incomprehensible form message. If difficulties repeat throughout the journey, then we study the site's structure and priorities.
In a website creation project, I want to be able to follow a request from the first screen until its reception. The mockup allows for discussing design. This journey allows for verifying that the site actually does its job.
We often talk about "responsive" design, meaning a layout that adapts to the screen. It is necessary, but it's not the end of the job. A button can fit perfectly within the width of the phone and yet do nothing useful when tapped.
Here are the eight checks I would perform before considering the mobile journey ready.
1 Reading without searching for the right angle
On a computer, in a quiet setting, grey text on a photo might look elegant. Outside, on a less bright screen, it can become almost invisible. Test important information, button text, and form instructions, not just the main headline.Also, increase the text size and use the zoom. A person shouldn't lose the contact button just because they need to read larger text. Long addresses, tables, and images must stay within the screen without forcing the user to scroll the entire page from left to right.
It's not about removing your visual identity. It's about not asking the visitor for a reading effort before they've even understood what you offer.
2 Finding the menu and being able to exit it
Open the menu, choose a service, and go back. Try closing it too. Does the close button remain visible? Does the page return to its normal scrolling? Does the menu hide information you need?A menu that opens correctly can still hinder the journey if the user doesn't know where they are or how to resume reading. Keep labels that speak to the customer. If someone is looking for your services, they shouldn't have to understand your internal jargon to find them.
3 Tapping with a thumb, not a pointer
Two small links side-by-side might be easy to select with a mouse but annoying on a phone. Try actions with your thumb, especially those on maps, footers, and forms.The clickable area can be larger than the visible icon. This is useful when you want to keep a clean interface without requiring surgical precision. Le W3C specifically addresses target size and spacing ; in practice, the test should primarily confirm that a tap doesn't trigger the neighbouring link.
Also, look at fixed bars and widgets. A messaging button shouldn't cover the submit button, and a banner shouldn't take up most of the first screen.
4 Calling the displayed number
Actually tap the phone number. Is the correct number suggested? Does the email link launch an action suitable for the device? Is the contact option from a service page as accessible as the one on the homepage?A number written in an image or a sentence might be visible without being clickable. And an old address might survive in the footer even if the contact page has been updated. This check takes little time, but it verifies the result, not just the appearance.
If you offer several contact methods, give them explicit labels. Users should know if they are going to call, send a message, or request a quote before touching the button.
5 Sending a form with a minor error
Fill out the request like a prospect, then intentionally forget a required field. Does the site explain what to fix? Does it keep what you've already entered? Does the keyboard hide the field or button you need?A red border isn't enough to explain an error. "Incomplete email address" helps more than "invalid input". Le W3C recommends understandable notifications for both errors and success, so that the user knows where they stand.
Then, do a full submission and check the reception. An on-screen confirmation alone doesn't prove the message reached the right inbox. Also check that you can reply to the sender's address.
6 Attaching a photo taken from the phone
A tradesperson might need to see an installation. A client might want to send a plan. If your form offers an attachment, try a real photo from the phone and a document from its storage.Formats and sizes won't necessarily be the same as on your computer. A rejection should indicate what is accepted and what the person can do, without clearing the whole form. During the transfer, it must be clear if the file is still sending or if it has been successfully added.
Then check that the attachment is received and accessible. Displaying a filename in the form is only the start of the journey. A useful check follows this file all the way to where you will work with it.
7 Waiting with a less comfortable connection
Start the visit again without pre-loaded files, for example in private browsing, and with an ordinary mobile connection. This test doesn't guarantee reproducing every situation, but it already changes your perspective compared to office Wi-Fi.See what becomes usable first. Can you read the service and open the menu while the rest loads? Does an animation delay an action? Does a large photo shift the contact button during loading?
Les Core Web Vitals provide metrics to understand these issues. But before the score, there is a simple question: at the moment the person decides to contact you, does the site let them?
8 Having someone who doesn't know the site try it
Ask someone to find a service and send you a request. Don't explain the menu before the test and don't correct their path along the way. If they hesitate, that is precisely the information you are looking for.Try another phone, a different text size, and if possible, another browser. We aren't looking for an identical copy of the designer's screen. We are looking for a journey that retains its meaning with less space and different usage conditions.
Note the location, the action, and the result: "on this service, the button is hidden by the widget" will be much more useful than "the mobile version is weird". This allows for fixing a component and repeating the same test, rather than discussing a general impression.
Another person and another screen help spot hesitations that the designer no longer notices.
A few localised flaws don't necessarily justify a redesign. You can often start with the broken link, the wrong image size, or the incomprehensible form message. If difficulties repeat throughout the journey, then we study the site's structure and priorities.
In a website creation project, I want to be able to follow a request from the first screen until its reception. The mockup allows for discussing design. This journey allows for verifying that the site actually does its job.
