Mobile-first в 2026: почему десктопный подход убивает конверсию

Откройте аналитику почти любого продукта за последние два года — доля мобильного трафика давно перевалила за половину, а у многих ниш стремится к 80%. А теперь откройте Figma того же продукта. Артборды 1440. Десктопные макеты в центре, мобильные — где-то сбоку, нарисованы по остаточному принципу, часто после согласования «большой версии».

Это и есть главная причина, почему конверсия проседает там, где её ждут. Не «плохой копирайтинг», не «дорогой трафик», не «сложный продукт». Просто дизайн родился на экране, которым пользуется меньшинство, а потом его попытались ужать.

Mobile-first в 2026 — это уже не модный термин из старой статьи Люка Вроблевски. Это рабочая гигиена. И если команда всё ещё проектирует от десктопа, она теряет деньги в каждом релизе — просто не всегда видит где.

## Почему «адаптируем потом» больше не работает

Раньше схема «нарисуем десктоп, потом подгоним под мобайл» хоть как-то держалась: пользователь на телефоне был готов терпеть, потому что альтернативы не было. Сейчас альтернатива есть всегда — соседнее приложение, конкурент в выдаче, вкладка которую закрыли и не вернулись.

Что ломается, когда дизайн идёт от десктопа:

• Иерархия рассыпается. На 1440 у вас три колонки и красивая сетка. На 375 это превращается в стопку из 14 блоков, и пользователь не понимает, что здесь главное.
• CTA уезжают вниз. На большом экране кнопка «в первом экране». На телефоне до неё четыре свайпа и баннер cookies.
• Формы становятся пыткой. Поля, рассчитанные на мышь и таб, на телефоне требуют постоянного зума и переключения клавиатур.
• Контент дублируется. Десктопные «фичи-блоки» и «преимущества» на мобайле читаются как четыре одинаковых экрана подряд, и пользователь отваливается на втором.

В метриках это видно не как «UX-проблема», а как тихое снижение конверсии на мобайле при стабильном десктопе. Команда смотрит на средние цифры и не замечает, что половина воронки протекает.

## Сценарий, по которому это обычно происходит

Так выглядит типичный путь к десктопному дизайну, который потом «адаптировали»:

1. Продакт пишет ТЗ и прикладывает референсы — все десктопные.
2. Дизайнер открывает Figma, ставит фрейм Desktop 1440, потому что так удобнее раскладывать макет на ревью.
3. Стейкхолдеры смотрят презентацию с ноутбука, согласовывают «большую версию».
4. За день до сдачи дизайнер рисует мобильную версию, ужимая блоки.
5. Разработка верстает «как на макете», тестирует на ноутбуке.
6. Релиз. Через месяц аналитик замечает, что мобильная конверсия ниже ожидаемой. Никто не связывает это с процессом.

Проблема не в людях. Проблема в том, что инструменты, привычки и формат ревью заточены под большой экран.

## Первый сдвиг: меняем точку входа в макет

Самое дешёвое изменение, которое даёт эффект сразу — перестать открывать Figma на фрейме 1440.

### Что делать на практике

• Заводите стартовый фрейм 375 или 390. Дизайн начинается с него, даже если продукт «в основном десктопный».
• Десктоп рисуется как расширение мобильной версии, а не наоборот. Это сложнее, но именно так выясняется реальная иерархия.
• На ревью первым показывайте мобильный экран. Если стейкхолдер хочет «увидеть как на большом» — показывайте после.
• Прототип в Figma тестируйте с телефона через Mirror/превью, а не в окне браузера.

### Антипаттерны, которые стоит ловить на себе

• «Нарисую как удобно, потом адаптирую» — обычно «потом» наступает за два часа до дедлайна.
• «У нас B2B, у нас все на ноутбуках» — проверьте аналитику, а не интуицию. Даже в B2B мобильный трафик на лендингах и в письмах огромен.
• «Мобайл — это просто узкая колонка» — нет, это другой контекст: одна рука, плохой свет, плохой интернет, прерывания.

