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


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

Так начался Errorgate 2021.

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

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

Из чего состоит плохое сообщение об ошибке

«Упс! Что-то пошло не так. (неподходящий тон) Сторонний сервис, к которому вы пытаетесь подключиться, не отвечает (перебрасывание вины на другого), поэтому мы не можем извлечь ваши данные (использование технического жаргона). Повторите попытку позже (слишком шаблонно)».

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

Неподходящий тон: представьте, что врач выполняет процедуру и внезапно произносит «Упс! Что-то пошло не так...» Это последнее, что хочет слышать человек, когда идёт хирургическая операция или происходят действия, связанные с источником его дохода. Неподходящее время для кокетства или легкомысленности. Мы хотим показать пользователям, что осознаём серьёзность ситуации и понимаем её важность для них.

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

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

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

Шаблонность без причины: иногда мы не знаем, что вызвало ошибку… но иногда и знаем. Если мы знаем, что её вызвало, но не сообщаем об этом пользователям, то оказываем им медвежью услугу.

Из чего состоит хорошее сообщение об ошибке

«Невозможно подключиться к вашему аккаунту (объясняет, что произошло). Внесённые вами изменения сохранены (успокаивает), но мы не можем подключиться к аккаунту из-за технической проблемы с нашей стороны (тоже объясняет, почему произошла ошибка). Попробуйте подключиться повторно (демонстрирует эмпатию и помогает пользователю устранить проблему). Если проблема возникает многократно, свяжитесь со службой поддержки (показывает пользователю выход из положения)»

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

Сказать, что и почему произошло: максимально чётко объясните, что произошло или не произошло. Это можно сделать сочетанием визуального оформления и текста. Объясните, почему пользователь получил это сообщение, даже если единственное объяснение заключается в том, что произошла техническая ошибка. Наша команда решила, что если в сообщении достаточно свободного места, нужно писать «проблема на нашей стороне», чтобы ещё раз подчеркнуть, что это не вина пользователя.

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

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

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

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

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

Как мы работали над устранением плохих сообщений об ошибках

Мы выполнили поиск по своей CMS и обнаружили, что в ней есть 7643 ключа со словом «error» в качестве ключа или значения. То есть нам нужно было проверить как минимум 7643 единиц контента.

Задача казалась монументальной.

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


Всего одна из досок Monday.com, которые мы использовали для разбиения на категории всех единиц контента, связанных с ошибками. Подобные доски помогли нам задать приоритеты, сроки выполнения и держать всех в курсе ситуации.

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

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

Затем мы распределили приоритеты ошибок, указав, над какими из них нужно работать первыми. Чтобы задать приоритеты, мы смотрели, насколько часто происходит ошибка, и мешает ли она пользователю завершить поток работы. После этого мы установили сроки от одной до четырёх недель, чтобы ничто не отошло на второй план.

Чему мы научились

Между шаблонным и нечётким сообщением есть разница. Наряду со множеством шаблонных сообщений «Что-то пошло не так» было и много нечётких сообщений. Они столь же плохи, как и шаблонные сообщения, и заслуживают такого же внимания.


Шаблонное сообщение: «Что-то пошло не так, и это действие не может быть завершено». Нечёткое сообщение: «Убедитесь, что вы включили требуемые разрешения, и повторите попытку».

Сравнение шаблонного и нечёткого сообщений. В шаблонном сообщении мы просто не говорим пользователю ничего, кроме того, что что-то пошло не так. В нечётком сообщении мы попытались объяснить, что пошло не так, но объяснение сбивает с толку.

Чаще всего проблема не в содержании. Наш CEO Ависхаи Абрахами, благодаря которому был начат этот проект, в своём письме ко всем сотрудникам сформулировал это так: «Шаблонные ошибки — результат плохой разработки и плохого продукта… Нам нужно заниматься ими всем вместе».

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

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

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

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

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

Что мы изменили в своём рабочем процессе

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

Считаем это общей ответственностью. За правильную обработку ошибок отвечают все. Менеджеры продуктов должны уделять больше внимания ошибкам и пограничным случаям, а не только правильным потокам выполнения. Разработчики должны изучать и документировать ошибки согласно руководствам по каждой из платформ. Дата-саентисты должны лучше анализировать ошибки, чтобы мы могли правильно отслеживать события.

Проверяем ошибки спустя месяц после запуска. Иногда, особенно в совершенно новом продукте, мы даже не знаем, каких ошибок ожидать. Поэтому мы могли запускать продукт со шаблонными ошибками, но теперь у нас есть процедура проверки ошибок спустя месяц после запуска. Это позволяет нам увидеть, какие ошибки самые важные, и писать содержание специально под них.

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

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

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