UX-исследования: как узнать, что нужно пользователям, без большого бюджета

Исследование начинается не с метода, а с вопроса, на который команда не может ответить сама: «почему люди бросают запись на втором шаге?», «как клиенты сейчас выбирают мастера?», «найдут ли кнопку оплаты в новом макете?». Если вопрос не сформулирован, любое исследование превращается в приятную беседу без выводов. Nielsen Norman Group прямо предупреждает: слишком широкая цель вроде «узнать пользователей получше» даёт находки, с которыми нечего делать.

NN/g раскладывает методы исследований по трём осям. Первая — мнения против поведения: что люди говорят (опросы, интервью) и что они делают (тесты, аналитика, A/B-тесты). Вторая — качественные против количественных: качественные методы отвечают на вопросы «почему» и «как исправить», количественные — «сколько» и «как часто». Третья — контекст: пользуется ли человек продуктом естественно, по заданию или не пользуется вовсе.

Методы удобно связывать с этапом продукта. На старте, когда непонятно, что делать, помогают интервью и полевые исследования. Когда есть макет или прототип — юзабилити-тесты. После запуска — аналитика и A/B-тесты, которые сравнивают версии на большом трафике. NN/g отмечает, что почти любому проекту полезно несколько методов: аналитика показывает место проблемы, тест объясняет её причину.

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

Юзабилити-тест показывает поведение: ведущий (фасилитатор) даёт участнику реалистичную задачу и наблюдает, как тот её выполняет, а участник проговаривает мысли вслух. Тестировать можно что угодно — от бумажного эскиза и кликабельного прототипа до работающего сайта конкурента.

Логика простая: каждый следующий участник повторяет уже найденные проблемы, и новых становится всё меньше. Выгоднее найти главное, исправить и проверить снова — исправления могут не сработать или открыть следующие проблемы. Исключения: если у продукта несколько разных групп пользователей (например, клиенты и администраторы), берут по три-четыре человека из каждой; для количественных метрик вроде доли успешных выполнений пятерых мало — NN/g называет ориентир около двадцати.

Если сайт или приложение уже работают, часть ответов лежит в данных. Аналитика показывает, что и сколько: на каком шаге формы уходят люди, по каким запросам ищут во внутреннем поиске, с какого источника пришёл провал трафика. Но она не объясняет причину — NN/g приводит пример: аналитика покажет, где бросают форму, а почему (например, не хотят оставлять номер телефона) — покажет только тест.

• Воронка ключевого сценария: просмотр услуги → форма → отправка → «спасибо»
• События: нажатия на кнопки, ошибки валидации, открытие и закрытие форм
• Внутренний поиск: какими словами люди ищут то, что на сайте названо иначе
• Карты кликов: куда нажимают и что принимают за ссылку
• Записи сессий: как конкретный человек двигался по странице

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

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

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

• Спрашивать о будущем: «Пользовались бы вы…» — ответ показывает, что идея звучит привлекательно, а не что ей будут пользоваться
• Тестировать на коллегах и друзьях, которые знают продукт или не хотят вас огорчить
• Подсказывать на тесте и объяснять, «как задумано», — после этого сессия ничего не проверяет
• Спрашивать мнение о дизайне до того, как человек им воспользовался
• Проводить одно большое исследование вместо нескольких маленьких итераций
• Собирать данные без решения, что вы с ними сделаете