Грамотное общение с пользователем посредством интерфейса - это про умение продумывать сценарии, логику работы и формулировать мысли.
Первое и часто единственное, о чём разработчики хотят общаться с пользователями - об ошибках. Причем только об ошибках пользователей. Но даже в этой необходимой базовой вещи информативности бывает преступно мало.
Давайте посмотрим на простом примере
Есть платёжный документ, который надо отправить на согласование. Одна из основных проверок любого платёжного документа - предполагаемая дата оплаты, она же дата платежа.
Пользователь нажимает на кнопочку «Отправить на согласование» и получает ошибку
Некорректная дата платежа
«Чё ты доебался?» - спросит кто-то, ведь понятно же, что накосячили в дате платежа. Ну ок. А в чём именно? Как исправить? Каким должно быть значение, чтобы всё прошло на ура?
Сравните.
Указанная дата платежа - 22.04.2026 - не совпадает с установленными платёжными периодами для <Организации>/<Контрагента>/<Типа операции>. Измените дату платежа таким образом, чтобы она совпадала с платёжным периодом. Ближайший доступный период 27-30.04.2026. Или измените статус платежа на «срочный»
Да, сообщение получилось длиннее. Но информативнее. Мы сразу выдаём пользователю всю необходимую информацию: какое именно значение является некорректным, почему, что необходимо сделать, чтобы исправить ситуацию - и какие именно действия надо для этого предпринять.
В целом, для классических правил описания ошибки не хватает только начать с «Ошибка согласования документа». Но подобное я считаю необходимым только для отложенных или многосоставных действий.
На этой стадии ещё неплохо обеспечить согласованность интерфейса со сценарием исправления ошибки, создавайте у пользователя прямую связь с элементом интерфейса. Да, слово "изменить" - универсальное, но всё же
👉если для каждого статуса у вас предусмотрена собственная кнопка - используйте название этой кнопки (предположим, в информации для пользователя можно написать "или используйте опцию "срочный платёж")
👉если для изменения статуса используется чек-бокс, используйте глагол «установите»
При проверках на корректность заполнения не стоит заставлять пользователя изменять данные по очереди: по возможности, проверяйте все данные при каждой попытке выполнения операции, если только проверки не зависят от заполненности данных: если вам надо проверить какие-то свойства счета — сначала проверьте, что счёт указан, и только если да - что он, к примеру, не закрыт. Но если необходимо проверять два независимых свойства (те же дату платежа и счёт) — выполните обе проверки сразу в любом случае, вне зависимости от исхода одной из них (это пример нелогичного использования принципа «ранний возврат»).
Сообщения об ошибке где-то внизу рабочей области бывает недостаточно. Если действие критичное - убедитесь в том, что пользователь точно об этом узнает через диалоговое окно.
Не вводите пользователя в заблуждение - очищайте историю сообщений.
Говорят, что лучшее сообщение об ошибке - его отсутствие. В том плане, что при проведении какой-либо операции можно исправлять ошибки автоматически.
Я с этим не то, чтобы согласен: оставлять пользователя в неведении относительно внесённых изменений не очень хорошо. Лучше обеспечить эту логику при выполнении пользовательских действий, когда от изменения одних данных меняются другие.
При этом, если изменяемые по зависимости данные уже заполнены, пользователя лучше об этом информировать:
👉предупреждением до изменения, если данные объемные (таблицы)
👉если изменяемые по зависимости данные
▪️находятся в поле видения, но разнесены с изменяемыми пользователем — краткосрочным выделением цветом
▪️находятся вне видимости (на другой странице) —сообщением об изменении
👉сообщением о сбросе значений
Еще небольшой чек-лист:
▪️если сценарий подразумевает выполнение исчислимого количества операций в фоне - информируйте пользователя о ходе прогресс-баром
▪️если сценарий подразумевает выполнение в фоне — сообщайте об окончании процесса так, чтобы это было заметно из любой формы
ну наверное в
#медвежийкодстайл