Прощай, копипаст! Как мы сделали каталог готовых игровых механик и увеличили конверсию пресейлов

  Недавно мы в KTS выпустили каталог готовых игровых механик KTS Market, благодаря которому ускорили запуск новых проектов и ускорили процесс разработки. Надя Меркулова, руководитель разработки фронтенда в юните рекламных спецпроектов KTS, рассказывает, как переиспользовать код и оптимизировать процесс разработки в агентстве.  

Что такое игровые механики и как мы их запустили

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

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

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

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

Что пошло не так и почему нужно было менять этот подход

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

Stop-слово «NDA». Некоторые клиенты заключают с нами NDA, поэтому мы не можем демонстрировать механики прошлых проектов через скриншоты, что затрудняет коммуникацию с новыми заказчиками.

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

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

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

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

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

Признание проблемы — половина пути к решению. Но мы пошли до конца

Для решения проблемы с демонстрацией механик и переиспользованием кода мы создали свой каталог готовых механик. Итак, что мы сделали?

Выявили наиболее популярные механики

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

Для каждой механики мы предоставили возможность настройки. Например, в рамках механики «Карточки мемори» можно было настроить оформление, количество карточек и время на поиск.

Определили, что именно нужно кастомизировать

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

Например, в рамках механики «Пазл» можно было настраивать формы пазлов, их количество, картинки на пазлах и время на сборку изображения.

Разработали каждую из механик

При разработке механик мы столкнулись с рядом проблем. Рассказываю, как мы решали каждую из них.

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

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

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

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

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

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

В рамках механики «Яйцелов» можно настроить длительность игрового времени и уровни сложности, такие как скорость падения предметов

Настроили демонстрацию механик в удобном формате

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

В «Тиндере» можно было выбрать тип переключения и наполнение карточек

Оформили каталог механик как библиотеку

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

Например, в «Квизе» можно было настраивать форматы вопросов и ответов, а также комментарии к ответам.

Финал истории

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

Посмотреть, что у нас получилось, можно по ссылке.