Помощь группа сообщить об ошибке

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

Вот об этом я сегодня подробно и расскажу. 

Перед тем как написать письмо Яндексу…

Проверьте, не освещен ли ваш вопрос в специальном справочнике. В большинстве случаев ответы находятся там, и никуда в последующем писать не придется. В некоторых случаях можно погуглить пояндексить – бывает, что решение находится и на других сторонних ресурсах. Отправлять обращение в поддержку компании стоит только в том случае, если проблема носит уникальный характер. А уж там специалисты постараются решить ваш вопрос максимально быстро. 

Способы обращения в службу поддержки Яндекса

В каждом сервисе и приложении компании предусмотрен свой способ связи с сервисной службой. Существует общая страница, объединяющая все платформы – это Яндекс.Справка. Чтобы вопрос решился максимально быстро, рекомендуется обращаться именно через эту страницу. Потребуется выбрать сервис, с которым вы работаете, перейти в раздел «Служба поддержки» и написать о проблеме. Где-то действовать придется иначе, и об этом речь пойдет далее. 

Главная страница Яндекса

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

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

Яндекс.Маркет

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

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

Яндекс.Музыка

В музыкальном сервисе тоже предусмотрены отдельные способы обращения. В первую очередь это, конечно же, страница Справки. Но есть и другой способ – открыть свойства профиля и перейти в «Чат с поддержкой». В результате будет осуществлен переход в Яндекс.Мессенджер и открыт соответствующий чат. 

В приложении все работает несколько иначе. Для начала надо открыть раздел «Настройки», там перейти пункт «Написать разработчикам», указать тему сообщения и приступить к подробному описанию. 

Яндекс.Плюс

Обратиться в техподдержку компании по поводу подписки можно опять-таки со стартовой страницы, причем как с авторизацией в аккаунте Яндекса, так и без такового. Универсальный способ – прокрутить сайт до самого низа и открыть раздел «Служба поддержки» или же нажать на иконку «Поддержка» для общения со специалистом в Мессенджере.

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

Яндекс.Почта

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

Яндекс.Go

У сервиса такси и доставки технический раздел тоже реализован нестандартно. Да, перейти можно все тем же способом – открыть одноименную ссылку в подвале страницы. Далее вас перенаправит на страницу поддержки. Выбираете категорию вопроса, добавляете описание и отправляете сообщение сотруднику. Обработка будет осуществлена в максимально короткие сроки. 

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

Яндекс.Дзен

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

Яндекс.Вебмастер

Чтобы попасть в раздел службы поддержки Яндекс.Вебмастера, нужно перейти со стартовой страницы данного сервиса в раздел «Обратная связь». Он располагается, конечно же, в самом низу. Далее в справочнике вы сможете выбрать тему и изложить суть проблемы непосредственно специалисту сервиса. 

Яндекс.Директ

Способ решения проблемы в Директе практически не отличается от предыдущих – со стартовой страницы открываете раздел «Обратная связь» и конкретизируете тему сообщения. Но тут еще есть возможность связаться со специалистом по телефону. Все номера указаны в соответствующем разделе, у всех городов и регионов они отличаются. Есть даже контакты для тех, кто хочет обратиться с проблемой из СНГ. Вопрос можно решить как со стороны клиента, так и рекламного агентства. 

Заключение

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

Общение сотрудника технической поддержки с клиентом – это тонкая грань, по которой должны пройти оба участника диалога, чтобы успешно решить возникший вопрос. Имеется ввиду то, что в обучении по клиентскому обслуживанию чаще всего упоминается о персональном подходе к каждому клиенту. Однако стандартные ситуации Никуда не исчезнут и будут также систематически появляться. От сюда и идет речь о тонкой грани общения, ведь сотрудник Help Desk практически должен чувствовать своего собеседника на той стороне провода. Чтобы каждое обращение в службу поддержки не вызывало у сотрудника чувство безысходности и не ставила в тупик, необходим заранее заготовленный список шаблонных ответов. Чтобы сейчас не ломать голову над тем как составить такой список, воспользуйтесь шаблонами проверенными временем, которые безотказно работали и продолжают работать по сей день. Подчеркну, что не стоит использовать данные ответы в качестве способа по быстрее избавиться от клиента. У них абсолютно другое предназначение, они помогают сотруднику технической поддержки расположить клиента и выйти из сложной тупиковой ситуации. Давайте перейдем далее и рассмотрим поподробнее каждый шаблонный ответ из волшебного списка.

