В этом кейсе показано, как из идеи торговой площадки создаётся связанная система для покупателя, продавца и администратора – от каталога и карточки товара до раздельной доставки, выплат, споров и аналитики.
KRAMORA объединяет покупателя, независимых продавцов и команду маркетплейса в одном связанном интерфейсе.
Главная сложность такой разработки – не нарисовать каталог. Нужно заранее определить, кто отвечает за товар, оплату, доставку, возврат и выплату, а затем перевести эту логику в понятные экраны.
Почему маркетплейс нельзя проектировать как обычный интернет-магазин
В интернет-магазине один владелец управляет товаром, оплатой и отправкой. В маркетплейсе одна покупка запускает несколько параллельных процессов – и каждый должен быть понятен пользователю и управляем из кабинета.
Обычный магазин
- Один продавец и единые правила товара.
- Одна логика доставки и оплаты.
- Возврат обрабатывает одна компания.
- Каталогом управляет одна команда.
Маркетплейс KRAMORA
- Много продавцов, условий и складских остатков.
- Разделение одного заказа на отправления.
- Комиссии, удержания и выплаты продавцам.
- Модерация товаров, споры и контроль качества.
Три интерфейса работают как одна система
Покупатель
Ищет товары, сравнивает продавцов, собирает общую корзину, оплачивает, отслеживает отправления и открывает обращение при проблеме.
Продавец
Публикует ассортимент, обрабатывает свою часть заказа, передаёт данные доставки, отвечает покупателю и контролирует выплаты.
Администратор
Проверяет продавцов и товары, управляет комиссиями, платежами, категориями, спорами, ограничениями и качеством площадки.
Главная и каталог помогают начать выбор без перегрузки
Главная объясняет масштаб площадки и ведёт в популярные сценарии. Каталог превращает большой ассортимент в управляемый выбор через категории, фильтры, сортировку и понятные карточки.
Все иллюстрации кейса открываются по нажатию в исходном размере.
Карточка товара отделена от витрины продавца, но связана с ней
Покупателю нужно оценить не только характеристики товара, но и условия конкретного продавца. Поэтому товарная информация, варианты покупки, доставка, гарантии и репутация магазина собираются в единый сценарий.
Один платёж – несколько продавцов, отправлений и статусов
Корзина должна оставаться простой для покупателя, хотя внутри заказ делится по продавцам. В интерфейсе заранее показаны отдельные условия доставки, подытоги и ответственность каждой стороны.
Кабинет покупателя связывает заказы, обращения и повторные покупки
Интерфейс не заканчивается после оплаты. Пользователь должен увидеть каждую часть заказа, отследить доставку, скачать документы, обратиться к продавцу или открыть возврат – без поиска нужной функции по всему сайту.
Каждое действие имеет владельца, событие и следующий шаг
До отрисовки экранов фиксируется жизненный цикл заказа. Это предотвращает типичные разрывы – оплату без назначения продавцу, отправление без связи с заказом или возврат без понятного статуса денег.
Продавец управляет бизнесом, а не заполняет бесконечные формы
Кабинет объединяет задачи на сегодня, товары, заказы, остатки, цены, сообщения, документы, финансовый баланс и аналитику. Добавление товара строится по этапам, чтобы снизить количество ошибок при публикации.
Администратор видит не страницы, а состояние всей площадки
Управляющий интерфейс собирает продавцов, товары, заказы, комиссии, платежи, обращения и риски. Его задача – быстро обнаруживать отклонения и переходить от общей цифры к конкретной операции.
Логика заказа проверена от оплаты до выплаты продавцу
Карта показывает владельца каждого шага, переходы статусов и точки, где площадка должна отправить уведомление, удержать деньги или дать пользователю действие.
Спор – не исключение, а предусмотренный сценарий
На многосторонней площадке конфликт нельзя оставлять переписке без статуса. Покупатель прикладывает доказательства, продавец отвечает, администратор видит хронологию и принимает решение по правилам.
Мобильная версия перестраивает приоритеты, а не сжимает компьютерный экран
На смартфоне первыми остаются цена, наличие, продавец, доставка и главное действие. Таблицы превращаются в карточки, фильтры открываются отдельной панелью, а вторичные элементы не перекрывают содержимое.
- Крупные зоны нажатия и фиксированное основное действие.
- Фильтры, корзина и кабинет доступны большим пальцем.
- Длинные формы разбиты на короткие последовательные шаги.
- Статусы заказа читаются без горизонтальной прокрутки.
Компоненты собираются в новые экраны без визуального хаоса
Дизайн-система нужна не ради красивого листа. Она ускоряет разработку, сохраняет одинаковое поведение статусов и помогает развивать платформу без постоянной перерисовки базовых элементов.
Результат проектирования – не набор картинок, а основа разработки
Перед передачей в разработку экраны связываются с ролями, данными, состояниями и правилами. Это уменьшает количество спорных решений уже во время программирования.
Что важно определить до оценки маркетплейса
Можно ли начать с минимальной версии и не делать сразу все экраны?
Да. Но сначала всё равно нужна общая модель ролей, заказа и денег. После этого функции делятся на первый запуск и последующие очереди без риска, что минимальная версия закроет путь к развитию.
Чем разработка маркетплейса дороже интернет-магазина?
Количество страниц – не главный фактор. Стоимость увеличивают кабинеты разных ролей, разделение заказов, комиссии и выплаты, модерация, споры, уведомления, безопасность и интеграции.
Нужен ли кабинет продавца с первого запуска?
Если продавцов больше нескольких и они самостоятельно управляют товарами или заказами – нужен. Для закрытого пилота часть операций можно временно выполнять через администратора, но это должно быть осознанным ограничением.
Можно ли использовать готовую систему управления сайтом?
Иногда готовая платформа подходит для проверки спроса. Решение зависит от правил комиссий, числа продавцов, логики доставки, выплат и необходимой нагрузки. Это определяется после проектирования ядра продукта.
Что проверяется перед запуском?
Сквозные сценарии оплаты и возврата, права ролей, расчёты, уведомления, мобильная версия, безопасность, журнал действий, ошибки интеграций и поведение системы при частичном сбое.
Есть идея маркетплейса, но пока непонятно, во что превратить её технически?
Разберём участников, путь заказа, модель дохода, обязательные интеграции и состав первого запуска. После этого станет понятно, какие интерфейсы и функции действительно нужны, а что можно отложить.