- B2C
- Mobile
- E-commerce
Как я превратил поиск в основу пути к покупке
Спроектировал поиск предложений, выбор магазина и получение кешбэка. Работал ведущим дизайнером в команде из трёх человек и довёл решения до релиза.
Роль: Product Designer / Lead · Команда: 3 дизайнера
Период: февраль 2024 – июль 2025
Контекст и цель
Чекай помогает сравнивать предложения магазинов и получать кешбэк. Продукт проектировали с нуля. Цель – связать поиск товара, выбор магазина и получение кешбэка в один понятный путь.
Моя роль
Лично: проводил интервью, формулировал гипотезы, проектировал логику главной, структуру магазина и состояния чеков. Отвечал за связь этих сценариев, компоненты и подготовку макетов к разработке.
Как лид: распределял задачи между двумя дизайнерами, синхронизировал решения и проводил дизайн-ревью. С аналитиками выбирал направления, при реализации проверял согласованность экранов и состояний.
Дизайн-процесс
Погружение → исследование → формулировка задачи → выбор гипотез → прототип → проверка → релиз и оценка.
Исследование: 14 интервью. Проверка прототипов: 8 участников. По результатам меняли иерархию главной, представление выгоды и статусы чеков.
01. Погружение и ограничения
Основной путь: найти товар → сравнить предложения → выбрать магазин → купить → получить кешбэк. Для бизнеса важно, чтобы пользователь проходил этот путь и возвращался после покупки.
Ограничение первой версии: нет накопленной истории поведения для рекомендаций. Вместо рекомендательного механизма выбрали решение на доступных данных каталога. Отдельную витрину выгодных предложений оставили вторичной: она не помогала тому, кто уже сравнивал конкретный товар.
02. Исследование пользователей и сегментов
Провёл 14 глубинных интервью, изучил отзывы о похожих сервисах. Обсуждали реальные последние покупки: с чего начинали поиск, как сравнивали магазины и что происходило после оплаты.
Сегменты выделены по ситуации покупки. Один человек может переходить между ними в разных покупках.
| Ситуация | Задача пользователя | Что нужно в продукте |
|---|---|---|
| Знает конкретный товар | Найти, где купить выгоднее | Глобальный поиск и сравнение предложений |
| Знает категорию, но не выбрал товар | Сузить выбор | Категории и подборки |
| Ищет акции без конкретной покупки | Найти интересную выгоду | Актуальные предложения и условия |
| Уже совершил покупку | Получить кешбэк и проверить начисление | Сканер и история чеков |
Главное наблюдение: товар часто был отправной точкой, а магазин – параметром выбора. Для незнакомого магазина люди дополнительно проверяли отзывы и искали промокоды. После отправки чека им было важно видеть, что происходит с начислением.
03. Job Stories
Найти выгодное предложение. Когда я уже выбрал товар, я хочу сравнить предложения магазинов, чтобы купить его на подходящих условиях и быть уверенным в выборе.
Выбрать товар. Когда я знаю только категорию покупки, я хочу посмотреть подходящие варианты и предложения, чтобы определиться с товаром.
Проверить незнакомый магазин. Когда у незнакомого магазина привлекательная цена, я хочу увидеть отзывы и условия выгоды рядом с предложением, чтобы принять решение о покупке.
Получить кешбэк. Когда покупка уже совершена, я хочу загрузить чек и следить за его статусом, чтобы понимать, принят ли он и когда появится кешбэк.
04. Конкурентный анализ
Разбирал сценарии Едадила и ЧекСкана: точку входа, представление магазинов, переход от товара к предложению, отображение скидки и кешбэка, действия до полезного результата.
| Функция | Едадил | ЧекСкан |
|---|---|---|
| Поиск товаров и сравнение цен | ||
| Акции и промокоды | ||
| Кешбэк за чеки | ||
| QR-сканирование чеков | ||
| Список покупок | ||
| Учёт расходов и статистика трат | ||
| Хранение карт лояльности |
Выводы
- Поиск, сравнение цен и сканирование чеков есть у обоих сервисов. Для Чекай это базовые функции.
- В Чекай связал выбор товара, условия магазина и кешбэк в один путь. Итоговую цену показал отдельно от возможного возврата денег.
- После покупки акцент сместил на статус чека и начисление: пользователь должен понимать, что происходит с его деньгами.
05. Проблема и критерии успеха
В ранних вариантах сценария пользователь должен был заранее выбирать магазин, собирать условия покупки по разным разделам и отдельно искать результат обработки чека.
Для оценки решения выделил три проверяемых задания:
| Задание | Признак успеха | Что фиксировать |
|---|---|---|
| Найти товар | Без подсказки открывает подходящее предложение | Завершение задания и ошибки навигации |
| Выбрать магазин | Объясняет цену к оплате и отличает скидку от условного кешбэка | Самостоятельный выбор и понимание условий |
| Загрузить чек | Отправляет чек, находит его в истории и понимает статус | Завершение задания, время и ошибки |
06. Гипотезы и приоритеты
С аналитиками сравнили три альтернативы для выбора магазина: влияние на текущую покупку, необходимые данные и объём новой продуктовой логики.
| Направление | Влияние на текущую покупку | Данные и реализация | Решение |
|---|---|---|---|
| Единая страница магазина | Помогает оценить предложение в момент выбора | Доступный каталог; не нужен новый рекомендательный механизм | Первая версия |
| Персональные предложения | Помогают находить релевантные товары, но не объясняют условия уже выбранного | Нужны история поведения и рекомендации | Отложили до накопления данных |
| Витрина «Самые выгодные» | Помогает при свободном просмотре; не решает сравнение конкретного товара | Нужен отдельный раздел и сценарий | Вторичный приоритет |
Это качественное сравнение, без числовых оценок влияния и трудозатрат.
Для сквозного пути приняли ещё две гипотезы: поиск до выбора магазина убирает преждевременное решение; история со статусами помогает контролировать кешбэк после отправки чека. Их проверяли на прототипах.
07. Как изменились сценарии
Схемы ниже сопоставляют раннюю и финальную логику по материалам проекта. Под каждой – реальные экраны финального решения.
Поиск: магазин перестал быть обязательным входом
В раннем варианте магазин нужно было выбрать ещё до сравнения цен. Перенёс этот выбор после поиска. Категории и подборки сохранил для тех, кто ещё не определился с товаром.
Ранний вариант
- Выбрать магазин
- Найти товар в его каталоге
- Посмотреть предложение
В релизе
- Найти товар
- Сравнить предложения
- Выбрать магазин
Магазин: от разделов к решению о покупке
Ранняя структура «Товары / Акции / Кешбэк / Отзывы» сохраняла переключения внутри продукта. Объединил информацию вокруг одного предложения. Итоговую цену сделал основной, скидку и условный кешбэк показал раздельно.
Ранний вариант
- Открыть товар
- Проверить акции, кешбэк и отзывы в разных разделах
- Вернуться к товару
В релизе
- Открыть предложение
- Сравнить цену, условия и отзывы в одном контексте
- Перейти к покупке
Чеки: отправка больше не завершает сценарий
Одноразовое сообщение об отправке не объясняло, где проверить результат позже. Связал сканер с историей: чек сразу виден в обработке, после проверки – с начислением или причиной отказа.
Ранний вариант
- Отсканировать чек
- Получить сообщение об отправке
- Закрыть экран
В релизе
- Отсканировать чек
- Увидеть чек в истории со статусом
- Вернуться за результатом
08. Что показала UX-проверка
После внутреннего разбора проверили прототипы с 8 участниками. Давали задачи найти товар, выбрать магазин и загрузить чек. Просили объяснить выбор; не подсказывали использовать отзывы, промокоды или кешбэк.
| Задание | Что наблюдали | Что изменил |
|---|---|---|
| Найти покупку с точным запросом и без него | С конкретным товаром шли в поиск; при свободном выборе использовали категории и подборки | Сохранил оба входа, поиск оставил главным |
| Выбрать магазин и объяснить решение | Часть участников сравнивала заметные проценты, не учитывая условия. Для незнакомого магазина раньше искали подтверждение надёжности | Перенёс акцент на цену к оплате, разделил скидку и кешбэк, усилил условия и отзывы |
| Загрузить чек и найти место для проверки начисления | За результатом возвращались в историю; она работала как экран контроля, а не архив | Усилил статус и сумму кешбэка непосредственно в списке |
Эти наблюдения стали основанием для правок. Рост успешности после итерации количественно не подтверждён.
09. Реализация и результат
Передавал в разработку макеты, компоненты и состояния сценариев. В чеках разделил получение данных и начисление: «В обработке» не обещает, что кешбэк уже получен. Для отказов предусмотрел причины; в дизайн-ревью проверял одинаковую логику цены, скидки и кешбэка между разделами.
Поиск, страница магазина и чеки вошли в релиз. Подтверждённый результат – выпущенные сценарии и изменения по наблюдениям UX-проверки. Количественные показатели после запуска не сохранились.
10. План продуктовой аналитики
С аналитиками определили, как оценивать прохождение пути после запуска. Открытие поиска или просмотр магазина сами по себе не считались успехом.
| Сценарий | Метрики |
|---|---|
| Поиск | Доля поисковых сессий с открытием предложения; запросы без результатов и ошибки |
| Выбор магазина | Доля посетителей страницы, перешедших к предложению и следующему этапу покупки |
| Загрузка чека | Доля начавших загрузку, которые её завершили; время до отправки; ошибки обработки |
| Повторное использование | Повторные загрузки чеков и возвраты пользователей |
| Поддержка | Обращения о загрузке, статусе чека и начислении кешбэка |
Это план измерения, а не результаты запуска. Целевые значения требуют базового замера.