Был рад помочь!

Как показывают статистические данные, только 25% клиентов обращающихся в техническую поддержку, оставляют обратную связь по прошедшему диалогу с сотрудником Help Desk, остальные остаются в стороне. Не каждый клиент высказывает свое мнение по поводу оказываемых услуг. Некоторые обращающееся стыдятся того, что им что-то непонятно и ввиду этого не сообщают поддержке о недопонимании. Другие клиенты слишком лояльны и не претендуют с ярым желанием указать на Ваши проблемы в части объяснения решения. Эти и другие факторы заставляют клиента не оставлять оценку по выполнению обращения. Но обратная связь с клиентской стороны важна, даже негативная, так как это позволяет совершенствоваться в лучшую сторону. Так, как быть и получать оценки по выполненной работе? Нужно изменить свое понимание в части закрытия заявки. Думайте не о том как закрыть вопрос, а о том как «закрыть клиента» по принципам продаж. Задача заключается в том, чтобы вопрос был решен, и клиент был полностью удовлетворен данным решением. При этом старайтесь оставлять завершающий ответ с фразой, которая будет означать, что Вам было приятно помочь решить проблему и готовы сделать это вновь, если понадобиться. Таким образом наводите клиента на мысль о всегда открытой для него двери. Так у клиента пропадет чувство надоедания, почувствует, что ему всегда здесь рады и он будет полностью расположен к тому, чтобы оставить отзыв и чаще положительный отзыв.

Очень жаль, я представляю каково это (…)

Сочувствие, понимание важные аспекты, которые стоит проявлять в диалогах с расстроенным клиентами. Как говорил в начале статьи, сотрудник поддержки должен чувствовать собеседника, значит разделить переживания. Без подобного приема нельзя будет начать продуктивное общение, приводящее к успешному решению. Первым делом, проявляем понимание и сочувствие, а после переходим к делу. Правда, на практике здесь допускаются ошибки, support старается ответить слишком банально «Жаль, понимаю Вас». Это неправильно, здесь необходима конкретика, клиент должен почувствовать, что Вам знакома подобная ситуация. Для этого нужно воспроизвести ситуацию простым пониманием и посоветовать выход. Звучит абстрактно, поэтому приведу пример, поступает обращение «Программа не работает, не могу завершить работу. Теперь придется задержаться на работе и пропустить (некое событие)». На что сотрудник отвечает: «Мне очень жаль, что произошла такая ситуация. Задерживаться на работе это не из приятного, но ничего, сейчас вместе быстро устраним проблему и Вы везде успеете». Согласитесь, услышав подобный ответ, человек воспрянет духом так как почувствует мощную поддержку. Это позволит ему не опустить руки, а стараться в тандеме с сотрудником технической поддержки решить вопрос. Клиент предоставит всю необходимую информацию, а специалист продуктивно использует ее в решении.

Хороший вопрос, минуточку, я уточню.

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

Ни в коем случае не старайтесь юлить и оперировать аргументами о недолгом нахождении на данной должности. Ответы из разряда:

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

Подскажите, пожалуйста.

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

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

Спасибо за Ваше обращение.

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

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

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

Хоть мы и не Гугл, и даже не Яндекс, нам довольно часто пишут в поддержку: хостинг — дело серьезное.

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

При этом обработка тикета будет проходить быстрее, если правильно составить текст запроса. Рекомендации о том, как это сделать, собрали в статье.

Три главных правила для составления запроса:

1. Сформулируйте суть проблемы

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

Для сравнения возьмем два запроса об одной и той же проблеме:

Запрос №1: 

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

Запрос №2:

«Здравствуйте!
1. На сервере 123.45.67.89 не загружается сайт domen.ru, возникает ошибка 500 Server Error (скриншот). 
2. Зайти на сервер не удалось, подключался так:
ssh root@123.45.67.89 -p22 
с паролем RiDFuk3E»

