Как выучить неправильные глаголы английского, если ты продуктовый менеджер?

Очевидно, сделать продукт для их изучения.

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

Как это было, с чем столкнулся и какие выводы сделал – читайте под катом.

Идея

Вообще-то мне хотелось просто подучить неправильные глаголы.

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

Посмотрев на все это безобразие, я невольно задумался – а что мешает сделать простейшее приложение самому? Механика несложная, а популярных irregular verbs всего штук 100…

Думаю, когда появляется интересная идея, – важно не убить ее сразу, представив все возможные проблемы и сложности. Лучше, наоборот, позволить себе немного пофантазировать: «Каким было бы приложение моей мечты?».

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

Ограничения

Я старый солдат и знаю, что когда придумал продукт мечты – важно отсечь лишнее и оставить только ключевой функционал. Иначе есть риск попросту не закончить проект. Особенно если делаешь его в одиночку.

Поэтому в первую версию я заложил всего 2 фичи:

• список глаголов, чтобы познакомиться с ними;

• тренировки глаголов, чтобы закрепить их в памяти.

Кроме того, я решил, что приложение будет:

• бесплатным;

• без рекламы;

• только под Android;

• без адаптации под планшеты;

• без подстройки экрана под разворот телефона;

• работать без сервера.

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

Варфреймы

Скетчи на бумажке — это хорошо, но нужно детально продумать путь пользователя в приложении. Какие у него будут задачи и как он их решит?

Например, список слов. Что там будет? Только 3 формы неправильных глаголов? Но люди, которые учат глаголы, наверняка не знают всех переводов. А нужна ли им транскрипция? А озвучка? А прогресс изучения каждого слова? А возможность скрывать изученные глаголы?

Тут легко нагородить лишних механик или, наоборот, упустить что-то необходимое. Поэтому важно иметь вижн продукта.

Мой вижн звучал примерно так:

Приложение ориентировано на начинашек и должно полностью закрывать их потребность в изучении неправильных глаголов. Но делать это предельно просто и без занудства.

Не вдаваясь в детали, расскажу про 2 инсайта, которые я поймал в процессе прототипирования:

1.      Горизонтальная ориентация

Изначально я представлял вертикальное приложение.

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

Зато в ширину всё помещалось без проблем. Поэтому пришлось переделать все варфреймы под горизонтальную ориентацию.

Я думаю, это хорошая практика – не делать слепо «как у всех» или «как принято». А, наоборот, учесть особенности своего продукта. Так список глаголов мог бы быть слабой частью моего приложения, но стал преимуществом.

2.      Отказ от клавиатуры

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

Но клавиатура ломала пользовательский опыт:

• остальные тренировки сводились просто к выбору варианта, а тут такое усложнение;

• в клавиатуре слишком много отвлекающего: переключение языков, знаки, цифры;

• при выезде клавиатуры нужно как-то смещать или перекрывать контент.

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

Реализация

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

Вообще Construct – это конструктор игр, позволяющий делать игры условно «без программирования». Вся логика строится на интерактивных объектах и событиях «если …, то …». По итогу в моем проекте получилось 322 таких события (это около двух тысяч строчек кода).

Но главная фишка Construct – возможность экспортировать готовый проект на множество платформ, в том числе на Android и iOS.

Уточню, что я неплохо знаком с этим конструктором. Собственно, персональную лицензию я получил, заняв призовое место в конкурсе игровых разработчиков Construct 2.

Немного о конструкторе

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

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

Если стандартных возможностей конструктора не хватает – можно использовать JS-вставки. Например, я так делал для определения дня года.

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

Организация проекта

Постараюсь не углубляться в специфику Construct, но расскажу вкратце, как устроен проект.

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

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

Интересно, что бэклог проекта я вел просто в текстовом файле. И то, занялся этим в самом конце разработки – просто чтобы ничего не упустить. Большую же часть приложения сделал вообще «из головы». Это один из примеров запуска продукта без ТЗ, о которых обещал рассказать в прошлой статье.

Уточню, что код я достаточно подробно комментировал, иначе сам бы в нем быстро запутался.

Дизайн

Часто при запуске нового продукта UX важнее UI.

То есть продукт должен быть, прежде всего, удобным. А красоту можно и позже навести.

Но, конечно, мне хотелось, чтобы приложение выглядело более-менее прилично и современно. Поэтому начал я со стандартного варианта: минимализм, flat design, бледно-голубые оттенки, вот это всё. Учитывая, что сам я не дизайнер, – это беспроигрышный вариант.

