Что делать, если пользователь сообщает о событии, которого нет в системе?

#33
modal close button

Что делать, если пользователь сообщает о событии, которого нет в системе?

Копировать ссылкуСкопировано!

Возможные ответы (7)

. Прежде всего нам следует понять мотивы пользователя. Не стоит сразу считать его лжецом, даже если мы уверены, что его история невозможна. Иногда человеку достаточно испытать эмоции, чтобы поверить в свою правоту (, ).
. Если мы нашли доказательства несостоятельности утверждений пользователя, нам следует излагать их постепенно. Сухо констатируя факты мы не даем пользователю сохранить лицо. Так как мы не можем быть уверены в его мотивах, не исключено, что он просто что-то забыл либо не верно интерпретировал. Все наши аргументы должны даваться постепенно, с параллельной оценкой реакции пользователя.
. Иногда пользователь просто пытается скрыть свою тотальную некомпетентность (либо факт своей ошибки). Часто это проявляется в виде коротких утверждений типа «система сама удалил файл, я этого никогда не делал» и т.п.
. В случаях, когда осознал свою ошибку, но ему неловко в этом признаться, мы можем помочь ему не потерять лицо. Как вариант, мы можем предложить ему плацебо в виде «мы обязательно зарегистрируем этот инцидент и проведем соответствующие проверки». Также иногда может быть полезно предоставить какие-нибудь формы/кнопки/почтовые адреса для связи. Это особенно актуально если мы работаем с людьми в возрасте, либо просто приверженцами консервативных взглядов ().
. Возможно в нашей коммуникации мы использовали опасные формулировки, что заставило пользователей обеспокоиться и обратиться к нам.
. История нашего пользователя может быть продолжением какого-то негативного эпизода, происшедшего с ним ранее.
. Нам не следует объяснять пользователю, что проблема в когнитивных искажениях и его мыслительных процессах. Даже если у нас есть безупречные аргументы – нам никогда не стоит этого делать.

Связанные вопросы

#47.

Что учитывать при прямом контакте с пользователем?

#51.

Какие факторы приводят к ошибкам пользователей при использовании нашего продукта?

#10.

Почему пользователи жалуются на качество нашей поддержки?

#31.

Как защищаться от информационных атак (напр. Дезинформации)?

#38.

Что учитывать при создании механизмов модерации/решения диспутов?

#44.

Что учитывать при работе с отзывами пользователей (фидбэком)?

Насколько полезным вы нашли этот материал?
Не полезно
1
2
3
4
5
6
7
8
9
10
Не полезно
Очень полезно
Спасибо за ваш вклад в развитие проекта!
previous bias
next bias
keepsimple logo
picВойти
Мой профильНастройкиВыйти
Ссылки
UX COREGUIDEPERSONAUX CATBob - AI AssistantБоб - ИИ Ассистент
keepsimple logo
UX CoreGuidePersonaИгра на вниманиеBob - AI AssistantБоб - ИИ Ассистент
Ссылки
Использование проекта в образовательной системе
UX CORE GUIDE
Добавление вашего вопроса
UX CORE PERSONA
Вводная статьяHabr.com publishing platform logo
APIUX Core API
picВойти
Мой профильСохраненные ПерсоныНастройкиВыйти

UX CORE GUIDE

arrow downКак пользоваться

UXCG — это бесплатный инструмент, который помогает командам выявлять проблемы пользовательского опыта, связанные с когнитивными искажениями, на всех стадиях разработки продукта: от прототипирования и тестирования до улучшения действующего продукта.

Как использовать UXCG

  1. Выберите стадию вашего продукта ниже;
  2. Выберите интересующий вас вопрос;
  3. Прочтите возможные ответы.

Каждый ответ объясняет, как когнитивные искажения связаны с вашим вопросом. Поскольку вы лучше всего понимаете свой контекст, вы можете напрямую применять полученные знания. Хотя инструмент не предоставляет готовых решений из-за уникальности каждого случая, он открывает новые перспективы, подкрепленные наукой.

Описание лейблов
Вопросы связанные с кооперацией команд и лиц, работающих над продуктом.
Вопросы связанные со стадией разработки продукта (от идеи до публичного релиза).
Вопросы связанные с продажами, маркетингом, потенциальными пользователями и общей оберткой продукта.
Вопросы связанные с интеракцией пользователей с продуктом и его функционалом.
Вопросы связанные с чтением аналитики по продукту.
search icon
Выберите стадию вашего проекта
#10.

Почему пользователи жалуются на качество нашей поддержки?

#30.

Какие ошибки мы допускаем в работе с аналитическими данными по продукту?

#41.

Что делать если упрямство наших коллег наносит вред рабочему процессу?

#43.

Что учитывать при планировании релизов продукта?

#45.

Что делать если некоторые участники нашей команды не высказывают свое мнение?

#50.

Как работать с некомпетентным коллегой/начальником?

#59.

Что учитывать при упоминании политических, социальных либо экономических событий в текстах компании/продукта?

#61.

Что делать, если команда тратит слишком много времени на неважные мелочи?

Be Kind. Do Good.