Как использовать HEART Framework для улучшения UX программного обеспечения

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

Что такое структура СЕРДЦА?

Структура HEART представляет собой действенную структуру для определения потенциальных областей улучшения пользовательского опыта (UX) в программных продуктах. Аббревиатура « СЕРДЦЕ » означает пять категорий пользовательского опыта: счастье, вовлеченность , принятие , удержание и успех задачи. Далее в этом подробном руководстве мы более подробно определим каждую из этих категорий.

Каждая категория HEART содержит три отдельных компонента, помогающих стимулировать действия и измерять прогресс: цели , сигналы и показатели .

• Цели – это качественные бизнес-цели
• Сигналы — это качественное поведение конечного пользователя, связанное с целями.
• Метрики — это количественные измерения сигналов

В следующем разделе мы приводим определения и примеры целей, сигналов и показателей.

Мы можем визуализировать эту структуру в виде диаграммы HEART, похожей на пример реального продукта, который мы разберем позже:

Для чего вообще существует структура HEART?

Структура HEART была опубликована в 2010 году Керри Родденом , Хилари Хатчинсон и Синь Фу из Google в ответ на более старую структуру состояния продукта под названием PULSE («просмотры страниц, время работы, задержка, активные пользователи в течение семи дней, и прибыль »).

Родден и др. обнаружил, что платформа PULSE не может успешно измерить истинное влияние изменений UX, и стремилась создать альтернативу, которая более точно «измеряла бы качество взаимодействия с пользователем и предоставляла данные, которые можно использовать». Имея в виду эти цели, Rodden et al. разработал фреймворк HEART, который нашел поддержку как в командах дизайнеров UX, так и в командах по управлению продуктами.

Теперь, когда мы знаем, что такое фреймворк HEART, давайте обсудим преимущества использования этого фреймворка для улучшения UX с течением времени.

Преимущества использования фреймворка HEART для UX

Использование структуры HEART обеспечивает три основных преимущества:

1. HEART связывает результаты UX с бизнес-целями
2. HEART поможет вам решить, «что улучшить» с ясностью и детализацией
3. HEART ориентирован на принятие мер, а не на простую отчетность

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

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

Наиболее частой основной причиной этой проблемы было то, что они не связывали желаемые результаты UX с бизнес-целями. Когда я помог им преобразовать цели UX в бизнес-приоритеты, они с большей вероятностью довели свое предложение до финишной черты.

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

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

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

В-третьих, СЕРДЦЕ естественным образом побуждает к действию. Имея структуру HEART, мы сразу же знаем, какие показатели мы стремимся изменить с любым предложением по улучшению UX, мы знаем, какую именно пользу это принесет конечному пользователю, и мы знаем, как именно это отразится на более широком бизнесе.

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

Следующий вопрос, который мы должны решить: кто должен взять на себя инициативу по внедрению HEART?

Кому следует использовать структуру HEART?

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

Дизайнеры лучше всего подходят для:

• Решите, какие цели пользователей имеют отношение к бизнесу
• Определите, какие метрики функций точно способствуют достижению целей пользователей.
• Используйте метрики, чтобы решить, какие улучшения сделать дальше
• Определить, имели ли улучшения ожидаемый эффект

Для продуктов, которые еще не имеют структуры HEART, менеджеры по продукту должны стремиться сократить разрыв.

Менеджеры по продукту лучше всего подходят для:

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

Когда использовать структуру HEART

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

Чтобы помочь нам выбрать правильную степень детализации для HEART, давайте возьмем в качестве примера продукт Google Maps. Функция продукта Google Places показывает сведения об определенном местоположении, включая адрес, рейтинг, отзывы, маршруты, веб-ссылки и другую ключевую информацию.

Если вы нацелены только на конкретное микровзаимодействие, то, скорее всего, вы не получите достаточного возврата инвестиций (ROI), чтобы это упражнение стоило вашего времени. Например, при нажатии на достопримечательность в Google Places есть микровзаимодействие, при котором левая боковая панель выдвигается. Маловероятно, что измерение Вовлеченности «взаимодействия со скользящей полосой» изменит положение пользователя, продукта или бизнеса.

С другой стороны, если вы пытаетесь использовать HEART для улучшения продукта, который содержит множество функций, ваши результаты будут в лучшем случае неясными, а в худшем — противоречивыми. Попытка использовать HEART во всем продукте Google Maps разделит наше внимание на множество функций, от Google Places до Directions, спутникового просмотра и просмотра улиц.

