Mobile sites for small businesses: 8 checks before losing a lead
Menus, 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 find out if your site works on a phone, opening the home page is not 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 that looks very clean in a screenshot requires a lot of patience from someone who actually wants to use it.
We often talk about "responsive" design, meaning a layout that adapts to the screen. This is necessary, but it is not the end of the job. A button can fit perfectly within the width of the phone and do nothing useful when you press it.
Here are the eight checks I would perform before considering the mobile journey ready.
Also, increase the text size and use zoom. A person should not lose the contact button because they need to read larger text. Long addresses, tables, and images must stay within the screen without forcing the user to scroll the whole 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 have 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 client. If someone is looking for your services, they shouldn't have to understand your internal vocabulary to find them.
The clickable area can be larger than the visible icon. This is useful when you want to maintain a clean interface without requiring surgical precision. The W3C specifically addresses target size and spacing; in practice, the test should primarily confirm that one press doesn't trigger the neighbouring link.
Also look at fixed bars and widgets. A messaging button should not cover the submit button, and a banner should not occupy most of the first screen.
A number written in an image or within a sentence might be visible without being clickable. And an old address might survive in the footer even though 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. The user should know if they are going to call, send a message, or request a quote before touching the button.
A red border is not enough to explain an error. "Incomplete email address" helps more than "invalid entry". The W3C recommends understandable notifications for both errors and success, so the user knows where they stand.
Then perform a full submission and check the reception. An on-screen confirmation alone does not prove the message arrived in 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 entire form. During the transfer, it must be clear if the file is still sending or if it has been successfully added.
Then verify that the attachment is received and accessible. Displaying a filename in the form is only the start of the journey. A useful check follows that file all the way to where you will work with it.
Look at what becomes usable first. Can you read the service and open the menu while the rest arrives? Does an animation delay an action? Does a large photo shift the contact button during loading?
The 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 do it?
Try another phone, another 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 keeps 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 you to fix a component and repeat the same test, instead of discussing a general impression.
Another person and another screen help spot hesitations that the designer no longer notices.
A few localized flaws don't necessarily justify a redesign. You can often start with the broken link, the wrong image size, or the confusing form message. If difficulties repeat throughout the journey, then you 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 is actually doing its job.
We often talk about "responsive" design, meaning a layout that adapts to the screen. This is necessary, but it is not the end of the job. A button can fit perfectly within the width of the phone and do nothing useful when you press it.
Here are the eight checks I would perform before considering the mobile journey ready.
1 Read without searching for the right angle
On a computer, in a quiet environment, grey text on a photo can 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 zoom. A person should not lose the contact button because they need to read larger text. Long addresses, tables, and images must stay within the screen without forcing the user to scroll the whole 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 have even understood what you offer.
2 Find the menu then be able to exit it
Open the menu, choose a service, and go back. Also try to close it. 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 client. If someone is looking for your services, they shouldn't have to understand your internal vocabulary to find them.
3 Press with a thumb, not a pointer
Two small links side by side can be easy to select with a mouse and annoying on a phone. Try actions with your thumb, especially those in cards, the footer, and forms.The clickable area can be larger than the visible icon. This is useful when you want to maintain a clean interface without requiring surgical precision. The W3C specifically addresses target size and spacing; in practice, the test should primarily confirm that one press doesn't trigger the neighbouring link.
Also look at fixed bars and widgets. A messaging button should not cover the submit button, and a banner should not occupy most of the first screen.
4 Call the number that is displayed
Actually press the phone number. Is the correct number suggested? Does the email address link launch an action suitable for the device? Is contact from a service page as accessible as from the home page?A number written in an image or within a sentence might be visible without being clickable. And an old address might survive in the footer even though 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. The user should know if they are going to call, send a message, or request a quote before touching the button.
5 Send a form with a small error
Fill out the request like a prospect, then intentionally forget a required field. Does the site explain what to correct? Does it keep what you have already entered? Does the keyboard hide the field or button you need?A red border is not enough to explain an error. "Incomplete email address" helps more than "invalid entry". The W3C recommends understandable notifications for both errors and success, so the user knows where they stand.
Then perform a full submission and check the reception. An on-screen confirmation alone does not prove the message arrived in the right inbox. Also check that you can reply to the sender's address.
6 Attach 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 space.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 entire form. During the transfer, it must be clear if the file is still sending or if it has been successfully added.
Then verify that the attachment is received and accessible. Displaying a filename in the form is only the start of the journey. A useful check follows that file all the way to where you will work with it.
7 Wait with a less comfortable connection
Repeat the visit 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.Look at what becomes usable first. Can you read the service and open the menu while the rest arrives? Does an animation delay an action? Does a large photo shift the contact button during loading?
The 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 do it?
8 Have 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, another 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 keeps 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 you to fix a component and repeat the same test, instead of discussing a general impression.
Another person and another screen help spot hesitations that the designer no longer notices.
A few localized flaws don't necessarily justify a redesign. You can often start with the broken link, the wrong image size, or the confusing form message. If difficulties repeat throughout the journey, then you 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 is actually doing its job.
