Приложение для fashion-бренда: как спроектировать размеры, остатки и возвраты
Товарная модель, размерные сетки, остатки, комплекты и возвраты: критерии решений и границы первой версии.
В одежде остаток, отказ и возврат живут на уровне конкретного сочетания модели, цвета и размера. От того, как это сочетание описано в данных, зависит, увидит ли покупатель свой размер и сможет ли он вернуть одну позицию из заказа. Разберём, какие решения по этим данным принимаются до старта разработки и какие сценарии проверяются перед релизом.
Вариант товара: что считать единицей каталога
Каталог одежды описывается тремя уровнями. Верхний уровень — модель: пальто одного кроя, под своим артикулом. Средний — цветовое исполнение этой модели. Нижний — размер, и именно на нём держатся остаток, штрихкод и цена. Эту нижнюю единицу в учёте называют SKU (единица складского учёта).
Бизнес-перевод простой. Покупатель ищет «пальто», а покупает «пальто, бежевое, 46». На уровне модели живут карточка, выдача и описание. Остаток, резерв, корзина, доставка и возврат считаются на уровне SKU. Фильтр по размеру и аналитика размерного ряда читают данные уровня SKU, а показывают результат на уровне модели.
Уровень карточки: модель или цветовое исполнение
Первое решение по данным — на каком уровне живёт карточка товара в приложении. Вариантов два, и выбор зависит от того, как заведены фотографии и как устроен каталог в учётной системе.
Уровень карточки товара: когда подходит и чем ограничен
| Уровень карточки | Когда подходит | Ограничение |
|---|---|---|
| Карточка на модель, цвет переключателем внутри | Фотографии привязаны к цвету, описание и состав общие для всех цветов | Ссылка из рекламы и поиска ведёт на модель, а не на конкретный цвет; нужен параметр цвета в адресе экрана |
| Отдельная карточка на каждое цветовое исполнение | Цвета продаются как самостоятельные товары, у них разные описания или разные цены | Каталог раздувается, в выдаче поиска один и тот же товар занимает несколько позиций |
Четыре сценария, зависящие от уровня карточки
Это решение определяет четыре сценария приложения, и переделывать их после релиза дорого.
- Поиск и фильтр по размеру. Фильтр «мой размер» отбирает модели, у которых нужный размер есть на складе. Для этого остаток должен быть виден поиску на уровне SKU.
- Избранное. Покупатель сохраняет модель или конкретный размер. Второй вариант позволяет уведомить о поступлении, первый — нет.
- Ссылки и пуш-уведомления. Переход из уведомления ведёт на цвет и размер, которые покупатель смотрел, иначе сценарий возврата к товару ломается.
- Аналитика ассортимента. Отчёт «какие размеры заканчиваются первыми» строится только там, где просмотры и заказы пишутся на уровне размера.
Что точная модель даёт бизнесу
Товарная модель выглядит внутренней технической деталью, но её последствия видит клиентский сервис и финансовая служба.
- Меньше отмен после оплаты. Отмена оплаченного заказа — это возврат платежа, разбор с покупателем и потерянный слот комплектации. Недоступная кнопка в карточке не стоит бизнесу ничего.
- Меньше возвратов из-за размера. По нашему опыту несовпадение размера — одна из основных причин возврата одежды. Таблица мерок по конкретной модели и понятный размерный ряд снимают часть таких возвратов до покупки.
- Меньше обращений в поддержку. Вопросы «есть ли мой размер», «когда привезут» и «как вернуть одну вещь из трёх» закрываются интерфейсом, если эти сценарии спроектированы.
- Данные для закупки. Подписки на поступление и просмотры недоступных размеров показывают реальный спрос на размерный ряд, а не только фактические продажи.
Размерные сетки: как спроектировать
Размерная сетка в fashion-ритейле редко бывает одна. У бренда может работать буквенная линейка для трикотажа, числовая для верхней одежды и отдельная сетка для детских товаров. Лекала у разных моделей тоже разные, поэтому мерки живут на уровне модели, а не на уровне бренда.
Своя сетка бренда и соответствия
Сетку стоит хранить справочником на стороне серверной части, а не вписывать в код приложения. Тогда новая линейка или дополнительный размер появляются без выпуска новой версии в сторах. Справочник описывает три вещи: сам размерный ряд, порядок размеров внутри ряда и соответствия другим системам обозначений, если покупатель привык к ним.
Отдельное решение — таблица мерок. Она прикладывается к модели, содержит обхваты и длины в сантиметрах и описывает, как снять мерку. Общая таблица «на весь каталог» работает против покупателя: он измеряет себя, получает один размер, а посадка у конкретной модели другая.
Размеры, которых нет в наличии
Недоступный размер остаётся в размерном ряду и помечается как недоступный. Покупатель видит, что бренд выпускает его размер, и понимает, что товар закончился. Рядом работает подписка на поступление: покупатель оставляет согласие на уведомление, приложение присылает пуш, когда размер снова появился. Скрытый размер даёт противоположный результат — покупатель решает, что на него не шьют.
Подсказка размера по истории заказов
Подсказка «вам обычно подходит 46» строится на истории заказов: приложение берёт размеры, которые покупатель оставил, и исключает те, которые он вернул с причиной «не подошёл размер». Это заранее описанное правило, а не догадка системы: соответствия между моделями задаёт мерчандайзер вручную. Подсказка включается после того, как история накопилась, — до этого момента экран работает без неё.
Остатки по складам и магазинам
Остаток меняется с каждой продажей в рознице и онлайне, поэтому расходится с показанным в приложении быстрее остальных данных. Источником истины остаётся учётная система, а приложение показывает копию. Дальнейшие решения вытекают из того, насколько свежей должна быть эта копия.
Источник истины и частота обновления
Связь с учётной системой строится двумя способами. Периодическая выгрузка по расписанию проще в поддержке, но между выгрузками данные расходятся с реальностью. Передача изменений по событию держит остаток точнее и нужна там, где ходовые размеры уходят за часы. Критерий выбора — скорость оборота и доля дефицитных размеров. Для обоих способов описывается поведение приложения, когда обмен не прошёл: показать последние данные с отметкой времени или скрыть доступность.
Остатки склада и остатки магазинов
Остаток склада интернет-магазина и остатки розничных точек — разные данные с разной точностью. В магазине товар уносят в примерочную и продают на кассе быстрее, чем обновляется учёт. Поэтому «есть в трёх магазинах рядом» требует и геолокации с остатками по точкам, и внутренней договорённости: кто отвечает за расхождение и что видит покупатель, приехавший за отложенной вещью.
Два независимых решения по остатку: показ и момент резерва
| Модель | Что видит покупатель | Чем рискует бизнес |
|---|---|---|
| Показ: точный остаток числом | «Осталось 2 штуки» | Любое расхождение с учётом заметно покупателю и подрывает доверие к остальным данным |
| Показ: признак доступности без числа | Размер доступен или помечен как недоступный | Теряется аргумент срочности: нет пометки «осталось мало» |
| Резерв: в момент оформления заказа | Размер закрепляется за ним на время оплаты | Брошенные заказы держат остаток, нужен срок снятия резерва |
| Резерв: в момент добавления в корзину | Размер удерживается, пока не истёк срок резерва | Ходовые размеры блокируются надолго, часть спроса не доходит до оплаты |
Когда размер не подтвердился
Если резерв ставится только при оформлении, остаётся окно, в котором два покупателя берут последнюю вещь. Этот сценарий проектируется заранее, а не чинится поддержкой вручную. В приложении нужны понятное сообщение о неподтверждённой позиции, частичная отмена заказа с сохранением остальных позиций и возврат денег с пересчётом доставки и скидок.
Подбор комплектов и связи между товарами
Комплект формируется двумя механиками. Ручные образы: стилист или контент-менеджер собирает комплект из конкретных SKU и привязывает его к съёмке. Автоматические рекомендации: подборка строится по признакам товара и истории просмотров. Первая механика даёт контроль над стилем и требует редакторского ресурса на каждую коллекцию, вторая ручной работы не требует, но ошибается в сочетаниях.
Что делать, когда одна позиция комплекта недоступна
Комплект живёт, пока доступны все его позиции в нужных размерах. Это ограничение механики, и правило поведения задаётся до разработки. Вариантов три: подменить недоступную позицию заранее заданной альтернативой, показать комплект без неё или убрать его из подборки. Выбор зависит от того, что важнее — целостность образа или наличие предложения на экране.
Покупка комплекта целиком требует отдельного экрана. Покупатель выбирает размер для каждой позиции, и кнопка добавления становится доступной, когда размеры выбраны везде. Если по одной позиции размеров не осталось, экран предлагает добавить остальные.
Возвраты: процесс внутри приложения
Возврат — часть покупательского пути, а не исключение из него. В одежде он происходит регулярно, и его стоит проектировать с той же тщательностью, что и оформление заказа.
Заявка на возврат и её статусы
Заявка оформляется в четыре шага: выбор заказа, отметка возвращаемых позиций, причина по каждой позиции и способ передачи товара. Дальше покупатель видит статусы: заявка принята, товар получен, проверка пройдена, деньги отправлены. Заявка при этом попадает в учётную систему, а не в почту службы поддержки, — иначе статусы расходятся с реальностью и покупатель всё равно звонит.
Причина возврата — справочник, а не свободное поле. Формулировки стоит писать так, чтобы их потом читал мерчандайзер: «мал в груди», «коротковат рукав», «цвет отличается от фото». Такие причины связываются с размерной сеткой и описанием модели, и по ним видно, что править — лекало, таблицу мерок или съёмку.
Частичный возврат и возврат комплекта
Частичный возврат чаще других сценариев вызывает споры о деньгах. Когда покупатель возвращает одну вещь из трёх, пересчитываются скидка за объём, промокод, бонусные баллы и доставка. Правило пересчёта описывается до разработки: покупатель видит сумму к возврату на экране заявки, а не узнаёт её после проверки товара.
Сценарии возврата: что нужно в приложении и в учётной системе
| Сценарий | Что нужно в приложении | Что нужно на стороне учёта |
|---|---|---|
| Возврат одной позиции из заказа | Выбор позиций, расчёт суммы к возврату, статусы заявки | Документ возврата на часть заказа, пересчёт скидок и доставки |
| Возврат позиции из купленного комплекта | Предупреждение о потере скидки за комплект и новая сумма | Правило распределения комплектной скидки по позициям |
| Обмен на другой размер | Проверка доступности нужного размера на момент заявки | Связка возврата и нового заказа, резерв размера под обмен |
| Возврат в розничном магазине сети | Код заявки для сотрудника магазина, список точек приёма | Приём возврата интернет-заказа на кассе и движение товара между складами |
Правовые рамки, влияющие на интерфейс
Продажа через приложение подчиняется дополнительным правилам по сравнению с продажей в торговом зале. Покупатель вправе отказаться от товара в любое время до его передачи и в течение семи дней после. Если информацию о порядке и сроках возврата не передали в письменной форме вместе с заказом, срок отказа — три месяца. Для приложения отсюда следуют три требования: памятка в составе документов, которые покупатель получает при доставке, фиксация даты передачи заказа и доступная из приложения политика возврата. Такое проектирование помогает учитывать требования закона, но не заменяет проверку условий юристом бренда.
Частые ошибки проектирования
По нашему опыту эти решения переделывают после релиза чаще остальных.
- Остаток на уровне модели. Карточка показывает «в наличии», покупатель выбирает размер, а его нет. Заказ отменяется после оплаты.
- Скрытые недоступные размеры. Пропадает и спрос, и данные о нём: подписок на поступление нет, закупка опирается только на продажи.
- Одна таблица мерок на весь каталог. Покупатель получает размер, который не совпадает с посадкой конкретной модели, и возвращает вещь.
- Причины возврата свободным текстом. Собрать из них отчёт нельзя, и обратная связь до мерчандайзера не доходит.
- Возврат только через поддержку. Покупатель не видит статусов, служба поддержки обрабатывает обращения вручную, срок возврата денег растёт.
- Комплекты без правила недоступности. Образ рассыпается на витрине, как только один размер заканчивается.
Что измерять после запуска
Эффект решений по данным видно по шести показателям. Заложить их в аналитику нужно до релиза, иначе сравнивать будет не с чем.
Показатели, по которым проверяется работа размеров, остатков и возвратов
| Показатель | Как считать | О чём говорит |
|---|---|---|
| Доля возвратов с причиной «не подошёл размер» | По категории и по отдельной модели | Качество таблицы мерок и описания посадки |
| Доля отмен из-за неподтверждённого остатка | Отменённые позиции к оплаченным | Свежесть обмена данными с учётной системой |
| Просмотры недоступных размеров | Открытия карточки, где нужный размер помечен недоступным | Неудовлетворённый спрос на размерный ряд |
| Отдача подписки на поступление | Заказы после уведомления к числу подписок | Окупаемость механики и точность уведомлений |
| Доля возвратов, оформленных в приложении | Заявки из приложения ко всем возвратам | Нагрузка на службу поддержки |
| Срок от заявки до возврата денег | Среднее и худшее значение по месяцу | Состояние процесса между складом, учётом и банком |
Сценарии тестирования перед релизом
Эти проверки закрывают места, где данные о размерах и остатках расходятся с интерфейсом. Список стоит отдать тестировщикам и прогонять перед каждым обновлением.
Товарная модель и размеры
- SKU заведён без фотографии и без цены — карточка не должна открываться с пустым экраном.
- Одна модель в двух цветах с разными размерными рядами.
- Размерный ряд модели изменился после того, как товар попал в избранное у покупателя.
- Фильтр «мой размер» при пустом профиле покупателя.
Остатки и резерв
- Остаток равен единице, два покупателя оформляют заказ одновременно.
- Остаток изменился между добавлением в корзину и оплатой.
- Обмен данными с учётной системой не прошёл — проверяется поведение карточки и корзины.
- Срок резерва истёк, пока покупатель был на экране оплаты.
Возвраты
- Частичный возврат заказа, на который применялся промокод.
- Частичный возврат заказа со скидкой за объём.
- Заявка на возврат за пределами срока отказа.
- Возврат заказа, частично оплаченного бонусными баллами.
Границы первой версии
Критерий отбора для первой версии простой: в ней остаётся то, без чего нельзя продать и вернуть один товар. Механики, которые требуют отдельных данных, отдельных договорённостей внутри компании или ручного редакторского ресурса, выносятся во вторую волну.
Границы первой версии приложения fashion-бренда
| Входит в первую версию | Выносится во вторую волну | Почему так |
|---|---|---|
| Каталог с выбором цвета и размера, недоступные размеры помечены | Подсказка размера по истории заказов | Подсказке нужна накопленная история покупок и возвратов |
| Остаток на уровне размера по складу интернет-магазина | Остатки розничных точек и самовывоз с примеркой | Нужны учёт по точкам и ответственный сотрудник в каждом магазине |
| Таблица мерок модели и подписка на поступление размера | Ручные образы и покупка комплекта целиком | Образы требуют редакторского ресурса на каждую коллекцию |
| Заявка на возврат с выбором позиций, причинами и статусами | Обмен на другой размер и возврат в розничном магазине | Обмен связывает возврат с новым заказом и резервом размера |
Итог: четыре решения до старта
Проектирование приложения одежды упирается в четыре решения, и принимать их лучше до дизайна экранов. Первое — на каком уровне живёт карточка товара и где считается остаток. Второе — как обновляются остатки и что приложение делает, когда обмен данными не прошёл. Третье — где хранятся размерные сетки и таблицы мерок. Четвёртое — как устроена заявка на возврат и кто пересчитывает деньги при частичном возврате.
Зафиксировать эти четыре решения письменно до старта разработки — оптимальный порядок работы: он снимает большую часть переделок после релиза. Дальше стоит пройти список сценариев тестирования по текущему каталогу и обсудить спорные места с командой, которая будет делать приложение.
Частые вопросы
Какие функции нужны в мобильном приложении магазина одежды?
Продажа одежды в приложении держится на четырёх механиках. Первая — карточка с выбором цвета и размера, где недоступные размеры видны и помечены. Вторая — остаток на уровне размера, а не модели, иначе заказы приходят на то, чего нет. Третья — подписка на поступление размера, которая возвращает покупателя в приложение. Четвёртая — заявка на возврат с выбором позиций и причин. Поиск, избранное и программа лояльности надстраиваются поверх этих механик.
Как показывать размеры, которых нет в наличии?
Недоступный размер лучше оставить в размерном ряду и пометить как недоступный, а не убирать из карточки. Покупатель видит, что бренд его размер выпускает, и понимает, что товар закончился, а не отсутствует в линейке. Рядом с таким размером ставится подписка на поступление: покупатель оставляет согласие на уведомление, приложение присылает пуш, когда размер снова появился на складе. Скрытый размер даёт обратный эффект — покупатель решает, что в его размер бренд не шьёт, и больше не возвращается.
Как связать остатки в приложении с учётной системой?
Источником истины по остаткам остаётся учётная система или склад, а приложение показывает копию этих данных. Связь строится двумя способами: периодическая выгрузка по расписанию и передача изменений по событию. Выгрузка проще и дешевле в поддержке, но между выгрузками данные устаревают. Передача по событию держит остаток точнее и нужна там, где размеры заканчиваются за часы. Выбор зависит от скорости оборота и доли дефицитных размеров. В обоих случаях нужен сценарий поведения, когда обмен данными не прошёл.
Можно ли оформить возврат товара через мобильное приложение?
Да, заявка на возврат оформляется в приложении: покупатель выбирает заказ, отмечает позиции, указывает причину и способ передачи товара. Приложение показывает статусы заявки и сроки, а деньги возвращаются на тот способ оплаты, которым был оплачен заказ. Чтобы это работало, заявка должна попадать в учётную систему, а не в почту поддержки: иначе статусы расходятся с реальностью. Порядок и сроки возврата при дистанционной продаже задаёт закон, и памятка об этом нужна прямо на экране заявки.
Чем SKU отличается от артикула товара?
Артикул обычно обозначает модель — например, пальто одного кроя. SKU — это единица учёта, на которой держатся остаток, штрихкод и цена: конкретное сочетание модели, цвета и размера. Одна модель даёт десятки SKU. Для приложения разница практическая: карточка, выдача и описание живут на уровне модели, а остаток, корзина, резерв и возврат считаются на уровне SKU. Если остаток считается по артикулу, покупатель закажет размер, которого на складе нет.
Что включить в первую версию приложения fashion-бренда?
В первой версии стоит оставить то, без чего нельзя продать и вернуть один товар: каталог с выбором цвета и размера, остаток на уровне размера по складу интернет-магазина, таблицу мерок, подписку на поступление, оформление и оплату заказа, заявку на возврат с частичным возвратом позиций. Остатки по магазинам сети, самовывоз с примеркой, ручные образы, покупку комплекта целиком и подсказку размера по истории заказов разумно вынести во вторую волну: каждая из этих механик требует отдельных данных и отдельных договорённостей внутри компании.
Источники
- Закон РФ «О защите прав потребителей», статья 26.1 «Дистанционный способ продажи товара».
- Постановление Правительства РФ от 31.12.2020 № 2463 «Правила продажи товаров по договору розничной купли-продажи».
- Нормы проверены 19 октября 2026 года.
