UX-команды регулярно сталкиваются с вопросом: какие функции действительно важны пользователям, а какие просто кажутся хорошей идеей внутри команды. В одних случаях новая возможность вызывает восторг, в других — воспринимается как само собой разумеющаяся вещь, а иногда пользователи вообще не замечают её ценности. Именно для понимания таких различий используется модель Кано.
Когда компании хотят понять, довольны ли клиенты продуктом или сервисом, чаще всего используют простые опросы удовлетворенности: шкалу от 1 до 5, CSAT или NPS. Эти методы понятны, быстро внедряются и дают удобные цифры для отслеживания динамики. Но в работе с клиентскими опросами мы регулярно сталкиваемся с ситуацией, когда высокий уровень удовлетворенности не объясняет, что именно делает пользователей довольными, а низкие оценки не подсказывают, какие изменения действительно улучшат продукт.
Редизайн — один из самых рискованных этапов в жизни цифрового продукта. Меняется интерфейс, логика сценариев, структура разделов, иногда — сама философия взаимодействия с пользователем. При этом ставки всегда высоки: можно усилить лояльность и конверсию, а можно — получить волну негатива и падение ключевых показателей.
Когда компании начинают использовать модель Кано, чаще всего они ожидают простой и наглядный результат: список функций, разделённых на категории — обязательные, линейные и восхищающие. На практике именно на этом этапе многие и останавливаются. Таблица с буквами M, O и A кажется достаточно понятной, чтобы сразу принимать продуктовые решения. Но такой подход сильно упрощает саму модель и лишает исследование значительной части полезной информации.
pochemu-vostorgayushchie-fichi-ne-vsegda-stoit-delat-pervymi
Когда работаешь с B2B-продуктами, довольно быстро понимаешь: определить, какие функции действительно важны клиенту, гораздо сложнее, чем кажется на этапе планирования продукта. В потребительских сервисах реакция пользователей обычно быстрая и очевидная — рост или падение метрик, отзывы, оценки в приложении. В корпоративных продуктах картина гораздо менее прозрачна. Решение о покупке принимают несколько человек, ожидания формируются на разных уровнях, а обратная связь часто приходит уже после внедрения.
Когда команда продукта оценивает несколько вариантов интерфейса, иконок или концепций функций, чаще всего используют рейтинговые шкалы: например, просят пользователей поставить оценку от 1 до 5 или от 1 до 10. На практике такой подход не всегда дает ясную картину. Пользователи по-разному интерпретируют шкалу, часто выбирают средние значения или ставят одинаковые оценки нескольким вариантам. В итоге исследователь получает цифры, но они не всегда помогают уверенно понять, какой вариант действительно лучше.
В работе с продуктами и коммуникациями почти всегда возникает одна и та же ситуация: есть несколько вариантов решения, и нужно понять, какой из них действительно лучше. Команда обсуждает дизайн лендинга, спорит о формулировке письма для пользователей, выбирает сценарий онбординга или вариант рекламного баннера. У каждого участника есть аргументы, но субъективные предпочтения не всегда помогают принять уверенное решение. В таких случаях хорошо работает метод парных сравнений — простой, но очень эффективный инструмент исследования.
Когда ко мне приходят клиенты с задачей «понять, что для пользователей действительно важно», разговор почти всегда сводится к выбору метода приоритизации. Чаще всего на столе оказываются два варианта — парные сравнения и MaxDiff. Оба подхода кажутся похожими: респонденту предлагают выбирать между вариантами, а на выходе мы получаем ранжирование. Но за этой внешней схожестью скрываются принципиально разные механики и, что важнее, разные типы инсайтов.
Когда мы проектируем опрос или исследование, почти всегда возникает соблазн «сравнить всё со всем». Клиенты хотят понять, какой продукт лучше, какой вариант дизайна предпочтительнее, какая функция действительно важнее другой. И на этом этапе появляется ключевой вопрос: сколько сравнений можно показать одному респонденту, чтобы он не устал и не начал отвечать наугад?