Без исследований дизайн опирается на ощущения и спор в чате. Это не значит, что исследования надо делать перед каждой кнопкой — но в ключевых решениях они дешевле, чем переделки потом.
Виды исследований
- Качественные — интервью, наблюдения, дневники. Объясняют «почему» и «как».
- Количественные — опросы, A/B-тесты, аналитика. Отвечают «сколько» и «как часто».
- Порождающие — проводят до проектирования, чтобы понять задачи и контекст.
- Оценочные — проверяют, насколько хорошо работает то, что уже есть.
Как встроить в работу
- Перед серьёзными изменениями: 5–8 интервью с целевыми пользователями.
- Регулярно после релизов: короткие опросы, тесты юзабилити, наблюдения.
- В сложных продуктах — постоянный поток исследований, не «одноразовый проект».
- Перед запуском нового продукта или большой функции
- Когда метрики не сходятся и непонятно, почему пользователи действуют так, как действуют
- В работе с новой аудиторией, которую команда плохо понимает
- Когда речь о мелком очевидном изменении: исследовать каждое — слишком дорого
- Когда нет ресурса на честную работу с результатами — тогда исследование рискует стать «отметкой»
Команда видит, что новые пользователи не доходят до ключевой функции. Аналитика показывает, где они отваливаются, но не объясняет почему. Восемь коротких интервью с такими пользователями выявляют простую закономерность: люди не понимают, для чего им вообще нужна эта функция, и интерфейс не показывает её ценность в первые секунды. Никакая аналитика без разговоров этого бы не дала.
Самые частые ошибки — задавать вопросы о будущем («стали бы вы пользоваться?») и наводящие вопросы. Лучше работают вопросы про прошлое и конкретику: «как вы решали эту задачу в последний раз?», «покажите, как делаете это сейчас». Это даёт реальные данные, а не выдуманные ответы из вежливости. Расшифровки и находки держите в базе знаний, чтобы к ним возвращался не только исследователь, но и вся команда.