Phone calls, maps and the things only a phone can do

A desktop browser cannot dial a phone number, open a native maps app with directions already loaded, or send an SMS — these are device-native interactions with no desktop equivalent at all, and building them correctly is a forms-and-interaction problem, not a visual design one, because the thing being tested is whether an action fires correctly, not how it looks.

The interactions that only exist on a phone

Tap-to-call, using a correctly formatted tel: link, opens the device’s phone dialler directly with the number pre-filled — covered in the conversion context on phone-first design for trades and emergency services, and included here because getting the link itself to fire correctly is a device-interaction question distinct from the design decision to prioritise it.

Tap-for-directions, using a link to a mapping service with the business’s address encoded in the URL, opens the device’s maps application with directions ready to go — removing the step of a visitor manually typing or copying an address into their own maps app.

Tap-to-text (SMS), using an sms: link, opens the device’s messaging app pre-addressed to the business’s number, useful for a business that accepts enquiries by text as an alternative to a call.

Tap-to-email, using a mailto: link, is the oldest and most familiar of these but shares the same testing requirement as the others: confirming it actually opens the device’s configured mail app rather than assuming the markup is correct because it looks right in a code editor.

Why this is a testing problem, not a design problem

Each of these links can be visually perfect — correctly styled, correctly positioned — while still failing to fire on a real device because of a malformed URI, an incorrect number format, or an address encoding issue in a maps link. None of these failures are visible by looking at the page; they are only visible by actually tapping the link on a real phone, which is why this is fundamentally the same discipline as testing your website on real devices applied specifically to device-native actions rather than layout.

What to check for each interaction type

Interaction	What to test on a real device
Tap-to-call (tel:)	Dialler opens with the correct number pre-filled, on both a recent iPhone and a recent Android phone
Tap-for-directions	Maps application opens with the correct address, checking which app opens by default on each platform
Tap-to-text (sms:)	Messaging app opens pre-addressed to the correct number
Tap-to-email (mailto:)	Mail app opens with the correct address in the “to” field

Why maps links specifically need more care than they get

An address embedded incorrectly — wrong formatting, a typo, or a link pointing at a generic search rather than the specific business address — can silently send a visitor to the wrong location or an unhelpful generic search result rather than genuine turn-by-turn directions to the actual premises. This is a higher-stakes failure than it looks, because a visitor already travelling toward the business who gets an incorrect location has a worse experience than one who never had a maps link at all.

Structured data lets a search engine build its own click-to-call button

Beyond the links on the page itself, correctly implemented LocalBusiness structured data — the business’s phone number and address marked up in a machine-readable format — is what lets Google generate its own call and directions buttons directly inside search results and Google Maps listings, independent of anything a visitor does on the actual website. This means the phone number and address should be consistent, correctly formatted and marked up in structured data as well as present as working links on the page itself, because a mismatch between what is shown on the page and what is marked up in structured data can produce an incorrect number or address appearing directly in a search result, before a visitor ever reaches the site at all.

Photo capture through a form is a related device-native capability

Beyond calling and navigating, a mobile browser can also access the device’s camera directly through a file input configured to prefer it, letting a visitor photograph something (a leaking pipe, a damaged item) and attach it to a form in a couple of taps rather than needing to have a photo already saved. This is the device-native mechanism behind the photo-upload field covered in the conversion context on how many fields a form should have, and it deserves the same real-device testing as the call and maps links above, since a file input that works correctly in a desktop browser does not automatically confirm the camera-capture behaviour works as expected on a real phone.

A tel: link still needs to behave reasonably for a desktop visitor

Because the same page is reachable from both mobile and desktop visitors, a tel: link should not be hidden or broken for whoever reaches the site from a desktop computer — many desktop operating systems and browsers can still hand a tel: link off to a calling application (a softphone, a video-calling tool) if one is configured, and where none is available the link should still degrade to visibly readable text a visitor can note down or copy, rather than doing nothing at all when clicked.

What to do next

Test every device-native link — call, directions, text, email — on both a real iPhone and a real Android phone before launch, using the same discipline as any other form or interactive element. For the specific case of a phone-first business where the call link is the primary conversion mechanism, phone-first design for trades and emergency services covers the design side. For where this fits into a small business build generally, what a small business actually needs covers the wider scope.