Как выучить неправильные глаголы английского, если ты продуктовый менеджер?
Очевидно, сделать продукт для их изучения.
Так я и поступил. Пилил приложение в одиночку, по вечерам, после основной работы. Путь от сырой идеи до релиза занял месяц. Еще месяц ушел на то, чтобы вывести приложение на первые места стора по всем ключевым запросам.
Как это было, с чем столкнулся и какие выводы сделал – читайте под катом.
Содержание
Идея
Вообще-то мне хотелось просто подучить неправильные глаголы.
Но, установив десяток приложений из топа стора, я так и не нашел ничего подходящего. Приложения были перегружены рекламой, неудобными интерфейсами и мудреными механиками. Многие сразу требовали заплатить им денег.
Посмотрев на все это безобразие, я невольно задумался – а что мешает сделать простейшее приложение самому? Механика несложная, а популярных 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-дизайнера. Но и то, и другое будет стоить по несколько тысяч долларов. Не совсем понятно, зачем этим сейчас заниматься.
Поэтому я довольствуюсь тем, что получил ценный опыт и сделал что-то полезное для людей. Может быть, когда-нибудь появится вдохновение, и я продолжу эту историю.
