Третий GAMES MEETUP получился контрастным. Первый доклад — технический: как из заказной разработки вырастает продуктовая платформа геймификации. Второй — редкий жанр на профильных мероприятиях: честный рассказ о том, как проект не получился и почему.
Часть 1. Геймификация как платформа
Что это технически
Определение простое: геймификация — это помещение игровых механик в неигровой контекст. Обучение, работа, здоровье. Для пользователя это усиление мотивации и придание смысла рутинным процедурам. Для бизнеса — активация пользователей, тюнинг конкретных продуктовых метрик и ненавязчивый онбординг в новые части продукта через задания в игровой форме.
Технически система устроена так: она реагирует на действия пользователя, потребляя поток событий, в реальном или почти реальном времени пересчитывает его игровой контекст и выдаёт обратную связь.
Игровой контекст складывается из двух частей:
- Механики — математика, которая обсчитывает поток событий.
- Легенда — эмоциональная составляющая, то, что придаёт геймификации шарм. Метавселенная, история или просто большая доменная область.
Практическое наблюдение: чем шире выбранная доменная область, тем проще строить геймификацию. Космос даёт кучу терминов; компания, связанная с электрикой, получает электроны и вольты, и всё выстраивается вокруг них.
Отдельно подчёркнута скорость обратной связи: она напрямую работает на дофаминовое подкрепление. Сделал — сразу увидел результат и награду.
Почему платформа вообще появилась
История типична для многих продуктов. Компания занималась заказной разработкой, и с определённого момента к каждому проекту стали просить добавить геймификацию — сначала эпизодически, потом регулярно.
Проблема, которая при этом вскрылась:
На хорошую геймификацию обычно не хватало бюджета, что-то делалось по остаточному принципу. Основные деньги уходили в визуал и простые механики, которые в основном хардкодились.
Захардкоженные механики нельзя перенастроить, нельзя измерить их эффективность и нельзя проверять гипотезы. При этом механики от проекта к проекту повторялись.
Финальный аргумент за продукт сформулирован через аналогию: подключая аналитику к сайту, никто не пишет её с нуля — берут готовое решение. Для геймификации, несмотря на повторяемость, такого решения не было.
Базовый набор механик
| Механика | Что это технически | Что даёт |
|---|---|---|
| Рейтинг | Число, связанное с пользователем, растущее и убывающее от его действий | Понятный критерий сравнения; основа для лидербордов, топов, дуэлей, командного зачёта |
| Челленджи (задания, миссии) | Качественная характеристика: набор шагов в заданном порядке или вразнобой | Хорошо ложится на LMS и системы проверки знаний — челлендж почти равен тесту |
| Бейджи | Награды и ачивки | Мотивация; бывают техническими — пользователь не знает о награде, но ему вдруг стала доступна тёмная тема |
| Валюта | Система счетов и транзакций | Копить, тратить, благодарить коллег переводами, конвертировать в реальные ценности в корпоративном магазине |
| Лиги | Периодическая перетасовка участников | Критично при масштабе |
Про лиги стоит развернуть отдельно, потому что это решение частой проблемы:
Если я новичок и вижу, что впереди меня в рейтинге 700 человек, мне вообще не хочется туда заходить. А если каждые две недели нас перетасовывают и я понимаю, что перехожу лигой выше или ниже, это меня мотивирует.
Механика та же, что обсуждалась на предыдущих митапах в контексте брендовых игр, — но здесь она встроена в платформу как настраиваемый параметр.
Откуда взяли архитектуру
Референсы искали не на рынке геймификации — платформ тогда просто не существовало. Взяли три класса систем:
- Системы бизнес-аналитики. Работают почти так же: собирают события от пользователей и считают метрики. Поскольку сбор событий и анализ эффективности механик были ключевыми требованиями, аналитику изучали особенно внимательно.
- Системы управления фича-флагами. Отсюда — построение масштабируемого API, организация экосистемы библиотек под разные стеки и устройство админ-панели.
- Технический мониторинг и алертинг. Умеют процессить метрики в реальном времени и триггерить события при достижении пороговых значений — механизм, прямо необходимый в геймификации.
Получилась API-first платформа: API, набор библиотек и админка для конфигурирования комбинаций механик. В админке настраиваются правила выдачи наград и логика рейтинга — какое событие увеличивает, какое уменьшает, какое умножает.
Сознательное решение — отказ от дефолтного визуала. Причина: не сужать сегмент компаний, в которые можно зайти. Визуализация адаптируется под продукт, в который встраивается система: обычно кастомные виджеты, иногда отдельные страницы. Один и тот же рейтинг может отображаться как лидерборд, как уровень или как развитие персонажа, получающего аксессуары по мере роста числа.
Корпоративный магазин частью платформы не стал: взяли open-source решение и научились брендировать. Зато разработали платёжный шлюз, похожий на настоящий, но работающий с игровыми валютами. Если у клиента уже есть магазин, платформа подключается к нему как система оплаты или лояльности.
Коробка против бесшовного внедрения
Самая содержательная часть доклада — про столкновение с рынком в тендерах 2024 года.
Наиболее развитый сегмент — геймификация HR-процессов: корпоративная валюта с магазином, награды, плановые соревнования команда на команду и отдел на отдел. Там уже есть игроки с коробочными решениями.
Плюсы коробки: это хорошие, эффективные решения, которые хорошо себя ведут — геймификация действительно эффективна на HR-порталах и HR-процессах.
Минусы коробки:
- типовой набор механик;
- выбор из нескольких фиксированных легенд — своё придумать нельзя;
- дорогое перебрендирование;
- главное — она не встраивается в существующий личный кабинет. Отдельный визуал, отдельная страница, отдельная система: сотрудник работает в одном месте, а результаты смотрит в другом.
Альтернатива — бесшовное внедрение элементов геймификации через виджеты прямо в существующие системы.
Неожиданное препятствие: заказчик приходит за визуалом
И здесь команда напоролась на несовпадение языков.
Бизнес-заказчики приходили за визуалом. Они говорили: покажите нам. Зачем вы показываете нам вот это — какие-то API, механики? Покажите наборы иконок.
Решение оказалось не в переубеждении, а в добавлении второго входа. К заказчикам, которым важен визуал, стали приходить с design-first подходом; к тем, кому важны гибкость, интеграция и влияние на метрики, — с API-first.
Итоговая мысль доклада:
В геймификации важно равновесие эмоций и расчётов. Только красивые иконки или только сложные механики не будут увлекать пользователей долгое время.
Примеров обоих провалов достаточно: классный визуал при скучной реализации и продуманные механики, которыми неудобно пользоваться из-за интерфейса.
Как выглядит интеграция
Изначальная гипотеза была про SaaS — пускать всех на свою инфраструктуру. С крупными компаниями это не сработало: они хотят все компоненты в собственном замкнутом контуре.
Рабочая схема сводится к двум этапам:
- Наладить сбор событий — через набор подключаемых библиотек. Событием может быть что угодно, вплоть до прихода на работу вовремя или активности в корпоративной соцсети.
- Наладить визуализацию — система отдаёт наружу данные в формате JSON, а портал клиента отрисовывает их так, как ему нужно.
Отдельный приём для legacy-систем, из которых события в реальном времени не достать: написали адаптер, который читает регулярные выгрузки аналитики в отдельную БД, определяет произошедшие события и отправляет их батчами.
Показательный пример гибкости — фиджитал-кейс: на мероприятии геймифицировали лазертаг. Написали модуль интеграции с оборудованием, собирали события с реальных игр и тут же выводили результаты на табло, обсчитывая всё на том же движке. Заложенных механик хватило для непрофильной задачи.
Часть 2. Антикейс: как игра «по приколу» не принесла результата
Второй доклад — от двух студий, которые сделали совместный спецпроект и пришли рассказать, что из этого не вышло.
Как всё началось
Идея родилась при заполнении контент-календаря. Стандартные праздники казались скучными, и захотелось взять неочевидную дату — День святого Патрика, под который контент почти никто не делает.
Дальше сработала ассоциативная цепочка: День святого Патрика → пабы → пиво → коллега, известный любовью к пиву и футболкам с динозавром → раннер по образцу известного офлайн-динозавра из браузера, только с этим персонажем.
Персонажей сделали двух, обоих — реальных сотрудников со своим лором. Один собирает пиво и уклоняется от коктейлей; второй собирает кроссовки и уклоняется от ведёрка с куриными крылышками — отсылка к записи подкаста, где он публично признался, что предпочитает крылышки другой сети.
Что сделали технически грамотно
Стоит отдать должное: с механикой команда обошлась профессионально.
- Понимали риск читерства. На клиентском проекте, код которого лёг в основу, пользователи уже находили способ накрутить очки. Здесь заранее подготовились и завели метрики, по которым накрутку можно отследить.
- Не ограничились all-time рейтингом. Понимали, что он быстро надоест или кто-то преисполнится в навыке. Добавили недельные рейтинги — чтобы соревнование перезапускалось и можно было разыгрывать призы по неделям.
- Сделали mobile-first. Верно предположили, что люди будут открывать ссылку из Telegram с телефона.
Недельные рейтинги, кстати, сработали: соревновательный дух запустился настолько, что один из разработчиков временно выпал из рабочих задач, пока не обогнал незнакомца из интернета.
Где всё пошло не так
Скоуп разросся. Начиналось с «за две недели соберём на коленке и все покекают». Дошло до «а давайте по-нормальному, красиво нарисуем, надолго запустим, будем добавлять персонажей». В итоге разработка заняла полгода вместо месяца.
Отдельная причина — визуал. Хотели пиксель-арт как более простой вариант, но иллюстратор в моменте пиксель-арт не умел, поэтому пошли в более сложную рисовку. Прорисовка всех кадров съела огромное количество времени, и иллюстратор просидел на проекте все полгода.
К моменту готовности привязка ко Дню святого Патрика была невозможна. Инфоповод для запуска пришлось искать заново — им стал бар на отраслевом мероприятии, где наливали за регистрацию в игре.
Планы были наполеоновскими: игровые стримы от известных людей из индустрии, добавление новых персонажей (вплоть до платного размещения), розыгрыши среди топа лидерборда, использование собранной базы контактов для продвижения коммерческих продуктов.
Результат: 160 регистраций за всё время, из которых порядка 90% пришлись на дни мероприятия, и 405 забегов.
Три причины провала
Команда назвала их сама, и все три не имеют отношения к разработке.
1. Не было чётких критериев успеха и метрик. Делали, как подсказывало сердце, и на старте ничего особенного не ожидали. Ожидания появились в процессе — но поскольку критерии успеха не закладывались, успеха и не случилось.
2. Не хватило ресурса. У обеих компаний PR-команды крошечные — у одной в отделе, кроме руководителя, вообще никого. Появились другие проекты, за которые платят деньги, и спецпроект отложили.
3. Не было дедлайнов и ответственных. Самая точная формулировка вечера:
План предполагает, что у тебя есть исполнитель и срок. Мы обсудили, что было бы круто сделать. Подумали, но не сделали.
Показательный момент: готовясь к выступлению, участники подняли переписки с планами и сами удивились, насколько хорошо всё звучало и насколько ничего из этого не было сделано.
Что стоит сделать иначе
- Поставить прозрачные числовые цели до старта: сколько площадок с каким охватом привлекаем, сколько подписчиков хотим получить.
- Заранее решить, как будет использоваться актив — собранная база, сам продукт, кейс.
- Составить план с исполнителями и точными датами, а не список идей.
Один плюс из этой истории всё же извлекается, и он неочевиден. Собственный проект — это кейс, о котором можно рассказывать свободно. Корпоративные проекты обычно закрыты NDA, и согласование каждой буквы для публикации превращается в отдельную работу.
Что забрать из митапа
- Геймификация технически — это поток событий, механики и легенда. Механики считают, легенда даёт эмоции; без второго математика не работает.
- Захардкоженные механики — тупик. Если их нельзя перенастроить и измерить, вы не узнаете, что работает.
- Лиги решают проблему безнадёжного отставания. Периодическая перетасовка возвращает мотивацию новичкам.
- У коробки и бесшовного внедрения разные компромиссы. Коробка быстрее, но живёт отдельной страницей; виджеты встраиваются в текущий кабинет, но требуют интеграции.
- Заказчик приходит за визуалом, даже когда покупает механику. Разговаривать с ним на языке API — верный способ его потерять.
- Спецпроект без метрик, сроков и ответственного не станет результатом, каким бы хорошим ни был продукт.
Материал подготовлен по видео We Wizards «GAMES MEETUP #3 | Геймификация для решения бизнес-задач».