## Контент-приоритизация: что показать на 375 пикселях

Когда экран узкий, нельзя «впихнуть всё». Приходится решать, что главное. И это полезное упражнение, потому что на десктопе вы это решение просто откладывали — места хватало, чтобы спрятать конфликт под красивой сеткой.

### Метод «один экран — одна задача»

На каждый видимый экран мобильного скролла должна приходиться одна понятная задача пользователя. Не «расскажем о продукте, покажем отзывы, дадим CTA и упомянем интеграции». А: первый экран — понять, что это и нажать. Второй — снять главное возражение. Третий — увидеть социальное доказательство. И так далее.

### Вопросы для ревью мобильного макета

• Что пользователь видит в первые 2 секунды без скролла?
• Где находится главный CTA — он в зоне большого пальца?
• Сколько экранов до основного действия? Можно ли убрать хотя бы один?
• Какие блоки можно удалить совсем, а не «сжать»?
• Что произойдёт, если у пользователя медленный интернет и шрифты ещё не загрузились?

Короткий итог раздела: mobile-first — это не про размер артборда. Это про то, кто принимает решения о приоритете контента — узкий экран или широкая привычка команды.

## Второй сдвиг: диагностика существующего продукта

Если макет уже в проде и переделать всё с нуля нельзя, начинать надо не с редизайна, а с честной диагностики. Цель — понять, где именно мобильный пользователь спотыкается, и расставить приоритеты, а не переписывать всю сетку.

### Как провести быструю мобильную диагностику за полдня

1. Откройте продукт на реальном телефоне, не в DevTools. DevTools врёт про скорость, тач-таргеты и поведение клавиатуры.
2. Пройдите ключевой флоу одной рукой, держа телефон как в метро — большим пальцем правой руки. Зафиксируйте каждое место, где приходится перехватывать.
3. Включите режим медленного 3G и пройдите тот же флоу заново. Что грузится последним? Что прыгает при загрузке?
4. Запишите экран. Потом пересмотрите запись на скорости 2x — лишние шаги и мусор становятся очевидными.
5. Сделайте то же самое на маленьком Android за 15 тысяч рублей, а не только на новом iPhone. Это два разных продукта.

### Что искать в аналитике параллельно

• Разница в конверсии desktop vs mobile по тому же сценарию. Если разрыв больше, чем «нормальная» разница по индустрии — это не «мобильные пользователи просто хуже конвертят», это ваша вина.
• Drop-off на конкретных шагах формы. Часто проседает один экран — поле «дата рождения» или капча.
• Rage taps и быстрые возвраты назад. Если есть инструмент сессий — пересмотрите 10 записей подряд, не выбирая «удобные».
• Доля пользователей, которые делают зум. Это прямой сигнал, что шрифты или тач-таргеты не подходят.

## Типичные ошибки, которые легко поймать на ревью

Эти вещи всплывают почти в каждом мобильном макете, который рисовали «после десктопа». Их стоит проверять механически, как чеклист безопасности.

### Тач-таргеты и зона большого пальца

• Кнопки меньше 44 пикселей по короткой стороне. Палец не мышь, точность ниже.
• Два кликабельных элемента впритык — пользователь промахивается и тыкает не туда.
• Главный CTA вверху экрана, в зоне, до которой большой палец не дотягивается без перехвата.
• Деструктивное действие («удалить», «отписаться») рядом с основным — на десктопе это просто неаккуратно, на мобайле это баг.

### Формы

• Поле телефона без inputmode="tel" — открывается обычная клавиатура.
• Поля email с автокапитализацией первой буквы.
• Лейблы только в плейсхолдере — после ввода непонятно, что это за поле.
• Один длинный экран формы вместо разбиения на шаги. На десктопе скролл дешёвый, на мобайле — нет.
• Кнопка «Отправить», которую перекрывает поднявшаяся клавиатура.

### Навигация и шапка

