«Матрёшка» — B2B/B2C-экосистема, спроектированная с нуля вокруг одной архитектурной идеи: продавец на платформе — это одновременно поставщик для конечных покупателей и B2B-закупщик у других продавцов площадки. Вокруг этой двойной роли выстроены три продукта: витрина для покупателя, CRM для продавца (совмещающего обе роли на одной платформе) и административная система для управления каталогом и модерацией.
Роль: Product / UX-UI дизайнер — единственный дизайнер на проекте 12 месяцев от первого экрана до передачи в разработку через Figma Dev Mode.
Продукт: CRM продавца (B2C-витрина + B2B-закупки между продавцами), B2C-Маркетплейс, Админ-панель, UI Kit
Пользователи: Продавец — и поставщик, и B2B-закупщик; конечный B2C-покупатель; администратор продукта; команда поддержки.
Задача: Определить визуальный язык, спроектировать ключевые сценарии и заложить основу масштабируемой B2B/B2C-экосистемы, на единой дизайн-системе.
Особенность: Продавец совмещает роль поставщика и B2B-закупщика внутри одной CRM. Это решение задало архитектуру всей системы.
Что сделано: 300+ экранов и состояний B2B/B2C-экосистемы. Дизайн-система — от первого компонента до общей библиотеки, обслуживающей три продукта.
Я единолично отвечала за целостность дизайн-системы на всех этапах роста продукта — от первого компонента до общей библиотеки, обслуживающей три продукта.
Работу над проектом я начала с дизайн-системы — не как с формального требования, а потому что три продукта с разной сложностью интерфейсов не могли существовать без единого языка компонентов.
Высоконагруженный продукт, сложные сценарии в условиях частичных бизнес-ограничений по финансовым и техническим причинам без потери гибкости сценариев пользователя.
Проектирование новых экранов велось по принципам атомарного дизайна на основе готовой системы компонентов, что кратно ускоряло создание новых экранов по сравнению с проектированием каждого элемента с нуля.
Срок: ~7–8 месяцев · Масштаб: 180+ уникальных экранов и состояний
8 разделов кабинета продавца (180+ экранов) — финансовая аналитика с графиками динамики, товары (создание, карточка, варианты), управление товарами с массовым импортом и экспортом, логистика, заказы, возвраты, заявки на приобретение товара под заказ (опт), чаты (заявки и возвраты), споры с историей переписки — полный операционный цикл продавца на платформе.
Изначальные названия статусов пересекались по смыслу между продавцом и покупателем внутри одной системы — путаница в коммуникации между сторонами. Проанализировала подходы конкурентов: ни один не подходил напрямую из-за специфики двусторонней роли пользователя, поэтому спроектировала собственную логику статусов с нуля.
Пересмотрела расположение и иерархию кнопок на ключевых экранах — прежнее расположение сбивало пользователя с интуитивного пути в критичных сценариях (возврат заказа, модерация заявок).
Заявки на опт оформлялись, а возвраты и заказы покупателей обсуждались через чат между продавцами и покупателями — без способа фильтрации. Инициировала (вне исходного скоупа задачи) фильтры по виду операции (заявка/заказ/возврат), внутри вида — по типу (входящие/исходящие) и статусу каждой операции прямо в интерфейсе окна.
На главном экране аналитики убрала часть показателей — не все метрики финансовой отчётности, предусмотренные в ТЗ, технически корректно отображать за произвольно выбранный период. Решение принято самостоятельно, на основе понимания ограничений источника данных, а не только визуальной композиции дашборда.
Спроектировала ввод остатков и изменение цен прямо внутри табличных строк с визуальной индикацией роста или снижения значения — паттерн, критичный для рутинной работы продавца с большим объёмом позиций.
Отдельной задачей стало объединение двух ролей внутри одного аккаунта. Пользователь может не только продавать свои товары, но и закупать товары у других продавцов на платформе. Спроектировала переключение «Продажи / Покупки»: в одном режиме кабинет работал как seller CRM, в другом — как B2B-сценарий закупки внутри той же системы.
Отдельно спроектировала экраны авторизации и ошибок — базовые, но важные сценарии, которые влияют на общее восприятие продукта. Через экран авторизации формируется первое впечатление о системе, а error-сценарии определяют продукт в нестандартных ситуациях. Важно было сохранить единый визуальный язык и сделать даже технические состояния полноценной частью визуального образа маркетплейса.
Срок: ~4 месяца · Масштаб: 70+ экранов и состояний
Участвовала в проработке решения проблемы холодного старта площадки — на начальном этапе часть товаров планировалось искусственно продвигать в блоки «Популярное» и «Рекомендуем» для раскрутки платформы.
Товар, созданный продавцом в CRM, отображается в каталоге маркетплейса в другом визуальном формате — более плотном, информационном для продавца и упрощённом для покупателя. Спроектировала единую модель данных товара в двух разных UI-паттернах под разный контекст использования, сохранив целостность данных между системами.
Логика способов доставки и оплаты менялась несколько раз по ходу проекта: часть платёжных сервисов оказалась недоступна для MVP по финансовым и техническим причинам. Переработала флоу так, чтобы доставка выбиралась отдельно на каждую позицию товара — один заказ с разными пунктами доставки для разных товаров. Решение адаптировало продукт под меняющиеся бизнес-ограничения без потери гибкости сценария для пользователя.
По объёму бизнес-логики и переменных условий, которые приходилось учитывать при проектировании:
Срок: ~2 месяца · Масштаб: 50+ экранов
Спроектировала отдельную от CRM административную систему: вход/восстановление пароля, карточки товаров, блок управления (категории товара, словари характеристик), блок модерации (варианты, цены, продавцы, магазины, вопросы и ответы, бренды, отзывы), блок заказов (чаты).
Администратор работает в отдельном встроенном админ-модуле — со своей навигацией, своими таблицами и отдельным цветовым кодированием интерфейса для мгновенной идентификации уровня доступа.
Самый сложный раздел системы. Товары маркетплейса относятся к разным категориям с принципиально разным набором характеристик. Задача требовала спроектировать архитектуру категорий и словарей, которая одновременно:
Это задача на стыке информационной архитектуры и моделирования данных — спроектированное решение обеспечивает сквозную связь между управлением справочником в админ-панели и его практическим использованием в CRM.
Продукт доведён до состояния готового к запуску MVP — три взаимосвязанных продукта (маркетплейс, CRM, админ-панель) на единой дизайн-системе, суммарно более 300 уникальных экранов и состояний, спроектированных и доведённых до реализации мной за 12 месяцев. Дальнейшее решение о запуске находится на стороне бизнеса.
