UX-стратегия. Часть 5 — Дизайн с выхлопом
Статья написана для журнала UXmatters (часть 2 на подходе).
Общий язык бизнеса и дизайна
Дизайнеры отстаивают права пользователя, но апеллируют к вещам, которые непонятны менеджерам — лучшим практикам, гайдлайнам, чужому опыту или просто «во-первых, это красиво». Они не всегда могут переложить их на свой продукт. Laura Martini проводит правильную аналогию: бухгалтеры не говорят, что зарабатывают, заполняя таблицы приходов и уходов, а кадровики — что получают деньги за звонки и письма кандидатам; они говорят о ценности для бизнеса — здоровые финансы и усиление команд, соответственно. Лучше перевести боль пользователей на язык бизнеса, а не продолжать спорить — тогда будут довольны все.
Один из примеров — Design Value Index. Это индекс капитализации компаний, инвестирующих в дизайн — в 2015 году он вырос на 211% сильнее фондового индекса S&P 500.
Design Value Index, 2015 © DMI
На самом деле нет. Bloomberg сопоставили American Customer Satisfaction Index и рыночную динамику 190 ведущих компаний — всё наоборот.
Сопоставление American Customer Satisfaction Index и рыночной динамики 190 ведущих компаний © Bloomberg
На самом деле правы оба индекса. На конкурентном B2C-рынке качество продукта и обслуживания очень важны для успеха на рынке. Но если продажи мало зависят от мнения конечного пользователя (монопольные отрасли, государственные сервисы, корпоративное ПО с централизованными закупками), работают другие закономерности. Кроме того, вложения в качество продукта нацелены на долгосрочную перспективу, они не покажут быстрого результата.
Поэтому недостаточно ссылаться на успех других компаний — их бизнес может работать по другим принципам.
Нужно трезво оценивать текущую ситуацию и понимать, где дизайн может принести пользу бизнесу. Иначе вы останетесь двигателями пикселей или игрушкой в руках менеджмента.
Решение проблем бизнеса — это основная задача дизайнеров после самого базового — помощи в разработке продуктов. Компании, конечно, важно, насколько хорошо мы делаем свою работу — дизайн не должен задерживать вывод продуктов и их обновлений на рынок, а его качество должно быть достойным. Но это только маленький кусочек. Ещё лучше, если дизайнеры помогут бизнесу принимать лучшие продуктовые решения. Или даже находить новые возможности для роста.
Именно это позволит дизайн-команде стать не просто исполнителем и продвинуться по модели зрелости от оперативного (насколько хорошо специалист делает свою работу) и тактического уровней (насколько хорошо выстроен процесс производства продукта) к стратегическому (куда и насколько успешно развивается компания). В итоге — влиять на то, что и зачем делает компания.
Дизайн должен решать проблемы бизнеса
Дизайнеры часто жалуются, что их не привлекают к работе по определению продукта. Требования приходят от менеджеров и они просто рисуют картинки. Где-то это обусловлено незрелостью компании и менеджмента, где-то — слабостью и недальновидностью самих дизайнеров.
Начните с себя — нужно повышать авторитет дизайн-команды и не оставлять хвосты, решая базовые проблемы на оперативном и тактическом уровнях (про это я достаточно написал в 2–4 частях). Но если вы хотите влияния на продукт — боритесь! Важно показывать и доказывать ценность дизайна — мы много знаем о пользователях, а это важно менеджерам продуктов для принятия решений. Тогда вас начнут приглашать не только для производства макетов и прототипов. Bobby Ghoshal из WeWork говорит, что 80% дизайн-решений принимаются вне пикселей — на обсуждениях, презентациях, отчётных встречах и т.п. — и важно уметь аргументировать свои идеи.
Melissa Perri и Scott Sehlhorst показывают, что менеджер продукта и дизайнер пересекаются во многом. Часть из этого касается вполне привычных проектных артефактов, которые дизайнеры давно и успешно делают. Но самое главное — проблемы пользователей. Уметь находить их, оценивать важность для клиентов (цели, контекст, мотивация и возможности) и самого бизнеса (продуктовая стратегия, конкуренция, организационный потенциал и т.п.), а в итоге — способность предложить и наглядно представить будущее, в котором проблема решена — вот где ключевые точки роста для дизайн-команды, стремящейся к зрелому UX.
Общий язык и проблемы © Melissa Perri
В зрелой компании с кросс-функциональными командами дизайнеры помогают менеджерам продуктов принимать решения. Где и какие? Представим идеализированный процесс работы над продуктом:
- Продуктовая гипотеза. Поиск нерешенных проблем пользователей, которые мог бы закрыть наш продукт, чтобы увеличить показатели бизнеса.
- Предварительная валидация. Аналитическая оценка того, насколько востребованным и коммерчески оправданным может быть такой продукт.
- Дизайн и разработка. Производство продукта или функциональности в нужные сроки и качество.
- Тестирование решения. Предварительная оценка того, насколько продукт подходит целевой аудитории.
- Дистрибьюция продукта. Привлечение пользователей по разным каналам и рынкам, возможно с разными посылами и ценностями. Плюс организация бесшовного перехода пользователя между каналами.
- Обратная связь от рынка и пользователей. Реальная оценка продукта и внесение изменений в него, будь то детали реализации, возможности или концепция/целевая аудитория в целом.
- Поддержка пользователей. Решение проблем, возникающих при использовании продукта, с которыми пользователи обращаются в службу поддержки, социальные сети и другие каналы связи с компанией.
Идеализированный процесс работы над продуктом или функциональностью
Модель разработки продуктов и их новых функций последние 10–15 лет становится всё более динамичной, поэтому эта схема достаточно условна — полно как более итеративных, так и более консервативных примеров. Кроме того, в реальном мире первые этапы зачастую сокращаются до готового продуктового плана. Но это не меняет сути.
Lean-модель работы над продуктом или функциональностью © Jason Evanish
Если по ходу всей этой цепочки дизайнеры будут всегда помнить о том, для чего компания решает конкретные проблемы и как эти решения влияют на бизнес, фокус переместится с проектных артефактов и методов на продуктовую работу. И мы наконец-то будем не просто решать задачи разработки, а влиять на ключевые показатели бизнеса и, возможно, даже внедрять инновационные идеи. Эта трансформация роли дизайнеров состоит из трёх этапов:
- Помощь в поиске и решении проблем бизнеса и пользователей.
- Оценка максимального выхлопа при решении проблем.
- Переход от решения проблем к инновациям
Шаг 1. Помощь в поиске и решении проблем
Если вынести разработку продукта за скобки, то перед продуктовой командой и её менеджером стоят три основные задачи:
- Найти нерешённые проблемы пользователей (пространство проблем)
- Понять, что и как делать для решения проблемы (пространство решений)
- Оценить, насколько хорошо решена проблема (как развивать продукт)
Их можно представить как цепочку «проблема → решение → валидация». Продуктовая команда пройдёт по ней эффективнее с помощью инструментов, которые есть у UX-специалистов. Многие компании начинают интеграцию дизайнеров с последнего этапа, организуя процесс юзабилити-тестирования — это сравнительно просто, а выхлоп сразу понятен. Но если включиться во все три, можно радикально повысить ценность работы дизайнеров.
1. Найти нерешённые проблемы пользователей
Один из путей запуска новых продуктов и развития существующих — идти от ещё нерешённых проблем пользователей. Если потенциальная аудитория достаточно велика и есть перспективы монетизации, компания может предложить им подходящий продукт. Что в этом случае делает менеджер продукта:
- Оценка рынка (ёмкость в деньгах и аудитории, основные продукты-конкуренты, типичные бизнес-модели, перспективы роста, карта предметной области).
- Исследование конкурентов (доли рынка, бизнес-модели, функциональность продуктов, маркетинг).
- Функциональная матрица (сравнение функций, которые есть в продуктах-конкурентах).
- Оценка целевой аудитории (сегментация, предпочтения, ожидания, проблемы, платёжеспособность).
- Построение бизнес-модели.
Не всегда преимущество идёт от самого продукта (где-то конкурентная борьба выигрывается более дешёвой ценой или новыми каналами дистрибьюции; кто-то начинает с технологии). Но если дело всё-таки в нём самом, то дизайн-команда может здорово помочь менеджеру продукта:
- Исследование пользователей и их потребностей. Этнографические исследования, интервью, опросы, дневники, фокус-группы, работа с аналитикой дадут много полезной информации о важности проблем и особенностях целевой аудитории (сегменты, поведение, мотивация, контекст, ментальные модели и модели потребления, ожидания, страхи и предубеждения).
- Анализ продуктов-конкурентов. Сравнительное юзабилити-тестирование, экспертная и эвристическая оценка и методы пользовательских исследований из предыдущего пункта. Они покажут, насколько хорошо проблемы решают другие компании на рынке и что пользователи считают особенно важным.
Для формализации проблем пользователей всё чаще используется методика Jobs to Be Done. Применительно к цифровым продуктам про неё сейчас много пишут Intercom и James Kalbach. Job stories показывают, какие жизненные ситуации вызывают у пользователей проблемы (функциональные, эмоциональные, социальные), за которые они готовы платить. Схожий подход к поиску и описанию потенциальных проблем описывают HubSpot.
Job story © Alan Klement
Модель Jobs to Be Done: 4 силы © Intercom
Модель Jobs to Be Done: Жизненный цикл © Intercom
Модель Jobs to Be Done © James Kalbach
Jobs to be Done являются ещё и способом сегментации пользователей по потребностям. Раньше дизайнеры использовали для этого персонажей, но этот инструмент в последнее время потерял былую славу — мало кто эффективно использует их по ходу всей работы над продуктом, а не только в начале. Кроме того, у JTBD чёткий фокус на проблемах, в то время как персонажи часто тратят много времени на описание личных характеристик, притом — взятых из головы, а не пользовательских исследований. Именно проблемы проще использовать как фильтр последующих продуктовых решений. Хотя персонажи всё ещё отлично прокачивают у продуктовой команды эмпатию к своим пользователям. И если сегментация аудитории продукта достаточно чёткая, персонажи в связке с JTBD станут отличным инструментом.
Схожую задачу связки описания портрета пользователя и его проблем облегчает Value Proposition Canvas. Этот подход показывает, как бизнес планирует решать проблемы пользователей через предоставление им ценности.
Фреймворк The Value Proposition Canvas © Alexander Osterwalder
Хороший инструмент для более детального анализа проблем пользователей — customer journey map (карта взаимодействия с продуктом) и experience map (более абстрактный процесс решения жизненной проблемы). Это язык дизайнеров, которому полезно научить менеджеров (причём наиболее продвинутые из них уже распробовали его). Хотя в дополнение к этим двум форматам выделяют ещё и service blueprints (как компания оказывает сервис), многие эксперты советуют не убиваться по поводу семантической точности и соответствия шаблонам — главное, чтобы карта помогала в работе.
Customer Journey Map © Macadamian
Experience Map © Beth Kyle
Такие карты показывают, как пользователь решает свою задачу сейчас (в конкретном продукте и вне привязки к нему), отмечая ключевые этапы этого сценария, а также позитивные и проблемные места в них. Они могут включать полный цикл приобретения компанией клиента от его осведомлённости о продукте до активного использования и рекомендаций знакомым, либо взаимодействие с отдельным большим куском сервиса. Если речь идет о новом продукте компании, карта поможет представить его основные функции; если о существующем — покажет узкие места, решение которых позволит развивать его. Причём карта затрагивает как цифровой продукт, так и сопроводительные сервисы в других каналах взаимодействия с пользователем (включая офлайн). А это глубокий взгляд на проблему, дающий ещё больше полезной информации для принятия решений.
Карта взаимодействия не обязана быть сложной и эффектной, как в примерах выше. Главное, чтобы она помогла визуализировать проблемы пользователей.
Customer Journey Map в упрощённом варианте © Shopify
Правда, выхлоп зависит от сложности сценариев использования. Одностраничный промо-сайт лучше включать в общую карту взаимодействия с продуктом, который он продаёт — взаимодействие с самим лендингом слишком примитивно. Если же продукт обрабатывает много сценариев, но всё равно атомарных (например, интернет-поиск) — поможет скорее сложная аналитика и поведенческая сегментация пользователей.
В реальности компании зачастую идут от возможности на рынке, быстро запуская продукт и итеративно развивая его, а понимание пользователей прикладывается позже. В таком случае многие углы срезаются и пользовательские исследования не проводятся. Но для успешного роста продукта необходимость понимать своих клиентов важна, поэтому к этим вопросам менеджер продукта рано или поздно вернётся. Тем более, что фокус зрелых компаний всё чаще смещается с решения проблем на их поиск, а без понимания пользователей эти возможности ограничены.
2. Понять, что и как делать для решения проблемы
Когда проблема изучена достаточно хорошо, а её важность и ценность для пользователей достаточно велики, менеджеру продукта необходимо предложить продуктовое решение для целевой аудитории. Что в этом случае делает менеджер продукта:
- Видение продукта (как мы решим проблемы пользователей, чтобы компания имела коммерческий успех или достигла других целей).
- Возможности продукта (функциональный набор, ранжированный по ценности для пользователей и бизнеса).
- Концепция или прототип решения (или нескольких альтернативных).
- План производства, запуска и распространения (можно ли сразу делать первую версию или для начала нужно проверить основные гипотезы; какая команда и ресурсы нужны для этого).
Здесь участие дизайн-команды более активное и мы можем ещё больше помочь менеджеру продукта:
- Оценка отношения пользователей к продуктовой идее. Хотя на совсем ранних стадиях, когда нет даже прототипа, пользователям сложно оценить свой интерес к продукту, есть форматы опросов и интервью для того чтобы прощупать их.
- Проверка гипотез с помощью прототипа решения. Создание статических и интерактивных прототипов, псевдо-автоматизированных сервисов с ручной обработкой заказов и уйма чего ещё — есть большой спектр дешёвых решений. После этого — тестирование: качественное (интервью, юзабилити-тестирование) или количественное (аналитика после запуска на небольшую аудиторию, сравнение нескольких вариантов решения) и итеративная доработка прототипа.
Проверка гипотез — главное место для принесения пользы дизайнерами. Причём благодаря популяризации практик дизайн-мышления, компании всё активнее «думают руками», создавая прототипы решений. А с распространением lean-подходов важность быстрой итеративной работы на ранних этапах повысилась.
Хотя гипотезы проверяются на следующем этапе, ставить их нужно на этапе предложения решений (да и сама постановка проблемы является, по сути, гипотезой). Важно понять, как мы убедимся, что предложенная концепция действительно решает выбранную проблему пользователей. Для этого нужно определиться с экспериментом: способом проверки (как и какие пользователи и увидят концепцию), метрики успешности (какие статистически значимые данные аналитики или пользовательских исследований подтвердят гипотезу) и минимальным набором функций (MVP (minimum viable product): какие сценарии должна отрабатывать концепция). Во многом это задача менеджера продукта, но дизайн-команда владеет многими методами для проверки гипотез и в зрелой компании активно вовлечена в процесс.
Интересный подход к описанию гипотез предлагает John Cutler.
Формат описания гипотез © John Cutler
Исходя из этого возможна разная степень проработки прототипа, в зависимости от самой гипотезы и стадии процесса: от грубого показа ключевых шагов в виде структурных схем экранов до полноценной отработки customer journey map на реальных данных, включая начальное обучение. Здесь важна уместность для текущей стадии проекта и глубины понимания продукта и пользователей.
Интересный формат описания связки проблемы и решения предлагает Nikkel Blaase.
Формат описания проблемы и решения © Nikkel Blaase
3. Оценить, насколько хорошо решена проблема
Когда продукт приближается к запуску и после самого релиза, менеджеру необходимо убедиться, что качество реализации на должном уровне, а пользователи понимают, как с ним работать и довольны результатом. Что он делает в этом случае:
- Проверка изначальных гипотез (востребован ли продукт рынком, решает ли поставленные задачи бизнеса, насколько хороши основные показатели, соответствует ли продукт ожиданиям пользователей (изначальным и сформированным нашим маркетингом)).
- Оценка качества реализации продукта (всё ли работает, не забыты ли важные функции или элементы интерфейса, понятны ли пользователям интерфейс и концептуальная модель в целом).
- План развития продукта (ранжированный список проблем и решений для них; план внедрения доработок).
В lean-среде переход от гипотезы и MVP к ранней версии продукта и его релизу не всегда чёткий, поэтому этапы 2 и 3 бывает сложно разделить. Но в целом это классическая задача для дизайн-команды, когда мы помогаем менеджеру продукта улучшить его:
- Поиск проблем в продукте. Пользовательское тестирование, экспертная и эвристическая оценка, аналитика позволяют проверить гипотезы и обнаружить проблемы.
- Ранжирование проблем по ценности для бизнеса и пользователя. Среди них нужно выбрать наиболее критичные по нескольким параметрам, включая потребительские качества — время выполнения задач, количество ошибок и т.п. Проблемы продукта можно показать по ходу сценариев работы пользователя — это упростит выбор конкретных решений.
- Проверка решений проблем. Ещё один цикл выдвижения гипотез и проведения экспериментов для решения проблем. Кстати, дизайн-команда должна следить за попаданием исправлений в roadmap.
Это хлеб с маслом для продуктовых дизайнеров и пользовательских исследователей; первая роль, для которой они привлекаются даже в не самых зрелых компаниях. Формат работы прост и понятен, хотя зачастую бывает нелегко добиться внесения изменений. Молодые дизайн-команды могут начинать с этой стороны, а потом вовлекаться в продуктовую работу глубже. При этом важно привлекать менеджеров продуктов к самим пользовательским исследованиям и тестированию как наблюдателей. Они увидят проблемы в продукте своими глазами и будут больше доверять дизайнерам (а вам будет интересно посмотреть все пять стадий принятия неизбежного).
Правда, протестировать и проанализировать все гипотезы не получится. Важно научиться сопоставлять количество новой информации, которое команда получит после проведения исследования, и затраты времени и ресурсов, необходимых для этого. Часто мы можем полагаться только на экспертное мнение, так что умение грамотно доносить свои аргументы — не менее важный навык. Ed Catmull говорит, что избитая фраза «вы не можете управлять тем, что вы не измеряете» многие воспринимают излишне буквально — слишком много скрытых паттернов и взаимозависимостей существует в любом наборе данных, так что надо осознавать, что зачастую даже на основе данных мы строим только предположения.
Очень хорошие мысли на этот счёт высказывает Taylor Palmer (продолжение): любые дизайн-активности правильно воспринимать как «активности по обучению», а значит и дизайн-инструменты — в первую очередь «инструменты для обучения». Хорошую карту методов исследований под конкретные задачи предлагают Meena Kothandaraman и Zarla Ludin:
Карта методов пользовательских исследований © Meena Kothandaraman и Zarla Ludin
Для большей наглядности того, как работает продукт и какие проблемы стоит решать в первую очередь снова пригодится customer journey map. Проблемы продукта можно показать по ходу сценариев работы пользователя — это сделает выбор для решения конкретных из них проще. Здорово, если отмечать проблемы и инсайты на карте (как и создавать её изначально) вы будете с менеджером продукта — это даст общее понимание того, как работает продукт. Полезные мысли на этот счёт есть у Scott Sehlhorst и 3M.
Карта взаимодействия, на которой отмечены проблемы в интерфейсе
Хороший способ организации внутренней работы дизайн-команды по всей цепочке от поиска проблем до предложения и проверки решений предлагает Optimizely. Они организовали специальную канбан-доску, показывающую постепенное углубление в проблему и решение:
Канбан-доска Optimizely
А Atul Handa и Kanupriya Vashisht показывают отличный формат планирования исследовательских активностей в современных динамичных проектах. Они делят их на три типа: стратегические (помогают сформировать продуктовое видение, стратегические цели и roadmap, а также сегментировать целевую аудиторию), тактические (помогают в работе над конкретными функциями и комплексными взаимодействиями) и валидация (проверка гипотез, оценка дизайн-решений, поиск проблем).
Исследования в agile-процессе © Atul Handa и Kanupriya Vashisht
Шаг 2. Оценка максимального выхлопа при решении проблем
После того как дизайн-команда помогла менеджеру продукта найти нерешённые проблемы пользователей и продуктовые решения для них, нужно следить за попаданием исправлений в roadmap и проверять, что проблемы действительно решены.
Правда, абсолютно все проблемы, баги и недоделки продукта исправить невозможно. Это бесконечный процесс, который, к тому же, отнимает ресурсы у внедрения новых функций. Задача дизайнеров — вместе с менеджером продукта оценить, какие доработки дадут максимальную пользу для бизнеса и пользователей.
Если посмотреть на работу компании как бизнеса в целом, то общая картина покажет, куда она движется и какие проблемы стоят перед ней. Помимо понимания предпосылок, которыми руководствуются топ-менеджмент и менеджеры продуктов, дизайн-команда сможет сама предлагать направления развития сервисов. В первой части серии я описывал контексты жизни компаний — в них разные проблемы, задачи и потребности. На каждом мы можем быть полезны по-своему, и наша роль (а также инструментарий и методы работы) должны отличаться:
- Поиск подходящего рынка, продуктового решения и бизнес-модели для его монетизации. Продукт просто обязан меняться часто и может быть даже кардинально, чтобы компания выжила.
- Рост пользовательской базы и/или прибыли. Продукт обрастает новыми функциями, получает новые способы распространения.
- Удержание пользователей. Появляется потребность отстройки от конкурентов — с помощью повышения потребительских качеств, расширения возможностей продукта, оптимизации ключевых сценариев использования, усиления важности бренда, рыночной дифференциации.
- Эффективность ведения бизнеса. Становится важно ускорять и упрощать процесс создания и развития сервисов, в том числе — их дизайна. Особенно это характерно для компаний, имеющих линейку продуктов.
- Вывод продукта из кризиса, когда падают пользовательская база, прибыль или рыночная доля — всё сразу или что-то из них. Можно сказать, что это возврат к первому контексту и возможны два сценария — постепенная эволюция или радикальные изменения.
В каждом из этих контекстов есть свои показатели здоровья компании и её продуктов. Если дизайнеры помогут улучшить их, то станут ещё ценнее. А если помимо решения проблем бизнеса находить и использовать возможности для его роста, уважение к дизайн-команде станет ещё сильнее.
В этом разрезе призма «проблема → решение → валидация» станет более полной — «целевые показатели бизнеса → возможность на рынке (проблема пользователей или недоработка продукта) → решение → валидация → рост бизнеса». А это общий язык, на котором дизайнеров всегда поймёт менеджмент — многие интерфейсные изменения можно привязать к ценности для бизнеса.
Помимо стадии жизненного цикла важно понимать бизнес-модель продукта (прямые продажи, подписка, freemium, open source, реклама, партнёрский клуб, посредничество, франчайзинг, краудсорсинг, аукцион и обратный аукцион, лизинг и т.п.), уровень конкуренции, тип рынка (B2C, B2B, бизнес с государством или некоммерческими организациями), его состояние (существующий, новый, региональный клон) и сегментация (по цене или нише). Это сильно влияет на дистрибьюцию и маркетинг, выбор метрик, а значит и фокус на проблемах пользователей и бизнеса. Что в конечном итоге определяет то, привнесения какой ценности компания ожидает от дизайнеров.
Метрики продукта и бизнеса
Для оценки здоровья бизнеса в целом и конкретных продуктов есть ряд метрик. Они покажут, есть ли у продукта проблемы, которые нужно решать. Эти метрики отображают текущее состояние и помогают оценить перспективы роста. В общем смысле «метрика» — это собираемая и измеряемая оценка, которая позволяет отслеживать эффективность определённого критерия работы продукта или бизнеса в течение времени. Метрика говорит, что что-то происходит, а её анализ — почему это происходит.
Метрики могут относиться как ко всей базе пользователей, так и к определённым сегментам аудитории. Понимание процентного и абсолютного числа пользователей, чью проблему решает новая функция или улучшение существующей — ещё одна важная часть общего языка между дизайнером и менеджером продукта. Абстрактные улучшения для абстрактных людей сложнее продать.
1. Деньги
Самый прямой индикатор успешности коммерческого продукта. В зависимости от бизнес-модели, этапа развития бизнеса и особенностей продукта, можно считать заработанные, потраченные и сэкономленные деньги:
- LTV (lifetime value, также встречается как CLV и CLTV) — среднее количество денег, которые приносит клиент за всё время использования продукта.
- Конверсия — какой процент потенциальных покупок, подписок или других ключевых действий совершается в реальности.
- Рекламная прибыль — насколько хорошо работает медийная, контекстная и нативная реклама.
- Стоимость привлечения клиента — сколько денег уходит на дистрибьюцию в расчёте на одного пользователя.
- Экономия — экономия на службе поддержки, сокращение времени выполнения ключевых операций с помощью продукта.
Их расчёт — тема отдельной статьи. Часть из этого я затронул в своей публикации на UXmatters несколько лет назад. И хотя дизайн-решения часто влияют на них только опосредованно, важно всегда помнить о денежных метриках.
2. Отношение пользователей к продукту
Настроения пользователей — зачастую косвенные показатели, но они хорошо отражают отношение к компании и продуктам. Если следить за их изменениями, можно прогнозировать и денежные метрики.
- Коэффициент удержания клиентов (retention или возвращаемость) — сколько пользователей продолжают использовать продукт через определённое время (как правило — неделю или месяц).
- Коэффициент оттока клиентов (churn) — сколько ранее зарегистрировавшихся пользователей перестают использовать продукт через определённое время.
- Число активных пользователей (MAU (monthly active users) and DAU (daily active users)) — сколько зарегистрированных пользователей используют его в течение месяца или дня.
- Удовлетворённость — насколько пользователи довольны продуктом.
- NPS (Net Promoter Score) — готовность рекомендовать продукт.
- Лояльность — комбинированная мера отношения к бренду. Может учитывать возвращаемость, повторные покупки, увеличение среднего чека, готовность рекомендовать продукт. Есть также опросник CLI (Customer Loyalty Index).
- Вовлечённость — активность использования продукта и его отдельных функций. Количество создаваемого контента в UGC, участие в социальном взаимодействии, глубина просмотров отдельных единиц контента и количество просмотренных единиц за сессию, виральность (насколько быстро и активно пользователи делятся контентом).
- Узнаваемость бренда — вспоминает ли клиент о торговой марке при выборе продукта (по одному из трёх критериев: первый названный бренд, спонтанная и подсказанная известность).
Если удовлетворённость отслеживается с задержкой и показывает скорее долгосрочное здоровье продукта, то вовлечённость и коэффициент удержания более динамичны и хорошо подходят для отслеживания реакции на улучшения. Цепочка примерно такая: «вовлечённость → возвращаемость → удовлетворённость → рекомендация». При этом вовлечённость — это скорее собирательное название для широкой группы метрик, которые зачастую уникальны для конкретного продукта. Многие крупные сервисы нащупали свои критерии активности пользователей, ведущих к долговременному использованию. Олег Якубенков приводит несколько примеров:
Пользователь Facebook с очень высокой вероятностью станет регулярно использовать сервис, если за 7 первых дней добавит 10 друзей. Для пользователя Twitter аналогичным критерием является наличие 30 подписчиков. Для пользователей Dropbox — хотя бы один файл, добавленный в папку сервиса. Если вы пройдёте регистрацию на упомянутых выше сервисах, то заметите, что ещё в процессе обучения работе с продуктом вас целенаправленно проводят через шаги добавления друзей или выбора тех, на кого вы подпишетесь. Это как раз та небольшая инвестиция, которая создает мотивацию вернуться для вас, а также даёт разработчику возможности для создания триггеров для вашего возвращения.
Интересный эксперимент проверили менеджеры продукта компании Yammer. Казалось бы, упрощая процесс достижения определенной цели, мы максимизируем долю тех, кто до этой цели доберётся. В целом всё именно так, но максимальное число добравшихся не означает, что такой подход максимизирует долю тех, кто продолжит пользоваться продуктом. Экспериментируя с процессом регистрации, они обнаружили, что удаление лишних шагов, на которых пользователи как раз делали свои первые небольшие инвестиции, повышает конверсию туториала, при этом ухудшает метрики использования сервиса в среднесрочной и долгосрочной перспективе.
Invesp пишут, что 44% компаний фокусируются на привлечении пользователей против только 18% компаний, ориентирующихся на возвращаемость. При том что затраты на привлечение превышают затраты на удержание в пять раз. Это полезное напоминание и для дизайнеров, на чём стоит фокусироваться. Samuel Hulick показывает, как строить onboarding для лучшей возвращаемости. А многие эксперты в growth hacking советуют ориентироваться на анализе тех пользователей, которые ос