Следуя аналогичной логике, мы должны избегать использования HEART на уровне продуктового портфеля. То есть, если мы попытаемся использовать HEART, чтобы решить, следует ли сосредоточиться на улучшении Google Maps, Gmail или Google Calendar, мы не придем к однозначному выводу.

Погружение в категории HEART

Давайте теперь четко определим каждую из категорий СЕРДЦА: счастье, вовлеченность, принятие, удержание и успех задачи.

Счастье

Во-первых, счастье сосредоточено на эмоциональном состоянии пользователя, когда он использует ваши продукты и функции. Как Родден и др. делится, счастье относится к «субъективным аспектам пользовательского опыта, таким как удовлетворение, визуальная привлекательность, вероятность рекомендации и воспринимаемая простота использования».

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

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

Один из способов измерить уровень счастья — задать вопрос, связанный с показателем NPS: «Насколько вероятно, что вы порекомендуете этот продукт другу или коллеге?»

Еще один способ измерить счастье — задать вопрос Шона Эллиса о соответствии продукта рынку: «Насколько вы были бы разочарованы, если бы больше не могли использовать наш продукт?»

Обручение

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

Имейте в виду, что участие требует, чтобы мы определили «подходящее действие», то есть не все функции одинаково ценны для конечного пользователя. Простой вход в систему или простой просмотр страницы не должны считаться взаимодействием, так как трудно доказать, что такая неглубокая активность создала реальную ценность в жизни пользователя. Вместо этого мы должны измерять действия, создающие ценность для конечного пользователя, используя формулировку, аналогичную «заданиям, которые необходимо выполнить» (JTBD).

Вовлеченность можно разделить на следующие две категории HEART: внедрение (привлечение новых пользователей) и удержание (удержание существующих пользователей).

Принятие

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

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

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

Для более глубокого обсуждения внедрения продукта, ориентированного на клиента, наша команда Product Teacher разработала руководство по внедрению функций.

Удержание

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

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

Чтобы получить более подробную информацию об удержании и оттоке клиентов, ознакомьтесь с подробным руководством по анализу оттока клиентов от Product Teacher.

Успешное выполнение задачи

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

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

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

Приоритет категорий СЕРДЦЕ

Теперь у нас есть четкое представление о пяти категориях HEART: счастье, вовлеченность, усыновление, удержание и успех задачи. Прежде чем мы двинемся дальше, обратите внимание, что категории СЕРДЦА естественным образом находятся в противоречии друг с другом.

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

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

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

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

Разрушение компонентов СЕРДЦА

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

Цели

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

Основная гипотеза любой функции программного обеспечения заключается в следующем: «мы получаем ценность для бизнеса, создавая ценность для конечного пользователя». Не попадитесь в ловушку создания ценности исключительно для конечного пользователя, не определяя, как получить ценность для бизнеса. Когда бизнес не учитывается, проекты UX обычно не выходят из фазы предложения, поскольку заинтересованные стороны бизнеса не могут определить, как инициатива UX будет продвигать бизнес вперед.

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

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

Таким образом, цели HEART являются ключевыми для разработки наших UX-инициатив таким образом, чтобы продвигать бизнес вперед. Если ваша организация уже использует цели и ключевые результаты (OKR), обратите внимание, что цели HEART хорошо сочетаются с целями OKR.

Сигналы

После того, как мы определились с целью для каждой категории HEART, нам нужно решить, какие сигналы мы ищем. Сигнал — это качественное поведение конечного пользователя, связанное с целью, которую мы установили для этой функции.

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

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

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

Если целью является «распространение информации из уст в уста», то этот сигнал имеет смысл включить.

Но если СЕРДЦЕВАЯ цель состоит в том, чтобы «сократить время завершения рабочего процесса, чтобы свести экономию затрат к перспективам продаж», то этот сигнал не является хорошим. Микроанимации требуют времени, и, хотя они могут повысить удовлетворенность пользователя, они могут не повысить способность пользователя быстро выполнять задачу.

Кроме того, сигналы должны меняться только тогда, когда пользовательский опыт является единственным объяснением изменения. Например, вы не хотели бы отслеживать сигнал, который движется вверх и вниз в зависимости от маркетинговых усилий, а не изменений UX. Остерегайтесь объединяющих факторов, таких как маркетинговые усилия, усилия по обеспечению успеха клиентов и усилия по продажам.

