При критике исследовательских вопросов, даже если удаётся выйти за пределы «так надо — так не надо», редко разговор касается того, почему исследователь задал вопрос именно так. С какой перспективы, опираясь на чью логику. А такая проблематизация — самая продуктивная.

Возьмём рядовой вопрос из гайда: «Какой информации о товаре вам не хватает в выдаче?» Его легко критиковать. Хотя бы потому, что он:
— вынуждает собеседника артикулировать «отсутствующее» как категорию;
— требует отрефлексировать информационные потребности в абстрактной форме;
— не завязан на реальный опыт;
— имплицитно подразумевает, что «информация» — это скорее текст, тогда как на деле информативны и визуальная часть, и состав выдачи по конкретному запросу/фильтру, и в целом система технических аффордансов на сайте или в приложении;
— и, главное, является формирующим, подразумевая, что человеку чего-то не хватает.

Однако фундаментальная проблема с ним лежит в иной плоскости. Она не в его функциональной или эпистемической слабости.

Лишь в первом приближении вопрос задан от потребности и опыта человека — исходя из предположения, что ему важны некоторые сведения о товаре и их может быть недостаточно [а мы-то хотим ему помочь]. Если вдуматься, сюда зашит запрос продакт-менеджера. Звучит user-centric, но на поверку это переформулированное «Что нам надо добавить?». Изучение практики втихую подменяется набором суждений о технологических артефактах. На короткой дистанции это упрощает жизнь и даёт возможность говорить об эффективности своей работы якобы доказательно: берём ответы на прямой вопрос, классифицируем их, приоритезируем их по RICE или Кано, и — та-дам! — мы вроде как добавили что-то вроде бы data-proven в дорожную карту продукта.

А если действительно начать думать, как посетитель совершает выбор при изучении выдачи, то вопрос «Какой информации о товаре вам не хватает в выдаче?» начнёт трансформироваться как по волшебству. Захочется понять, как именно человек видит эту часть сервиса и как она сообразуется с его практикой и потребностями. Что он привык и хочет видеть. В чём, в соблюдении каких условий он нуждается, чтобы продолжать и в конечном счёте сделать желанное для вас действие, а это, да, не только «информация». Как потребность собственно в информации зависит от контекста использования сервиса, от режима вовлечённости человека. И, как ни удивительно, отсюда уже проще будет переходить к UX-измерению — к perceived cost of action и иже с ним.

Или другой кейс. Клиента фудтех-сервиса спрашивают: «Устраивает ли вас скорость доставки?» Тоже вроде user-centric, а на деле — нет. Точнее, спросить это можно, чтобы сделать заход на тему. В качестве первого шага. А так-то это вопрос руководителя клиентской службы, обеспокоенного своими KPI, а не тем, ок ли клиенту скорость доставки. И главное, даже искренний ответ респондента на него вряд ли будет хоть чем-то полезен.

(Продолжение — в комментах.)