Выбор вариантов товара (размер, цвет): как не запутать покупателя

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

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

Почему выбор варианта решает судьбу заказа

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

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

Что стоит на кону

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

Свойство или торговое предложение

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

Правило простое: если от вариации зависят цена, остаток или отдельный учёт на складе — это торговое предложение. Размер и цвет почти всегда сюда попадают, потому что «синий 44» и «чёрный 46» — это разные складские позиции с разным наличием. Свойством же оставляют то, что описывает товар целиком и не влияет на учёт, — материал, бренд, сезон.

Как устроены SKU в 1С-Битрикс

В 1С-Битрикс торговые предложения — это отдельный инфоблок, подчинённый инфоблоку товаров. Каждый товар-родитель может иметь набор предложений, а сами вариации задаются свойствами торгового предложения (например, свойство «Размер» и свойство «Цвет» типа «список» или «привязка к элементу справочника»).

Ключевые сущности, которые важно понимать при проектировании:

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

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

Селектор размера и цвета: паттерны

Как именно показать выбор — вопрос не вкуса, а понятности. Разные типы вариаций требуют разных элементов управления.

• Цвет — плитки-сватчи. Показывайте сам цвет квадратиком или кружком, а не текстом. Человек выбирает глазами. Подпись «Синий» дублируется при наведении и после выбора.
• Размер — кнопки. Ряд кнопок с размерами читается быстрее выпадающего списка: всё наличие видно сразу, ничего не спрятано.
• Длинные списки — dropdown. Если значений очень много (например, диагонали или объёмы памяти), уместен выпадающий список, но с наличием у каждого пункта.
• Размерная сетка. Рядом с размерами — ссылка на таблицу соответствия, критично для одежды и обуви, чтобы снизить возвраты по размеру.

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

Наличие вариантов и матрица комбинаций

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

Механика такая: компонент отдаёт матрицу доступных предложений, и при выборе одного параметра фронтенд пересчитывает доступность остальных.

1. Показать всё, что бывает. Все размеры и цвета модели видны, включая отсутствующие в наличии.
2. Пометить отсутствующие. Нет на складе — вариант приглушён или зачёркнут с подписью «нет в наличии».
3. Гасить невозможные комбинации. Выбрали красный — размеры, которых в красном не бывает, становятся недоступны.
4. Дать подписку. На отсутствующем варианте — кнопка «сообщить о поступлении», чтобы не терять спрос.

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

Фото, цена и артикул под вариант

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

• Галерея. Выбрал «зелёный» — фото в карточке переключились на зелёный вариант, а не остались на дефолтном.
• Цена. Если у вариантов разная цена (например, большой размер дороже), она обновляется мгновенно при выборе.
• Артикул и SKU. Отображается артикул именно выбранного предложения — это и доверие, и удобство для тех, кто заказывает по коду.
• Кнопка и наличие. Текст у кнопки отражает реальный статус выбранной комбинации: «В корзину» или «Нет в наличии».

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

Как не дать покупателю ошибиться

Даже с хорошим селектором остаётся риск, что клиент закажет не тот вариант по невнимательности. Несколько приёмов сводят это к минимуму:

• Явная подсветка выбора. Выбранный размер и цвет визуально выделены — их видно с одного взгляда.
• Текстовое дублирование. Рядом с кнопкой строка «Выбрано: синий, 44» — на случай, если сватч неочевиден.
• Блокировка до выбора. Нельзя добавить в корзину, пока обязательный параметр не выбран; подсказка объясняет, что именно нужно выбрать.
• Контроль в корзине. В корзине и письме-подтверждении — полное наименование варианта с артикулом, чтобы клиент увидел, что заказал.

Много вариаций: когда становится сложно

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

Стратегии, которые спасают:

• Разнести на отдельные товары. Если между вариациями большая разница (разные модели, а не оттенки), лучше сделать отдельные карточки и связать их блоком «другие цвета».
• Вынести редкий параметр в фильтр. То, что покупатель выбирает не в карточке, а на этапе подбора, логичнее оставить в структуре данных и умном фильтре.
• Ограничить обязательный выбор. В карточке оставляют только те 1–2 параметра, между которыми клиент реально выбирает здесь и сейчас.
• Сгруппировать значения. Например, объединять близкие оттенки в семейства, чтобы не показывать 30 почти одинаковых сваток.

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

Остатки, обмен с 1С и мобильный UX

Реальное наличие по вариантам приходит на сайт из учётной системы. По протоколу CommerceML 1С выгружает торговые предложения с их артикулами и остатками по складам, а сайт сопоставляет их с существующими SKU и показывает наличие. Если сопоставление нестабильно (артикулы «плавают», предложения пересоздаются), наличие по размерам и цветам начинает врать — и весь красивый селектор теряет смысл.

Поэтому корректный выбор вариантов — это на треть UX и на две трети правильно настроенный обмен. Стабильная выгрузка остатков по складам, корректная привязка SKU и своевременное обновление — задача автоматизации, которую мы закрываем услугами автоматизации продаж и склада на 1С и автоматизации на 1С. Отдельно стоит проверить мобильный UX: на телефоне сваты и кнопки размеров должны быть достаточно крупными для пальца, а смена фото при выборе цвета — не вызывать «прыжка» вёрстки.

Скорость карточки с торговыми предложениями

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

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

Скорость важна не только для UX, но и для инфраструктуры под нагрузкой — про фундамент мы писали в статье о хостинге и инфраструктуре BitrixVM. А стабильность выкладки изменений в карточку без простоев обеспечивает грамотный CI/CD и деплой на Битрикс.

Частые ошибки выбора вариантов

• Размер и цвет сделаны свойствами товара. Нет отдельного остатка и цены по варианту — учёт и наличие ломаются.
• Недоступные варианты спрятаны. Покупатель думает, что ассортимент беден, и не может подписаться на поступление.
• Невозможные комбинации не блокируются. Клиент собирает несуществующий заказ и упирается в ошибку на кнопке.
• Фото не меняется под цвет. Растут возвраты «пришло не то, что на картинке».
• Кнопка неактивна без объяснения. Клиент не понимает, что нужно выбрать размер, и уходит.
• Слишком много вариаций в карточке. Комбинаторный лабиринт вместо простого выбора.
• Наличие врёт из-за обмена. SKU нестабильно сопоставлены с 1С, остатки по размерам неверны.
• Мелкие элементы на мобильном. В сваты и размеры невозможно попасть пальцем.

Чек-лист внедрения

1. Структура определена. Размер и цвет — торговые предложения; материал и бренд — свойства товара.
2. Селектор понятен. Цвет — сваты, размер — кнопки, всё наличие видно сразу, есть размерная сетка.
3. Наличие честное. Отсутствующие варианты помечены, невозможные комбинации блокируются по матрице.
4. Зависимости обновляются. Фото, цена и артикул меняются при выборе варианта.
5. Защита от ошибки. Выбор подсвечен и продублирован текстом, добавление заблокировано до выбора.
6. Обмен настроен. SKU и остатки по складам стабильно приходят из 1С по CommerceML.
7. Мобильный проверен. Элементы крупные, смена фото без «прыжка» вёрстки.
8. Скорость под контролем. Компонент карточки кэшируется, мёртвые вариации вычищены.

Вывод

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

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