Из примеров наглядно видно, что по Запросу №2 можно сразу приступать к диагностике работы сервера 123.45.67.89, чтобы установить причины ошибки 500 на сайте domen.ru. По Запросу №1 нужно сперва выяснить: о каком сервере идет речь, какой сайт не работает, как возникает ошибка, с каким паролем не удается подключиться. Таким образом, выяснение информации потребует участия клиента и займет какое-то время, а значит к решению проблемы техподдержка приступит значительно позже, чем в случае с Запросом 2.

2. Создавайте отдельные тикеты на разные вопросы

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

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

3. Проверьте, нет ли готового ответа на ваш вопрос

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

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

Шаг 1. Собираем данные для написания запроса

1. Если сервер недоступен

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

• Есть ли пинг до сервера?
• Сайт открывается не только по домену, но и по IP-адресу? В ином случае см. пункт 2.
• Панель управления открывается? Есть SSH/FTP-доступ?
• Нет ли проблем с вашим интернет-соединением? Попросите друга попробовать зайти на сервер и узнать, будет ли проблема у него.
• Баланс лицевого счета положительный и услуги не остановлены? Нет запроса о блокировке или уведомления в личном кабинете о каких-либо работах?
• Сервер доступен через VMmanager по VNC или Shell-доступ(OVZ)? Если да, см. пункт о проблемах сети.

2. Если сайты недоступны (но сервер доступен, в ином случае см.п. 1)

Лучше всего собрать ответы на следующие вопросы и кратко описать их в тексте запроса:

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

3. Не пускает с логином и паролем в ISPmanager, BILLmanager, phpMyAdmin, FTP, MySQL, Почтовый клиент, SSH или в другое место.

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

4. Не запускается программное обеспечение.

• Какое программное обеспечение вы запускаете? Как вы запускаете ПО?
• Возможно ли запустить данную программу через консоль?
• Какую ошибку вы видите при запуске программы через консоль?
• Что пишется в логах запускаемого программного продукта?
• Вы писали в техническую поддержку этого программного продукта? Какой ответ?
• Как должен выглядеть успешный запуск программного обеспечения?

5. Отправка и принятие почты.

• С какого на какой ящик почта не уходит/приходит? 
• При отправке вы видите какие-либо ошибки?
• На ящик отправителя приходит письмо с ошибкой? 
• На другие почтовые ящики почта уходит/приходит? 
• Какой почтовый клиент вы используете? 
• Или вы используете скрипт при отправке? Какой? 
• Работала почта раньше? Отправляли ли рассылки?

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

• Что делать, если мои письма не доходят или попадают в папку «спам»?
• Работа с почтовым сервером exim при блокировке почтового трафика
• Как настроить отправку почты с нового VDS
• Настройка почты на сервере в панели ISPmanager 5
• Как настроить почту для Bitrix GT
• Настройка почты на VM Bitrix

6. Проблемы сети.

• Какой IP компьютера, с которого у вас наблюдается проблема?
• На другом устройстве и при выходе в интернет через другого провайдера проблема сохраняется?
• Для анализа проблемы необходимо, чтобы вы при помощи утилиты mtr, сформировали детальный отчет, с соблюдением двух условий:
  • должно быть отправлено не менее 1000 пакетов;
  • мультитрейс должен быть сделан в обоих направлениях, то есть на проблемный сервер и с него в обратном направлении.

Способы установки mtr:

• SuSE: через Yast 
• Debian/Ubuntu: apt-get install mtr-tiny
• Gentoo: emerge -av mtr 
• FreeBSD: pkg install mtr-nox11 
• Windows: winmtr http://winmtr.sourceforge.net  

Хорошо подойдет для диагностики следующий синтаксис, по окончанию будет выведен отчет:

mtr -s 1000 -r -bw -c 1000 -i 0.1 www.ya.ru 

Тест обычно занимает около 3-4 минут.

При запуске Winmtr на Windows использовать синтаксис, указанный выше, не нужно. Достаточно указать проблемный IP, запустить мультитрейс и дождаться, когда счетчик покажет 1000 пакетов.

