UI/UX Design Basics for Marketers · Landing-page UX and mobile-first design · lesson 12 of 21 · 10 min

Mobile-first design

Most of your visitors are on phones

For traffic from social media, messaging apps and many email campaigns, mobile devices are often the majority. Mobile-first design means designing for small screens, touch input and variable connections first, then enhancing for larger screens.

Why mobile first works

Forces prioritization: one column means you must decide what matters most.
Improves performance: fewer, lighter elements.
Aligns with how search engines evaluate sites: Google uses mobile-first indexing, primarily using the mobile version of content for indexing and ranking.
Reflects real usage: in many markets, including Pakistan, the Gulf and much of the world, mobile is the main or only way many people access the internet.

Mobile design principles

| Principle | Practice | |---|---| | Thumb-friendly | Key actions reachable; large targets (at least WCAG's minimum, ideally around 44–48 px); spacing between links | | Readable | Body text around 16 px or larger; short paragraphs; sufficient contrast | | Scannable | Clear headings, bullets, accordions for detail | | Fast | Compressed images, limited scripts, avoid heavy video backgrounds | | Focused | One primary CTA; simplified navigation | | Forgiving | Easy to correct mistakes; autofill; appropriate keyboards | | Context-aware | Tap-to-call, WhatsApp links, maps, wallet payments where relevant |

Responsive layouts and breakpoints

Responsive design adapts layouts to screen width:

Mobile: single column, stacked sections, full-width buttons.
Tablet: two columns where helpful.
Desktop: multi-column layouts, side-by-side images and text.

Decide how each section transforms: a three-card row becomes a stack or a horizontal swipe; a comparison table becomes stacked cards or a scrollable table with a sticky first column.

Forms on mobile

Single column fields.
Correct input types (email, tel, number) to show the right keyboard.
Autocomplete attributes so browsers can fill details.
Minimal typing: selectors, toggles, smart defaults.
Keep the submit button visible and clearly labeled.
Show errors inline and near the field.
Allow wallet payments and local payment methods where relevant.

Mobile-specific pitfalls

Intrusive interstitials: full-screen pop-ups on arrival frustrate users and can hurt search visibility; Google has guidance against intrusive interstitials on mobile.
Sticky elements (headers, chat bubbles, cookie banners, CTA bars) stacking up and covering content.
Hover-dependent interactions that don't work on touch.
Tiny text in images (infographics that are unreadable on phones).
Horizontal scrolling caused by oversized elements.

In-app browsers

Many visitors from social platforms open links in the app's built-in browser. These can behave differently: autofill may be limited, users may not be logged in to other services, and some payment or login flows break. Test your key flows from within the major social apps your audience uses.

Testing on real devices

Emulators in browser developer tools are helpful, but test on real phones too — including a mid-range Android device on a mobile connection, which reflects many users' reality better than a flagship phone on office Wi-Fi.

Mobile QA checklist
[ ] Hero message and CTA visible quickly
[ ] Text readable without zoom
[ ] Tap targets comfortable; no accidental taps
[ ] No horizontal scrolling
[ ] Sticky elements don't cover content
[ ] Forms use correct keyboards and autofill
[ ] Works inside social in-app browsers
[ ] Acceptable load time on mobile data

Worked example: a restaurant ordering page

Before: desktop-designed menu with small text, a PDF menu link, hover-to-see prices, and a phone number that wasn't tappable.

After: mobile-first menu with categories as sticky tabs; dishes as cards with photos, prices and "Add" buttons; tap-to-call and WhatsApp buttons; an Arabic/English language switch; checkout with wallet payments and cash-on-delivery options where relevant.

Common mistakes

Designing on desktop and "shrinking" to mobile.
PDF menus or brochures as the main content.
Stacking multiple sticky elements.
Testing only on flagship phones and fast Wi-Fi.

Performance budgets for mobile

Set a simple performance budget for campaign pages — for example a maximum total page weight, a limit on third-party scripts, and a target for how quickly the main content appears on a mid-range phone. Check it before every launch. Budgets make trade-offs visible: adding a chat widget or tracking pixel then becomes a deliberate decision rather than something that quietly slows the page.

Hands-on: a mobile-first QA session with Chrome DevTools and real phones

Part 1 — in the browser (15 minutes).

Open the page in Chrome, press F12 (or Cmd + Option + I on Mac) and click the device toolbar icon (or Ctrl/Cmd + Shift + M).
Test widths of 320, 360, 390 and 430 px. Look for horizontal scrolling, clipped text, and overlapping sticky elements.
In the Network panel, choose a throttling preset such as "Slow 4G" and reload. Note when the headline and CTA appear.
In the Lighthouse panel, run a Mobile report for Performance and Accessibility, and note the top issues. Remember that lab tests are simulations; field data from real users (for example in PageSpeed Insights or Search Console's Core Web Vitals report) is what matters most.

Part 2 — on real devices (15 minutes). Use one mid-range Android phone on mobile data, and open the page from inside the social apps you advertise in. Complete the main task end to end.

Part 3 — fix the form basics. Make sure every field uses the right type and autocomplete hint so phones show the right keyboard and can autofill:

<label for="name">Full name</label>
<input id="name" name="name" autocomplete="name">

<label for="tel">Mobile number</label>
<input id="tel" name="tel" type="tel" autocomplete="tel" inputmode="tel">

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email">

<label for="postcode">Postal code</label>
<input id="postcode" name="postcode" autocomplete="postal-code">

And make sure the page scales correctly on phones — this line belongs in the page <head> (most builders add it automatically):

<meta name="viewport" content="width=device-width, initial-scale=1">

Part 4 — tap-to-call and messaging links. Use tel: links for phone numbers and official click-to-chat links for WhatsApp where your audience expects them, and test them inside in-app browsers.

MOBILE QA LOG
Device/OS | Browser or app | Width | Issue | Screenshot | Severity | Fix | Retested?

How to measure success

Compare mobile and desktop conversion rates for the same traffic source; a large, persistent gap usually signals a mobile UX problem. Track Core Web Vitals field data for mobile, form completion on mobile, and conversions from in-app browser traffic specifically, since that is where many social visitors arrive.

Summary

Design for small screens, touch and variable connections first; prioritize one column; make forms and targets thumb-friendly; avoid intrusive pop-ups and sticky clutter; test in in-app browsers and on real mid-range devices.

Video lecture: Mobile-first design

Lecture coming soon · 12 chapters · about 8 minutes. Read the full transcript below.

Mobile-first design
Why mobile-first works
The packing analogy
Mobile design principles
Responsive transformations
Mobile pitfalls
Worked example 1: restaurant ordering
Worked example 2: skincare brand (illustrative)
Watch me do it: DevTools + real phone
Fixing what the phone reveals
Common mistakes and measures
Recap and try this now

Lecture transcript

Mobile-first design

Here's a quick experiment. Look at your latest campaign report and find the split between mobile and desktop visitors. For traffic from social media and messaging apps, mobile is often the clear majority. Now, where was the landing page designed and approved? Probably on a large monitor in an office. That gap between where pages are made and where they're used is one of the most expensive blind spots in marketing. In this lecture, you'll learn why mobile-first works, the core mobile design principles, how to handle forms and in-app browsers, and a practical QA routine with DevTools and real phones.

Why mobile-first works

Mobile-first design means designing for small screens, touch input and variable connections first, then enhancing for larger screens. Why does it work? It forces prioritization, because one column means you must decide what matters most. It improves performance, because you use fewer, lighter elements. It aligns with how Google evaluates sites, since Google uses mobile-first indexing, primarily using the mobile version of content for indexing and ranking. And it reflects real usage. In many markets, including Pakistan, the Gulf and much of the world, the phone is the main or only way people get online.

The packing analogy

Here's an analogy. Packing for a weekend trip with one small bag. You can't take everything, so you choose what really matters. Then, if you're given a bigger suitcase, adding things is easy. Doing it the other way around is painful. Pack a huge suitcase first, then try to squeeze it into a small bag, and you end up sitting on it, with socks hanging out. That's desktop-first design. Mobile-first is packing the small bag first. The essentials are guaranteed. Everything else is a bonus for bigger screens.

Mobile design principles

Now the principles. Thumb-friendly: key actions within reach, with large targets, at least WCAG's minimum and ideally around forty-four to forty-eight pixels, and spacing between links. Readable: body text around sixteen pixels or larger, short paragraphs, good contrast. Scannable: clear headings, bullets and accordions for detail. Fast: compressed images, few scripts, no heavy background video. Focused: one primary call to action and simplified navigation. Forgiving: easy to correct mistakes, with autofill and the right keyboards. And context-aware: tap to call, WhatsApp links, maps and wallet payments where relevant.

Responsive transformations

Responsive layouts adapt to screen width. On mobile: one column, stacked sections, full-width buttons. On tablet: two columns where helpful. On desktop: multi-column layouts, with images and text side by side. The trick is deciding how each section transforms. A row of three cards becomes a stack, or a horizontal swipe. A comparison table becomes stacked cards, or a scrollable table with a sticky first column. Plan these transformations in your wireframes, instead of letting a page builder decide for you.

Mobile pitfalls

Watch out for mobile pitfalls. Intrusive interstitials: full-screen pop-ups on arrival frustrate people, and Google has guidance against intrusive interstitials on mobile. Sticky element pile-ups: a header, a chat bubble, a cookie banner and a call to action bar all stacked until there's barely any content visible. Hover-only interactions that don't work on touch. Tiny text inside images, like infographics nobody can read on a phone. And horizontal scrolling caused by one oversized element. Then there are in-app browsers. Links from social apps often open inside the app, where autofill, logins and some payment flows may behave differently.

Worked example 1: restaurant ordering

Worked example one, simple. A restaurant ordering page. Before: a menu designed for desktop, with small text, a PDF menu link, prices that only appear on hover, and a phone number that isn't tappable. After: a mobile-first menu with categories as sticky tabs. Dishes as cards with photos, prices and add buttons. Tap to call and WhatsApp buttons. An Arabic and English language switch. And a checkout with wallet payments and cash on delivery where relevant. Every fix removes effort for a hungry person holding a phone in one hand.

Worked example 2: skincare brand (illustrative)

Worked example two, a business scenario with illustrative numbers. A skincare brand in Jeddah sees mobile conversion at roughly a third of desktop from the same Instagram campaign. A QA session inside Instagram's in-app browser reveals three problems. The phone field is a plain text field, so people get a letter keyboard and make mistakes. A chat bubble covers the checkout button on smaller phones. And a full-screen discount pop-up appears before the product loads. The team fixes the input type, moves the chat bubble, and delays the pop-up until after the visitor has engaged. The mobile gap narrows over the following weeks.

Watch me do it: DevTools + real phone

Watch me do it. I open the page in Chrome, press F twelve, and switch on the device toolbar. I test at three hundred twenty, three hundred sixty, three hundred ninety and four hundred thirty pixels wide, looking for horizontal scrolling and overlapping sticky elements. In the network panel, I throttle to slow 4G and reload, noting when the headline and button appear. Then I run a mobile Lighthouse report for performance and accessibility. Lab tests are simulations, so I also check field data from real users in PageSpeed Insights. Finally, I pick up a mid-range Android phone on mobile data, and open the page from inside Instagram.

Fixing what the phone reveals

On that phone I complete the main task, end to end. The phone field shows a letter keyboard, so I check the code. The fix is simple: use type tel and an autocomplete hint of tel, and do the same for email, name and postal code, so the right keyboard appears and the browser can autofill. I check that tap to call uses a tel link, and that the WhatsApp button works inside the in-app browser. Every issue goes in a QA log with the device, the app, the width, a screenshot, severity, the fix, and whether it's been retested.

Common mistakes and measures

Common mistakes. Designing on desktop and shrinking to mobile. PDF menus or brochures as the main content. Stacking multiple sticky elements. Testing only on flagship phones and fast office Wi-Fi. Never testing inside social in-app browsers. And ignoring performance budgets, so every new tracking pixel or chat widget quietly slows the page. How do you measure success? Compare mobile and desktop conversion for the same traffic source. A large, persistent gap is a signal. Also track mobile Core Web Vitals field data, mobile form completion, and conversions from in-app browser traffic.

Recap and try this now

Let's recap. Design for small screens, touch and variable connections first. Prioritize one column, make targets thumb-friendly, keep text readable, and make forms easy with the right keyboards and autofill. Avoid intrusive pop-ups and sticky clutter. And test on real mid-range phones, on mobile data, inside the social apps where your ads open. Try this now. Open your key landing page on a mid-range phone using mobile data, from inside one social app. Run the mobile QA checklist, log what you find, and fix the top three issues this week.

Key takeaways

Mobile-first design forces prioritization and reflects how most social traffic arrives.
Make targets thumb-friendly, text readable and forms easy with correct keyboards and autofill.
Avoid intrusive interstitials and stacked sticky elements.
Test on real mid-range phones, mobile data and social in-app browsers.

Try it

Open your key landing page on a mid-range phone using mobile data, and from inside one social app. Run the mobile QA checklist and fix the top three issues.