Пишем эффективные сообщения об ошибках

* отсылка к известному английскому афоризму: “Если жизнь дает вам лимоны, сделайте из них лимонад”.

Работа над ошибками — командный вид спорта.

Сообщения об ошибках являются неотъемлемой частью нашей повседневной жизни онлайн. Каждый раз, когда сервер не работает или мы забываем заполнить одно из обязательных полей в форме, мы получаем сообщение об ошибке. «Что-то пошло не так» — стандартный текст, с которым наверняка сталкивался каждый из нас. Но что пошло не так? Что именно случилось и почему? И, самое главное, как можно это исправить?

Около года назад наша команда внезапно осознала, что Wix слишком часто не дает пользователям ответы на эти вопросы. Получив тревожный звоночек, мы приняли решение действовать глобально, а не просто исправить одно сообщение об ошибке, которое заставило нас обратить внимание на проблему.

Добро пожаловать на Errorgate 2021!

Тогда мы исправили тысячи сообщений об ошибках на нашей платформе Wix всего за месяц.

Для начала нам нужно было определиться, какие сообщения об ошибках мы считаем плохими, а какие — хорошими.

Какое сообщение об ошибке можно назвать плохим?

Неподходящий тон: представьте, что в процессе проведения операции врач вдруг говорит: «Ой! Что-то пошло не так…» Это последнее, что хочется слышать, когда ставки так высоки (речь может идти о здоровье, доходе или чем-то еще), верно? Поэтому наша задача — показать пользователям, что мы понимаем, как это серьезно и важно для них.

Технический жаргон: даже в мире современного дизайна, ориентированного на пользователя, технический жаргон все еще проникает в сообщения об ошибках. Вы не смогли извлечь мои данные? Мои учетные данные были отклонены? Но что же все это означает? Технические детали не важны для пользователей, они просто хотят знать, что пошло не так и как это исправить.

Перекладывание вины: постарайтесь сосредоточиться на проблеме, а не на действии, которое привело к ней. Мы не можем стыдить и обвинять пользователей, даже если их поведение является причиной ошибки.

Также мы приняли решение не перекладывать ответственность на третьих лиц, потому что это выглядит непрофессионально. Пользователь пришел на платформу Wix, поскольку считает ее надежной и доверяет ей. Хотя мы можем сказать что-то вроде «У нас возникли проблемы с подключением к ___», мы никогда не скажем «___ сейчас не отвечает».

Шаблонные формулировки: иногда мы действительно не знаем, что вызвало ошибку. Однако если причина нам известна, но мы не говорим ее пользователям, мы оказываем им медвежью услугу.

Какое сообщение об ошибке можно назвать хорошим?

Информирует, что произошло и почему: используйте для этого комбинацию визуальных элементов и текста. Объясните, почему пользователь столкнулся с ошибкой, даже если единственной причиной является техническая проблема. В Wix мы приняли решение всегда, когда у нас есть для этого место, брать ответственность на себя («проблема с нашей стороны»), чтобы донести до пользователя, что в произошедшем нет его вины.

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

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

Помогает исправить ошибку: если есть способ исправить ситуацию, предоставьте пользователю точные инструкции по решению проблемы. Не хватает места? Тогда добавьте ссылку на страницу, которая поможет решить проблему. Например «Узнайте, как решить эту проблему» или «Как мне это исправить?»

Всегда предлагает решение: если пользователи не могут самостоятельно решить проблему или если проблема возникла повторно, предоставьте им способ связаться со службой поддержки.

Теперь, когда мы определили, какие сообщения об ошибках можно считать хорошими, а какие плохими, начнем избавляться от последних.

Как мы избавлялись от плохих сообщений об ошибках

Мы провели поиск в нашей системе управления контентом и обнаружили 7643 совпадений со словом «ошибка». Это означает, что нам необходимо было как минимум просмотреть 7643 фрагментов контента.

Задача казалась невыполнимой, но мы справились с ней.

