В компании Twilio обнаружили, что стажировка в службе поддержки клиентов значительно повышает эмпатию сотрудников. Джейсон Насси (Jason Nassi) написал по этому поводу:[20]
«Пройдя обучение по обработке запросов в службу поддержки, новые сотрудники начинают лучше понимать, почему некоторые наши клиенты обожают Twilio и как нужно помогать другим пользователям, чтобы и они полюбили наш продукт».
Вот несколько способов сделать поведение команды более ориентированным на пользователя:
Требуйте, чтобы все PM время от времени отвечали на запросы, поступающие в службу поддержки.
Ведите рейтинг среди коллег по количеству визитов к клиентам.
Каждую неделю устраивайте для команды встречи с клиентами.
Введите в повестку собраний команды регулярный обмен новой информацией о клиентах.
Добавьте раздел «Информация о клиентах» в шаблон спецификации.
Спрашивайте о потребностях клиента в ходе обзора продукта.
Будьте образцом для подражания сами проводите встречи с клиентами и делитесь полученными знаниями.
Помните, что все это касается всей команды. Конечно, именно PM являются «голосом потребителя». Но еще лучше, если разработчики, тестировщики и другие участники команды тоже хорошо разбираются в потребностях пользователей.
Практики роста
МЫСЛИТЕ, КАК НОВИЧОК
Суть успеха в работе с продуктом состоит в том, чтобы хорошо в нем разбираться. Когда его использование становится привычным и простым (что часто бывает в практике PM), легко забыть, каково это знакомиться с новым для себя продуктом.
Старайтесь как можно чаще ставить себя на место того, кто будет пользоваться продуктом впервые. Опробуйте все возможные функции, представляя, что вы с ним не знакомы. Что могло бы вас запутать? Какие описания или значки кажутся непонятными? Если вы сделаете это внимательно, вам удастся быстро выявить проблемы, с которыми могут столкнуться новые пользователи.
Чтобы развить этот навык, обращайте особое внимание на то, чему вам пришлось научиться и какие затруднения вы испытывали, когда были новичком. Наблюдайте за действиями новых пользователей и отслеживайте ситуации, которые вызывают у них проблемы, но были бы понятны опытным людям.
УСТАНОВИТЕ СВЯЗЬ МЕЖДУ ВЫБОРОМ ПРОДУКТА И ЗНАНИЕМ ПОТРЕБНОСТЕЙ КЛИЕНТА
Понимание потребностей клиента носило бы чисто теоретический характер, если бы вам не нужно было использовать свои знания для создания популярных продуктов.
Важно четко понимать, как знание потребностей клиента влияет на принятие решений о продукте. И здесь очень важную роль играет интенциональность, или направленность. Не нужно хвататься за дикие идеи, которые пришли вам во сне; каждое решение должно приниматься на основании каких-то предпосылок.
Неопытные PM часто недооценивают, как важна эта связь. Помните, что инженеры и руководители не знают потребности клиентов так глубоко, как вы: они могут не запомнить какой-то важный вывод исследования или не заметить очевидные для вас связи.
Однажды мы наблюдали, как PM сделала построчные аннотации к дизайну продукта, связав каждое решение с потребностями клиента, чтобы все понимали, почему дизайн должен быть именно таким. И этот, возможно, «маниакальный» подход стал настоящим хитом; люди стали быстрее соглашаться с ее замыслами и воспринимать ее как клиентоориентированного PM. С тех пор ее команда была уверена, что все ее предложения не просто «кажутся ей правильными», а хорошо обоснованы.
РАЗВИВАЙТЕ ИНТУИЦИЮ
Со временем вы почувствуете, что пора переходить от медленных, тщательно выстроенных процедур получения информации о пользователе к более быстрым процессам и интуитивно выбирать области, на которых нужно сосредоточиться.
Чем больше вы будете следить за исследованиями потребностей пользователей и замечать в них закономерности, тем сильнее разовьете свою интуицию. Составьте список ошибок, с которыми уже сталкивались вы или другие PM. Анализируйте ситуации, в которых что-то идет не так или возникает нечто неожиданное, и делайте выводы. Обсуждение идей с вашей командой также поможет закрепить новое знание в вашей памяти и сформировать паттерны.
РАССТАВЛЯЙТЕ ПРИОРИТЕТЫ
Нужно ли устранять все обнаруженные вами проблемы с юзабилити продукта? Это сложный вопрос. И ответ как это часто бывает в жизни (и в управлении продуктами) таков: все зависит от ситуации.
Когда у вас мало опыта, решение проблем, возникающих при использовании продукта, должно стать для вас повседневной задачей. Как правило, на этом этапе вы еще только устанавливаете планку качества своей работы и часто действуете в авральном режиме. Плохо, если команда увидит в ваших действиях небрежность. Поэтому да, будьте внимательны даже к самым мелким проблемам юзабилити продукта.
Однако по мере продвижения по служебной лестнице такая сосредоточенность может дать обратный результат. Вы должны показать, что, с одной стороны, вы цените качество, а с другой действуете разумно в ситуации сложного выбора. Каждый раз сравнивайте затраты и ожидаемый эффект от тех или иных решений. И не стоит пропускать второстепенные потребности пользователей. Установите им более низкий приоритет, но не игнорируйте.
Не надо полагать, что качество не имеет значения. Имеет и еще как! Но главное здесь баланс. Хороший PM понимает, когда обнаруженная проблема с юзабилити важна настолько, что нужно отложить запуск продукта на три недели.
РАСПРОСТРАНЯЙТЕ ЗНАНИЯ О ПОТРЕБНОСТЯХ КЛИЕНТОВ
Отличить опытного PM от новичка можно по тому, как он раскрывает актуальную информацию о клиентах.
Первый обычно действует так:
В ходе совещаний приводит примеры из жизни.
Указывает другим PM на интересные пользовательские исследования.
Выступает с общекорпоративными докладами, где дает ключевую информацию о предпочтениях клиентов.
Предоставляет руководству полученные сведения и их стратегический анализ.
Мы рекомендуем делиться знаниями, которые могут помочь вашей команде и компании в целом в принятии правильных решений.
ДОКАПЫВАЙТЕСЬ ДО СУТИ, КОТОРАЯ ПОМОЖЕТ ВСКРЫТЬ ПРОБЛЕМУ
ШУТКА О ГЕНЕРАТОРЕ
В одной компании сломался крупный генератор, и никто из инженеров не мог понять, в чем проблема.
Вызвали ремонтника. Тот прислушался к тому, как работает установка, и поставил крестик мелом на одной из деталей. «Проблема здесь», сказал он. Инженеры осмотрели указанное место, поняли, в чем дело, и устранили неполадку. Когда ремонтник выставил счет на $10 000, компания отказалась платить и запросила его расшифровку. Ремонтник с радостью выполнил просьбу и ответил так:
Мел: $1.
Знание, где поставить крестик: $9 999.
Примерно так и выглядит глубокое понимание потребностей клиента вы должны видеть связи между фактами и знать, какая информация важна в конкретной ситуации.
Как этому научиться? Получив некие сведения о клиенте, вы должны сразу просчитать их влияние на вашу работу. Какие принятые решения они могут изменить? Какие решения они затронут в будущем? Продумывайте все заранее и тогда в будущем у вас будет больше шансов вспомнить что-то именно тогда, когда это будет действительно важно.
Концепции и фреймворки
РАБОТА, КОТОРУЮ НУЖНО СДЕЛАТЬ (JTBD)
Вы можете знать возраст, адрес и род занятий ваших пользователей, но эта информация ничего не скажет вам о том, что для них действительно важно. Что именно они хотят сделать с помощью вашего продукта?
Идея, которую популяризовал Клей Кристенсен (Clay Christensen), одновременно проста и сложна. Он объясняет ее так:
«Люди не просто покупают товары или услуги, они их нанимают, чтобы успешно решить тот или иной вопрос. Чаще всего они совершают покупки, чтобы решить проблему, с которой они столкнулись».
Рассмотрим, к примеру, покупку музыкального приложения. Какую «работу» хочет выполнить пользователь?
Первым на ум приходит наивный ответ он хочет послушать музыку (да конечно!). Если бы это было так просто, достаточно было бы сделать приложение для прослушивания старых, полюбившихся пользователю композиций. В крайнем случае, можно добавить возможность самостоятельно составлять плейлисты.
Более развернутый ответ (в зависимости от конкретного приложения и пользователя) звучит так: «Я устраиваю вечеринку и хочу создать приятную атмосферу. Мне нужно то, что понравится моим друзьям и поднимет всем настроение». И этот ответ ведет нас к новому вопросу: «Как создать плейлист под определенное настроение?»
Методология «Работа, которую нужно сделать» (Jobs To Be Done, JTBD) используется для изучения мотивации и поведения клиентов[21].
Чтобы прописать сценарий использования продукта по методу JTBD, можно воспользоваться следующим шаблоном:
Когда я <ситуация>, я хочу <мотивация>, чтобы я смог <ожидаемый результат>.
Например, «когда я устраиваю вечеринку, я хочу ставить веселую музыку, чтобы мы с друзьями хорошо провели время».
Говоря с потенциальным клиентом, постарайтесь выяснить, для какой «работы» он хочет «нанять» ваш программный продукт. И не останавливайтесь на этом, копните глубже. Спросите почему.
ПУТЬ КЛИЕНТА
Путь клиента представляет собой описание этапов, которые человек проходит в течение всего периода использования продукта. Все они интуитивно нам знакомы. К сожалению, многие PM акцентируют свое внимание только на последних этапах.
Рассмотрим упрощенный пример пути клиента для приложения Netflix.
Осведомленность: я узнал (возможно, много лет назад), что Netflix существует.
Рассмотрение: я выяснил, что на Netflix есть мой любимый сериал. Я подумываю о том, чтобы оформить ради этого подписку. Но стоит ли оно того? Может, лучше просто купить фильм на Amazon?
Покупка: я решил оплатить подписку на Netflix.
Удержание: продолжаю платить за Netflix (потому что он мне нравится или потому, что я забыл отменить подписку).
Лояльность: на вопросы друзей я отвечаю, что любимый сериал смотрю на Netflix. И добавляю, что, похоже, у них хороший выбор фильмов и сериалов.
Улучшение на любом из этих этапов может повлиять на успех вашего продукта. Поэтому задавайте клиентам текущим и потенциальным вопросы по каждой стадии. Как появляется осведомленность? Что ведет от осведомленности к рассмотрению? А от рассмотрения к покупке? И так далее. Ищите факторы, которые влияют на каждый этап.
РЕКОМЕНДАЦИИ ПО ЮЗАБИЛИТИ ПРОДУКТА
Каждый PM должен знать общие принципы юзабилити продукта. Поэтому рекомендуем запомнить приведенные ниже пункты, чтобы не делать глупых ошибок.
Золотым стандартом в области удобства использования программных продуктов стали эвристические правила, созданные компанией Nielsen Norman Group.
10 основных принципов юзабилити[22]
Эти принципы, описанные Джейкобом Нильсеном (Jakob Nielsen), называют эвристическими, потому что они представляют собой общие универсальные правила, а не специальные указания по юзабилити продукта.
1. Видимость статуса системы
Система должна постоянно информировать пользователя о том, что происходит. Клиенту нужна хорошая обратная связь, предоставляемая в разумные сроки.
2. Соответствие системы и реальности
Система должна использовать язык пользователя знакомые ему слова, фразы и понятия, а не узкоспециальные термины. Следуйте общепринятым нормам подачи информации, выстраивая ее в естественной и логической последовательности.
3. Пользовательский контроль и свобода действий
Пользователи часто включают те или иные системные функции по ошибке, и им требуется четко обозначенный «аварийный выход», чтобы быстро и без лишних усилий отменить нежелательное действие. Предоставьте пользователю возможность отменять операции и повторять их заново.
4. Последовательность и соответствие стандартам
У пользователя не должно возникать сомнений по поводу значения слов, ситуаций или действий. Следуйте принятым для конкретной платформы стандартам.
5. Предотвращение ошибок
Сообщения об ошибках, безусловно, необходимы. Но тщательно проработанный интерфейс, позволяющий избежать проблем, намного полезнее. Устраните условия возникновения ошибок или проверьте систему на наличие таких условий и предоставьте пользователю возможность подтверждать свои действия перед выполнением операций.
6. Распознавание вместо запоминания
Сведите к минимуму нагрузку на память пользователя, сделав объекты, действия и параметры интерфейса видимыми. Избавьте пользователя от необходимости запоминать какую-либо информацию, переходя от одного действия к другому. Подсказки по использованию системы должны быть заметными и легко доступными.
7. Гибкость и эффективность использования
Инструменты быстрого доступа, незаметные для новичков, помогают опытным пользователям ускорить свое взаимодействие с системой. В результате она отвечает требованиям клиентов с любым уровнем опыта. Предоставьте им возможность самостоятельно настраивать быстрый доступ.
8. Эстетичность и минимализм дизайна
Диалоговые области интерфейса не должны содержать посторонние или редко используемые сведения. Каждая дополнительная единица информации будет оттягивать внимание пользователя от важных блоков, тем самым снижая их заметность.
9. Распознавание, диагностирование и исправление ошибок
Сообщения об ошибках должны быть написаны простым языком (без кодов), точно указывать на проблему и предлагать решение.
10. Справка и документация
В идеале система должна быть такой, чтобы изучать сопроводительную документацию не требовалось. Но иногда справочная информация необходима. В этом случае она должна быть доступной, краткой, ориентированной на задачу пользователя и содержать конкретные шаги по ее выполнению.
Помимо перечисленных выше правил, существует несколько общих рекомендаций, которые следует запомнить:
Ограниченное внимание: в жизни пользователи обращают на пользовательский интерфейс (user interface, UI) намного меньше внимания, чем вам кажется. Люди подсознательно игнорируют большие кричащие баннеры и любые другие элементы, похожие на рекламу. Они не читают длинные абзацы и даже предложения. В любой момент их могут прервать или отвлечь. Если им не будет четко понятна последовательность действий, они даже не попытаются в ней разобраться.
Свободное пространство и пропорции: реакция людей на продукт обычно интуитивна, и пропорции элементов интерфейса, а также организация свободного пространства серьезно влияют на мнение пользователей. Сэкономишь на пространстве интерфейс будет казаться перегруженным и запутанным, а переборщишь с пустотами будет выглядеть слишком примитивным и скучным. Практически невозможно получить полезный отзыв об интерфейсе, в котором эти детали не продуманы, потому что они вызывают очень негативную реакцию.
Доступность: около 4 % населения страдают той или иной степенью дальтонизма, а около 2 % населения имеют другие нарушения зрения[23]. Тестирование продукта на совместимость с программами считывания с экрана, предназначенными для слабовидящих и людей с цветовой слепотой, позволит избежать потери некоторых пользователей. Важные объекты UI желательно не только выделить цветом или обозначить изображением, но и снабдить альтернативным текстом. В придачу ко всему от так называемого универсального дизайна, который применяют, чтобы сделать продукт доступным для людей с ограниченными возможностями, выигрывают и обычные пользователи[24].