• Sticky-хедер высотой 80 пикселей, который съедает треть экрана.
• Бургер-меню, в котором спрятаны ключевые разделы, по которым реально ходят.
• Хлебные крошки, перенесённые с десктопа, в которых на мобайле помещается только «...».

### Контент

• Карточки с горизонтальным скроллом без визуального намёка, что они скроллятся.
• Модалки на весь экран без очевидной кнопки закрытия.
• Картинки фиксированной ширины, которые на узком экране уезжают за край и ломают вёрстку.
• Текст в две колонки, который на мобайле превращается в кашу.

## Как встроить mobile-first в рабочий процесс команды

Личная дисциплина дизайнера не спасёт, если процесс вокруг продолжает работать по-старому. Нужно поменять несколько точек, в которых принимаются решения.

### На уровне постановки задачи

• В шаблон ТЗ добавьте обязательное поле «как это выглядит на 375». Без него задача не берётся в работу.
• Референсы прикладываются парой: десктоп и мобайл. Если мобильного нет — это знак, что фичу ещё не додумали.
• В definition of done пропишите проверку на реальном устройстве, а не «на ноутбуке в Chrome».

### На уровне ревью макетов

• Презентация всегда открывается с мобильного фрейма. Если стейкхолдер просит «покажи на большом» — это происходит во второй половине встречи.
• Прототип шарится ссылкой, которую все участники открывают с телефона до начала созвона.
• Дизайн-критика идёт по чеклисту тач-таргетов, форм и зоны большого пальца, а не по «нравится / не нравится».

### На уровне разработки и QA

• Тестовые сборки прогоняются на «худшем разумном» устройстве из вашей аналитики, а не на флагмане разработчика.
• В баг-репортах появляется отдельный тег mobile-critical для проблем, которые на десктопе невидимы.
• Lighthouse / Web Vitals для мобильной версии висит на дашборде команды, а не открывается раз в квартал.

### Если в работе AI-инструменты и MCP-интеграции с Figma

Здесь главный риск — генерация «по дефолту в десктопном виде». Модель, которой не задали контекст, выдаст лендинг 1440 с тремя колонками фич. Поэтому:

• В системном промпте или правилах проекта явно указывайте, что стартовая ширина — мобильная.
• Сгенерированный макет всегда проверяйте руками на узком фрейме и реальном устройстве, а не только на превью.
• Не доверяйте AI решение о приоритете контента — это всё ещё работа дизайнера и продакта. Инструмент хорошо ускоряет рутину, но плохо отличает «главное» от «важное».

Короткий итог раздела: mobile-first внедряется не одним макетом, а сдвигом в трёх местах — как ставится задача, как проходит ревью и на чём тестируют. Уберите хотя бы одну из этих точек — и через пару спринтов команда снова рисует «как удобно на ноутбуке».

## Продвинутые сценарии, где mobile-first ломается даже у опытных команд

Базовые правила тач-таргетов и форм усваиваются за пару спринтов. Дальше начинается зона, где команда с хорошим намерением всё равно делает десктопный продукт — просто потому, что сценарии нестандартные и для них нет готового шаблона.

### Сложные таблицы и дашборды

Самое больное место. Аналитика, CRM, админки — это контент, который на десктопе живёт в виде широкой таблицы с десятью колонками. На мобайле эта таблица превращается либо в горизонтальный скролл, в котором теряется заголовок строки, либо в нечитаемое сжатие.

Рабочие подходы:

• Превратить строку таблицы в карточку: ключевое значение крупно, остальные поля парами «лейбл — значение» снизу.
• Оставить 1–2 главные колонки видимыми, остальные открывать по тапу на строку.
• На мобайле показывать не «всё, что есть», а тот срез, ради которого пользователь вообще зашёл с телефона. Сценарий «глубокая аналитика на ходу» обычно фейковый — на ходу смотрят сводку.

### Мультишаговые процессы и онбординг