• Добавляли/меняли ли ip-адреса и другие сетевые настройки на вашем сервере?
  Полезная статья на нашем сайте: Сетевые настройки в кластерах с технологией VPU

7. Не работает элемент сайта

• На каком сайте возникает проблема?
• Какая именно функция сайта не работает (импорт, корзина, страница, плагин, тема)?
• Как воспроизвести проблему в работе сайта?
• Проблема сохраняется в различных браузерах с различных устройств и провайдеров интернета?
• На сайте отсутствуют вирусы? Инструкция по поиску вирусов в панели ISPmanager
• Какой результат должен быть при корректной работе функции сайта?

8. Установка дополнительного программного обеспечения на сервер.

• Что вы пытаетесь установить?
• Какую команду для этого вы запускаете? Может вы пользуетесь какой-то инструкцией?
• Какую ошибку вы видите при установке?
• Соответствует ли сервер техническим требованием устанавливаемого вами ПО?

Шаг 2. Пишем запрос

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

А именно:

• Если у вас подключено несколько проектов (FirstVDS или 1Dedic), выбирайте нужный проект в правом верхнем углу личного кабинета.
• Выбирайте нужную услугу (очень важно). Даже если она у вас одна. Без выбранной услуги у сотрудников поддержки не отобразится информация по вашей услуге и им придется сначала опираться только на ваш текст, а уже потом, исходя из понимания вашего текста, выбирать услугу.
• Придерживайтесь официально-делового стиля, останавливаясь только на конкретике и фактах.
• В теме указывайте суть проблемы.
• Подробно описывайте проблему (ответьте на все перечисленные выше вопросы из того раздела, который относится к вашей проблеме).
• Предоставьте сразу все необходимые для решения проблемы доступы (очень важно). Речь идет чаще всего о пароле и порте для доступа по SSH/FTP/ISPmanager, доступе в админ-панель сайта, доступ в почтовый ящик (если не работает почта) и т.д.
• Если несколько вопросов на одну тему, разбейте их на отдельные пункты и визуально обозначьте это в тексте запроса (например: 
  1) ……….
  2) ……….
  и т.д.)
• Если несколько вопросов на разные темы и по разным услугам, создайте по каждой отдельный запрос.

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

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

Способы связи с Яндекс Маркетом

Чтобы отправить свой отзыв или просьбу в Я.Маркет, клиент может воспользоваться одним из вариантов.

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

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

Номер горячей линии и email

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

Номер телефона и email:

• 8 (495) 414‑30‑00
• help@market.yandex.ru

Кроме основного адреса электронной почты у Я.Маркета есть чат в Твиттере Как отправить сообщение:

1. Перейти по ссылке: Техническая поддержка Маркета
2. Авторизоваться и перейти к чату.
3. Вписать сообщение – отправить.

Но страница активно не ведется, поэтому вероятность получить ответ таким способом – ниже, чем по номеру телефона.

Написать в социальных сетях

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

Как получить помощь с помощью Вконтакте:

1. Перейти в официальное сообщество: Яндекс Маркет в ВК
2. Сверху появится значок: «Отправить сообщение» — описать проблему.
3. Отправить уведомление.

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

Почтовый адрес Я.Маркета

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

Изначально, пользователю нужно написать в чат поддержки на сайте:

1. Зайти в Яндекс Маркет – авторизоваться.
2. Нажать по значку своей аватарки – в выпадающем меню выбрать: «Чат поддержки».
3. Отправить сообщение и подождать, пока ответит оператор.

Вопросы отправляют в правовой департамент, если это касается проблем с товаром, его комплектацией или с повреждениями, которые появились при доставке.

Как получить поддержку партнерам

В Яндекс Маркете поддержка продавцов и партнеров осуществляется через дополнительный сайт. Это страница, где можно авторизоваться и начать продавать. В нижней части страницы находится кнопка: «Служба поддержки».

Как воспользоваться помощью:

1. Перейти по ссылке: Сайт про продавцов
2. Снизу кнопка: «Служба поддержки».
3. Снизу появится «Поддержка для партнеров».

Отправить запрос можно двумя способами: если есть доступ к кабинету или если он отсутствует.