Но, поработав над приложением какое-то время, я задумался: «Какого черта? Я же делаю некоммерческий продукт для души. Зачем мне очередной клон Facebook с гаммой хирургического кабинета?». И перекрасил все в теплые ламповые цвета. А войдя в кураж, добавил ещё и лиса в шляпе, чтобы у приложения было узнаваемое лицо.

Учитывая, что Construct – все-таки игровой движок, я не удержался и сделал в главном меню анимированный фон с эффектом параллакса. Это не типично для обучающих приложений, поэтому должно было вызвать небольшой вау-эффект.

Дизайн готовил в Adobe Illustrator – где-то с нуля, где-то на основе бесплатных векторных стоков. Векторная графика удобна, когда не умеешь рисовать: можно тягать точки, пока результат тебя не устроит. Таким макаром, например, я сделал заглавную иллюстрацию для этой статьи.

Сборка билда

Сборка билда под стор – тот еще головняк. Конечно, потом привыкаешь и делаешь все на автомате. Но в первый раз хотелось всё бросить.

Вот обобщенный порядок действий:

• экспортировать готовый проект из Construct в формат Cordova;

• с помощью Adapter сбилдить проект Cordova в apk-файл;

• сгенерировать уникальную подпись разработчика;

• с помощью Apk-signer подписать apk-файл;

• с помощью Apk-signer верифицировать и выровнять apk-файл (что бы это ни значило);

• залить готовый билд в стор;

• а в первый раз нужно ещё установить и настроить все эти программы и библиотеки.

Самое забавное, что это – простой способ. Он считается аморальным. Есть еще «правильная сборка», которая предполагает древние языческие ритуалы и компиляцию через консольные команды. Кому интересно – вот видеоинструкция.

Конечно, для меня это всё – темный лес. Я же продакт, у меня лапки!

Как пользователь Construct я хотел бы, чтобы компиляция делалось одной кнопкой «Превратить проект в готовый apk-файл». Наверное, тут Construct сильно уступает «настоящим» средам разработки? Или там такая же морока? Кто в теме, напишите в комментариях, пожалуйста.

Тестирование

Проверялось приложение вручную. Для этого я:

• собирал билд и прокликивал его на телефоне;

• открывал проект в окне браузера на ПК и тестировал приложение на основных мобильных разрешениях;

• сбрасывал тестовый билд друзьям для проверки на других устройствах;

• добавил в настройках возможность полного сброса прогресса.

Релиз в Google Play

Должен признаться, Google, я разочарован.

Я привык, что продукты Google для широкой аудитории (почта, поиск, карты, переводчик, гуглдоки) – шикарны. Но когда речь заходит о профессиональных инструментах – все очень-очень плохо.

Достаточно сравнить Google Analytics и Amplitude, чтобы понять, насколько отстал Google.

Та же история и с Google Play Console для разработчиков. Кажется, ее делали с похмелья какие-то джуны. Я не понимаю, как компания с неограниченным бюджетом может делать настолько запутанные и нелогичные интерфейсы. А почитайте, что пишут в отзывах про их приложение. Жуть.

Не буду утомлять вас деталями, но благодаря «великолепно» спроектированной Google Play Console я зарелизил свое приложение… случайно! Причем Google не позволяет отменить релиз. Позже я выяснил, что многие столкнулись с такой же проблемой. Повезло, что мое приложение было в приличном виде на момент релиза.

В общем, тут совет такой: будьте осторожны при заливке билда через Google Console, а лучше потренируйтесь сначала на тестовом приложении.

Проблемы

Как говорят в народе: «Скоро статья пишется, да не скоро билд эпрувится». И действительно, в процессе работы над приложением я столкнулся с рядом проблем. Вот самые неприятные из них:

1.      Адаптивность дизайна

Чтобы приложение смотрелось адекватно на любых экранах, приходилось:

• масштабировать интерфейс согласно разрешению;

• закреплять элементы относительно края экрана;

• рассчитывать позицию кнопок на основе ширины и высоты видимой области;

• проверять все изменения адаптивности на десятке ключевых разрешений.

И это всё равно не решает вопрос на 100%.

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

2.      Работа без аналитики

Как продуктовому менеджеру, мне очень некомфортно работать без аналитики. Может и есть какой-то способ ее подключить к проекту Construct, но простого решения я не нашел. Поэтому пришлось делать приложение фактически вслепую, полагаясь только на свой вижн и экспертизу.

3.      Отсутствие сервера

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

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

4.      Неполный контроль

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