Мы просмотрели каждый фрагмент и определили, имеет ли он отношение к тем целям, которые перед нами стоят. Когда мы составили список всех “шаблонных” и “бесполезных” сообщений об ошибках, мы отправили его разработчикам.

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

Опираясь на полученную информацию, менеджеры по продукту, UX-дизайнеры и копирайтеры приступили к поиску решений. Мы начали с переноса всех данных из электронной таблицы на доску Monday.com, где мы могли легко отслеживать список и статус задач. Иногда нужно было просто подправить в сообщении пару слов, в других случаях требовалось создать совершенно новый текст. Зачастую необходимо было также внести дополнительные правки в код.

Затем мы расставили все ошибки в приоритетном порядке. Мы сосредоточились на том, как часто возникает ошибка и проанализировали, мешает ли она пользователям достигать своих целей. Мы установили дедлайны от одной до четырех недель, чтобы ничего не упустить.

Что мы узнали?

Шаблонные и непонятные сообщения об ошибках — это не одно и то же. Безусловно, шаблонных сообщений «Что-то пошло не так» было много, но так же много было и непонятных сообщений. На самом деле, они не менее вредны, и заслуживают такого же внимания.

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

Нашей команде пришлось объединиться, чтобы исправить эти сообщения. Разработчики проводили исследования и искали причины ошибок. Менеджеры по продукту расставляли приоритеты и формулировали задачи. Дизайнеры проектировали новые пользовательские сценарии. А нам, UX-копирайтерам, пришлось писать и переписывать тысячи сообщений об ошибках.

Мы должны задавать больше вопросов: раньше разработчик мог сказать: «Нам здесь нужно шаблонное сообщение об ошибке. Можете добавить еще одно?» И мы соглашались, думая, что это сообщение будет появляться редко. Мы не задавались вопросами «Почему пользователи видят это сообщение?» и «Как все работает?»

Мы упустили возможность обучения: к сожалению, мы действовали реактивно, а не проактивно. Если бы эта работа была стратегически спланирована, она могла бы стать прекрасной возможностью для обучения, в частности, начинающих UX-копирайтеров. Вместо этого мы просто писали и переписывали сообщения, не задумываясь о стратегической пользе.

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

Когда мы работаем вместе, мы создаем лучшие продукты. Возможно это звучит банально, но это правда.

Что мы изменили?

Создали кросс-функциональную команду, чтобы сосредоточиться на обработке ошибок. Она состоит из старших менеджеров по продуктам, frontend и backend-разработчиков, UX-дизайнеров и UX-копирайтеров. Их цель — убедиться, что правильная обработка ошибок является частью жизненного цикла продукта, а не второстепенной задачей.

Все члены команды несут ответственность. Каждый несет ответственность за правильную обработку ошибок. Теперь менеджеры по продукту будут уделять больше внимания ошибкам и пограничным случаям, а не только удачным пользовательским сценариям. Разработчики будут выявлять и документировать ошибки в соответствии с принципами платформы. Специалисты по обработке данных будут лучше анализировать ошибки, чтобы мы могли эффективно отслеживать все события.

Анализ ошибок через месяц после запуска. Иногда, особенно если продукт совершенно новый, мы даже не знаем, каких ошибок ожидать. Единственный выход — запускаться с шаблонными сообщениями об ошибках. Мы решили проанализировать ошибки через месяц после запуска. Это позволит увидеть, какие из них возникают чаще всего, и написать текст специально для них.

Непрерывный процесс доработки. Как UX-копирайтеры, мы знаем, что все можно оптимизировать. Поэтому мы постоянно пересматриваем наши ошибки, даже те, которые мы обновили совсем недавно.

UX-копирайтеры имеют право ставить под сомнение шаблонные сообщения. Теперь, если менеджер по продукту или разработчик скажет: «Давайте везде использовать это шаблонное сообщение», у нас есть возможность сказать “нет”. Генеральный директор компании заявил, что шаблонные сообщения неприемлемы, поэтому мы не будем использовать их без дополнительного изучения и понимания проблем. 

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