Инсайты — это не результаты: провал исследовательских рекомендаций

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

Многие исследовательские группы проделывают хорошую работу. В переводе статьи Nielsen Norman Group рассказывается, как исследовательские группы выявляют актуальные проблемы, набирают подходящих участников и проводят исследования, которые показывают, что происходит на самом деле. Конечный продукт часто называют «инстайтами = выводами» — этот термин звучит ценностно, его легко использовать, и он даже стал частью названий многих команд.

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

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

Разрыв между рекомендациями и внедрением

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

На шкале ценностей стрелка исследования указывает вперёд, а стрелка результата — назад, к стрелке исследования, но они не соприкасаются.
Разрыв между исследованиями и результатами: идеи и рекомендации, разработанные исследовательскими группами, полезны только в том случае, если они устраняют разрыв между исследованиями и результатами и воплощаются в жизнь.
Именно в этом пробеле любит прятаться надежда. Мы надеемся, что заинтересованные стороны начнут действовать. Мы надеемся, что они расставят приоритеты правильно. Мы надеемся, что доказательств будет достаточно. Но если вы полагаетесь на надежду, то рискуете быть обманутыми. Без доказательств того, что ваши рекомендации воплотились в продукте, вы можете только надеяться, что ваша работа привела к изменениям, а не была просто убедительной, но одноразовой историей.

Поломка: аналогия с розничной торговлей

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

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

Вы наверняка видели подобные варианты:

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

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

Цепная реакция поломок

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

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

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

Почему сохраняется поломка

Большинство ошибок происходит непреднамеренно. Это побочный эффект работы в условиях цейтнота. Из-за конкурирующих приоритетов исправления откладываются. Разрозненность отделяет людей, которые испытывают трудности, от тех, кто может их решить. Сроки вознаграждают за то, что готово к выпуску, а не за то, что необходимо для выпуска. Команды дизайнеров и разработчиков интерпретируют рекомендации так, как им удобно для быстрого выполнения. Ответственность размывается, а там, где размыта ответственность, умирают и рекомендации.

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

Абсурдность надежды

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

Диаграмма под названием «Отсутствие подотчётности» с четырьмя столбцами: «Продажи», «Продукт», «Финансы» и «Исследования». В каждом столбце приведён пример неполного выполнения задач: отдел продаж не отслеживает, подписаны ли предложения, отдел продукта не проверяет, выполнены ли требования, финансовый отдел не измеряет соответствие расходов, а отдел исследований не проверяет, были ли реализованы рекомендации. На диаграмме показано, что в то время как другие отделы никогда бы не допустили таких пробелов, отдел исследований часто их допускает, что подчёркивает необходимость подотчётности в UX-исследованиях.

Отсутствие подотчетности: представьте, что другие подразделения компании работают в таких же условиях. Это звучит абсурдно, но именно так обстоят дела с UX-исследованиями. Другие отделы (например, отдел продаж, продуктовый отдел и финансовый отдел) отслеживают свои результаты. Исследовательский отдел тоже должен это делать.
Тем не менее в UX-исследованиях многие по-прежнему представляют результаты и надеются, что их примут. Так проблемы остаются незамеченными. Удобно предполагать, что умные люди поступят правильно. Но предположения не приводят к появлению функций. Предположения не устраняют препятствия для пользователей. Предположения защищают организацию от неудобств, а не пользователя от боли.

Эмоциональная нагрузка на исследователей

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

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

Через какое-то время возникает ощущение, что ты кричишь в пустоту. Люди начинают отстраняться. Они упрощают отчёты, потому что знают, что сложные моменты будут проигнорированы. Они перестают настаивать на правильном решении, потому что устали слышать, что сейчас не время. Людей изматывает не сложность исследования. А отсутствие прогресса в решении проблем пользователей, которые выявляет их работа.

Если вы хотите защитить своих исследователей, вы должны защитить их веру в то, что доказательства ведут к действию.

Почему нужно отслеживать поломки

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

Это меняет формулировку с «Узнали ли мы что-то новое?» на «Сделали ли мы что-то?» Без отслеживания сбоев невозможно понять разницу между командами, которые доводят дело до конца, командами, которые выбирают только то, что им нравится, и командами, которые просто игнорируют исследования.

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

От данных к действию: цепочка создания ценности в исследованиях. Рекомендации — это наиболее ценный результат исследовательского процесса. Мы собираем данные, делаем выводы, выявляем закономерности и, наконец, разрабатываем рекомендации. Чем дальше мы продвигаемся по этой цепочке, тем ценнее становится наша работа, поскольку она приближает нас к реальным действиям.
Отслеживание сбоев позволяет выявить слабые места в этой цепочке. Были ли данные достоверными, но выводы были искажены при передаче заинтересованным сторонам? Возможно, идея была ясной, но рекомендация была изменена в соответствии с привычным шаблоном проектирования, который не затрагивал первопричину. Или, может быть, рекомендация была обоснованной, но ей не уделили должного внимания, потому что у неё не было исполнительного спонсора.

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

Практические признаки приближающейся поломки

Существуют ранние признаки, которые указывают на поломку ещё до того, как вы проведёте официальное измерение:

• Команды просят провести «ещё один раунд», не уточняя, какие новые доказательства могут повлиять на решение
• Выводы, в которых самая важная рекомендация приводится в качестве сноски, потому что это политически невыгодно
• Дизайнеры спокойно обходят стороной рекомендацию использовать библиотеку шаблонов, которая упрощает процесс разработки, но не решает основную проблему
• Целый ворох документов без соответствующих заявок, без владельца и без плана выпуска
• Руководители ссылаются на результаты исследования в общих чертах, не указывая на конкретные изменения, которые они отражают

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

Ничто из этого по отдельности не указывает на поломку, но вместе они рисуют чёткую картину. Ценность создаётся исследованиями. Ценность теряется при доставке.

Краткий пример

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

После публикации результатов исследования произошло три события:

1. Команда приняла изменение в копии, потому что оно было быстрым.
2. Удаление переключателя было отложено, поскольку соответствующая логика принадлежала другой команде.
3. Предварительный просмотр был преобразован во всплывающую подсказку, которая появлялась только при наведении курсора и исчезала на мобильных устройствах.

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

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

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

Что показывает сбой в отслеживании

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

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

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

Ключевые выводы

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