Каталог интернет-магазина становится сложным не тогда, когда в нём
много карточек. Сложность появляется, когда пользователю нужно быстро
ориентироваться в ассортименте с разными группами и характеристиками, а
сама структура должна оставаться понятной при дальнейшем наполнении.
В проектах Mercury RUS этот вопрос встречался в разных
e-commerce-контекстах: интернет-магазин
автоаксессуаров 196.ru, «Родион
Принт», фабрика декора МАРТГРУПП и
href="/portfolio/169/">B2B-магазин «Снабженец Юг». Проекты
различаются по продуктам и аудитории, поэтому их функции нельзя
механически объединять в одну «идеальную» модель магазина. Но они дают
достаточную основу для нескольких общих принципов проектирования
каталога.
Сначала
структура ассортимента, потом интерфейс
Первый этап работы с каталогом — не рисование карточек и фильтров, а
описание самого ассортимента.
В проекте МАРТГРУПП отдельно зафиксирована задача создать структуру
каталога, которая помогает ориентироваться в широком ассортименте. Это
важная формулировка: проблема большого каталога решается прежде всего
архитектурой информации.
До интерфейсов нужно понять, какие группы товаров действительно
являются самостоятельными, где требуется вложенность и по каким
признакам пользователь различает соседние категории. Внутренняя
номенклатура компании может быть удобна для учёта, но не обязательно
подходит для публичной навигации.
Если этот этап пропустить, дальнейшие инструменты — фильтры и поиск —
начинают компенсировать слабую структуру вместо того, чтобы дополнять
её.
Категории должны
помогать сузить задачу
Хорошая категория отвечает на простой вопрос: «я стал ближе к нужному
товару или нет?»
Если после перехода пользователь получает ещё один длинный список без
понятного различия между позициями, уровень каталога не выполняет свою
функцию. Если же категорий слишком много и каждая содержит несколько
товаров, навигация становится раздробленной.
Поэтому при проектировании полезно проверять структуру на реальных
маршрутах. Пользователь начинает с общей потребности, проходит один или
несколько уровней и попадает в выборку, где уже можно различать позиции
по характеристикам. Количество уровней здесь не является целью само по
себе — важно, чтобы каждый переход уменьшал неопределённость.
Фильтр нужен
там, где категория уже не справляется
В проекте 196.ru в исходных данных
отдельно упоминается фильтр для подбора продукции. Сам факт такой
функции показывает типичную границу: когда внутри одной категории
остаётся много вариантов, пользователю нужен дополнительный инструмент
сужения выборки.
Но фильтр нельзя проектировать как перечень всех свойств товара. Его
задача — дать несколько действительно полезных критериев выбора.
Для каждого параметра стоит задавать три вопроса: использует ли его
человек при выборе; различаются ли товары по этому признаку; помогает ли
параметр сократить выборку. Если ответ отрицательный, свойство может
оставаться в карточке товара, но не обязано попадать в фильтр.
Так фильтрация становится частью сценария выбора, а не технической
демонстрацией возможностей каталога.
Поиск решает другую задачу
Фильтр помогает человеку, который знает критерии, но ещё выбирает.
Поиск нужен пользователю, который уже способен сформулировать
запрос.
В B2B-магазине «Снабженец Юг» быстрый
поиск указан в исходном описании проекта как значимый элемент работы с
ассортиментом. При этом старые формулировки о влиянии поиска на объём
заказов не следует использовать как независимо подтверждённый результат.
Для проектирования важен сам факт: в большом каталоге существует
отдельный сценарий прямого поиска товара.
Это означает, что каталог должен поддерживать как минимум два пути:
последовательную навигацию через структуру и прямой переход через поиск.
Один не заменяет другой.
Карточка товара
завершает, а не начинает выбор
Когда пользователь дошёл до конкретной позиции, большая часть
навигационной работы уже выполнена. Карточка должна дать информацию,
необходимую для следующего решения, но не обязана компенсировать слабый
каталог.
Состав карточки зависит от продукта. Исходные данные по проектам
164–169 не дают основания утверждать единый набор блоков для всех
магазинов, поэтому универсальный шаблон здесь был бы искусственным.
Вместо этого стоит разделять данные на два уровня. Первый —
характеристики, которые помогают отличать товары в каталоге и могут
участвовать в фильтрации. Второй — подробности, которые важны уже после
выбора позиции. Такое разделение делает и список товаров, и карточку
более управляемыми.
id="b2b-контекст-меняет-приоритеты-но-не-отменяет-базовую-логику">B2B-контекст
меняет приоритеты, но не отменяет базовую логику
Проекты «Родион Принт» и «Снабженец Юг» связаны с бизнес-аудиторией.
Это не означает, что любой B2B-магазин обязан иметь персональные цены,
роли, закрытый кабинет или сложную интеграцию — такие функции требуют
отдельного подтверждения и отдельного проектирования.
Но B2B-контекст усиливает требования к предсказуемости каталога.
Пользователь часто приходит не для долгого знакомства с ассортиментом, а
с предметной задачей. Поэтому названия категорий, характеристики,
фильтрация и поиск должны помогать быстро прийти к нужной группе или
позиции.
Именно поэтому «эффектный каталог» и «рабочий каталог» — не всегда
одно и то же.
Как проверить
архитектуру каталога до разработки
До начала программирования полезно собрать упрощённую модель
ассортимента и прогнать по ней несколько сценариев.
Можно взять конкретную товарную задачу и проверить: с какого раздела
начинает пользователь, на каком шаге ему нужен фильтр, может ли он
сформулировать поисковый запрос, какие характеристики видит до открытия
карточки и что требуется уже внутри карточки.
Если для ответа приходится постоянно добавлять исключения — «для этой
категории будет отдельное меню», «здесь другой фильтр», «эти товары
ищутся иначе» — возможно, проблема находится не в интерфейсе, а в
исходной классификации данных.
Каталог должен быть готов к
росту
Ещё одна проверка — что произойдёт, если ассортимент расширится.
Структура, которая хорошо работает на десятке товаров, может
разрушиться после появления новых групп. Поэтому архитектура должна
выдерживать расширение без постоянного создания новых уникальных
правил.
Это особенно важно для проектов с широким ассортиментом, как в кейсе
МАРТГРУПП. Хорошая структура не просто раскладывает текущие товары — она
задаёт систему, в которую можно добавлять новые позиции без пересборки
всей навигации.
Главное
Сложный каталог проектируется в последовательности:
структура ассортимента → категории → критерии выбора →
фильтры → поиск → карточка товара.
Если начинать с фильтров и интерфейса, команда рискует
автоматизировать неудачную классификацию. Если сначала привести в
порядок продуктовую архитектуру, фильтр и поиск становятся точными
инструментами, а не способом скрыть сложность.
Проекты Mercury RUS в e-commerce показывают именно эту практическую
ценность: хороший каталог помогает пользователю уменьшать
неопределённость на каждом шаге — от входа в раздел до конкретной
позиции.
