SicPama Loyalty

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

Loyalty MVP Design · B2C Mobile Ordering · B2B Management Portal
Loyalty MVP Design · B2C Mobile Ordering · B2B Management Portal
Обзор проекта

Компания:

Компания:

SicPama

Команда:

Команда:

CEO, CTO, инженеры, Raptor Singapore (партнеры) и я

Роль:

Роль:

Единственный продуктовый дизайнер (end-to-end)

Объем:

Объем:

Интеграция в B2B портал для ресторанов + B2C мобильные заказы

Сроки:

Сроки:

2 – 2,5 месяца

Обязанности:

Обязанности:

  • Определить скоуп MVP на основе широкого брифа

  • Сформировать продуктовую логику и функциональные требования

  • Спланировать информационную архитектуру и интеграцию функционала в B2B и B2C поверхности

  • Спроектировать ключевые флоу, вайрфреймы и финальный UI

  • Создать базовую дизайн-систему и подготовить файлы для передачи в разработку

Введение

Продукт

SicPama помогает более чем 22 ресторанам в Южной Корее, Сингапуре и Малайзии управлять операциями и принимать групповые заказы за столом через QR. Ключевым мерчантам уже несколько месяцев обещали систему цифровой лояльности, интегрированную с порталом для мерчантов и приложением QR-заказов для клиентов.

Некоторые детали опущены в соответствии с соглашением о неразглашении.

Челлендж

Цель:

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

Первоначальный бриф:

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

Срочность:

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

Положение до дизайна и ограничения

До этого проекта:

1

Не было инфраструктуры и логики программы лояльности.

Специальные предложения (купоны, акции) управлялись вручную — медленно, с ошибками и невозможно масштабировать.

2

Специальные предложения не действовали внутри B2C веб-приложения заказов.

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

3

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

4

В B2C приложении заказов не было даже единой дизайн-системы.

Ограничения:

1

Жесткий дедлайн: мерчантам нужно было показать что-то рабочее как можно скорее.

2

Зависимость от партнера: POS Raptor Singapore предъявлял операционные требования, которые нужно было учесть.

3

Существующие паттерны CRM нужно было сохранить, чтобы не раздувать объем разработки.

4

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

Изменения

Отказ от уровней участников программы лояльности

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

Продвижение по уровням строилось исключительно на оплате, без значимого поведенческого драйвера

Различия в бонусах между уровнями были незначительными и неощутимыми для клиентов

Реализация потребовала бы отдельного исследования для определения значимых порогов, логики сценариев и значительного времени для разработки

Что еще важнее: ничего из этого не было необходимо для достижения реальных бизнес-целей

После представления результатов анализа стейкхолдерам и бизнес-партнерам, мы решили убрать уровни из Фазы-1 и сфокусироваться на двух механиках, которые напрямую решали бизнес-задачи при меньшей сложности:

Новый скоуп польностью удовлетворял бизнес-цели и при этом требовал меньше времени для подготовки к запуску.

Дизайн-решения и обратная связь

Как должна работать покупка пакетов для пополнения баланса?

Когда скоуп был определен, я предложила несколько вариантов флоу покупки пакетов пополнения. Вот основные варианты:

Вариант A — пакет пополнения как товар в корзине

Пользователи добавляют пакет пополнения в корзину вместе с едой и оплачивают все одним чеком. Этот вариант был нацелен минимализировать трение для индивидуальных клиентов и ускорить процесс заказа.

Проблема варианта A
Проблема варианта A

Приложение заказов SicPama построено для групповых заказов. Корзины общие.

Если Пользователь A добавляет пакет пополнения, а Пользователь B в итоге оплачивает весь стол — пакет пополнения становится конфликтом. Кто платит за персональный кредит на баланс, когда кто-то другой оплачивает счет?

UI корзины должен был бы различать личные и общие позиции. Для решения этой проблемы потребовалось бы 3+ недели дополнительной работы.

Приложение заказов SicPama построено для групповых заказов. Корзины общие.

Если Пользователь A добавляет пакет пополнения, а Пользователь B в итоге оплачивает весь стол — пакет пополнения становится конфликтом. Кто платит за персональный кредит на баланс, когда кто-то другой оплачивает счет?

UI корзины должен был бы различать личные и общие позиции. Для решения этой проблемы потребовалось бы 3+ недели дополнительной работы.

Вариант Б — пакет пополнения покупается отдельно

Пользователи оплачивают пополнение как отдельную транзакцию до или после заказа. Баланс обновляется сразу.

Решение: Оставить вариант Б
Решение: Оставить вариант Б

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

Компромиссом стало более высокое трение для новых покупателей: второй платежный флоу вместо одного.

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

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

Компромиссом стало более высокое трение для новых покупателей: второй платежный флоу вместо одного.

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

Дизайн-решения и обратная связь

Две модели использования

Обсуждение со стейкхолдерами подтвердило общее направление, но выявило расхождение между рынками:

Проблема
Проблема

Мы предполагали, что самый простой опыт — обналичивание баланса и ваучеров напрямую внутри приложения.

Мы предполагали, что самый простой опыт — обналичивание баланса и ваучеров напрямую внутри приложения.

Обратная связь от бизнес-партнеров:
Обратная связь от бизнес-партнеров:

Некоторым мерчантам в Сингапуре было необходим контроль персонала, а не полностью самостоятельная онлайн-модель. Мерчанты хотели подтверждать обналичивание до того, как клиент уйдет. Это соответствовало существующим рабочим процессам и предотвращало риск ухода без подтверждения.

Решение

Вместо навязывания одной модели я спроектировала обе:

  1. Обналичивание через POS терминал — приложение проводит клиентов через процесс верификации у стойки.

  2. Обналичивание онлайн — клиенты применяют баланс и выбирают ваучеры прямо в приложении SicPama перед оплатой.

Новые пользовательские флоу для оплаты у стойки

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

План информационной архитектуры:
Низкодетализированные вайрфреймы:

Дизайн-решение

B2B Управление программой лояльности для мерчантов

Для мерчант-портала я намеренно опиралась на существующие паттерны CRM, чтобы сократить затраты на дизайн и разработку. Приоритетом была операционная ясность и быстрое внедрение, без введения новых визуальных элементов.

  1. Управление предложениями пополнения баланса

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

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

2. Управление ваучерами

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

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

Дизайн-решение

Превью дизайн-системы для B2C приложения заказов

В приложении заказов не было единой дизайн-системы, что замедляло разработку и создавало несогласованность. Я построила базовую систему, охватывающую токены, компоненты и паттерны как для существующих поверхностей приложения, так и для новых функций лояльности. Моя цель — новая система должна быть быстрой в разработке, эффективной для быстрых QR-заказов и переиспользуемой для любых типов мерчантов SicPama.

Дизайн-решение

B2C Мобильное приложение для заказов

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

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

1. Получение ваучеров
1. Получение ваучеров

Карточки Welcome / Top up / Birthday были спроектированны прямо в главном меню, чтобы предложения были видны без перехода на другие экраны. Дизайн карточек сфокусирован на простоте и универсальности, чтобы разные рестораны могли запускать систему вознаграждений без кастомного UI под каждый тип заведения.

Карточки Welcome / Top up / Birthday были спроектированны прямо в главном меню, чтобы предложения были видны без перехода на другие экраны. Дизайн карточек сфокусирован на простоте и универсальности, чтобы разные рестораны могли запускать систему вознаграждений без кастомного UI под каждый тип заведения.

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

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

  1. Покупка пакетов пополнения баланса

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

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

  1. Обналичивание через POS

Реализовано как навигация и верификация, а не как транзакция в приложении. После заказа клиенты видят свой баланс и доступные ваучеры с единственной кнопкой «Обналичить у стойки». 4-шаговая инструкция показывает как пользователь может использовать свои награды и обналичить с помощью персонала. Детали остаются доступными, чтобы клиенты могли показать персоналу, что именно у них есть.

Реализовано как навигация и верификация, а не как транзакция в приложении. После заказа клиенты видят свой баланс и доступные ваучеры с единственной кнопкой «Обналичить у стойки». 4-шаговая инструкция показывает как пользователь может использовать свои награды и обналичить с помощью персонала. Детали остаются доступными, чтобы клиенты могли показать персоналу, что именно у них есть.

  1. Онлайн обналичивание

Награды появляются как опциональные дополнения в чекауте. Выбери ваучер, введи сумму баланса, посмотри точные списания до подтверждения оплаты. Финальный экран «Заказ принят» подтверждает завершение и при этом оставляет видимым новые предложение пополнения.

Награды появляются как опциональные дополнения в чекауте. Выбери ваучер, введи сумму баланса, посмотри точные списания до подтверждения оплаты. Финальный экран «Заказ принят» подтверждает завершение и при этом оставляет видимым новые предложение пополнения.

  1. Мой аккаунт (баланс, ваучеры, история транзакций)

Легкий хаб бонусов, построенный по банковским паттернам — баланс, количество ваучеров и история активности с табами статусов (Доступные / Использованные / Истекшие) и фильтрами (Все / Начисленные / Потраченные / Истёкшие) для снижения путаницы о том, куда делись бонусы.

Легкий хаб бонусов, построенный по банковским паттернам — баланс, количество ваучеров и история активности с табами статусов (Доступные / Использованные / Истекшие) и фильтрами (Все / Начисленные / Потраченные / Истёкшие) для снижения путаницы о том, куда делись бонусы.

Заключение

Результаты
MVP доставлен за 2,5 месяца после нескольких месяцев задержки без дизайнера в проекте
Пройдено несколько раундов обратной связи от стейкхолдеров; стейкхолдеры и бизнес-партнёры остались довольны

"Design is good, I like it", "Best designer we had so far"— команда SicPama

Первая цифровая система лояльности для мерчантов SicPama

в настоящее время на этапе разработки и тестирования

Выводы

Главная работа в этом проекте была не в самом UI, а в том, чтобы определить скоуп, функционал и логику системы лояльности. Чтобы доставить проект как можно скорее, при этом который соответсвует всем бизнес целям, было важно сделать компромисс по объему проекта. Когда я показала, что логика уровней значительно усложняет продукт, не улучшая при этом ключевой результат, команда смогла согласовать более реалистичный MVP.

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

Новый урок:

Иногда продуктовый дизайн — это не про выполнение каждого запроса,

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