B2B-платформа для управления интернет-магазином и ИИ-поиском
Единый back-office для работы с товарами и заказами, аналитикой и настройкой ИИ-поиска — в одном рабочем пространстве.
Web
UX/UI
B2B SaaS
E-commerce
Recom+ — ИИ-поиск для e-commerce
Клиентский кабинет должен был помочь бизнесу понять ценность ИИ-поиска и управлять его работой. В процессе проектирования решение выросло в единый back-office интернет-магазина.
Что такое Recom+
Recom+ — сервис умного поиска для интернет-магазинов. Он понимает смысл запроса, работает с опечатками и разговорными формулировками и помогает покупателю находить более релевантные товары.
Изначальная задача: спроектировать клиентский кабинет для мониторинга эффективности поиска, анализа запросов и управления его настройками.
Что я проектировала
По мере проработки сценариев стало понятно, что поиск нельзя рассматривать отдельно от каталога и заказов. Чтобы исправить запрос, нужны данные о товарах; чтобы оценить эффект — конверсия, заказы и выручка.
Поэтому в одной системе я связала товары, заказы, аналитику, поисковые запросы, ИИ-настройки, роли и системные функции.
КАК РЕШЕНИЕ РАСШИРИЛОСЬ
Из дашборда для ИИ-поиска — в полноценную B2B-платформу управления интернет-магазином.
ИИ-поиск стал не отдельным техническим модулем, а частью операционного контура e-commerce: пользователь может увидеть проблему, перейти к товару или настройке, внести изменение и затем проверить результат в аналитике.
01 — О проекте
02 — Постановка проблемы
Проблема не в отсутствии данных. Проблема — в разрыве между данными, интерпретацией и действием
На основе брифа и анализа сценариев я сформулировала три системных разрыва, которые мешают бизнесу управлять поиском как инструментом продаж.
Нет связи между данными
Команда видит запросы, клики, товары
и заказы, но эти данные существуют отдельно. Из-за этого сложно понять, какие запросы приводят к покупке,
где пользователи уходят и какая часть результата связана с поиском.
и заказы, но эти данные существуют отдельно. Из-за этого сложно понять, какие запросы приводят к покупке,
где пользователи уходят и какая часть результата связана с поиском.
Проблема не ведёт к действию
Запрос без результатов или низкая релевантность фиксируют сбой,
но не отвечают на вопрос: что именно нужно изменить? Пользователю приходится отдельно анализировать каталог и искать способ повлиять
на выдачу.
но не отвечают на вопрос: что именно нужно изменить? Пользователю приходится отдельно анализировать каталог и искать способ повлиять
на выдачу.
ИИ остаётся «чёрным ящиком»
Автоматизация есть, но бизнесу
не всегда понятно, почему показаны именно эти товары, какие правила влияют на результат и как проверить эффект внесённых изменений.
не всегда понятно, почему показаны именно эти товары, какие правила влияют на результат и как проверить эффект внесённых изменений.
PRODUCT PROBLEM
Как превратить данные ИИ-поиска в понятный рабочий цикл: увидеть проблему → оценить её влияние → исправить → проверить результат?
КЛЮЧЕВОЙ СДВИГ
Исследование сместило фокус с вопроса «какие данные показать
в дашборде?" на вопрос «как помочь пользователю пройти путь
от сигнала к решению?"
в дашборде?" на вопрос «как помочь пользователю пройти путь
от сигнала к решению?"
Прототип и проверка гипотез появляются дальше — после JTBD, инсайтов, приоритизации и основного flow.
ОТ БРИФА К ПРОДУКТОВОЙ РАМКЕ
01
02
03
04
05
Бриф и сигналы
Кастдев · опыт e-commerce
Анализ контекста
Роли · задачи · решения
Problem framing
Поиск · каталог · бизнес-метрики
JTBD и сценарии
Что пользователь пытается
сделать
сделать
Гипотезы
Что нужно проверить решением
03 — Исследование и формирование продуктовой рамки
Сначала нужно было понять, какую задачу бизнес действительно пытается решить
На старте я опиралась на бриф Recom+, сигналы из кастдева и опыт команды в e-commerce. Исходная формулировка была сфокусирована на клиентском дашборде для ИИ-поиска, поэтому сначала я разобрала контекст использования продукта: кто будет работать с системой, какие решения эти пользователи принимают и каких данных
им для этого не хватает.
им для этого не хватает.
Клиентский кабинет должен был помочь бизнесу понять ценность ИИ-поиска и управлять его работой. В процессе проектирования решение выросло в единый back-office интернет-магазина.
В процессе анализа стало понятно, что задача шире просмотра метрик поиска. Пользователю нужно не только увидеть отклонение, но и понять его причину, оценить значимость для бизнеса и перейти к конкретному действию.
На этой базе я сформировала рабочую модель продукта: роли пользователей, JTBD, ключевые сценарии
и продуктовые гипотезы, которые дальше определили информационную архитектуру и основной flow.
и продуктовые гипотезы, которые дальше определили информационную архитектуру и основной flow.
01
Бриф и сигналы
↓
02
Анализ контекста
↓
03
Problem framing
↓
04
JTBD и сценарии
↓
05
Продуктовые гипотезы
04 — Пользователи и JTBD
Разные роли — один общий прогресс
Роли отличаются глубиной погружения, но объединяются одной задачей: понять, где поиск влияет на результат магазина, и решить, что делать дальше.
Владелец магазина
Нужен быстрый health-check: работает ли поиск, влияет ли он на деньги и требует ли ситуация внимания.
Маркетолог
Нужно находить проблемные запросы, быстро корректировать выдачу и видеть результат своих действий.
Product manager
Нужна полная картина: аналитика, причинно-следственные связи, экспорт данных и аргументы для решений.
PRIMARY JTBD
Когда я отвечаю за эффективность интернет-магазина, я хочу видеть, где поиск помогает или мешает пользователю найти товар, чтобы понимать влияние проблемы на продажи и решать, что исправлять в первую очередь.
Оценить состояние → Найти проблему → Определить приоритет → Исправить → Проверить эффект
05 — Синтез инсайтов
Четыре вывода, которые определили дизайн системы
Я сократила исследовательские наблюдения до четырёх принципов, каждый из которых напрямую повлиял на структуру и сценарии продукта.
Проблемы имеют разный бизнес-вес
Низкая релевантность сама по себе не задаёт приоритет: важны также частота запроса, поведение пользователей
и потенциальный коммерческий эффект.
Design implication: показывать рядом качество поиска и бизнес-контекст.
и потенциальный коммерческий эффект.
Design implication: показывать рядом качество поиска и бизнес-контекст.
Чем больше автоматизации, тем важнее контроль
Бизнесу не нужно знать внутреннюю механику ИИ, но нужно понимать, что можно изменить и как это повлияет на выдачу.
Design implication: сделать точки ручного контроля очевидными.
Design implication: сделать точки ручного контроля очевидными.
Метрика сама по себе не объясняет ценность
CTR, релевантность или количество запросов нужно рассматривать в контексте заказов, конверсии и выручки.
Design implication: связать search metrics и business metrics
в одном информационном контексте.
Design implication: связать search metrics и business metrics
в одном информационном контексте.
Обнаружение проблемы — только половина сценария
Запрос без результата сообщает, что что-то пошло не так,
но не помогает понять следующий шаг.
Design implication: дать прямой переход от проблемного запроса
к исправлению выдачи.
но не помогает понять следующий шаг.
Design implication: дать прямой переход от проблемного запроса
к исправлению выдачи.
06 — Приоритизация
Из множества идей — к опорным сценариям
Клиентский кабинет должен был помочь бизнесу понять ценность ИИ-поиска и управлять его работой. В процессе проектирования решение выросло в единый back-office интернет-магазина.
В исследовательской доске я приоритизировала идеи и собрала ядро продукта вокруг действий, которые дают пользователю максимальную ценность без лишних переходов.
Core — сделать первым
- Финансовые KPI на главном
- Проблемные запросы
- Действие прямо из строки запроса
- Связь запроса с товаром
- Быстрый переход от проблемы к исправлению
Next — усилить анализ
- Воронка поиска
- Быстрые действия на главном
- Экспорт отчётов
- Приоритеты товаров
- Сравнение динамики после изменений
Later — расширить контроль
- Подсказки «что сейчас важно»
- Продвинутые сценарии ИИ-ассистента
- Более глубокая сегментация
- и аналитика
- Дополнительные системные настройки
Так появились две связанные модели: архитектура всей платформы и отдельный цикл оптимизации ИИ-поиска.
07 — Масштаб решения
Из дашборда — в полноценный e-commerce back-office
По мере проработки flow стало понятно, что ИИ-поиск нельзя улучшать отдельно от каталога и коммерческих данных. Решение расширилось до единой системы управления магазином.
Operate
Заказы · Товары · Каталог
Understand
Dashboard · Analytics · Search Queries
Control
ИИ-настройки · Синонимы · Ranking · Widget
System
Роли · Версии · Отчёты · Данные
АРХИТЕКТУРНЫЙ ПРИНЦИП
ИИ-поиск стал не отдельным техническим модулем, а частью операционного контура интернет-магазина.
Чтобы исправить проблемный запрос, пользователь может перейти к товару или настройке; чтобы оценить эффект — вернуться к заказам и аналитике.
УРОВЕНЬ 1 · БЫСТРАЯ ПРОВЕРКА
Дашборд
Смотрю ключевые показатели
→
Есть проблема?
Сигнал требует внимания?
Нет
Да
Чек завершён
Возвращаюсь к работе
Перейти к проблеме
Запускаю основной сценарий
УРОВЕНЬ 2 · ОСНОВНОЙ СЦЕНАРИЙ
Исправление
Товар · синоним · правило
←
Диагностика
Понимаю причину
←
Приоритизация
Выбираю, что важнее
←
Проблемные запросы
Открываю список проблем
↓
Нет
Сохранить
Фиксирую изменение
→
Новые данные
Жду накопления сигнала
→
Аналтика
Сравниваю результат
→
Эффект улучшился?
↓
Да
Проблема решена
08 — Основной пользовательский flow
Сначала быстрый чек, затем — сценарий исправления
Вместо одного большого flow я разделила сценарий на два уровня: ежедневная проверка состояния и более глубокая работа с проблемой только тогда, когда она действительно обнаружена.
Уровень 1 · Быстрая проверка
01
Dashboard
↓
02
Есть проблема?
↙
↘
НЕТ
Чек завершён
Возврат к работе
ДА
Перейти к проблеме
Запустить сценарий
Уровень 2 · Основной сценарий
01
Проблемные запросы
↓
02
Приоритизация
↓
03
Диагностика
↓
04
Исправление
↓
05
Сохранить
↓
06
Новые данные
↓
07
Аналитика
↓
08
Проверка эффекта
09 — Прототип и usability testing
Проверила ключевые сценарии и продуктовые гипотезы на 23 респондентах в Pathway
После сборки кликабельного прототипа я проверила, считывают ли пользователи не отдельные экраны, а логику продукта: где посмотреть состояние, как найти проблему, что сделать дальше и какие механики действительно помогают в работе.
Что проверяла
Быстрый health-check на Dashboard
Поиск и разбор проблемного запроса
Работу с синонимами / ИИ-настройками
Аналитику и подготовку данных
Поиск и разбор проблемного запроса
Работу с синонимами / ИИ-настройками
Аналитику и подготовку данных
Что подтвердилось
Основные разделы и ключевые сценарии находились. Пользователи могли перейти от агрегированной информации к деталям и выполнить целевое действие.
Где возникала сложность
Профессиональная терминология
и незнакомая предметная модель ИИ-поиска создавали дополнительную когнитивную нагрузку.
и незнакомая предметная модель ИИ-поиска создавали дополнительную когнитивную нагрузку.
КЛЮЧЕВАЯ НАХОДКА ТЕСТИРОВАНИЯ
Часть затруднений была связана не с навигацией, а с уровнем знания предметной области: профессиональные термины ИИ-поиска повышали порог входа.
Что произошло с гипотезами
Результаты я разделила на подтверждённые, частично подтверждённые и те, которые нельзя было корректно проверить в формате прототипа.
Инсайты на Дашборде помогают быстрее заметить проблему
Инсайты помогали войти в контекст и увидеть проблемную зону, но не всегда было понятно,
какое действие должно следовать дальше.
какое действие должно следовать дальше.
Вывод для дизайна — показывать не только сигнал, но и причину проблемы + следующий шаг.
Частично подтвердилась
Экспорт PDF / CSV / Excel снижает ручную работу с отчётами
Сценарий экспорта оказался понятным и соответствовал ожиданиям пользователей как часть аналитического инструмента.
Вывод для дизайна — сохранить экспорт как supporting scenario и не перегружать им основной flow.
Подтвердилась
Ручной контроль ИИ повышает доверие к системе
Пользователям было важно понимать, что выдачу можно скорректировать через синонимы, товары, правила и настройки. Эффект на доверие подтвердился качественно, но не количественно.
Вывод для дизайна — делать точки ручного контроля очевидными и предсказуемыми.
Частично подтвердилась
После изменений нужно показывать динамику ключевых метрик через 24−48 часов
Гипотеза зависит от накопления данных во времени, а формат кликабельного прототипа не позволял реалистично проверить delayed feedback.
Вывод для дизайна — валидировать после запуска или на прототипе с симуляцией данных во времени.
Не удалось проверить
Синонимы и теги помогают самостоятельно исправлять некорректную выдачу
Работа с синонимами считывалась как понятный способ исправить поисковую связь без обязательного участия разработчика.
Вывод для дизайна — связать синонимы напрямую с контекстом проблемного запроса и товара.
Подтвердилась
10 — Отслеживание
Дашборд отвечает на вопрос «что происходит?»
На первом экране я объединила показатели бизнеса и качества поиска, чтобы пользователь оценивал не работу технологии саму по себе, а её влияние на магазин.
Ключевое решение: рядом с выручкой, конверсией и заказами показывать запросы без ответа и популярные запросы — так Дашборд становится точкой входа в оптимизацию, а не только отчётом.
11 — Обнаружение проблемы
Проблемные запросы помогают понять, что исправлять первым
Я выделила проблемные запросы в отдельный рабочий слой и добавила контекст: показы, релевантность, причину проблемы и потенциальный коммерческий эффект.
ПРИНЦИП
От «какой запрос работает плохо?» → к «какую проблему выгоднее исправить первой?»
12 — Улучшения
Товар стал частью поисковой модели
Исправление поиска связано с данными каталога. Поэтому в карточке товара появились синонимы поисковых запросов и рекомендации, а из проблемного запроса пользователь может перейти к подходящим товарам.
Это замыкает действие в одном контексте: проблема → товар → изменение поисковой связи → сохранение
13 — Проверка результата
После изменения пользователь возвращается к данным
Аналитика расширяет Дашборд и помогает проверить, изменилось ли поведение пользователей после вмешательства в выдачу.
Я разделила аналитику на два уровня: эффективность поиска и поведение пользователей. В первом — CTR, клики, добавления в корзину и заказы; во втором — сессии, время до первого клика и повторные поиски.
14 — Контроль
ИИ автоматизирует поиск, но бизнес сохраняет контроль
Пользователь может управлять поведением поиска, релевантностью, персонализацией, опечатками, ограничениями выдачи и коммерческими правилами — без погружения во внутреннюю механику модели.
Принцип: ИИ отвечает за автоматизацию, человек — за бизнес-ограничения, приоритеты и стратегию выдачи.
15 — Полноценный back-office
Финальный продукт шире исходного дашборда
Заказы
Статусы, доставка, клиенты и ежедневная обработка.
Товары
Каталог, цены, наличие и данные, влияющие на поиск.
Роли и доступы
Разные права для участников команды.
Версии
Черновики, история изменений и откат.
Виджет
Настройка внешнего вида и интеграции на сайт.
Отчёты и данные
Экспорт, хранение, анонимизация и системные параметры.
Чтобы ИИ-поиск работал в реальном e-commerce контексте, система включает не только поиск и аналитику, но и ежедневные операционные и командные сценарии.
16 — Результат
Не набор экранов, а связанная система принятия решений
За 10 недель я прошла путь от брифа и анализа бизнес-проблемы до протестированного интерактивного прототипа B2B-платформы.
РЕЗУЛЬТАТ
Исходный дашборд вырос в e-commerce back-office, где пользователь может увидеть проблему, понять её влияние, изменить каталог или правила выдачи и затем проверить результат.
Прозрачность
Качество поиска связано с понятным бизнес-контекстом.
Практичность
Проблема приводит к конкретному следующему действию.
Контроль
ИИ автоматизирует поиск, но бизнес сохраняет точки управления.
17 — Финальный вывод
ИИ-поиск стал частью операционной системы интернет-магазина
Главным результатом проекта стала связность: поиск, каталог, заказы, аналитика и настройки работают не как отдельные разделы, а как единый контур принятия решений.
ГЛАВНАЯ ИДЕЯ
Управлять магазином → Понимать происходящее → Влиять на результат.
Внутри ИИ-сценария: Отслеживать → Находить причину → Исправлять → Проверять результат
Внутри ИИ-сценария: Отслеживать → Находить причину → Исправлять → Проверять результат
Что я вынесла из проекта
Data ≠ insight — метрика ценна, когда помогает принять решение.
AI needs explainability — сложность технологии должна скрываться за понятными последствиями и точками контроля.
Analytics should close the loop — обнаружение проблемы и действие должны быть связаны.
Domain knowledge affects usability — иногда барьер находится не в UI, а в предметной модели.
AI needs explainability — сложность технологии должна скрываться за понятными последствиями и точками контроля.
Analytics should close the loop — обнаружение проблемы и действие должны быть связаны.
Domain knowledge affects usability — иногда барьер находится не в UI, а в предметной модели.
