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

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

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

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

Это могла бы быть реклама no code сервиса или сообщества зерокодеров, но не в этот раз.

MVP 1.0 как таблетка от головной боли

Летом 2020 я ошарашила своих пользователей внезапным редизайном календаря и расписания уроков.

Календарь — это самое чувствительное место для преподавателя: в расписании он планирует день, нагрузку, управляет уроками и учениками.

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

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

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

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

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

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

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

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

• что точно делать не будем;
• что уже в работе;
• что обсуждаем и проектируем.

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

Открытый беклог календаря

И это действительно сработало. Вместо холивара учителя начали аргументированно мотивировать коллег голосовать (писать комментарии) за важные для всех фичи. Мы с командой смогли четко приоритизировать задачи на основании фидбека и решить все самые острые проблемы за 2 недели.

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

Учителя увидели, что они действительно могут влиять на продукт. Открытый беклог сработал отлично. Но была и проблема — он требовал много ручной работы: сбор, вычитка, тегирование всех комментариев, проставление статусов, подвязка макетов.

Поэтому после того, как календарь достиг пользовательской оценки 4.95/5, мы перестали поддерживать открытый беклог в актуальном состоянии.

MVP 2.0 или системная терапия

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

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

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

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

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

Сейчас был другой масштаб, и мне нужен был инструмент, который:

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

Беклог календаря мы собрали на airtable с интеграцией typeform через zapier. Но теперь нам требовался чуть более сложный инструмент.

Я люблю no code решения и часто к ним прибегаю, этот случай не стал исключением.

Выбор инструмента

Я поисследовала, какие инструменты и решения есть на рынке. Сначала я попробовала усложнить систему в airtable: вынести расчеты голосов отдельно по форме, прикрутив Intergromat, но это оказалось совсем не френдли.

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

В итоге я остановила свой выбор на Glide.

Почему:

• сбор приложения на гугл-доках;
• большой выбор инструментов;
• кастомный приятный дизайн;
• ограничения логинов по почтам;
• мобильный вид (год назад у Glide не было веб-версии).

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

Появление Skyfitcha

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

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

Так родилась Skyfitcha.

Давайте покажу, что получилось:

Skyfitcha внутри

У приложения в итоге около 30 экранов, собрано оно на гугл таблице в 11 вкладок.

Таблица — основа приложения

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

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

Призывы учителей голосовать за идеи

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

• это был еще один дополнительный источник информации;
• дополнительная авторизация;
• дополнительная иконка на рабочем столе;
• отсутствие веб-версии (она была, но специфичная, сейчас классная кстати!)

Почему от Skyfitcha в итоге отказались

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

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

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

Резюме

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

За год приложением пользовалось ~20% аудитории учителей английского языка. Они сгенерили ~300 идей, оставили 6000 уникальных голосов и 2000 попытки проголосовать более 1 раза.

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

Это примерно в 24 раза дешевле реализации в продукте.

Сегодня я хочу сказать RIP Skyfitcha. И поблагодарить сообщество зерокодеров Вадима Михалёва и ребят из чата Glide, которые помогали мне реализовывать все мои выкрутасы с профилями и связями в таблице.

Из сложностей я столкнулась с тем, что

• Glide активно развивается, то что есть в обучалках, совсем уже не так в действительности, и тут сильно помогло комьюнити зерокодеров и форум пользователей;
• из-за того Glide активно развивался и релизил свои фичи, у меня один раз пропали почты моих пользователей, менялась логика и вид экранов. Замечать и предвидеть эти риски было сложно, но не критично.

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

Быстро, дешево, без технический знаний и навыков дизайна. Включайте фантазию и не бойтесь экспериментировать!

Skyfitcha переродится в экосистеме преподавателей (а возможно, и не только преподавателей) Skyeng.

Stay tuned!