«Да все равно эти исследования в итоге не пригодятся», —– именно такими словами однажды на созвоне прервал мое выступление коллега. Я замерла с открытым ртом. Хорошо, что камера была выключена. 

За секунду до этого я рассказывала о результатах проведенного исследования. Перед ноутбуком у меня лежал листок с заметками, которые я старательно писала от руки. Мне казалось, все идет хорошо. А тут такое!

Уже позднее, на другом проекте и другой встрече, ситуация повторилась. Исследование было уже проведено, я сделала анализ и рассказывала о результатах и гипотезах. И снова вопрос «Зачем это нужно?». Б — боль.

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

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

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

Подробнее об этом еще скажу ниже, но сначала немного базы.

Какие бывают исследования 

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

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

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

В юзабилити-тестах есть несколько этапов: 

1. Подготовка макетов и кликабельного прототипа.

2. Организация тестирования с помощью специальных онлайн-сервисов вроде useberry или через личную встречу с фокус-группой.

3. Проведение тестирования.

4. Анализ результатов, генерация гипотез и решений.

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

Зачем проводить исследования на макетах

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

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

Команда анализирует ситуацию и решает провести кастдев (от англ. Customer Development, сокращенно custdev, «кастдев»). Выясняется, что у конечного пользователя абсолютно другое представление об интерфейсе, работать ему неудобно и непривычно, что влияет на метрику NSAT.

Тут важно понимать, что прежде всего пользователи делятся на сегменты: сами сотрудники и их руководители. В работе с отчетом по КПЭ у них разные задачи и цели. Например, специалист хочет знать, получит ли он премию по итогам месяца. Ему не подходит сложная и гибко настраиваемая таблица с перечнем всех возможных показателей и всех сотрудников. А руководитель хочет направить данные по бюрократической цепочке, чтобы ему и его группе подчиненных вовремя были назначены премии. Ему, в целом, подошла бы и кнопка скачивания документа в Excel, ведь он все равно отправляет данные по почте файлом.

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

Отсюда вытекают минимум три причины, почему исследования на этапе макетов можно и нужно проводить:

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

2. Чтобы команда могла принять обоснованные решения касаемо UX/UI и функциональности в целом. Если сотрудники спорят, как реализовать ту или иную фичу, исследования помогают разрешить конфликт. Верно то решение, которое отвечает потребностям пользователей и которое подтвердило метрики. 

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

Когда исследования не нужны

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

Давайте рассмотрим ситуации, когда исследования проводить не стоит:

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

Например, аналитика показывает, что у 80% пользователей возникает сбой при попытке скачать документ с сайта. А из обратной связи ясно, что проблема связана с расположением кнопки «скачать» — например, она незаметная или до нее сложно «дойти». Тогда у нас достаточно информации, чтобы оперативно предложить и реализовать решение, — переместить кнопку в более очевидное место.

Когда дешевле сделать и проверить, чем исследовать. Если речь о небольших изменениях или функциональности, проще и быстрее будет сразу сделать эту доработку и посмотреть, как ее приняли пользователи. Например, можно использовать A/B-тестирование или просто проанализировать, как обновление повлияло на метрики. 

Ситуации, где можно это применить:

1. Небольшие визуальные изменения — новый цвет кнопки, выравнивание текста.

2. Проверка гипотез с низким уровнем влияния на основной флоу.

3. Если новый дизайн отличается от старого незначительно, и нет явных рисков.

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

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

Исследования нужны только дизайнерам. Или нет?

Сразу возникает вопрос: если исследования проводятся на этапе макетов, не должны ли за них отвечать только дизайнеры или продакты? На первый взгляд, логично. Но практика показывает, что так работает не всегда.

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

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

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

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

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

3. Прокачать удобство пользования — например, настроить работу скроллов, подогнать страницу под ширину экрана и так далее.

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

Команда мечты

Обычно отношение технических специалистов к исследованиям ложится на эти три сценария:

1. Я не вижу пользы от исследований и считаю их тратой времени.

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

3. Я вижу пользу от исследований и активно участвую в их проведении и генерации гипотез.

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

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

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

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

А что по этой теме думаете вы? Делитесь мнением в комментариях — мне будет интересно почитать.