У компании «СКБ Контур» (один из продуктов — облачная бухгалтерия «Эльба») есть интерфейсные гайдлайны. Например, о валидации форм:
— Когда и как показывать сообщения об ошибках;
— Каким должен быть текст;
— Что делать с чекбоксами и группами радиокнопок в формах.
«Мгновенная валидация — появляется в момент ввода без потери фокуса. Не используйте мгновенную валидацию. Мы не хотим преждевременно ругать пользователя, мы хотим дать ему шанс исправиться самостоятельно».
#form #error
— Когда и как показывать сообщения об ошибках;
— Каким должен быть текст;
— Что делать с чекбоксами и группами радиокнопок в формах.
«Мгновенная валидация — появляется в момент ввода без потери фокуса. Не используйте мгновенную валидацию. Мы не хотим преждевременно ругать пользователя, мы хотим дать ему шанс исправиться самостоятельно».
#form #error
Контур.Гайды
Валидация форм — Формы и таблицы — Принципы — Контур.Гайды
Контур.Гайды — это требования к дизайну пользовательского интерфейса веб-сервисов Контура. Данный сборник примеров незаменим для самостоятельного обучения веб-дизайну.
Настя Овсянникова написала серию статей об отображении ошибок в интерфейсе.
— С точки зрения взаимодействия между пользователем, клиентом и сервером можно выделить виды ошибок: а) Сбой клиента; б) Результат валидации данных на клиенте и сервере; б) Результат обработки данных и команд; в) Потеря связи с сервером;
— Потеря связи с сервером происходит, если пропал интернет, проблемы с VPN, сервер упал или от него вообще нет ответа;
— Обстоятельства, при которых обнаруживаются ошибки: а) Приём данных от пользователя; б) Скачивание или подгрузка данных по его инициативе; в) Перенаправление на другую страницу; г) Перенаправление в модальное окно;
— Единые решения по отображению 4 видов ошибок при 4 видах обстоятельств позволяют: а) Команде говорить на одном языке; б) Не создавать макеты ошибок для каждой ситуации и сохранять консистентность; в) Упростить подключение новых членов команды;
— При сбое клиента решили перенаправлять пользователя на особенную страницу в виде Configuration Item, которая существует вне информационной архитектуры и всегда может быть отображена клиентом, но на ней нельзя показать разные варианты текста ошибки в зависимости от контекста;
— Ошибка валидации данных может быть связана с отдельным полем или группой полей. Во втором случае сообщение должно быть визуально связано со всей группой (например, отображаться над ней);
— Если нет связи с сервером, на странице решили показывать баннер-растяжку сверху, а в модальном окне — алерт под его заголовком;
— Если есть фоновая проверка связи с сервером, и пользователь просматривает модальное окно, сообщение о потере связи лучше показывать после того, как он на что-нибудь нажмёт или закроет окно;
— Если ошибка произошла после перенаправления пользователя на страницу, решили отображать полноэкранную ошибку с соответствующим текстом. После перенаправления в модальное окно — алерт под его заголовком;
— На странице Configuration Item не стоит размещать кнопки и ссылки и советовать перезагрузить страницу (это ни к чему не приведёт). Стоит подсказать, куда обратиться и что сообщить сотрудникам техподдержки;
— Если суть сообщения об ошибке одна, а сущности разные, можно использовать общие грамматические конструкции. Например, когда сущность уже есть там, куда её добавляем, можно использовать конструкцию «Такой(-ая) [сущность] уже входит в [сущность]»;
— То же самое, если меняются не сущности, а значения параметров. Например: «Загрузите 1 файл до 100МВ в формате .docx, .pdf или .xlsx». Меняется количество файлов, лимит мегабайтов и форматы;
— Для специфических полей (номер телефона, дата или сумма) можно зафиксировать отдельные ситуации. Например: «Дата окончания периода не может быть раньше даты начала»;
— Ошибка может отображаться по-разному (полноэкранная, алерт, нотификация) с разным контентом. Стоит предусмотреть текстовые токены, из которых можно собрать любое отображение ошибки. Например: заголовок, полный текст, краткий текст, основное действие, второстепенное действие.
Настины статьи:
— Как возникают ошибки;
— Выбор способа отображения ошибки в интерфейсе;
— Выбор контента для описания ошибки пользователю.
#error
— С точки зрения взаимодействия между пользователем, клиентом и сервером можно выделить виды ошибок: а) Сбой клиента; б) Результат валидации данных на клиенте и сервере; б) Результат обработки данных и команд; в) Потеря связи с сервером;
— Потеря связи с сервером происходит, если пропал интернет, проблемы с VPN, сервер упал или от него вообще нет ответа;
— Обстоятельства, при которых обнаруживаются ошибки: а) Приём данных от пользователя; б) Скачивание или подгрузка данных по его инициативе; в) Перенаправление на другую страницу; г) Перенаправление в модальное окно;
— Единые решения по отображению 4 видов ошибок при 4 видах обстоятельств позволяют: а) Команде говорить на одном языке; б) Не создавать макеты ошибок для каждой ситуации и сохранять консистентность; в) Упростить подключение новых членов команды;
— При сбое клиента решили перенаправлять пользователя на особенную страницу в виде Configuration Item, которая существует вне информационной архитектуры и всегда может быть отображена клиентом, но на ней нельзя показать разные варианты текста ошибки в зависимости от контекста;
— Ошибка валидации данных может быть связана с отдельным полем или группой полей. Во втором случае сообщение должно быть визуально связано со всей группой (например, отображаться над ней);
— Если нет связи с сервером, на странице решили показывать баннер-растяжку сверху, а в модальном окне — алерт под его заголовком;
— Если есть фоновая проверка связи с сервером, и пользователь просматривает модальное окно, сообщение о потере связи лучше показывать после того, как он на что-нибудь нажмёт или закроет окно;
— Если ошибка произошла после перенаправления пользователя на страницу, решили отображать полноэкранную ошибку с соответствующим текстом. После перенаправления в модальное окно — алерт под его заголовком;
— На странице Configuration Item не стоит размещать кнопки и ссылки и советовать перезагрузить страницу (это ни к чему не приведёт). Стоит подсказать, куда обратиться и что сообщить сотрудникам техподдержки;
— Если суть сообщения об ошибке одна, а сущности разные, можно использовать общие грамматические конструкции. Например, когда сущность уже есть там, куда её добавляем, можно использовать конструкцию «Такой(-ая) [сущность] уже входит в [сущность]»;
— То же самое, если меняются не сущности, а значения параметров. Например: «Загрузите 1 файл до 100МВ в формате .docx, .pdf или .xlsx». Меняется количество файлов, лимит мегабайтов и форматы;
— Для специфических полей (номер телефона, дата или сумма) можно зафиксировать отдельные ситуации. Например: «Дата окончания периода не может быть раньше даты начала»;
— Ошибка может отображаться по-разному (полноэкранная, алерт, нотификация) с разным контентом. Стоит предусмотреть текстовые токены, из которых можно собрать любое отображение ошибки. Например: заголовок, полный текст, краткий текст, основное действие, второстепенное действие.
Настины статьи:
— Как возникают ошибки;
— Выбор способа отображения ошибки в интерфейсе;
— Выбор контента для описания ошибки пользователю.
#error
Medium
Отображение ошибок в интерфейсе, часть 1 – Как возникают ошибки
Виды ошибок и обстоятельства, при которых они возникают.
Тим Нойсессер и Эван Санволл написали о сообщениях об ошибках.
— Отображайте сообщения об ошибках там, где они произошли, чтобы было проще связать сообщение с требующим внимания элементом интерфейса;
— Используйте заметные и доступные индикаторы. Не оформляйте ошибки только цветом и анимацией, для доступности можно добавить иконки;
— Не показывайте ошибки преждевременно. Например, когда пользователь переместил фокус из незаполненного поля, показывать сообщение рановато — человек ещё только изучает интерфейс;
— Кратко опишите проблему и предложите способ её решения, иногда может потребоваться объяснить, как работает система;
— Не обвиняйте пользователя и избегайте шуток;
— Помогайте избегать ошибок. Например, Gmail предупреждает о неприложенном файле при попытке отправить письмо;
— Сохраняйте введённые пользователем данные, чтобы ошибку можно было исправить редактированием, а не новым вводом;
— Помогайте исправлять ошибки. Например, заменить ввод на вариант без опечатки;
— Если всё, что может сделать пользователь, это вернуться позже (например, сервер перегружен), на странице с ошибкой можно совместить извинения с чем-то неожиданным и новым. Твиттер показывает иллюстрацию с птичками с китом.
In English. #error #writing
— Отображайте сообщения об ошибках там, где они произошли, чтобы было проще связать сообщение с требующим внимания элементом интерфейса;
— Используйте заметные и доступные индикаторы. Не оформляйте ошибки только цветом и анимацией, для доступности можно добавить иконки;
— Не показывайте ошибки преждевременно. Например, когда пользователь переместил фокус из незаполненного поля, показывать сообщение рановато — человек ещё только изучает интерфейс;
— Кратко опишите проблему и предложите способ её решения, иногда может потребоваться объяснить, как работает система;
— Не обвиняйте пользователя и избегайте шуток;
— Помогайте избегать ошибок. Например, Gmail предупреждает о неприложенном файле при попытке отправить письмо;
— Сохраняйте введённые пользователем данные, чтобы ошибку можно было исправить редактированием, а не новым вводом;
— Помогайте исправлять ошибки. Например, заменить ввод на вариант без опечатки;
— Если всё, что может сделать пользователь, это вернуться позже (например, сервер перегружен), на странице с ошибкой можно совместить извинения с чем-то неожиданным и новым. Твиттер показывает иллюстрацию с птичками с китом.
In English. #error #writing
www.uprock.ru
Как создавать эффективные сообщения об ошибках — читайте на UPROCK
Эффективные сообщения об ошибках — заметные, конструктивные и транслируют уважительное отношение к усилиям пользователя.: читайте полезные статьи о дизайне в блоге UPROCK
Кира Калимулина написала о тексте для пустых состояний и ошибок.
— Пустое состояние отображается, когда на экране нет содержимого: 1) Пользователь не добавил или нужные данные ещё не накопились, 2) Он всё удалил, 3) Нулевые результаты поиска или фильтрации;
— Общие рекомендации: определите контекст появления такого состояния; в заголовке расскажите, что произошло; в подзаголовке подскажите, что делать дальше (иногда имеет смысл успокоить пользователя); в тексте кнопки направьте его к целевому действию;
— В статье Кинерет Ифры — более подробная классификация пустых состояний и отдельные рекомендации под каждое;
— Вместо пустого состояния можно показать видеоподсказку или инструкцию;
— Если поиск не нашёл то, что искал пользователь, можно показать что-то похожее. Но важно сообщить об этом;
— Можно показать демоверсию содержимого, например, если эту функциональность открывает премиальный тариф;
— Не стоит: рассказывать о других фичах (может запутать); шутить, когда появление такого состояния может разочаровать пользователя; драматизировать («Мы очень старались, но так ничего и не нашли! Простите нас, пожалуйста, мы обещаем исправиться!»);
— В сообщениях об ошибках превращайте негатив в позитив, если это не искажает смысл. Например: «Эти товары недоступны для юридических лиц» → «Эти товары доступны только для физических лиц»;
— Если есть возможность, к сообщениям об ошибке добавляйте полезные ссылки. Например, на чат с поддержкой;
— Не пишите «Упс» или «Ой» — становится похоже, будто вы не контролируете, что происходит с вашим сервисом;
— Единственная ошибка, в тексте которой можно шутить, — 404.
#empty_state #error #writing
— Пустое состояние отображается, когда на экране нет содержимого: 1) Пользователь не добавил или нужные данные ещё не накопились, 2) Он всё удалил, 3) Нулевые результаты поиска или фильтрации;
— Общие рекомендации: определите контекст появления такого состояния; в заголовке расскажите, что произошло; в подзаголовке подскажите, что делать дальше (иногда имеет смысл успокоить пользователя); в тексте кнопки направьте его к целевому действию;
— В статье Кинерет Ифры — более подробная классификация пустых состояний и отдельные рекомендации под каждое;
— Вместо пустого состояния можно показать видеоподсказку или инструкцию;
— Если поиск не нашёл то, что искал пользователь, можно показать что-то похожее. Но важно сообщить об этом;
— Можно показать демоверсию содержимого, например, если эту функциональность открывает премиальный тариф;
— Не стоит: рассказывать о других фичах (может запутать); шутить, когда появление такого состояния может разочаровать пользователя; драматизировать («Мы очень старались, но так ничего и не нашли! Простите нас, пожалуйста, мы обещаем исправиться!»);
— В сообщениях об ошибках превращайте негатив в позитив, если это не искажает смысл. Например: «Эти товары недоступны для юридических лиц» → «Эти товары доступны только для физических лиц»;
— Если есть возможность, к сообщениям об ошибке добавляйте полезные ссылки. Например, на чат с поддержкой;
— Не пишите «Упс» или «Ой» — становится похоже, будто вы не контролируете, что происходит с вашим сервисом;
— Единственная ошибка, в тексте которой можно шутить, — 404.
#empty_state #error #writing
Хабр
Дорогая, что-то пошло не так. Гид по пустым состояниям и ошибкам + шаблоны на все случаи
Всем привет! Меня зовут Кира Калимулина, я руководитель группы UX-редактуры в Ozon. Я занимаюсь всеми интерфейсными текстами в приложении и на сайте. UX-тексты сильно отличаются от маркетинговых...
Александр Мачуговский написал, как сообщать пользователю о пустых обязательных полях формы.
— Правило хорошего UX — дать пользователю возможность вернуться в предыдущий режим, к изначальному состоянию;
— Пользователь нажимает на кнопку отправки формы, все пустые поля переходят в состояние Error, в нормальное состояние они возвращаются по очереди по мере заполнения. По сути форма переходит в режим отладки;
— Нажатие на кнопку приводит к изменению состояния полей, но объект взаимодействия — кнопка, с ней связан локус внимания пользователя. Но не она говорит с пользователем, а поля (которые вместо полей ввода стали полями вывода);
— Если автоматически фокусироваться на первом пустом поле, на мобильных это приведёт к отображению клавиатуры и затруднит изучение формы в целом. Можно прокручивать страницу к этому полю, но тогда пользователю придётся нажимать на поле, чтобы его заполнить;
— Стоит разделять ошибки данных (не хватает @ в адресе электронной почты) и ошибки процесса (пришёл ответ сервера о несуществующем адресе);
— Пустое поле — не ошибка данных, а приглашение к взаимодействию;
— Принцип «один экран — одно действие» сокращает количество вариантов для выбора и повышает его скорость;
— Если на экране одновременно одно поле, поднимающаяся при фокусе клавиатура не мешает. Если оставить его пустым, нажатие на «Продолжить» вернёт фокус в поле и отобразит клавиатуру, приглашая к взаимодействию без сообщения об ошибке;
— Если на экране полей много, можно реализовать их последовательное заполнение, переходя между полями кнопкой Next на экранной клавиатуре и прокручивая страницу так, чтобы заполняемое поле было ровно над клавиатурой;
— При попытке отправить форму можно вернуть пользователя к первому неправильно заполненному полю (с сообщением об ошибке), не помечая все остальные.
Копия статьи. #error #form
— Правило хорошего UX — дать пользователю возможность вернуться в предыдущий режим, к изначальному состоянию;
— Пользователь нажимает на кнопку отправки формы, все пустые поля переходят в состояние Error, в нормальное состояние они возвращаются по очереди по мере заполнения. По сути форма переходит в режим отладки;
— Нажатие на кнопку приводит к изменению состояния полей, но объект взаимодействия — кнопка, с ней связан локус внимания пользователя. Но не она говорит с пользователем, а поля (которые вместо полей ввода стали полями вывода);
— Если автоматически фокусироваться на первом пустом поле, на мобильных это приведёт к отображению клавиатуры и затруднит изучение формы в целом. Можно прокручивать страницу к этому полю, но тогда пользователю придётся нажимать на поле, чтобы его заполнить;
— Стоит разделять ошибки данных (не хватает @ в адресе электронной почты) и ошибки процесса (пришёл ответ сервера о несуществующем адресе);
— Пустое поле — не ошибка данных, а приглашение к взаимодействию;
— Принцип «один экран — одно действие» сокращает количество вариантов для выбора и повышает его скорость;
— Если на экране одновременно одно поле, поднимающаяся при фокусе клавиатура не мешает. Если оставить его пустым, нажатие на «Продолжить» вернёт фокус в поле и отобразит клавиатуру, приглашая к взаимодействию без сообщения об ошибке;
— Если на экране полей много, можно реализовать их последовательное заполнение, переходя между полями кнопкой Next на экранной клавиатуре и прокручивая страницу так, чтобы заполняемое поле было ровно над клавиатурой;
— При попытке отправить форму можно вернуть пользователя к первому неправильно заполненному полю (с сообщением об ошибке), не помечая все остальные.
Копия статьи. #error #form
vc.ru
Как сообщать об ошибках — Дизайн на vc.ru
Александр Мачуговский Дизайн11 мар