Регистрация, KYC, оформление заказа с доставкой и оплатой — на десктопе помещаются на один длинный экран. На мобайле это всегда воронка с потерями.

• Один шаг — одна цель. Не «введите данные и выберите тариф», а сначала данные, потом тариф.
• Прогресс-индикатор сверху, но компактный. Большая шкала «Шаг 2 из 7» отпугивает сильнее, чем сам факт семи шагов.
• Кнопка «назад» обязательна и не должна совпадать с системным жестом возврата браузера.
• Сохранение состояния между шагами — на мобайле сессия рвётся постоянно: звонок, переключение, упавшая сеть.

### Жесты, которые конфликтуют с системой

Свайп влево для удаления, pull-to-refresh, длинный тап. Каждый из них уже занят либо браузером, либо ОС. Если ваш свайп влево по карточке мешает свайпу «назад» — пользователь раздражается и не понимает, на кого.

Перед тем как ставить жест, проверьте: не перекрывает ли он системный, есть ли видимая альтернатива (кнопка) для тех, кто жест не нашёл, понятен ли он без обучающего экрана.

## Как проверять качество, а не «вроде нормально»

Глаз дизайнера привыкает к макету за десять минут и перестаёт замечать проблемы. Нужны внешние процедуры.

### Чеклист перед отдачей макета в разработку

• Все экраны открыты во фрейме 360–390 пикселей, не только в 1440.
• Проверено на реальном устройстве, а не только в превью Figma.
• Длинные тексты заменены на «худший разумный» вариант: имя в 40 символов, цена в шесть знаков, заголовок в три строки.
• Пустые состояния, состояния загрузки и ошибки нарисованы, а не подразумеваются.
• Клавиатура поднята — основной CTA всё ещё доступен.
• Свайпы и жесты не конфликтуют с системными.
• Контраст текста проверен на ярком солнце, а не на студийном мониторе.

### Вопросы для дизайн-ревью

• Какая задача пользователя на этом экране в одну строку?
• Что он видит первым, попав на экран сверху вниз?
• Сколько тапов до основного действия?
• Что произойдёт, если связь оборвётся посередине?
• Какие два элемента ближе всего и легко ли промахнуться?

Если на любой вопрос нет внятного ответа — макет ещё не готов.

## Как объяснять решение команде и стейкхолдерам

Mobile-first часто отвергают не потому, что не верят в цифры, а потому, что десктопный макет красивее на презентации. С этим нужно работать отдельно.

### Что не работает

• «Так делают все нормальные продукты». Аргумент авторитета бесит и не убеждает.
• «Гугл сказал». Особенно если стейкхолдер не из digital и не понимает, при чём тут поисковая выдача.
• Показ только мобильного макета без десктопного. Воспринимается как «дизайнер сэкономил половину работы».

### Что работает

• Покажите долю мобильного трафика и долю мобильной выручки именно в вашем продукте. Не из обзоров, а из своей аналитики.
• Откройте текущую версию сайта на телефоне стейкхолдера прямо на встрече. Один промах пальцем по CTA убеждает сильнее презентации на двадцать слайдов.
• Сформулируйте решение как «сначала закрываем сценарий, который приносит деньги, потом расширяем», а не «отказываемся от десктопа». Это снимает страх потерь.
• Покажите оба макета рядом и объясните, что десктоп получается из мобильного добавлением, а не урезанием. Команде становится понятно, что работы не меньше, а порядок другой.

Итог раздела: продвинутые сценарии требуют не больше правил, а больше дисциплины — проверять руками на устройстве, говорить с командой на языке метрик и денег, и не путать «выглядит сложно» с «работает плохо».

## Анти-паттерны, которые видно сразу

Эти ошибки повторяются из проекта в проект. Если хотя бы одна узнаётся — это уже точка приложения сил.

### «Сделаем мобильный потом»

Самый частый и самый дорогой паттерн. Команда рисует десктоп, согласует с заказчиком, отдаёт в разработку, и только на этапе вёрстки кто-то спрашивает: «А как это будет на телефоне?». Дальше начинается перерисовка половины компонентов, споры о приоритете блоков и компромиссы, которые видно невооружённым глазом.

