Что учитывать при создании механизмов модерации/решения диспутов?
English
Armenian
Russian
Что учитывать при создании механизмов модерации/решения диспутов?
Копировать ссылкуСкопировано!
Поделиться
Возможные ответы (15)
. Большинство людей верит, что мир устроен справедливо и что каждый получает то, что заслуживает.
. В ситуации, которая подразумевает сомнение в чьих то словах (например – решение диспутов), люди по-умолчанию напряжены. Не следует интерпретировать их эмоциональные реакции как доказательства чего либо.
. Многие люди склонны к преувеличению уровня своей компетентности. Они отличаются высокомерием, льстивом представлении о себе (), а также уверенным тоном речи. Следует понимать, что эти люди не лгут и не притворяются. Они просто не способны объективно оценить свои способности.
. Некоторые люди, ожидая вынесения решения по своему делу, ведут себя необычно, странно. Часто это бывает вызвано тем, что им кажется что их действия «всем видны».
. Если мы создаем какой-то механизм решения диспутов для службы поддержки, мы можем предоставить им инструменты для просмотра записей действий (logs) пользователей. Это поможет нашим коллегам гораздо больше, чем попытки выяснить логику действий пользователей.
. Нам следует объяснить пользователям степень власти, которой обладает лицо выносящее решение (напр: Модератор, Администратор и т.п.). Чем более прозрачно и понятно мы это сделаем, тем меньше пользователи будут склонны к обсуждению вынесенных им решений.
. Даже если в большинстве случаев выносимые решения идут на пользу пользователю, при первом же отрицательном решении он может возмутиться. Нам не имеет смысла апеллировать к тому, что «в 95% случаев решения выносились в вашу пользу» и т.п. Подобная пользовательксая реакция основана на эмоциях а не логике.
, . В идеале, «обертка» любых наших решений, должна всегда соответствовать верованиям и ценностям нашей аудитории. Чтобы использовать элемент консерватизма в коммуникации нам следует с самого начала выписать ключевые ценности, являющиеся общими для нашей аудитории (Желательно, на стадии создания «Персоны»).
, . Если пользователь использует в своих аргументах события, которые согласно данным системы никогда не происходили, не следует считать его лжецом.
. Вынесенные решения должны всегда включать в себя как внешние, так и внутренние факторы. Если мы будем объяснять пользователю решение, которое было принято в ущерб его интересам его личными недочетами – это вызовет резко негативную реакцию. Если же мы будем объяснять наше решение, принятое в его пользу, исключительно внешними обстоятельствами – мы лишь снизим его уровень удовлетворения.
. Пользователь мог ошибиться из-за советов нашей системы. Мы могли не заметить, как системные «советы» и «рекоммендации» подталкивают пользователей к ошибочным действиям.
. Выносимое решение должно быть однозначным для понимания. Используемые нами формулировки должны исключать разночтения ().
. Мы можем использовать эффект социальной желательности для «подталкивания» пользователя к принятию результатов наших решений. Этот прием широко используется политиками.
. Нам не следует объяснять пользователю, что проблема в его когнитивных искажениях, мыслительных процессах. Даже если у нас есть безупречные аргументы – нам никогда не стоит этого делать.
В контексте работы с механизмами принятия решений будет также полезно ознакомиться с .
Связанные вопросы
#47.
Что учитывать при прямом контакте с пользователем?
#10.
Почему пользователи жалуются на качество нашей поддержки?
#11.
Пользователи винят нас в своих ошибках.
#13.
Почему наши пользователи не соблюдают правила безопасности?
#39.
Как мы можем сделать наших пользователей более ответственными?
Насколько полезным вы нашли этот материал?
Не полезно
1
2
3
4
5
6
7
8
9
10
Не полезно
Очень полезно
Спасибо за ваш вклад в развитие проекта!
Ссылки
UX CORE GUIDE
Добавление вашего вопроса
UX CORE PERSONA
Вводная статья
UX CORE GUIDE
(UXCG - Находим решения ваших проблем)
Как пользоватьсяUXCG — это бесплатный инструмент, который помогает командам выявлять проблемы пользовательского опыта, связанные с когнитивными искажениями, на всех стадиях разработки продукта: от прототипирования и тестирования до улучшения действующего продукта.
Как использовать UXCG
- Выберите стадию вашего продукта ниже;
- Выберите интересующий вас вопрос;
- Прочтите возможные ответы.
Каждый ответ объясняет, как когнитивные искажения связаны с вашим вопросом. Поскольку вы лучше всего понимаете свой контекст, вы можете напрямую применять полученные знания. Хотя инструмент не предоставляет готовых решений из-за уникальности каждого случая, он открывает новые перспективы, подкрепленные наукой.
Описание лейблов
Вопросы связанные с кооперацией команд и лиц, работающих над продуктом.
Вопросы связанные со стадией разработки продукта (от идеи до публичного релиза).
Вопросы связанные с продажами, маркетингом, потенциальными пользователями и общей оберткой продукта.
Вопросы связанные с интеракцией пользователей с продуктом и его функционалом.
Вопросы связанные с чтением аналитики по продукту.
Выберите стадию вашего проекта
#10.
Почему пользователи жалуются на качество нашей поддержки?
#30.
Какие ошибки мы допускаем в работе с аналитическими данными по продукту?
#41.
Что делать если упрямство наших коллег наносит вред рабочему процессу?
#43.
Что учитывать при планировании релизов продукта?
#45.
Что делать если некоторые участники нашей команды не высказывают свое мнение?
#50.
Как работать с некомпетентным коллегой/начальником?
#59.
Что учитывать при упоминании политических, социальных либо экономических событий в текстах компании/продукта?
#61.
Что делать, если команда тратит слишком много времени на неважные мелочи?
Be Kind. Do Good.