Решение, о том, какой функционал нужно сделать, и его создание – это только начало процесса. Новые функции – это всего лишь код, который собирает на себе виртуальную пыль до тех пор, пока его не начнут использовать. В первой главе мы обсуждали эту ситуацию: если функционал не используется, его нужно либо убрать, либо улучшить. Если вы не можете принять это решение по какой-либо причине, вы то рискуете потерять пользователей, которые уйдут к более проворному конкуренту, чей продукт решает их задачу эффективнее.
Запуск успешной функции требует таких же навыков как запуск успешного продукта. Разница в том, что вам приходится маневрировать между вашими прошлыми решениями и не забывать о текущих пользователях. В этом и есть хитрость.
Большинство новых функций проваливаются. Вы просто этого не замечаете. И в этом вся суть. «Улучшения» выходят ненужными, неиспользуемыми, и в конечном итоге их убирают. Добро пожаловать в мир информационных технологий. Улучшения – это тяжело.
Месяцы исследований. Демографии, метрики, инфографики, аналитика, психография и так далее. Вы встречаетесь с пользователями каждый день, неделю, месяц. Вы встречаетесь с их родителями, знакомитесь с их собакой, с собакой их родителей. Вы делаете всё, чтобы действительно понять, что нужно пользователями. Не то, о чём они говорят. Не то, как они думают, им нужно, или о чём они просят. То, что им действительно нужно. И вы делаете это!
И оно всё равно не взлетает.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Почему новый функционал проваливается
Суть в том, что если пользователи не используют функционал, он может просто не существовать. Об этом часто забывают, пытаясь в спешке что-то выкатить. Дело не в том, чтобы выкатить код на сервера, проставить чекбоксы на дорожной карте, а о том, чтобы продуктом пользовались. Так что прежде чем выпустить следующую функцию, задайте себе эти вопросы…
Все ли заметят и поймут её?
Забавный факт: когда Microsoft спросила у своих пользователей, чтобы они хотели добавить в Office, оказалось, что 90% процентов запросов уже были реализованы. В Microsoft решили, что это вопрос заметности, запустив тул-бар в виде ленты, на которомый были видны все функции, но в нем ничего нельзя было найти. Как мы и сказали, это сложно.
Когда вы создаете первую версию продукта, вы хотите, чтобы она выглядела завершенной. Поэтому вы не особо планируете расширение или место для будущих функций. После того как вы их все-таки добавляете, у ваших пользователей появляются проблемы с их обнаружением. Если вы постоянно думаете о том, где находится функция — у вас проблемы с обнаружением и все следующие функции провалятся или будут требовать много обучения, чтобы их нашли и начали использовать.
Вы показываете пользователям, что вы сделали или что они могут сделать?
Говоря пользователям что-то вроде «переписано с нуля», «создано с помощью HTML5», «отзывчивый дизайн», вы рискуете потерять их внимание, если только ваш продукт не для разработчиков. Никого не волнует, что вы сделали или даже, как вы это сделали. Пользователей волнует, что они сами с этим могут сделать.
Учитываете ли вы контекст при анонсе?
Новые функции, особенно маленькие улучшения, добавляются в продукт без особого контекста. Вашей целью не должно быть «давайте просто это выпустим». Целью должно быть «давайте сделаем так, чтобы это использовали». Почта, зачастую, плохой канал для таких анонсов: это просто перебор, к тому же она обычно приходит не в то время и без нужного контекста. Подходящее время, чтобы показать улучшение, когда кто-то уже в вашем продукте и готов его использовать, например, это могут быть анонсы внутри приложения, которые появляются во время определенного события.
Как будущие пользователи узнают об этом?
По мере роста, продукт достигает таких размеров, что его нельзя изучить за один присест. Это не проблема, потому что не каждая функция должна быть понятна сразу. Функции важны только тогда, когда они решают проблемы. Например, вам не нужно проставлять теги на файлы до тех пор, пока они не загрузились. Вам не нужно группировать теги, пока их не накопилось достаточно много. Так что сразу рассказывать новым пользователям о том, как группировать теги – не самое лучшее решение.
Таргетированные сообщения полезны, чтобы показывать пользователям функционал. В Intercom, мы рассказываем о шаблонных ответах после того, как пользователь несколько раз ответил на сообщения. Мы показываем сочетания клавиш после того, как пользователь проработал с продуктом достаточно долго, чтобы они были важны для него. Так вы делаете сообщения полезными.
Планируете ли вы общаться с теми, кто использует и не использует функционал?
Когда функционал выходит в релиз, вы должны пообщаться с теми, кто его использует, чтобы понять, как, почему и зачем они им пользуются. Ищите способы увеличить его использование. Вот несколько вопросов, которые я задаю пользователям о новом функционале:
- Когда вы его заметили? Что вы подумали в этот момент? Сразу ли вы начали его использовать?
- Понадобилось ли вам читать документацию? Была ли она исчерпывающей?
- Были ли какие-то сложности при использовании?
- Есть ли в течении рабочего дня моменты, когда вы хотите использовать функционал но не можете?
- Рассказывали ли вы какому-нибудь о том, что используете? Что вы говорили?
Также важно пообщаться с теми, кто не использует функционал, и понять, что их остановило. Зачастую вы встретите барьеры, которые легко разрушить, например: «я забывал проверить результат», «я не знаю, используют ли это другие люди в компании», «мне нужно получить CSV с данными» и так далее. Все эти проблемы вы решите, как только вы их поймете.
Ваш дизайн процесс должен учитывать, что вы понимаете что-то не так. Так много дорожных карт и спринтов это игнорируют. Дизайнеры и менеджеры продуктов постоянно что-то понимают не так, и когда это происходит, у них есть лишь два выхода: улучшить это или проигнорировать и пойти дальше. Делайте выбор в пользу последнего достаточно часто и скоро будете рассказывать о том, что 90% запросов функционала уже реализованы в вашем приложении. Надеюсь, вы любите ленты!
Улучшайте вовлечение пользователей
Аналитические приложения покажут вам просмотры страниц, вернувшихся посетителей, конверсии, но ни одно из них не сможет сразу сказать вам то, что вы хотите знать. Но игнорировать вовлеченность можно только на свой страх и риск.
Google+ говорили о 170 млн. пользователей, что обеспечило им несколько статьей в СМИ, но при этом игнорировали реальную проблему. Почти все их пользователи не были вовлечены. Это просто люди, которые кликают «ОК», когда встречают Google+. Это похоже на газеты, раздувающие просмотры своих страниц, используя уловки вроде слайдшоу или статей на несколько страниц. В какой-то момент вам придется задуматься о том, кого вы на самом деле обманываете.
Вовлеченность – лишь часть пазла, но его настолько часто игнорируют, что здесь появилось множество быстрых побед, которые вы можете получить. Вот три способа того, как вы можете улучшить вовлеченность.
Произведите хорошее первое впечатление
Каждый день, потенциальные пользователи впервые видят ваши интерфейсы. Об этом легко забыть, когда команда создает продукт для себя. Первый экран, который видят ваши пользователи, выполняет три важных действия…
- Объясняет, как работает ваше приложение
- Мотивирует пользователей начать работу
- Показывает пользователям, где они могут получить помощь, если что-то пойдёт не так
Веб приложения, которые не делают ничего из выше перечисленного, получают именно то, для чего они созданы. Пользователи выходят и больше никогда не возвращаются.
Есть множество прекрасных способов поприветствовать пользователя и показать ему, что он может сделать и как. Чистые листы, туториалы, тренировочные данные и так далее. Хороший шаг, который мы советуем делать новым пользователям Intercom — создать приветственное сообщение, чтобы персонально приветствовать каждого зашедшего к ним в чат. Это отлично помогает начать разговор, что в свою очередь увеличивает конверсию.
Даже простой разговор с вашими пользователями – это отличная возможность поощрить их задавать вопросы, пробовать функционал и просто оставаться в системе. Начиная диалог, вы увеличите шансы на то, что они спросят «Как я могу послать сообщение неактивным пользователям?» или «Как использовать теги?»
В лучшем случае, вы получаете больше пользователей. В худшем – узнаёте, что не так с вашим приложением.
Погружайте в продукт постепенно
У любого нормального приложения есть функционал, который не нужен пользователю сразу. Это могут быть такие полезные функции как почтовые уведомления, интеграции со сторонними приложениями, экспорт или даже небольшим оптимизации, например сочетания клавиш.
Такие углублённые преимущества нельзя показывать сразу. В конце концов, кого волнует экспорт данных, когда у них ещё нет данных? И сочетания клавиш, когда они ещё не использовали никаких функций?
Большинство менеджеров продуктов раскрывают такие функции через плохо спланированные почтовые сообщения, документацию или FAQ. Ни один из этих подходов не работает.
Почта приходит вне контекста, не вовремя и в большинстве случаев прерывает пользователя, а не заинтересовывает его. Их ответом будет архивирование сообщения и отписка от вашей рассылки.
Оставляя рассказ и объяснение функционала на FAQ или раздел помощи, вы рискуете тем, что их найдут только в тот момент, когда у пользователя будет проблема с какой-то частью вашего продукта. Не лучшее время для того, чтобы отвлекать его новым функционалом.
Мы советуем нашим пользователям составлять расписание, чтобы постепенно рассказывать о новом функционале. Когда у вас есть хорошее понимание пользовательской базы, вы можете понять, какие второстепенные функции радуют пользователей, и в какой момент они полезны. Стоит вам понять это, и все остальное сводится к своевременной коммуникации. Intercom позволяет вам наращивать коммуникацию от сессии к сессии. Это означает, что каждый раз, когда ваш пользователь заходи в приложение, вы показываете ему все больше причин задержаться подольше.
Вот пример вовлечения от одного из наших пользователей:
Анонсируйте функционал и улучшения внутри приложения
Пользователи не замечают, когда разработка вашего продукта замедляется. Они заходят, чтобы использовать ваш продукт, а не следить за прогрессом разработки. Однако, если вы молчите достаточно долго, они могут легко отвлечься, если конкурент выпустит новую функцию, неважно, полезную или нет.
Ваших пользователей волнует функционал или улучшения только тогда, когда они находятся внутри приложения, именно поэтому это лучшее время, когда вы должны их анонсировать.
Мы заметили десятикратное улучшение коммуникации (его заметили и наши пользователи) когда перешли на сообщения внутри приложения вместо почтовых анонсов, при этом есть и другие, незаметные на первый взгляд преимущества. Например, когда мы анонсировали возможность поделиться местоположением в Intercom, наши пользователи сразу переходили к функционалу, поражались его возможностями и начинали делиться местоположением своих пользователей по всему миру. Вряд ли почтовая рассылка смогла бы достигнуть похожего эффекта.
Разработайте расписание своих сообщений
Сценарий: вы менеджер продукта, который хочет, чтобы пользователи взаимодействовали с продуктом чаще, когда они выходят из офиса. Чтобы добиться этого, вы разработали мобильную версию вашего приложения. Теперь вам нужно рассказать об этом вашим пользователям.
Самое слабое решение — почтовая рассылка всем зарегистрированным пользователям, прямо сейчас, со ссылкой на мобильное приложение. Что произойдет дальше?
Кто-то получит его, пока находится на работе. Кто-то получит его, используя мобильную версию сайта. Его получат и те, кто не пользовался продуктом годами. Кто-то получит в четыре утра, кто-то в десять.
Отчет покажет, что ваше письмо открыли 4.43% пользователей, и вы будете разочарованы, так как потратили на это много сил. Худшей реакцией будет сказать «кликнуло 5%? Отлично, пошлем еще 19 таких же писем, и мы в шоколаде»
Можем ли мы сделать это лучше?
Альтернативный подход
Вы можете разделить пользователей на две группы: тех, кто ранее заходил в продукт с телефона, и тех, кто всегда пользовался десктоп версией. Это позволит вам подготовить подходящее сообщение для обеих групп.
Вы можете сделать сообщение в приложении для всех, кто использует его с мобильного телефона, чтобы они знали, что пропустили что-то новое. Вы можете послать письмо каждому, кто только что вышел из приложение, ведь вы знаете, что они все еще помнят о продукте. Вы можете написать смешное сообщение, подколов конкурентов, и добавить забавных картинок. Люди будут делиться этим, что поможет распространить новость.
Вы можете взять пример с команды Slack, которая сделала сообщения о обновлениях в App Store забавными и интересными.
“Исправлено: мы устранили лазейку из предыдущего обновления, которая позволяла произносить Gif как Jif. Прекратите!
Исправлено: когда клавиатура скрывалась с экрана с помощью свайпа, окно чата частично прокручивалось назад. Это, конечно, прикольно, но не очень удобно.”
Все эти опции выходят за пределы обычного подхода «Давайте завалим всех почтой», который выбирает большинство компаний.
Не бойтесь убивать функционал
Когда вы думаете о переизбытке функционала и раздутых продуктах, что приходит на ум? Бесконечные окошки, настройки, тулбары и прочее, верно?
Последние пять лет ни один разговор о UX или продуктовой стратегии не обходится без примера печально известного скриншота из Microsoft Word, в котором включены все дополнительные опции в тулбаре. Из-за этого оставалось совсем немного места в самом низу экрана, где пользователь мог что-то напечатать. Это идеальная иллюстрация того, почему нужно стремиться к простоте.
Плохой пользовательский интерфейс подчеркивает переизбыток функционала, именно поэтому вы должны спокойно убирать ненужное. Иначе вы получаете продукт, слишком сложный для понимания пользователями. Проблема в том, что такие ужасные экраны как у Microsoft Word не помогают в принятии дальнейших решений. Понятно, что мусора слишком много, но что с этим делать?
Чтобы разрешить эту проблему, вам нужно понять, какой функционал востребован всеми, а какой никто не замечает. Время провести аудит функционала, о котором мы говорили в Главе 1.
Не откладывайте в долгий ящик
Убрать функционал можно множеством разных способов. Вы можете скрыть его для новых пользователей, сделать объявление для текущих и дать им время подготовиться к этому. Или вы можете просто убрать его из интерфейса и никогда больше не говорить об этом. Все способы работают, но на все понадобится разное количество усилий. Чем больше становится продукт и растет количество пользователей, тем меньше вы можете позволить себе быстрых и простых решений.
Сохранить функционал, которым никто не пользуется, требует усилий в дизайне и коммуникации. Вы должны нацелиться на пользователей, которые его используют и узнать, почему. Спросить нескольких из тех, кто не использует, и узнать, почему. Очевидно, что тут в полной мере раскрываются такие инструменты как Intercom, так как вы можете нацелится на конкретную аудиторию и моментально начать разговор.
Зачастую, простое напоминание внутри приложения о существовании функционала уже может помочь. Мы работали с пользователями, которые увеличили вовлечение на 30%, просто написав нужной группе людей в правильное время. Также мы видели, как пользователи получают достаточно обратной связи, чтобы понять, что функционал просто не нужен, что облегчает принятие решения о закрытии.
Хорошие менеджеры продукта выпускают несколько слабых функций. Отличные — закрывают их сразу же.
Интерком о продакт менеджменте:
Глава 1. Узнайте свой продукт.
Глава 2. Когда говорить «нет» новому функционалу.
Глава 3. Какой функционал создать следующим.
Глава 4. Помогаем использовать функционал — вы прочитали сейчас.