Во втором случае:

1. Воспользоваться ссылкой: Форма обратной связи
2. Тип запроса: Другое или Жалоба.
3. Заполнить основную информацию: ID магазина, имя, почта для связи, добавить текстовое уведомление.
4. Отправить запрос и подождать ответ на email.

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

В остальных случаях, обращаться в Яндекс Маркет возможно через стандартный чат поддержки в профиле:

1. Зайти с мобильного приложения – авторизоваться.
2. Нажать кнопку: «Мой профиль» — Служба поддержки.
3. Вписать внизу текст проблемы – отправить.
4. Ответ поступит от реального оператора.

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

Какие вопросы рассматривает Я.Маркет

Яндекс Маркет рассматривает проблемы, связанные с:

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

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

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

В основе статьи доклад Антонины Хисаметдиновой с Heisenbug 2017 Moscow, которая занимается проектировкой пользовательских интерфейсов в компании Собака Павлова.

Кроме того, на Медиуме есть цикл статей «Руководство по проектированию ошибок». Цикл еще не дописан до конца, но дает более полную и цельную картину по теме статьи.

Ошибочный сценарий

Раз за разом мы проектируем основные сценарии самых разнообразных сервисов. В случае интернет-магазина основной будет таким:

Человек заходит на сайт, выбирает товар, заказывает его доставку; оплачивает и получает заказ.

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

Всё это — ошибочные сценарии, возникающие, когда что-то идет не так.

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

Еще пример: «У нас ошибка. Повторите вашу попытку позже»:

И еще одна категория ошибок — моя любимая: неизвестные ошибки.

Зачем работать над ошибочными сценариями?

Обосновать бизнесу необходимость проработки ошибочных сценариев бывает очень сложно. Зачем нам возвращаться назад и что-то исправлять, когда впереди у нас новые фичи? Но у меня есть четыре железных аргумента, которые помогут продемонстрировать вашему product owner’у или бизнесу необходимость такой работы.

Хорошее сообщение об ошибке снижает нагрузку на техническую поддержку и персонал

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

Обратите внимание, 400 человек в месяц звонят просто из-за того, что не могут войти или корректно ввести логин / пароль в соответствующей форме на сайте.

Хорошее сообщение об ошибке помогает пользователю не потеряться в воронке конверсии

Если сообщение об ошибке составлено грамотно, оно возвращает его к основному сценарию, даже если произошел разрыв сессии.

Хорошее сообщение об ошибке обучает работе с сервисом

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

Хорошее сообщение об ошибке позволяет сохранить доверие к сервису в трудную минуту

Это последний, но немаловажный аргумент.

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

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

Из-за чего возникают ошибки

Я несколько раз упомянула «хорошее сообщение об ошибке». Настала пора поговорить о том, что это значит. И для начала разберемся, из-за чего в принципе возникают ошибки.

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

Но это далеко не всё. Еще есть:

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

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

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

Давайте начнем с ситуации, когда ваш сервис полностью недоступен.

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

Хороший вопрос: что в такой ситуации делать?

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

Давайте посмотрим на сообщения, которые в этот момент выводятся:

Они достаточно простые и некоторые из них даже честно извиняются. Но пользователи все равно чувствуют себя некомфортно и пытаются понять, в чем же дело; повторяют вход далеко не через 15 минут; тыкают, куда попало.

Как им помочь?

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

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

Многие в таких ситуациях ограничиваются сообщением: да, у нас есть проблема и мы скоро ее поправим:

Но «скоро» — это когда?

Пользователю не нужно знать, когда вы всё поправите, с точностью до минуты. Но им нужно понимать какие-то значимые временные ориентиры, например, 15 минут, один час, пять часов или даже сутки. Это поможет им сориентироваться в пространстве и спланировать управление своими деньгами.

Еще один резонный вопрос (в ракурсе финансового сервиса): работают ли карточки?

И хорошее сообщение об ошибке сможет на него ответить. Даже если карточки не работают, лучше всё равно об этом сказать, потому что это очень важная информация.

Еще одна история — тут зарплата или перевод должны быть; а когда придут эти деньги?

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

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

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

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

