Прежде чем создавать проактивные ИИ-сообщения, прислушайтесь к слову «нет»
Если вы задумываетесь о функции ИИ, которая сама начинает разговор, сначала выясните, в каких случаях люди предпочли бы тишину. Пригласите потенциальных пользователей принять участие в исследовательском интервью, расспросите об обычных ситуациях, когда нежелательные сообщения были бы неуместны, и протестируйте концепции сообщений с помощью прототипа с возможностью отмены. Относитесь к прямому отказу «не связывайтесь со мной» как к требованию к продукту, которое нужно понять и учесть, а не как к возражению, требующему преодоления. Цель — узнать, какой именно контакт (и нужен ли он вообще) люди готовы приветствовать.
Начните с вопроса, стоящего за этой функцией
Предложение сделать ИИ «более проактивным» может скрывать под собой разные идеи: напоминание, рекомендацию, проверку статуса или сообщение, привязанное к привычному распорядку. Все это совершенно разный опыт. Прежде чем привлекать респондентов, опишите предлагаемое поведение простыми словами: что может послужить триггером для сообщения, что в нем может говориться и где именно человек его увидит. Это даст участникам конкретную основу для обратной связи без иллюзии того, что функция уже готова.
Оставляйте исследовательский вопрос открытым. Например: «В каких ситуациях, если таковые вообще есть, вы хотели бы получать сообщения такого рода, а когда предпочли бы их не видеть?» Не ограничивайтесь вопросом о том, нравится ли человеку эта идея или как часто он хотел бы получать сообщения. Общий положительный ответ может скрывать важные личные границы: к примеру, кто-то будет рад редкой подсказке во время готовки, но предпочтет тишину во время работы, поездок или общения с другими людьми. Это ориентиры для исследования, а не утверждения о том, что именно скажут пользователи.
Привлекайте людей, которые являются фактическими или вероятными пользователями разрабатываемого вами продукта, и подробно объясняйте условия приглашения до того, как они согласятся на участие. Руководство GOV.UK по пользовательским исследованиям рекомендует четко разъяснять цели и формат взаимодействия, сохранять добровольный характер участия и прямо указывать на возможность в любой момент прервать или прекратить его. Также рекомендуется предоставлять информацию заранее, чтобы люди могли подготовиться и решить, комфортно ли им участвовать (Getting informed consent for user research; Finding participants for user research).
Спрашивайте о ситуациях, а не только о предпочтениях
В коротком интервью начните с недавних повседневных примеров. Спросите, какие типы цифровых сообщений люди обычно замечают, когда они им рады, а что происходит, когда они их игнорируют или смахивают. Затем изучите контекст: время суток, текущее занятие, была ли активность инициирована ими самими и находится ли рядом кто-то еще. Сосредоточьте обсуждение на наблюдаемых привычках и реальных действиях, вместо того чтобы просить участников строить абстрактные идеальные предположения.
Полезными могут быть нейтральные вопросы: «Расскажите о недавнем случае, когда приложение побеспокоило вас, пока вы были заняты», «Что сделало бы подобное сообщение полезным в тот момент?» и «Бывают ли ситуации, когда вы предпочли бы, чтобы эта функция молчала?» Далее спросите: «Чем именно эта ситуация отличается?» Дайте респонденту пространство самостоятельно очертить границы. Не заполняйте паузы доводами, которых он не называл, и не выставляйте ответ «да» как предпочтительный.
Спрашивайте о разных форматах взаимодействия по отдельности. Человек может быть открыт к короткой подсказке внутри интерфейса во время использования функции, но категорически против push-уведомления при закрытом приложении. Ему может требоваться сообщение только после явного согласия на определенное действие, или же он вовсе не хочет непрошеных уведомлений. В документации Apple по уведомлениям проводится схожее продуктовое разграничение: разработчикам советуют запрашивать разрешение на отправку уведомлений в понятном контексте, отмечая, что они могут отвлекать и вызывать раздражение (Asking permission to use notifications). Это руководство для платформы не определяет предпочтения именно ваших пользователей — интервью должны выявить их собственные условия и жизненные ситуации.
Сделайте приглашение к исследованию по-настоящему добровольным
Приглашение к участию не должно напоминать саму тестируемую проактивную функцию. Укажите, что речь идет об исследовании, поясните, что предстоит делать участнику, какую информацию вы будете собирать и как будут использованы результаты. Запросите согласие напрямую. Сделайте отказ легким и позаботьтесь о том, чтобы он не влиял на доступ к стандартным возможностям продукта. Руководство GOV.UK по сбору персональных данных рекомендует предлагать прямой и конкретный выбор, подчеркивая, что отказ не должен блокировать использование сервиса (Collecting personal information from users).
Прежде чем делать заметки или включать запись, объясните эти возможности и получите согласие на конкретный метод фиксации данных. Участник может согласиться на интервью, но отказаться от записи. Четко дайте понять, что он может пропустить любой вопрос, сделать паузу или вовсе остановить сессию. Руководство GOV.UK рекомендует получать информированное согласие до ведения записей и использовать полученные материалы исключительно в согласованных целях (Taking notes and recording user research sessions).
В завершение поинтересуйтесь, комфортно ли участнику то, как были зафиксированы данные, и напомните, как связаться с командой, если он захочет пересмотреть свое решение. Держите фокус заметок исключительно на вопросах дизайна; не собирайте лишние персональные данные. Объясните, что исследовательская группа изучает предпочтения относительно форматов взаимодействия, а не пытается убедить респондентов принять новую функцию.
Протестируйте идею на прототипе с возможностью отмены
После проведения интервью преобразуйте выявленные ситуации в небольшой набор концепций сообщений. Используйте нейтральные примеры, привязанные к повседневным действиям, и показывайте триггер и контекст доставки вместе с текстом. Сообщение — это не просто предложение: участникам необходимо понимать, приходит ли оно во время активного использования, появляется позже или застает их вне продукта. Четко обозначьте концепт как прототип, чтобы люди не приняли его за работающую функцию.
Предоставьте участникам обратимый выбор, например: «показать этот пример», «попробовать для этого действия» или «без проактивных сообщений». Если прототип имитирует уведомление, покажите, как остановить тестирование, и убедитесь, что отключение срабатывает. Не отправляйте реальные сообщения в рамках теста, если пользователи осознанно не дали согласие на этот конкретный эксперимент. Сделайте тестирование достаточно коротким, чтобы респонденты могли оценить опыт без привязки к постоянной настройке.
Наблюдайте не только за ответами, но и за действиями: решают ли люди включить пример, смахнуть его, изменить предложенный контекст или отключить? Спросите, какого поведения они ожидали от каждого элемента управления. Это прикладной исследовательский метод, а не доказательство того, что отдельный элемент управления подойдет любому продукту. Главная проверка заключается в том, могут ли участники понять сделанный выбор и без проблем отменить его.
Фиксируйте отказы как практические рамки
Слово «нет» может иметь разные значения. Участник может отвергать определенное время, тип сообщения, конкретное действие или любые проактивные контакты в целом. Зафиксируйте эту границу его собственными словами и отметьте сопутствующие условия. Полезная структура анализа группирует выводы по ситуации и выбору: уместно в рамках выбранного действия, допустимо только в ограниченном контексте или категорически нежелательно. Оставляйте статус «без контакта» на виду как отдельный результат, а не прячьте его за общим согласием на периодические уведомления.
Отделяйте слова респондентов от собственной интерпретации. Например: «Участник попросил не присылать сообщений вне активной сессии» — это прямое наблюдение; «возможно, потребуется опция отправки только во время сессии» — это проектный вывод. Также фиксируйте моменты неопределенности. Одно интервью способно выявить возможную границу, но не позволяет определить, насколько такое предпочтение распространено среди всей аудитории.
Используйте полученные результаты, чтобы решить, стоит ли развивать функцию дальше и какие параметры выбора интерфейс должен предоставить пользователю. Если люди описывают весомые ситуации, требующие тишины, отразите их в концепции и протестируйте снова. Если участники выбирают полное отсутствие проактивного контакта, зафиксируйте этот итог в прототипе и сводке исследования. Смысл обратной связи в том, чтобы отказы пользователей меняли и совершенствовали дизайн.
Практическая последовательность для первого раунда исследований
Опишите один вариант проактивного поведения, включая триггер, текст сообщения и контекст доставки.
Пригласите потенциальных пользователей с помощью понятного приглашения, подчеркивающего добровольность; заранее поделитесь деталями сессии.
Расспросите о недавних сообщениях и конкретных ситуациях, когда контакт приветствуется, ограничен или нежелателен.
Продемонстрируйте четко обозначенный прототип с понятными вариантами выбора, включая полный отказ от проактивного контакта.
Дайте участникам возможность отменить свой выбор и проследите, соответствуют ли элементы управления их ожиданиям.
Анализируйте прямые наблюдения отдельно от проектных выводов; переносите варианты явного отключения функций в следующую концепцию.
Эта последовательность помогает команде понять, уместен ли проактивный контакт в пользовательском опыте, прежде чем продукт начнет строиться на догадках. Интервью раскрывают жизненные ситуации людей, а прототипы с возможностью отмены позволяют им взаимодействовать с конкретным выбором. Вместе они превращают слово «нет» в ценный вклад в проектирование и дают пользователям реальную возможность выбрать тишину.