Проектирование ошибок. Технические проблемы

В чем проблема?

Продуктовые команды уделяют слишком мало времени ошибочным сценариям. Типичное сообщение об ошибке выглядит так:

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

Главное при проектировании ошибочных сценариев — целостный подход.

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

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

* * *

1. Глобальные сбои

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

Есть два основных правила:

• подумайте о последствиях;
• предупредите заранее.

1.1. Подумайте о последствиях

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

Ниже даны примеры таких сообщений.

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

«Это они создали проблему, пусть сами ее и решают!» — думает он. И обрушивает свой гнев на операторов колл-центра.

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

Когда все заработает?

Не обязательно указывать точное время окончания работ, но надо дать людям реальные ориентиры. Когда можно будет оплатить заказ в магазине или перевести деньги маме — через 15 минут, через час, через сутки? Слово «скоро» не годится, оно порождает лишние вопросы.

Работают ли банковские карты?

Коснулся ли сбой карт? Сообщите, можно ли расплачиваться ими сейчас.

Как проверить баланс?

Пришла ли зарплата или перевод? Подскажите, как проверить баланс альтернативными методами.

Что делать, если деньги нужны сию минуту?

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

1.2. Предупредите заранее

Если вы уже знаете про сбой, предупредите о нем пользователей.

Как это сделать:

• SMS- или е-mail-рассылка;
• социальные сети;
• уведомление в личном кабинете или на сайте.

Уведомление на главной странице сайта Антиплагиат

Как, кого и когда предупреждать, зависит от целевой аудитории. Одно дело — профессиональный сервис, другое — интернет-магазин.

* * *

2. Специфические баги

Для разработчиков это часть ежедневной работы. Для пользователей все иначе. Некорректная или нестабильная работа пугает их и сбивает с толку.

Что делать? Следовать двум правилам:

• создайте быстрый способ обратной связи;
• предупредите о баге.

2.1. Быстрая обратная связь

Само собой, пользователь понимает, что с сервисом творится неладное.

Он может сообщить об этом через:

• раздел «Контакты» и формы обратной связи;
• онлайн-консультант и телефон техподдержки;
• социальные сети и чаты компании;
• отзывы (особенно на App Store и Play Market);
• блоги и форумы.

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

И это большая проблема. Если пользователи молчат, это не значит, что на их стороне все хорошо.

Давайте посмотрим на сервис, который учитывает нежелание людей выходить на контакт. Вот как собирает фидбек Semrush.

Выше вы видите два способа сбора обратной связи. На самом деле у Semrush их куда больше. Кнопки и окна для фидбека есть на каждом экране, чтобы люди могли сообщать о проблемах (и не только), не отрываясь от работы. Такая легкость связи особенно важна для сервиса на этапе бета-тестирования.

2.2. Предупредите о баге

Если баг нельзя исправить сразу, предупредите о нем. Для этого используйте уведомления — уникальные или шаблонные (если есть style guide).

Например, на сайте иконочной гарнитуры Material простое уведомление предупреждает о проблемах с обновленной версией шрифта.

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

Эти принципы работают для любых сервисов. К примеру, для онлайн-школы изучения английского языка SkyEng. Посмотрите, как проработаны ключевые сценарии: для ученика, для преподавателя или нового клиента. Также дано несколько быстрых способов связаться со службой поддержки.

* * *

3. Внешние проблемы

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

Хороший сервис сообщает о таких неполадках как о своих собственных. В этом случае правил три:

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

3.1. Дайте знать, какие действия недоступны

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

В большинстве онлайн-сервисов (например, в Google Docs) не описано, что можно делать, если интернет отключен. Пользователь вынужден догадываться сам.

Не заставляйте людей думать. Дайте ясно понять, какие функции недоступны из-за внешних проблем.

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

А вот написать или отправить сообщение без интернета нельзя. Если сообщение о сбое находится где-то с краю, не в фокусе внимания, пользователь его попросту не заметит.

Поэтому, при разрыве соединения, Slack дополнительно подсвечивает поле ввода сообщения бледно-желтым. При попытке отправить сообщение Slack напоминает, почему эта функция недоступна.

3.2. Пишите для пользователя, а не для технического специалиста

Далеко не все пользователи знают, что такое сервер, IP-адрес, ядро, файервол и т. п. Помните об этом, когда пишете сообщения об ошибках. Технические детали полезны специалистам, но пользователь не обязан быть профи. Непонятный текст приводит его в смятение.

Это сообщение кажется понятным.

Но на самом деле…

— Что произошло? Что это значит? Как связаться с поддержкой? — вопросы вертятся в голове у пользователя.

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

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

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

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

Писать понятные тексты умеют не все, но при желании этому можно научиться. Прочитайте статью про UX-писательство.

3.3. Помогите понять серьезность проблемы

«Загорелся „чек“? Что если я поезжу так еще неделю до зарплаты, а потом отвезу машину в сервис?» — типичный вопрос на автомобильном форуме.

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

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

В общем, важно указать одно — серьезность проблемы. Иногда «эксплуатацию продолжать нельзя», а иногда и правда можно подождать до зарплаты.

* * *

Заключение

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

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