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