Например, несколько пользователей пожаловались, что в приложении нет озвучки. Причем после перезагрузки она появилась. Я догадался, что звуки просто не успевают прогрузиться. И все, что я смог сделать, – это искусственно увеличить время загрузки приложения. Хорошо, что это помогло. Иначе у меня не осталось бы инструментов, чтобы исправить проблему.

5.      Планшеты

Как у разработчика у меня может быть 100500 причин, почему я не хочу делать поддержку планшетов. Например:

• моя целевая аудитория не использует планшеты;

• мой продукт не подразумевает использование на планшете;

• у меня маленькая команда и нет ресурса на планшетную версию;

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

Но Google не позволяет отсечь планшеты – ни при установке приложения, ни в рекламе.

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

Продвижение

Итак, спустя месяц разработки, я зарелизил приложение.

Жду день, жду второй… В выдаче стора оно не появляется. Почитал на форумах, что индексироваться может до недели. Ну что поделать, жду неделю. Ни-че-го.

Google, само собой, даже не пытается сделать этот процесс прозрачнее для разработчика.

Наконец, спустя 10 дней, приложение появляется в выдаче… на 143 позиции!

Делать нечего, пришлось заняться продвижением:

• прошу друзей установить приложение и поставить ему 5 звезд;

• полностью переписываю ASO-текст, включая туда максимум релевантных ключевых слов;

• перерисовываю скриншоты для стора, делая их симпатичнее;

• размещаю ссылку на приложение на нескольких ресурсах вроде 4PDA;

• отвечаю на все комментарии пользователей, иногда использую ключевики в ответах;

• делаю пробную закупку рекламы Google Ads (получилось недорого, порядка 5 центов за установку, всего потратил около 20$);

• правлю баги и выкатываю новые версии – чтобы стор видел, что приложение живое и дорабатывается;

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

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

Итоги всей этой движухи спустя примерно месяц:

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

На самом деле, я вижу ряд причин, почему так получилось:

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

• Я выбрал довольно удачное название – в него удалось впихнуть важные ключевые слова.

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

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

• Приложение достаточно удобное, бесплатное, работает офлайн, в нем нет рекламы – думаю, это положительно сказалось на поведении пользователей и их оценках.

Удержание пользователей

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

Так как аналитики у меня не было – пришлось полагаться на свой опыт. Для удержания пользователей я решил использовать геймификацию и пуш-уведомления.

Геймификация

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

Вот что я сделал:

• Каждый день генерировал «цель дня»: пройти Х упражнений, дать Х правильных ответов... Если брать все сочетания, то возможны 15 различных целей дня. Плюс в настройках можно выбрать их сложность.

• Ввел понятие «ударный темп». Это количество дней подряд, когда цель дня выполнялась. Если пропустить день – ударный темп обнуляется.

• В процессе выполнения упражнений отображается прогресс цели дня, а иногда выскакивает лис и дает мотивирующие комментарии.

Уведомления

Изначально казалось, что подключить пуши не получится.

Но в результате, с помощью стороннего плагина Construct, сервиса OneSignal и такой-то матери – я их все же прикрутил.

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

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

От 8 до 20% студентов, получавших такие уведомления, – тут же открывали приложение.

Оценки и отзывы

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

Ну или демотивировать.

Потому что даже одна единица сразу сбивает рейтинг приложения. И тогда думаешь: «Зачем мне это всё? Можно ведь вечер и лучше провести, а не возиться с вот этим всем».

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

Выводы

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

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

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

С приложением (да и с жизнью в целом, наверное) – такая же история. Если выяснять все возможные проблемы и подводные камни, то начинать что-то делать страшно. Но если позволить себе чуть-чуть пофантазировать, немного изучить вопрос, сделать небольшой прототип… можно очнуться, когда все уже получилось.

Еще хочу сказать, что это большое удовольствие – делать что-то в одиночку. На работе мне достаточно написать задачу – и целая команада профессиональных разработчиков воплотит ее в лучшем виде: учтет все кейсы, архитектуру, адаптивность, секьюрность, нагрузку... Но когда работаешь в одиночку, то вообще не нужно писать задач, ждать конца спринта, что-то кому-то объяснять. Просто воплощаешь свой вижн – напрямую, непосредственно. Это увлекает. Думаю, что-то подобное чувствует художник, работая над картиной.

Спустя год

Прошло уже больше года с момента релиза приложения. Сейчас у него около 12 000 установок и средняя оценка «4,6». Какое-то время я еще занимался приложением: рассылал пуши, правил баги, добавил несколько фич по просьбе студентов.

Но потом забросил и только иногда отвечаю на отзывы.

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

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

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

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