Не все пользователи готовы зайти в личный кабинет прямо сейчас, и далеко не все пользователи в принципе зайдут и заметят ошибку. Но если вы предупредите их заранее (например, постом в Twitter, SMS-сообщением или по электронной почте), то когда они столкнутся с сообщением об ошибке, будут готовы.

Отдельно стоит сказать про профессиональные сервисы, от которых ежедневно зависит работа пользователей. Например, сервис Антиплагиат иногда выводит такое сообщение о проведении технических работ:

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

Тема предупреждений об ошибках косвенно связана с сохранением доверия. Может показаться, что очередное предупреждение об ошибке заставит часть пользователей усомниться в надежности сервиса (возможно, они бы в этот момент и не воспользовались сервисом, т.е. в принципе не узнали бы об ошибке). Но восприятие предупреждения как заботы или как лишнего камня в огород сервиса зависит в том числе и от того, как часто вы говорите, что у вас проблемы. Плюс есть совершенно разные сервисы. Интернет-банк — это одно. Но, к примеру, если у вас интернет-магазин, не нужно каждый раз писать пользователю о проблемах, потому что он заходит к вам не так часто.

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

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

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

Для нас баги — это знакомая история. Мы четко классифицируем их по разным параметрам: степени опасности, необходимости исправления и т.п.

Но пользователи когда замечают баг, в принципе не понимают, с чем они столкнулись. Многие даже не знают этого термина. Для них баги на самом деле выглядят вот так:

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

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

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

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

Или могут вообще перестать пользоваться вашим сервисом, как неработающим.
Поэтому в багтрекере ВКонтакте висит такой вот тикет, который называется «отсутствие кнопки «Сообщить о баге»»:

Действительно, это проблема очень многих сервисов.

Создайте специальные окна для сбора обратной связи

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

В такой ситуации пользователю стоит меньших усилий написать вам о какой-то ошибке или о фидбеке. Особенно это актуально для бета-тестирования.

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

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

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

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

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

Ошибки пользователей

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

Первый пример узкого места многих сервисов — это, конечно, вход / регистрация:

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

Это происходит, потому что внимание пользователя в момент входа сосредоточено в одной очень узкой области — она называется фокусом внимания:

Как вы видите, сообщение об ошибке, достаточно высоко и пользователь может его просто не заметить при обновлении страницы. К тому же InVision стирает пароль (надо же помочь пользователю…). И шевеление в области пароля еще больше фокусирует внимание пользователя; он думает, что ошибка именно там.

Фишка 1. Разместите сообщение в фокусе внимания

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

Фишка 2. Показывайте, где именно ошибка

Подсвечивание обоих полей — это и есть вторая фишка.
Но и это не всегда помогает.

Например, дизайнеры компании Adobe считают, что пользователи действительно это всё читают:

Еще один классический пример предлагает Xiaomi:

Или, например, сайт Госуслуги (как и многие другие) просто дублирует название поля заголовка в ошибку:

Фишка 3. Используйте понятные и короткие формулировки

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

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

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

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

Фишка 4. Подскажите, как исправить ошибку

Кто сталкивался с кассами самообслуживания?

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

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

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

Фишка 5. Сохраняйте работу пользователя

Последнее, но самое интересное.

Давайте сразу на примере. Это кусочек пути регистрации (в очередной раз напоминаю, что регистрация — достаточно слабое место у очень многих сервисов):

Чтобы вообще начать пользоваться финансовым сервисом Revolut, я должна сначала подтвердить свой номер телефона. Обратите внимание, они уже автоматически определили и подставили код страны. Спасибо ребятам.

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

Но меня не обманешь — я ввожу адрес латиницей, нажимаю Continue. И, как вы думаете, что происходит?

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

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

Проблемы подключенного сервиса

Тестируйте API подключенных сервисов

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

Однажды этот мопс-партнер позвонил в стоковую компанию и пожаловался на поломку сервиса.

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

Учите их различать проблемы

Иногда недостаточно просто знать, что где-то там у вас проблема, потому что пользователи будут видеть странные окна, которые не будут им помогать:

И в интерфейсе эту проблему не решить.

Поэтому очень важно потратить усилия, чтобы научить ваш сервис различать причины проблем с API.

Предусмотрите в интерфейсе оповещение о проблемах

Очень хороший пример — сервис-автоматизатор ifthisthenthat. С помощью связок API различных сервисов (например, умного дома или социальных сетей) они заставляют сторонние сервисы делать определенные вещи. Например, если я опубликовала пост в Instagram, он автоматически уходит в мой Facebook. Или, если я вышла из дома, сервис определяет по моей геопозиции, что я нахожусь в офисе, и проверяет, выключила ли я все свои смарт-утюги. А если не выключила, то выключает.

Эти ребята проделали очень большую работу, и не только в интерфейсе.

Во-первых, они выделяют отдельную вкладку для ошибок. Все неудавшиеся операции собираются в этот лог.

Они определяют разные типы ошибок:

В первом случае — сервис Instagram офлайн, и мы понимаем, в чем проблема. Возможно, мы временно вышли из зоны действия сети.

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

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

Что такое внешние проблемы в моем пользовательском понимании?

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

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

Хороший пример — отсутствие интернет-соединения в коммуникаторе Slack. Если во время работы у меня отвалился интернет, я вижу вот такое сообщение сверху:

Как мы помним про сообщения об ошибках пользователей, в момент ввода какого-то текста пользователь сконцентрирован в этой области:

Slack об этом не забывает и подсвечивает поле желтеньким.

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

И в принципе очень доступно объясняет, с чем именно проблема. Такую ошибку я замечу достаточно быстро.

Большая проблема с внешними ошибками, которая пришла к нам еще из «древних» времен, когда продукты создавались инженерами для инженеров, — это содержание текстов об ошибках:

Они написаны таким языком, как будто мы сейчас до сих пор подразумеваем, что пользователь знает, что такое firewall, ftp, dll, ядро, kernel и так далее.

Четко разделите уровни компетенции

Техническому специалисту мы показываем одну информацию, а пользователю — другую.

Наверное, стоит отдельно сказать про то, как люди в принципе общаются с техподдержкой.

Для многих это действительно большой стресс. Большая часть сообщений об ошибках совершенно не подразумевает, что они должны быть поняты. Человек, который даже не знает английского языка, пытается как-то объяснить: у меня там что-то сломалось. Он испытывает очень сильный дискомфорт. И всё это влияет в целом на его опыт общения с вашим сервисом. Поэтому старайтесь создавать такие сообщения, которые пользователь сможет осознать и своими словами передать техподдержке.

Например, это фото 3D-принтера, который четко и ясно (с помощью маленького экранчика) говорит, что температурный сенсор испортился — произошла ошибка, поэтому он остановился. Свяжитесь с техподдержкой. Пользователь легко может понять, в чем дело, и для него не сложно описать эту проблему своими словами без технических терминов:

Помогите пользователю оценить приоритет проблемы

Что это значит?

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

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

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

Крайне необычное поведение пользователей или сервисов.

Бывает ситуация, как на графике. Что вызвало такой резкий скачок? К примеру, это температура в двигателе повысилась? Или это просто датчик какой-то забарахлил?

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

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

Но за PewDiePie тоже стояла большая армия поддержки. И на игры Шона Ванамана в Steam (сервис, который продает эти игры) посыпались сотни негативных отзывов. Эти отзывы не отражали качество игры, но могли негативно сказаться на ее продажах. И Steam проделал просто потрясающую работу: они обратили внимание пользователя, что произошло, что замечен нетипичный объем отрицательных отзывов с 11 сентября:

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

Дополнительные возможности — скрытый потенциал

Не все ошибки — просто баги. У многих есть скрытый потенциал. Давайте про это немного поговорим.

Обучайте через ошибки

Во-первых, как я уже говорила ранее, через ошибки можно и нужно обучать.
Например, сервис Skyeng — это онлайн школа английского языка, которая работает только через браузер Google Chrome. Этот браузер автоматически (по дефолту) иногда блокирует входящие видеозвонки или аудиозаписи. И в такой ситуации Skyeng вешает кнопочку, которая ведет на вполне подробную инструкцию:

У этого решения тоже есть некоторые проблемы. Если таких кнопочек в вашем сервисе будет очень много, все эти инструкции будет просто невыносимо, дорого и сложно поддерживать в актуальном виде. А пользователь на самом деле не сильно любит читать какие-то инструкции.

Еще один пример — SEMrush. Это окно входа в сервис:

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

Выводите из тупика

Еще один потенциал сообщений об ошибках — это вывод из тупика.

Часто ошибки являются абсолютно тупиковыми сценариями. Пользователю нужно вспоминать контекст и возвращаться по сценарию выше.

Например, возьмем сервис Avito. Там есть вкладка «Сохраненные поиски»:

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

А можно было сделать вот так:

Мы знаем (сохраняем) историю и выводим ее здесь, чтобы пользователь, не отрываясь от контекста, нажал звездочку и сохранил какой-то нужный ему поиск. Таким образом мы превращаем тупиковый сценарий в возврат к основному пути.

Доступность

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

Меня очень радует, что в последнее время об этом стали много говорить, и много в этом направлении стали делать. Например, недавно UsabilityLab проводили тестирование доступности интернет-банков для людей с нарушениями зрения и слуха.

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

Например, многие используют только цветовую индикацию ошибки. Так делать не стоит, потому что есть дальтоники:

Многие дизайнеры скажут: «Я всё проверил в специальном сервисе, который показывает, как видит дальтоник». Но на самом деле эти сервисы никогда не покажут точной картины, потому что все дальтоники видят по-разному. И даже если вы подберете яркость / контрастность, всё равно существует риск, что пользователь-дальтоник эту ошибку не распознает.

Например, поле регистрации во Wrike содержит как раз такую ошибку:

У них реализована чисто цветовая дифференциация — при ошибке красным подсвечивается обводка и текст внутри поля. Лучше всего добавить какое-то текстовое сообщение или символ.

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

Человек просто сломает глаза при попытке прочитать такой текст.

Проводите Accessibility testing для сценариев с ошибками

Бизнес-ценность

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

Что нужно делать? Мой коллега выстроил работу в своем коллективе следующим образом. Все ошибки, которые возникают, сначала собираются в какой-то один большой мешок (log). Оттуда вычленяются только те ошибки, которые повторяются.

Повторяющиеся ошибки уже имеют бизнес-ценность. Это те ошибки, на которые стоит потратить время.

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

Я понимаю, что интерфейс — это не всегда часть вашей работы. И даже далеко не все product owner’ы горят желанием выстраивать работу с ошибками в своей команде, потому что это не всегда выгодно (выгода, если и есть, иногда не видна сразу). Но моя цель — немного расширить ваш образ мышления и задать вопрос: вы делаете только свою работу или вы делаете классный продукт?

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

Резюме

Что я предлагаю вам делать со всей этой информацией?

1. Когда вы придете на работу, обсудите доклад с командой и владельцем продукта. Особенно полезно зайти к UX’ерам или к дизайнерам.
2. Проверьте, насколько ваши сообщения об ошибках полезны пользователям.
3. После этого вы сможете комплексно посмотреть на свой продукт, найти его слабые места, которых раньше, возможно, не замечали, и улучшить ошибочные сценарии.
4. И еще один очень важный пункт в контексте тестирования — ошибочные сценарии тоже нужно тестировать и часто на равных правах с остальными.

Что почитать?

Здесь есть несколько ссылок:

1. «Release It!: Design and Deploy Production-Ready Software», Michael T. Nygard
2. «How to write a great error message», Thomas Fuchs, https://goo.gl/4L8YWo
3. Architecting Your Software Errors For Better Error Reporting, Nick Harley, https://goo.gl/7em6cQ

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

Если тема тестирования и обработки ошибок вам так же близка, как и нам, наверняка вас заинтересуют вот эти доклады на нашей майской конференции Heisenbug 2018 Piter:

• Пишем UI тесты для Web, iOS и Android одновременно # python (Игорь Балагуров, Uptick)
• Web Security Testing Starter Kit (Андрей Леонов, SEMrush)
• Бета-тестирование ВКонтакте (Анастасия Семенюк, ВКонтакте)