Дизайн экрана каталога товаров мобильного приложения

Дизайн каталога товаров мобильного приложения: где теряются заказы

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

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

Отдельная история — перегруженная выдача. Плитка с шестью признаками на карточку выглядит убедительно на макете, но на реальном ассортименте различия между позициями теряются, а цену и наличие приходится искать вглубь. Человек не понимает, чем один товар отличается от другого, и откладывает выбор.

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

Что меняет переработка навигации и карточек

Переработка каталога начинается не с плитки товаров, а с карты пути к покупке. Мы размечаем каждый переход — категория, фильтры, карточка, выбор варианта, корзина — и видим точки отвала: возврат назад со сброшенными фильтрами, потерянный контекст поиска, уход в другое приложение для сравнения. Позиции и жесты сверяем с Apple Human Interface Guidelines — привычные элементы не приходится объяснять заново.

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

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

Глубина просмотра категорий растёт, когда вложенность читается с первого взгляда: понятные названия, счётчик товаров, переход в соседний раздел из карточки. Повторные заходы держатся на предсказуемости — найдя нужное без поиска, человек возвращается туда же. Заодно падает нагрузка на поддержку: обращения «не могу найти раздел» уходят.

Форматы выдачи: список, плитка, лента, гибрид

Формат выдачи — решение о плотности, а не об оформлении: сколько позиций на экране видит человек и сколько касаний нужно до карточки. Список умещает 6–8 наименований с названием, ценой и кнопкой действия, плитка — 4–6 с крупным фото, лента — 2–3 с изображением во всю ширину.

Формат выбирают по ассортименту и сценарию покупки, а не по вкусу. Каталог, где товар сравнивают по характеристикам, живёт в списке; визуальные категории — одежда, мебель, декор — в плитке или ленте. Ориентир простой: доля позиций с качественным фото и частота сравнения по параметрам.

Чем режимы отличаются

Гибрид снимает главный компромисс: режим подставляется по типу категории, а выбор клиента сохраняется между сессиями — при переключении он не теряет место в выдаче. Плотность проверяем на реальном ассортименте: доля переходов в карточку и глубина прокрутки важнее красоты макета.

Этапы работы над интерфейсом витрины

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

1. Разбор текущей витрины. Сводим данные о переходах, отказах и возвратах в каталог, находим, где теряется доля покупателей, дошедших до оформления заказа, и какие разделы они не находят вообще.
2. Схема навигации. Раскладываем дерево категорий, фильтров и поиска до конкретных экранов, проверяем глубину вложенности и то, попадает ли популярный товар в первый экран списка.
3. Интерактивный прототип. Собираем кликабельный сценарий на реальном ассортименте — с пустыми состояниями, долгой загрузкой и товаром без остатка, а не только с идеальными карточками.
4. Проверка сценариев. Прогоняем типовые пути: поиск по артикулу, подбор по фильтрам, сравнение и возврат к списку. Правки вносим до передачи, пока они стоят правки в схеме, а не в коде.
5. Передача в разработку. Отдаём экраны с состояниями элементов, правилами сетки и текстами, чтобы сборка шла без догадок и лишних уточнений.
6. Сопровождение сборки. Сверяем готовое приложение с прототипом на промежуточных сборках и закрываем расхождения по мере их появления.

Опишите задачу — вернёмся с оценкой и планом по этапам.

Макеты, состояния экранов и правила вёрстки

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

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

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

Кейс: витрина приложения до и после переработки

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

Что изменили

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

Метрики до и после

Доля сессий с переходом в карточку выросла с 41% до 63% — сработали цена и наличие в первом экране. Возвраты из карточки в список с сохранённой выборкой сократили повторные проходы по фильтрам: доля брошенных корзин упала с 78% до 61% на той же аудитории и том же ассортименте. Обращения в поддержку с жалобами на навигацию снизились втрое, и это разгрузило первую линию сильнее, чем любая правка текстов подсказок. Сравнение шло на равных долях трафика, чтобы сезонность не искажала картину.

Что делать, если витрина уже собрана на готовом шаблоне?

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

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

Жёсткие ограничения начинаются там, где нужна другая схема данных: варианты товара внутри одной карточки, зависимые характеристики, сравнение позиций, персональные подборки, нестандартная логика подгрузки и переходов. Такая правка упирается не в оформление, а в структуру экранов — шаблон не умеет хранить и показывать эти связи. Обход настройками даёт костыли, которые рассыпаются при первом обновлении платформы.

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

Технические сомнения перед началом работ

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

Можно ли выпускать изменения частями?

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

Останется ли поддержка у своей команды?

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

Обсудим задачу: что прислать для оценки

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

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

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