Мобильная версия интернет-магазина — это не тот же сайт, что на компьютере, только меньше. Покупатель с телефона думает иначе: сессии короче, внимание разрозненное, пальцы вместо точного курсора. Если интерфейс не подстроен под эти условия, часть аудитории уйдёт к конкуренту ещё до того, как положит товар в корзину.
Почему мобильный трафик — это не «уменьшенный десктоп»
В российском e-com мобильный трафик давно перевалил за половину. Точная цифра варьирует от категории к категории и от источника к источнику, но порядок ясен: большинство посетителей заходят с телефонов. При этом конверсия на мобильных часто ниже, чем на десктопе, и разрыв растёт не из-за намерений покупателя, а из-за трения в интерфейсе.
Поведение мобильного пользователя отличается по структуре. Сессии короче — человек ждёт автобус, стоит в очереди, смотрит телевизор параллельно. Прерывания случаются чаще: уведомление, звонок, нужно ответить в мессенджере. Вернуться к тому же экрану сложнее, чем переключиться между вкладками на компьютере. Потому каждый лишний шаг — лишний шанс потерять заказ.
Жесты заменяют курсор, и это меняет всё. Свайп вниз — не скролл колёсиком, а движение пальцем по стеклу, где отпечатки и жир уменьшают точность. Пинч-зум для увеличения фотографии товара — дополнительное действие, которое многие не делают, если картинка изначально мелкая. Тап по кнопке требует попадания пальцем в область, которую человек не видит, пока не коснётся экрана.
Скорость соединения нестабильна. В метро — 3G или его отсутствие, в кафе — перегруженный Wi-Fi, дома — 5G, который внезапно падает до LTE. Страница, которая грузится три секунды на десктопе с проводным интернетом, на телефоне в тоннеле может не открыться вовсе. И покупатель не будет ждать — переключит приложение и забудет про магазин.
Мобильный пользователь не терпит: он не «зайдёт вечером с компьютера», если сейчас не смог купить. Он купит у того, у кого получилось с первого тапа.
Что ломается чаще всего: типичные проблемы мобильных магазинов
Трафик уже мобильный, но интерфейс часто остаётся десктопным по логике. Вот что ломает путь покупателя чаще всего.
Кнопки меньше рекомендуемого минимума — 44x44 пикселя по гайдлайнам Apple, 48x48 по Material Design от Google. Пальцем в такую область попасть сложно, промахи накапливают раздражение. Особенно критично это для основных действий: «Купить», «В корзину», «Перейти к оформлению». Если пользователь дважды промахнулся по «Оформить заказ» и случайно открыл футер — он не обязательно вернётся.
Формы с горизонтальной прокруткой — прямой путь к брошенной корзине. Когда поле адреса или номера карты вылезает за край экрана, покупатель не понимает, что делать. Прокрутка внутри формы конфликтует с прокруткой страницы, палец цепляет не то, и человек уходит искать магазин без этой головной боли.
Поп-апы без крестика или с крестиком за пределами экрана — классическая ловушка. На десктопе клик мимо окна закрывает его, на телефоне такого нет. Пользователь застревает в промо-акции, которую не просил, и не может вернуться к каталогу. Особенно весело, когда поп-ап блокирует кнопку «Принять cookies», без которой сайт не работает.
Фильтры в боковой панели, не переработанные для мобильного — ещё один обрыв сценария. На десктопе боковая колонка с чекбоксами уместна, на телефоне она съедает весь экран или требует горизонтальной прокрутки. Правильное решение — выпадающие списки или нижний шит (bottom sheet), который открывается поверх контента и закрывается свайпом вниз.
Изображения товаров без зума или с зумом, ломающим скролл страницы, обесценивают главное преимущество онлайн-шопинга — рассмотреть товар. Покупатель хочет увеличить фото пальцами, как в галерее телефона. Если вместо этого открывается отдельная страница, которая потом не закрывается, или зум работает только двойным тапом — часть аудитории не разберётся.
«Гамбургер» как единственная навигация скрывает категории на второй уровень. Пользователь не видит ассортимент сразу и не понимает, есть ли в магазине нужное. Эффективнее — горизонтальный скролл категорий под шапкой или видимые иконки основных разделов.
Футер с десятками ссылок превращает вертикальный скролл в бесконечность. Человек, дошедший до конца страницы, вынужден пролистывать обратно вверх, чтобы перейти в корзину или в каталог. Фиксированная нижняя панель с основными действиями решает эту проблему.
Автовоспроизведение видео — расход трафика и неожиданный звук в общественном месте. Пользователь злится не на видео, а на магазин, который втихаря потратил его мегабайты и выдал его привычку листать ленту в туалете.
Проверочный список для аудита мобильной версии
От диагностики к конкретным инструментам. Проверять нужно не «красиво ли», а «удобно ли купить».
Google Mobile-Friendly Test даёт бинарный ответ: страница пригодна для мобильных или нет. Это базовый порог, не глубокая оценка UX. Пройти его — значит не получить штраф в поиске, но не значит, что покупатели довольны.
PageSpeed Insights важнее для практики: там Core Web Vitals — конкретные метрики, которые Google использует для ранжирования. LCP (Largest Contentful Paint) показывает, как быстро появляется основной контент. INP (Interaction to Next Paint) заменяет устаревший FID и измеряет отзывчивость на взаимодействия. CLS (Cumulative Layout Shift) ловит сдвиги вёрстки, когда кнопка «Купить» уезжает под палец в момент тапа. Пороги этих метрик Google обновляет; актуальные значения нужно сверять с документацией разработчиков.
Реальные устройства дают результат, отличный от эмуляторов в Chrome DevTools. Отрисовка шрифтов, поведение скролла, задержки тача — всё это по-разному работает на iOS Safari и Android Chrome. Тестировать стоит на самом старом и медленном устройстве в доступе: если там терпимо, на новом будет хорошо.
Проверка тач-целей в DevTools Chrome показывает покрытие и перекрытия кликабельных областей. Включите режим устройства, активируйте «Show touch size» — и увидите, где элементы слишком малы или налезают друг на друга.
Два сценария стоит прогнать вручную. «Одна рука, большой палец» — держите телефон одной рукой и пытайтесь дотянуться до всех основных элементов. Зоны, недосягаемые для большого пальца без перехвата, — кандидаты на перенос. «Походка» — листайте каталог, отвлекаясь каждые 15–20 секунд. Если после возвращения не понимаете, где находитесь и что делали — навигация не выдерживает фрагментарного внимания.
Аудит мобильной версии начинается не с инструментов, а с покупки товара на своём сайте с телефона в метро в час пик.
Как формируется задача на доработку: от замечания к требованию
Найденные проблемы нужно перевести в задачи, которые исполнитель поймёт и сможет оценить. Путь: замечание -> конкретное действие пользователя -> метрика -> требование.
«Неудобно оформлять заказ» — плохое замечание. «Покупатель вводит адрес вручную, хотя подсказки по ФИАС сократили бы время в три раза» — лучше. «40 % брошенных корзин на шаге доставки, при этом 70 % из них — мобильные» — уже повод для действия. Задача: внедрить автодополнение адреса через сервис вроде DaData или аналогичный, с привязкой к мобильной клавиатуре и без горизонтальной прокрутки формы.
Приоритизация — по влиянию на конверсию против трудоёмкости. Проблема, которая задевает 80 % пользователей и решается за день — в топе. Проблема, которая мешает 5 %, но требует переписывания корзины — внизу списка. Не пытайтесь сделать всё сразу: поэтапные правки дают возможность измерить эффект каждой.
Формат приёмки фиксируется заранее. Скриншот до/после для визуальных изменений. Видео сценария — для потоков вроде оформления заказа. Метрика — для изменений, где ожидается рост или падение показателя. Без чёткого критерия «готово» доработка растягивается бесконечно.
Когда адаптивный дизайн, когда отдельное приложение
Адаптивный дизайн — один URL, один индекс поиска, одна кодовая база. Это меньше поддержки, проще SEO, быстрее запуск. Подходит, если аудитория заходит эпизодически, выбор большой, а повторные покупки редки — например, бытовая техника или мебель.
Приложение даёт push-уведомления, офлайн-корзину, глубокую интеграцию с ОС — камерой, геолокацией, биометрией. Но требует разработки под две платформы минимум, обновления через сторы, отдельную поддержку. Окупается, когда покупки повторяются: еда, одежда, косметика, автозапчасти — всё, где LTV выше и частота визитов регулярна.
PWA — промежуточный вариант. Сайт, который можно «установить» на экран телефона как иконку, работает в браузерном движке, но с некоторыми возможностями приложения: офлайн-кэш, push (ограниченно), доступ к части аппаратных функций. Проще приложения, функциональнее обычного адаптива. Подробнее о выборе между этими путями — в статье про адаптивный дизайн или приложение.
Порог внедрения приложения определяется не технологиями, а экономикой. Если средний клиент возвращается реже двух раз в год — приложение не вспомнят удалить, но и не будут открывать. Если еженедельно — push о новых поступлениях работает.
Адаптивный дизайн закрывает 80 % задач мобильной торговли. Приложение стоит делать, только когда оставшиеся 20 % — push и офлайн — критичны для бизнес-модели.
Что делать, если мобильная версия устарела
Первый вопрос: аудит отдельных страниц или полная переделка? Критерий — возраст кода и связанность с бэкендом. Если сайт на современной CMS, шаблоны отделены от логики, а проблемы визуальные — можно править поэтапно. Если код десятилетней давности, фронтент перемешан с бэкендом, а каждая правка ломает три смежных экрана — дешевле выкинуть и переписать.
Когда правок набирается на переписывание шаблонов, это уже разработка интернет-магазина заново, а не доработка вёрстки. Поэтапный редизайн несёт риск рассогласования. Новая главная, старая карточка товара, промежуточная корзина — пользователь путешествует между эпохами и теряет ориентиры. Чтобы этого избежать, выделяют изолированный сегмент — например, раздел «Распродажа» или лендинг новой коллекции — и отрабатывают на нём перед масштабированием.
Запуск на поддомене m.site.ru — устаревшая практика. Два URL для одного товара, дублирование контента, путаница в индексе, сложности с редиректами. Google давно рекомендует адаптивный дизайн с одним URL; m-dot сайты остались у крупных игроков, которые не могут от них отказаться по историческим причинам, но новым проектам этот путь не нужен.
При переработке сохраняйте URL-структуру. Каждая смена адреса — необходимость в 301-редиректе, временная просадка позиций в поиске, риск потери внешних ссылок. Если структура каталога работает, не трогайте её ради красоты. Меняйте шаблон отображения, а не путь к товару.
Если переделка неизбежна, стоит заложить полный цикл: от прототипов до тестирования на реальных устройствах. О сроках и бюджете — в разборах создания интернет-магазина с нуля и полной сметы на разработку.
Переделывать мобильную версию ради «свежего дизайна» — плохая причина. Хорошая: покупатели не могут оформить заказ, и это измеримо.
Я постоянно вижу одну и ту же картину: владелец открывает магазин на своём айфоне последней модели, всё летает, он доволен. А потом берёт телефон жены, трёхлетний Android, и понимает, что кнопка «Купить» уезжает за край экрана. Проверяйте на худшем устройстве, которое есть в семье, — не на лучшем, которое есть у вас.
— Алексей Колесников, UX-дизайнер студии «ЦЕМЕС»
Что подготовить перед заказом доработок
Перед тем как обратиться к подрядчику, соберите материалы. Это сократит сроки согласования и даст точнее оценку.
Запись экрана реального сценария покупки важнее скриншотов. Видео, где вы сами проходите путь от каталога до оплаты, покажет промахи, паузы, возвраты — всё, что не увидишь на статичном изображении.
Статистика брошенных корзин по шагам помогает расставить приоритеты. Из какого поля уходят чаще всего — адрес, доставка, оплата? Это первое, что стоит править.
Список устройств для тестирования формируйте по реальным данным, а не по принципу «все айфоны». Какие модели и версии ОС держат ваши покупатели — ответ есть в аналитике.
Доступ к метрикам скорости понадобится для сравнения до и после. PageSpeed Insights, Search Console — базовый минимум.
Формат приёмки согласуйте заранее. Что считать готовым: скриншот, видео сценария, конкретная метрика? Без чёткого критерия доработка растягивается.
Бюджет и сроки закладывайте с запасом на итерации. Первая версия редко идеальна; время на правки после тестирования нужно изначально.
Источники
- Lighthouse — аудит мобильной страницы — Google
- Core Web Vitals — Google Chrome Developers
- Human Interface Guidelines: Buttons — Apple
- WCAG 2.2 — Target Size (Minimum) — Google
Если после проверки своего магазина вы нашли проблемы, которые не знаете, как сформулировать для подрядчика — соберите записи экрана и статистику, и свяжитесь с нами. Мы поможем расставить приоритеты и оценить объём работ.