Лечится одним правилом на уровне процесса: мобильный макет защищается раньше десктопного, а не после.

### Десктоп, сжатый до 360 пикселей

Карточка в три колонки превращается в одну, шрифт уменьшается на два пункта, отступы режутся пополам — и все довольны, потому что «адаптив есть». На деле это нечитаемая стена контента, по которой невозможно тапать.

Признак: на мобильной версии видны все те же блоки, что на десктопе, только мельче. Если убрать с мобайла было нечего — десктоп переусложнён.

### Меню-гамбургер вместо навигации

Гамбургер удобен дизайнеру: прячет всё, что не влезло. Но клик по нему — это лишний шаг и снижение использования всех скрытых разделов. Если у вас три-четыре ключевых раздела, они должны быть видны: нижняя панель, таб-бар, сегмент-контрол. Гамбургер оправдан только когда разделов реально много и они вторичны.

### Модалки на полэкрана с крестиком 16 на 16

Закрыть нельзя, проскроллить нельзя, форма внутри не помещается с поднятой клавиатурой. Если модалка занимает больше 70% высоты — это уже не модалка, а отдельный экран, и оформлять её надо как экран, с полноценным заголовком и кнопкой назад.

### Тосты и уведомления поверх CTA

Подтверждение «сохранено» появляется ровно там, где пользователь собирался тапнуть «продолжить». На десктопе курсор замирает, на мобайле палец уже в воздухе. Промах гарантирован.

### Бесконечная лента без якорей

Скролл без секций, без дат, без возможности понять, где ты находишься. Через минуту пользователь не помнит, видел ли он уже этот товар, и не может вернуться к месту, где остановился.

## Финальный чеклист перед запуском

Не для дизайн-ревью, а для момента, когда продукт уходит в прод.

• Открыли продукт на старом Android с медленным интернетом, а не только на свежем iPhone в офисном Wi-Fi.
• Проверили основной сценарий одной рукой, держа телефон большим пальцем.
• Прошли воронку с реальной клавиатурой и реальной автоподстановкой, включая ошибку валидации.
• Проверили, что происходит при входящем звонке посреди оформления.
• Открыли страницу через шеринг из мессенджера — превью, заголовок, первый экран без обрезаний.
• Проверили в тёмной теме, если она поддерживается системно.
• Прошли весь путь без звука — видео и анимации не должны нести смысл, который теряется без аудио.
• Замерили вес главной страницы и время до интерактивности на 3G-профиле в DevTools.

## Вопросы для продуктового ревью

Не дизайнерские, а продуктовые. Их полезно задавать на встречах, где обсуждается не макет, а решение.

• Какой процент аудитории мы реально обслуживаем по этому сценарию на мобайле — а не по факту захода?
• Где в воронке мы теряем именно мобильных пользователей сильнее, чем десктопных?
• Что из мобильного опыта мы откладываем «на потом», и сколько это «потом» уже длится?
• Какие решения в продукте приняты в логике десктопа и просто перенесены вниз без пересмотра?
• Если бы у нас была только мобильная версия, что бы мы выкинули из текущего скоупа?

Последний вопрос самый полезный. Он отсекает фичи, которые существуют по инерции и не выдерживают проверки приоритетом.

## Короткий итог

Mobile-first в 2026 — это не про «сначала нарисовать узкий макет». Это про привычку начинать любое продуктовое решение с самого ограниченного контекста использования: маленький экран, плохая сеть, одна рука, отвлечённое внимание, пять секунд на принятие решения. Всё, что выживает в этих условиях, потом легко расширяется до десктопа. Всё, что спроектировано наоборот, на мобайле ломается и тянет за собой конверсию.

Десктопный подход не плох сам по себе. Он плох как стартовая точка, потому что прощает слишком многое — и эти прощения оплачивает пользователь телефоном в метро.