Метрики

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

В общем, вы должны нормализовать свои показатели относительно размера вашей клиентской базы. То есть «общее использование» менее полезно для отслеживания, чем «среднее использование на пользователя».

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

У нас есть несколько показателей для этого сигнала:

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

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

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

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

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

Давайте теперь оживим фреймворк HEART, погрузившись в реальный пример.

Пример фреймворка HEART в действии

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

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

Вот гипотетическая диаграмма HEART, которую вы можете раскрутить, чтобы изучить, как еще больше улучшить рабочий процесс «переназначения клиентов» UX. Это тот же пример, которым я поделился ранее.

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

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

Теперь, когда у нас есть пример того, как выглядит заполненная диаграмма HEART, давайте обсудим, как стимулировать действие с помощью структуры HEART.

7 шагов к активным действиям с помощью схемы HEART

Вот семиэтапный план действий с помощью схемы HEART. Мы определили, кто из продуктового трио (управление проектами, дизайнеры и инженеры) должен участвовать в каждом этапе.

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

Во-вторых, управление продуктом и дизайн должны оценить, какой из категорий HEART имеет смысл отдать приоритет.

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

Этот третий шаг должен привести к значительным дебатам, что неплохо. Менеджеры по продукту, естественно, будут выступать за бизнес-результаты, а дизайнеры — за пользовательские результаты. Ключ в том, чтобы найти пользовательские результаты, которые способствуют достижению бизнес-целей.

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

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

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

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

Включение долгосрочных мониторов и предупреждений с помощью HEART

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

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

Но мониторы могут создать значительную умственную нагрузку, особенно если вы внедрили десятки или сотни метрик HEART. Поэтому работайте вместе с инженерами, чтобы настроить оповещения, такие как функция Amplitude Anomoly + Forecast, которые будут автоматически срабатывать, когда отслеживаемый показатель падает ниже определенного порога. Используйте эти оповещения, чтобы привлечь внимание и принять меры для команды.

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

Каждый фреймворк имеет недостатки и предостережения. Джон Катлер, евангелист продуктов Amplitude, говорит о фреймворках следующее: «Многие фреймворки плохо спроектированы. Они небезопасны. Они не поставляются с предварительными условиями, предупреждающими надписями и/или датами истечения срока действия. Они не зависят от контекста, и им не хватает механизмов, позволяющих сделать их контекстно-зависимыми».

Итак, вот четыре предупреждения, о которых следует помнить при внедрении HEART для ваших собственных UX-дизайнов и продуктов:

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

Во-первых, убедитесь, что выбранная область не слишком широка. Как упоминалось ранее, HEART работает лучше всего, когда он хорошо сфокусирован на функции внутри продукта, а не на самом продукте в целом. Однако проблема здесь заключается в том, что «функции» и «продукты» лежат в разных диапазонах и не всегда могут быть четко классифицированы. Некоторые продуктовые организации могут воспринимать функцию как продукт, а некоторые продуктовые организации могут воспринимать продукт как функцию.

Хорошей лакмусовой бумажкой того, правильно ли вы выбрали степень детализации, является стремление к совпадению целей (бизнес-задач) и сигналов (состояний конечных пользователей), но с достаточным расхождением в показателях. Если каждая из ваших целей HEART сильно отличается друг от друга или каждый из ваших сигналов HEART представляет совершенно разное конечное состояние пользователя, то вам, вероятно, нужно сузить фокус. С другой стороны, если ваши показатели HEART демонстрируют значительное совпадение, то вы, вероятно, слишком узко сфокусированы и должны поднять разговор на один уровень выше.

Во-вторых, не заставляйте использовать каждую категорию HEART. Некоторые функции просто не имеют независимого пути к внедрению или сохранению. В качестве примера рассмотрим процесс регистрации пользователя. Стремление втиснуть метрику «удержания» для этого рабочего процесса активации не имеет смысла, потому что регистрация обычно происходит только один раз для каждого пользователя.

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

Согласно принципу Парето, самые ценные 20 % усилий приносят 80 % ценности вашему конечному пользователю, а оставшиеся 80 % усилий следует инвестировать в другое место.

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

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

Заключительные мысли

Фреймворк HEART — это гибкая структура для разбивки целей UX и привязки их к бизнес-целям. И специалистам по UX, и менеджерам по продуктам следует рассмотреть возможность добавления фреймворка HEART в свой арсенал методов.

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