Mobile-first design — the real Azerbaijan numbers

Mobile-first design is the phrase every studio claims and almost nobody actually practices. The truth, as visible in any Baku analytics dashboard from the last three years: a clear majority of website traffic in Azerbaijan is mobile. The truth, as visible in any Baku studio's Figma file: the designs were sketched on a 27" desktop and adapted down to mobile as an afterthought. That order is wrong. The mobile version isn't the smaller version of the desktop site — it's the canonical version, and the desktop is the expanded version. Fixing that mental model is most of the work.

The real numbers, from Baku traffic in 2026

Aggregated across the analytics of the small business websites I've audited in the last 18 months:

78–84% of all sessions are mobile, depending on category.
Restaurants, cafes, retail: 85–92% mobile.
B2B services, legal, financial: 62–72% mobile (desktop higher because of office-hours research).
E-commerce: 78–85% mobile traffic, 60–72% mobile purchases (some completion still happens on desktop).
Government and educational: 70–78% mobile.

Compare to global averages: the Azerbaijani mobile share is consistently 5–10 percentage points higher than the global average, and noticeably higher than European averages. Reasons: mobile-first internet adoption (many users never had a home desktop), the dominance of social media as a discovery channel (which routes mobile traffic to sites), and the affordability calculus of mobile vs desktop hardware in the local market.

Whatever the reasons, the practical implication is consistent: your site is, for most visitors, a mobile site that happens to also have a desktop version.

What "mobile-first design" actually means in practice

It's a much more demanding discipline than "make it responsive."

1. The first comp you design is the mobile comp, not the desktop one

This is the single biggest behavioural change. Most designers open Figma at 1440×900 and start there. Mobile-first means opening Figma at 375×812 (iPhone) or 360×800 (typical Android) and starting there.

The constraints are immediate. You can't fit five service cards across the page. You can't put six menu items horizontally. The hero image has to crop differently. The headline has to be shorter. The form has to be simpler.

These constraints aren't bugs — they're the actual viewing condition for 80% of your users. Designing on them first means designing for reality.

2. The desktop version adds, not rearranges

When you expand from mobile to tablet to desktop, you should be adding capability — more space, more parallel content, more breathing room — not reshuffling the structure into something fundamentally different.

Bad pattern: mobile shows a single CTA at the top, desktop hides it in a header and replaces it with a hero image. The two versions are doing different jobs. Mobile and desktop users see different sites.

Good pattern: mobile shows hero + CTA stacked; desktop shows hero + CTA side-by-side with a third element added. Same structure, different breadth.

3. Tap targets — real, not decorative

A finger on a phone screen is roughly 7–9mm wide. Tap targets — buttons, links, form inputs — must be at least 44×44 px (about 8mm) according to Apple's guidelines, and 48×48 px (about 9mm) according to Google's.

What this rules out:

Thin text links in body copy that are part of long sentences — hard to tap accurately.
Tiny "X" close buttons on modals.
Icon buttons without enough padding.
Dense navigation lists where adjacent items are < 12px apart.

What it requires:

Buttons with at least 12–16px vertical padding around their text.
Icon buttons with at least 8px padding on all sides of the icon glyph.
Spacing between adjacent links of at least 16px vertically.

4. Typography sized for the actual viewing condition

On a desktop screen at arm's length, 14px body text is readable. On a phone screen at the same arm's length, 14px body text is small enough that users without 20/20 vision start squinting.

Mobile body text minimums:

Primary body: 16px minimum, 17–18px preferable.
Secondary / caption: 14px minimum, never below.
UI labels in forms: 16px to prevent iOS Safari auto-zoom on focus.

Display type can be smaller proportionally on mobile, but the body text needs to stay readable.

5. Images that serve mobile bandwidth, not desktop display

A 2400px-wide hero image weighs roughly 600 KB even with good compression. The mobile user sees that as 375px-wide; they didn't need the 2400px-wide file. They paid for it in download time anyway.

Responsive images with srcset are mandatory, not optional. The mobile user gets the 750px version (about 80 KB); the desktop user gets the 2400px version. The HTML markup is one line longer; the saved bandwidth is 80–85% on mobile.

6. Touch interactions, not hover-dependent ones

Hover doesn't exist on touch screens. Any UI pattern that depends on hover — tooltips, dropdown reveals, image-hover effects — needs an equivalent tap-based behaviour on mobile.

The most common failure: a desktop navigation with hover-revealed submenus, where the mobile version is "the same navigation but smaller." On mobile, the submenus are invisible and the navigation doesn't work.

Testing — on actual devices, not just in DevTools

Chrome's responsive design mode is useful for sketching. It's not enough for testing.

The real testing requires:

An actual iPhone (any model from the last 4 years).
An actual mid-tier Android phone (a 4–6 year-old device representative of what most users actually carry).
Test on each at the start of the build, in the middle, and before launch.
Test in real-world conditions — outdoors in bright sun, on a 4G connection (not your office Wi-Fi), one-handed while walking.

Things that look fine in DevTools and break on real devices:

Custom fonts that fail to load over slow connections, causing layout shift.
Hover effects that get "stuck" on the first tap.
Forms where the keyboard covers the submit button.
Image carousels that have impossible-to-trigger swipe interactions.
Sticky headers that take up 30% of mobile screen height.

The business cost of not being mobile-first

For a Baku business with 80% mobile traffic, a site that's poorly optimised for mobile loses revenue in three measurable ways:

Bounce rate on mobile is typically 15–30 percentage points higher than on desktop for poorly-optimised sites. That's a measurable acquisition loss.
Conversion rate on mobile is typically 30–50% lower than desktop when the mobile experience is broken. Same number of visitors, fewer become customers.
SEO: Google indexes mobile-first since 2019. If your mobile site is missing content the desktop site has, Google sees the mobile version and ranks accordingly.

Reversing this — bringing a 35-Lighthouse-on-mobile site to 85 — typically lifts mobile conversion 25–40% on otherwise identical traffic. Done in three to five days of work. ROI is usually clear in the first 30 days post-launch.

The honest summary

Mobile-first design isn't a slogan. It's a sequence of design decisions made differently from the desktop-first default. Most Baku sites still get this wrong because the design tools default to desktop-sized canvases and the designers themselves are most comfortable on desktop. Breaking that pattern requires conscious discipline — designing the mobile comp first, testing on a real phone weekly, treating desktop as the optional extra rather than the default.

At Qaynaq, every site we ship is designed mobile-first by default and tested on real devices before launch. If you want a mobile audit on an existing site — including a real-device walkthrough and a prioritised fix list — write to salam@qaynaq.com with the URL.