Перенос дизайна интернет-магазина на InSales для косметики в Москве: как я доработал DoctorPainS под нужный UX

GEO: Москва
Ниша: косметика / beauty, B2C
Домен: doctorpains.ru
Платформа: InSales
Тип работ: перенос дизайна из Figma + доработка UX и нестандартной логики
Срок: 2 месяца и 13 дней вместе с проверкой
Главная цель: не просто обновить визуал, а собрать брендовый магазин с нужными пользовательскими сценариями внутри InSales

Контекст

DoctorPainS обратились к нам не в первый раз, мы уже работали раньше. Магазин у них был действующий, на стандартном шаблоне. На входе задача выглядела понятно: есть готовый дизайн в Figma, нужно аккуратно перенести его на InSales и запустить обновлённый магазин.

Но почти сразу стало ясно, что это не история из серии “просто сверстать по макету”. У клиента был большой каталог профессиональной косметики, отдельные контентные страницы, свои сценарии покупки и ожидание, что магазин будет выглядеть как самостоятельный бренд, а не как типовой шаблон.

Настоящая проблема

Когда мы начали разбирать проект, стало понятно, что задача не в переносе дизайна как таковом.

Казалось, что нужно просто внедрить новый макет. А оказалось, что основная работа это доработать InSales под нужный UX клиента, не ломая базовую логику платформы.

Самые чувствительные места были сразу видны:

·        корзина;

·        личный кабинет;

·        чекаут;

·        страница брендов;

·        карточки товаров, где цена должна показываться только зарегистрированным пользователям.

То есть по факту это был не просто перенос дизайна интернет-магазина на InSales для косметики в Москве, а проект, где нужно было собрать свой сценарий покупки и личного кабинета внутри платформы.

Ограничения и риски

Все эти моменты прописали в ТЗ и на созвоне я на это обратил внимание заказчика.

У InSales есть зоны, где нельзя сделать всё “как в Figma” один в один. В чекауте часть структуры жёстко задана самой платформой. В личном кабинете тоже нельзя просто взять и свободно сверстать всё с нуля. Поэтому здесь важно было не обещать невозможное, а сразу показать клиенту, где делаем точно по дизайну, а где аккуратно адаптируем решение под платформу.

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

Принятое решение

Я сразу понял, что идти надо не через “натянуть макет любой ценой”, а через рабочую доработку магазина под реальные сценарии.

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

Для меня это и есть нормальный подход к e-commerce: не спорить с платформой ради красивой картинки, а собирать решение, которое выглядит сильно и работает предсказуемо.

Реализация

Перенесли дизайн из Figma на действующий магазин

Сначала мы изучили макет, разложили его в ТЗ и собрали план внедрения. Это было важно, потому что проект затрагивал не одну-две страницы, а ключевые сценарии магазина: каталог, карточку товара, корзину, оформление заказа, личный кабинет, контентные страницы и отдельные шаблоны.

Сделали нестандартную корзину в логике маркетплейсов

Это был один из самых сильных узлов проекта.

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

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

Доработали личный кабинет под нужную логику

Личный кабинет не сводился к обычной стилизации.

Мы собрали логику вывода заказов так, чтобы человек видел:

·        переключение между актуальными и завершёнными заказами;

·        превью товаров внутри заказа;

·        кнопку “подробнее”;

·        для завершённых заказов, сценарий “повторить заказ”.

То есть личный кабинет стал не просто техническим разделом, а понятным рабочим интерфейсом для покупателя.

Адаптировали чекаут под дизайн и бизнес-логику

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

Отдельно внедрили чекбокс “назначение косметолога”, который был в ТЗ.

Сделали отдельную страницу брендов с алфавитным указателем

Это тоже важная доработка, потому что для большого каталога брендов просто длинного списка мало.

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

Реализовали сценарий “цена по запросу” для части товаров

Клиенту нужна была возможность скрывать цену в определённых карточках от незарегистрированных пользователей.

Мы сделали это так, чтобы клиент управлял логикой сам: он добавляет товару метку “Цена по запросу”, и если пользователь не авторизован, то вместо цены видит текст “Цена по запросу”, а вместо обычного действия — кнопку “Зарегистрироваться”.

Это хорошая доработка тем, что не требует каждый раз лезть в код или идти к разработчику.

Собрали отдельный формат “схем ухода”

Ещё один сильный блок проекта — это “схемы ухода”.

По сути это не просто товар, а отдельный сценарный формат: категория со своими схемами и специальная карточка, где пользователь видит пошаговое применение.
 шаг 1, шаг 2, шаг 3 — и товары внутри этой логики.

То есть мы сделали не просто карточку комплекта, а отдельный формат подачи продукта, который лучше объясняет, как пользоваться набором и зачем в нём каждый шаг.

Добавили отдельные контентные страницы

Помимо e-commerce логики были ещё страницы в формате лендингов, в том числе консультационные. Это тоже важно, потому что в beauty-проектах магазин часто работает не только как каталог, но и как площадка для прогрева, объяснения и доверия.

Как мы вели сдачу проекта

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

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

Такой формат помогает не превращать запуск в стресс: проект двигается поэтапно, клиент видит результат по ходу работы, а финальная доводка проходит без хаоса. 

Результат

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

Но подтверждённый результат такой:

·        магазин перестал выглядеть как стандартный шаблон;

·        проект стал восприниматься как отдельный бренд;

·        внутри InSales появились сценарии, которых в стандартной логике платформы не было;

·        клиент получил управляемые решения, которыми может пользоваться без постоянного участия разработчика;

·        UX стал ближе к реальным e-commerce-сценариям, а не к базовой сборке “как есть”.

Для этого кейса это и есть главный итог: мы не просто перенесли дизайн, а доработали магазин под нужный формат работы и восприятия бренда.

Почему такие проекты нам подходят

Этот проект хорошо показывает наш подход в работе с InSales.

Мы не сводим задачу к формуле «перенести макет как-нибудь поближе к дизайну». Сначала смотрим, где у проекта реальные риски, потом честно объясняем, что можно сделать точно, что нужно адаптировать и где лучше сразу идти через доработку логики.

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

Финал

Заказ был не самый простой. Но в таких проектах это как раз и нормально.

Снаружи это выглядело как перенос дизайна на InSales. По факту — это была доработка магазина под бренд, каталог и реальные пользовательские сценарии. И именно такие проекты мне нравятся больше всего: когда нужно не просто перенести картинку, а понять, как магазин должен работать на самом деле.

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