Как создавать лучшие сообщения об ошибках — опыт Wix

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

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

Добро пожаловать, ребята, на Errorgate 2021.

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

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

Что делает сообщение об ошибке плохим

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

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

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

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

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

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

Что делает сообщение об ошибке хорошим

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что мы узнали

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник