Я считаю сообщение об ошибке частью продукта, когда оно помогает продолжить работу
Я считаю сообщение об ошибке частью продукта, когда оно не просто сообщает о сбое, а помогает человеку продолжить работу. В B2B-сервисе ошибка редко случается в пустоте: сотрудник оформляет заказ, закрывает месяц, вносит данные после звонка с клиентом. Если в этот момент экран отвечает «что-то пошло не так», работа не исчезает — она переезжает в чат, Excel или телефонный звонок.
На первый взгляд это мелочь интерфейса. На деле именно такие мелочи решают, станет ли сервис привычным рабочим инструментом или его будут обходить при первом напряжённом дне.
Ошибка — это момент, когда продукт сдаёт экзамен
Обычный сценарий легко спроектировать: пользователь нажал кнопку, система сохранила данные, всё получилось. Но доверие к продукту появляется не в этом моменте. Оно проверяется, когда связь пропала, обязательное поле забыли заполнить, другой сотрудник уже изменил запись или внешняя система не ответила.
Представим менеджера, который отправляет коммерческое предложение. Он нажимает «Отправить», а система пишет: «Ошибка 500». Дальше у него три вопроса. Ушло ли предложение? Сохранились ли правки? Что делать прямо сейчас? Если продукт не отвечает ни на один, менеджер начинает действовать наугад: отправляет письмо ещё раз, звонит в поддержку или ведёт параллельную таблицу.
Проблема не в том, что ошибка произошла. Сбой может случиться в любой системе. Проблема начинается, когда человеку приходится самому восстанавливать картину и принимать рискованное решение без подсказки.
Сначала отделяю три разных ситуации
За словом «ошибка» часто прячутся совершенно разные вещи. Их нельзя объяснять одной красной плашкой.
- Действие не выполнено. Например, не хватает обязательных данных. Здесь полезно показать конкретное поле и сохранить всё, что пользователь уже ввёл.
- Результат неизвестен. Запрос мог дойти до внешнего сервиса, но ответ потерялся. Самая опасная ситуация: повтор может создать два платежа, заказа или письма.
- Действие выполнено частично. Карточка создана, а файл не прикрепился. Пользователю важно увидеть границу: что уже есть, а что ещё нужно сделать.
Это похоже на доставку. «Курьер задерживается» и «заказ доставлен, но не удалось связаться с получателем» — не одно и то же. В первом случае можно ждать. Во втором нужно проверить факт и выбрать следующий шаг. У цифрового продукта должна быть такая же аккуратность в формулировках.
Не заставляю человека помнить то, что может помнить система
В плохом сценарии после ошибки человек заново собирает заявку, повторяет расчёт или вспоминает, на каком шаге остановился. Он тратит внимание не на свою работу, а на борьбу с интерфейсом.
Поэтому я начинаю с вопроса: что система уже знает и может безопасно сохранить? Черновик заказа, выбранные позиции, прикреплённый файл, место в маршруте согласования — всё это не должно пропасть из-за одного неудачного запроса.
Такой подход особенно важен для первого самостоятельного результата в B2B-продукте. Пока человек уверен, что система может потерять его работу, он не станет действовать самостоятельно. Он будет ждать коллегу, просить инструкцию или возвращаться к привычному обходу.
Сохранить введённое — не значит молча повторять опасную операцию. У операции должен быть понятный статус. Например: «Черновик сохранён. Отправка не подтверждена. Мы проверяем её состояние; пока не нажимайте кнопку повторно». Это не идеальная фраза на все случаи, но она честнее и полезнее безликого «попробуйте позже».
Показываю не диагноз сервера, а следующий шаг
Текст для разработчика и текст для пользователя — разные вещи. Код ошибки, имя сервиса и длинный стек вызовов помогают найти причину команде. Сотруднику отдела продаж они не отвечают на главный вопрос: что мне делать?
Хорошее сообщение обычно содержит четыре простые части:
- что произошло в понятных границах;
- что сохранилось или не сохранилось;
- какое действие безопасно сделать сейчас;
- как получить помощь, если самостоятельный путь не сработал.
Например, вместо «Не удалось выполнить операцию» полезнее сказать: «Предложение не отправлено: в карточке клиента нет адреса электронной почты. Данные в черновике сохранены. Добавьте адрес и отправьте снова». У человека остаётся работа, причина и следующий шаг.
Если причина пока неизвестна, это тоже можно сказать честно: «Мы не можем подтвердить отправку. Проверьте журнал в карточке через несколько минут; если записи нет, отправьте повторно». Важна не уверенная интонация, а ясная граница риска.
Не превращаю каждую проблему в баннер
Иногда команда лечит тревогу количеством уведомлений. В результате экран становится похож на приборную панель самолёта в плохом фильме: всё мигает, но непонятно, куда смотреть. Уведомление полезно, только если меняет ближайшее действие человека.
Если ошибка относится к одному полю, место ей рядом с полем. Если остановилась длинная фоновая загрузка, нужен статус в самой очереди задач. Если операция критична для всей команды, может понадобиться заметное сообщение и понятный обходной порядок.
Этот выбор связан с тем, как устроен рабочий экран B2B-продукта. Хороший экран не собирает все события в одну кучу. Он помогает увидеть именно те решения, которые сейчас принадлежат пользователю.
Проверяю восстановление на реальной рабочей цепочке
Сообщение об ошибке нельзя оценить по макету. Его нужно пройти как обычный сотрудник: открыть карточку, заполнить данные, намеренно вызвать сбой, закрыть браузер, вернуться через несколько минут и понять, что осталось.
Я бы проверил минимум пять вещей:
- не пропали ли введённые данные;
- понятно ли, выполнилась ли операция;
- безопасно ли повторять действие;
- может ли пользователь завершить работу без поддержки;
- видит ли команда, где именно цепочка остановилась.
Последний пункт уже относится к архитектуре. Когда важно восстановить действие, системе нужен след: идентификатор операции, время, статус и понятная связь с карточкой. Иначе поддержка просит у сотрудника скриншоты и пересказы, а он снова чувствует, что продукт ему не помогает. Подход к такой проверке хорошо перекликается с наблюдаемостью по пути одной критичной операции.
Осторожнее с фразой «обратитесь в поддержку»
Поддержка нужна. Но если эта фраза появляется после каждого сбоя, она становится запасным интерфейсом продукта. Команда поддержки принимает на себя то, что система могла объяснить сама: где данные, можно ли повторить действие, кому принадлежит следующий шаг.
Я отношу такие обращения не к «шуму пользователей», а к материалу для улучшения. Если за неделю несколько человек спрашивают, ушёл ли документ после ошибки, это не повод написать ещё одну инструкцию. Это повод сделать статус документа понятнее.
И наоборот: не каждое редкое исключение стоит превращать в сложную функцию. Сначала полезно увидеть повторяемость, стоимость ошибки и риск неверного действия. Это тот же принцип, по которому обращение в поддержку не всегда становится функцией продукта.
Разные роли должны получать разную ясность
Одна и та же техническая ошибка по-разному влияет на менеджера, бухгалтера и администратора. Менеджеру важно не потерять контакт с клиентом. Бухгалтеру — не создать повторный документ. Администратору — понять, нужна ли срочная реакция команды. Поэтому единственный шаблон сообщения редко помогает всем.
Это не значит, что надо построить три разных продукта. Чаще достаточно показать общий факт и добавить роль-зависимый следующий шаг. У менеджера в карточке остаётся черновик и кнопка проверки статуса. У администратора появляется задача с идентификатором операции. У поддержки есть технические детали в журнале, но они не мешают человеку, который просто хочет завершить работу.
Я бы особенно внимательно посмотрел на права. Если сотрудник не может исправить причину сам, сообщение не должно предлагать ему невозможное действие. Фраза «измените реквизиты клиента» бесполезна для человека без доступа к реквизитам. Гораздо честнее показать: «Для продолжения нужен адрес. Передайте задачу владельцу карточки» — и дать такой переход, если он предусмотрен процессом.
Тон важен, но честность важнее
Иногда ошибки стараются смягчить настолько, что смысл исчезает: «Упс», «Небольшая заминка», «Мы уже работаем над этим». В потребительском сервисе такая интонация может показаться дружелюбной. В рабочей системе она часто раздражает. Человек не пришёл развлекаться; у него есть обязательство перед клиентом или коллегой.
Спокойный тон не требует эвфемизмов. Можно прямо сказать, что действие не выполнено, но не обвинять пользователя и не нагружать его внутренностями системы. Хорошая формулировка уважает время: коротко называет факт, объясняет границу и показывает путь.
Ещё один риск — обещать то, чего продукт не гарантирует. «Мы всё исправим» звучит хорошо, но если обработка зависит от внешнего банка или сервиса, это обещание может оказаться неверным. Лучше обозначить проверяемый факт: «Статус обновится после ответа внешней системы» или «Мы сохранили заявку и сообщим, когда обработка завершится».
Как превратить ошибки в материал для развития
Полезно собирать не только число ошибок, но и контекст: на каком шаге они возникли, смог ли человек завершить задачу, сколько раз нажал кнопку повторно, обратился ли в поддержку. Один показатель «500 ошибок за неделю» мало говорит о пользователе. А вот цепочка «сбой при отправке, повторный клик, звонок менеджеру, ручное письмо» уже показывает конкретный разрыв в продукте.
Не нужно следить за каждым кликом ради отчёта. Достаточно выбрать несколько критичных сценариев и регулярно разбирать именно их. Если после изменения текста или статуса число повторных попыток уменьшилось, это хороший признак. Если люди всё равно уходят в обходной канал, значит, им не хватает не слов, а возможности продолжить путь.
Для меня здесь работает простое правило: ошибка должна оставлять пользователя с большей определённостью, чем была секунду назад. Он может быть недоволен сбоем, но не должен гадать о своих данных и следующем действии. Именно из таких спокойных моментов и складывается доверие к рабочему продукту.
Что можно сделать уже на этой неделе
Выберите одну операцию, за которую люди особенно переживают: отправку документа, создание заказа, закрытие периода, выгрузку данных. Пройдите её от начала до конца и специально сломайте один шаг. Затем посмотрите на экран не глазами разработчика, а глазами человека, которому нужно закончить рабочий день.
Если после ошибки ясно, что произошло, что сохранилось и как безопасно продолжить, продукт выдерживает реальную жизнь. Если нет — это не косметика. Это часть пути, на котором пользователи решают, можно ли ему доверять.
Обсудим?