В последнем релизе мы допустили грубую ошибку. Что делать?
English
Armenian
Russian
В последнем релизе мы допустили грубую ошибку. Что делать?
Копировать ссылкуСкопировано!
Поделиться
Возможные ответы (11)
. Ввиду того, что мы рассматриваем ошибки с точки зрения бизнеса, нам свойственно преувеличивать их значимость для пользователей. Поэтому, прежде чем мы будем решать что делать, нам следует оценить значимость ошибки глазами пользователя. Часто ошибки бывают несущественны для пользователей, что позволяет нам не публиковать их.
. Иногда мы преувеличиваем значимость ошибок из-за нашего личного подхода к делу. Чтобы избежать раздувания несущественных проблем, нам следует перепроверять наши предположения с командой.
. Нам следует четко понять какие эмоции вызывает эта ошибка. Для этого нам понадобится проанализировать процесс (workflow) в котором ошибка возникает, и определить «болезненность» ошибки. Именно интенсивность негативных ощущений вызываемых ошибкой отвечает на вопрос формы коммуникации которую мы выберем.
. Самые критические ошибки связаны с потерей пользовательских данных. Помимо скорейших извенений нам следует показать пользователям что ситуация под контролем, указав предпринимаемые нами шаги для восстановления данных. Если же потери безвозвратны, тогда мы обязаны предложить какие-то бесплатные бонусы и другие преференции.
. Если допущенная ошибка подразумевает, что ее долго будут обсуждать, нам следует выработать четкую позицию которую мы будем систематически доносить до нашей аудитории. В идеале мы должно добиться того, чтобы пользователи начали использовать наши аргументы для рационализации происшедшего. Прием широко используется политиками.
. Мы можем сообщить об ошибке в день, который окрашен положительными ассоциациями. При этом мы можем смешать сообщение с рядом хороших новостей. К примеру в следующем релизе мы можем рассказать о 6 нововведениях, 5 исправленных ошибках, и 1 найденной ошибке в прошлом релизе. При этом, если ошибка очень болезненная для пользователей, мы можем расписать детальный план по ее исправлению, чтобы пользователи видели что у нас все под контролем.
. Любые планируемые нами действия должны быть сверены с коллегами по команде. Иногда бездействие и игнорирование ошибки может быть хорошим решением (так делают много компаний). Однако в некоторых случаях игнорирование может стать худшим вариантом.
. Во время публичного признания ошибки нам следует избегать формулировок, в которых пользователи смогут «увидеть себя» (). Помимо этого наша коммуникация никаким образом не должна напоминать пользователю о теоретически возможных катастрофических последствиях ().
. Иногда бывает полезно дать пользователям какую-то кнопку, для обеспечения их эмоционального комфорта. К примеру можно добавить кнопку «Сообщить об ошибке» на странице где мы сами знаем, что есть ошибка. Подобный ход может быть полезен если нам нужно немного времени (24 часа?) для исправления ошибки.
. В зависимости от публичной дискуссии, которая началась после публикования ошибки, обязательно найдутся «эксперты», которые будут говорить, что «это было очевидно», «лишь вопрос времени» и т.п. Нам категорически не следует реагировать на такие выпады, т.к. это бесполезно. Если мы замечаем похожие настроения среди наших коллег – это должно быть резко пресечено.
. Большинство крупных ляпов можно вылечить со временем. Нам ни в коем случае не следует останавливать развитие продукта. Обновления должны выходить в штатном режиме. Нам следует избегать ситуаций, где мы сами нечаянно раздуем значимость проблемы ().
Связанные вопросы
#43.
Что учитывать при планировании релизов продукта?
#8.
Почему пользователи остро реагириуют на изменения в продукте?
#5.
Почему пользователи жалуются на обновления продукта?
#7.
Почему пользователи разочаровываются в нашем продукте?
#55.
Какие компоненты продукта наиболее чувствительны к изменениям?
Насколько полезным вы нашли этот материал?
Не полезно
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.