Опубліковано Груд 15, 2016 • Оновлено Берез 23, 2022

Ошибки и валидация форм мобильных приложений

Человеку свойственно ошибаться. Ошибки возникают, когда люди взаимодействуют с пользовательскими интерфейсами . Иногда это происходит потому, что пользователи делают ошибки. Иногда ошибки возникают в самом приложении. Независимо от причины, ошибки и их обработка имеют огромное влияние на UX. Некорректная обработка ошибки вместе с бесполезными сообщениями об ошибке, могут вызвать у пользователя негативную реакцию, что впоследствии может привести к отказу пользователя от использования вашего приложения. В данной статье, мы разберемся, как можно оптимизировать дизайн приложения для предотвращения пользовательских ошибок и как создать эффективные сообщения об ошибке в случае, если ошибки возникают независимо от того, что вводит пользователь. Также, мы рассмотрим, как хорошо обработанная ошибка может превратить неудачу в восхищение. Adobe представил новое приложение для дизайна и проектирования Experience Design (Adobe XD), которая позволяет вам создавать дизайн интерактивных проектов и состояний ошибок. Вы можете скачать и попробовать Adobe XD бесплатно.

Что такое состояние ошибки?

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

Профилактика лучше лечения

Если вы создаете приложение, вы должны понимать, какие основные взаимодействия пользователя с приложением могут привести к ошибке. Например, обычно очень трудно правильно заполнить форму с первой попытки, или невозможно корректно синхронизировать данные, если у устройства плохое сетевое соединение. Вы должны учитывать такие моменты для минимизации возможности возникновения ошибок. Другими словами, лучше предотвратить возможность ошибиться при помощи показа советов, использования ограничений и гибкости. Например, если вы даете людям возможность поиска и резерва отелей, зачем оставлять доступными даты в прошлом и выводить ошибку, если пользователь выбирает такую дату? Как показано на примере Booking.com, вы можете просто использовать выбор даты, который позволяет пользователям выбрать только сегодняшнюю дату и даты в будущем. Это будет побуждать пользователей выбирать только валидные даты. Выбор даты в приложении Boocking.com. Отображается полный месяц, но даты в прошлом недоступны.

Экран ошибки для валидации формы

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

Правильное время для информировании об ошибках (или успешном заполнении)
Правильное место для валидационного сообщения
Правильный цвет сообщения
Понятный язык сообщения

Правильное время (валидация строки)

Валидация ошибок формы неизбежна, и является логической частью ввода пользовательских данных (с тех пор, как ввод данных пользователем может сопровождаться ошибками). Конечно, состояния, которые могут вызвать ошибку, должны быть минимизированы, но валидацию ошибок убирать нельзя. Итак, самый важный вопрос: “Как упростить процесс восстановления после ошибки для пользователя?” Пользователи не любят процесс заполнения формы, особенно, когда в конце им приходит уведомление об ошибке. Особенное разочарование вызывает получение сообщения об ошибках в нескольких полях после заполнения длинной формы. И больше всего раздражает неясность того, какие ошибки вы допустили и где. Валидация должна моментально информировать пользователя о корректности данного ответа сразу после того, как пользователь ввел данные. Главный принцип хорошей валидации гласит: “Говорите с пользователями! Говорите им, что не так!” и валидация строки в режиме реального времени информирует пользователей о корректности введенных данных. Такой подход позволяет пользователям быстро исправить ошибки и не ждать отображения ошибок после нажатия кнопки подтверждения. Однако следует избегать валидации каждого нажатия клавиши потому, что в большинстве случаев, вы не сможете верифицировать данные до того, как пользователь закончит печатать свой ответ. Формы, которые валидируют значение сразу в процессе набора начинают раздражать пользователя сразу, как только он начинает вводить данные. Google формы отображают ошибку имейла даже когда вы еще не закончили печатать. С другой стороны, формы, которые осуществляют валидацию после ввода данных, не информируют пользователя достаточно оперативно об ошибке. Валидация в Apple Store осуществляется после ввода данных. Михаил Конжевич в своей статье “Валидация строки в формах - создание опыта! исследовал разные валидационные стратегии и предложил гибридную стратегию: ранняя награда, позднее наказание. Гибрид - ранняя награда, позднее наказание - подход

Правильное место

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

Правильный цвет (интуитивный дизайн)

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

Четкое сообщение

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

Сообщение о критической ошибке. Сообщения, которые говорят о внутренней ошибке кода приложения или содержат текст типа: “произошла ошибка тип 2” - загадочные и отпугивают.

Сообщение об ошибке, написанное разработчиком для разработчика.

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

Экран с ошибкой на Spotify гласит: "Произошла ошибка" и не содержит вариантов и шагов по решению проблемы.

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

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

Что пошло не так, и почему (возможно).
Что должен сделать пользователь, чтобы исправить ошибку.

Приложение Remote app объясняет, почему пользователи ничего не видят и предлагает решение.

Включайте юмор и изображения в сообщения об ошибках

Сообщения об ошибках - прекрасная возможность для использования иконок и иллюстраций потому, что люди лучше воспринимают визуальную информацию, чем просто текст. Но вы можете пойти еще дальше и добавить изображения к вашему приложению, что будет полезным для пользователей. Это позволит персонализировать ваше приложение и смягчить ваше сообщение. Azendoo использует иллюстрацию и юмор для того, чтобы вдохновить пользователя решить проблему. Юмор продлевает жизнь. Немного юмора никогда не повредит и поможет смягчить смятение от ошибки. Вы можете найти огромное множество примеров забавных сообщений в Littlebigdetails. Вот некоторые из моих любимых:

Basecamp: При ошибке валидации формы, герой слева делает удивленное выражение лица.

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

Однако, будьте осторожнее с юмором потому, что он может быть не всегда уместным в вашем сообщении об ошибке; это зависит от степени грубости ошибки. Например, юмор хорошо применим для простой проблемы валидации, как “404 ошибка” (страница не найдена). Но когда пользователь тратит определенное количество времени на просмотр страницы на которой написано “Ох!” - это выглядит неуместно.

Исчерпывающий чеклист идеальной страницы с сообщением об ошибке

Хорошие страницы с ошибками являются рукой помощи для пользователей и должны соответствовать следующим шести критериям:

Сообщение об ошибке появляется динамически, сразу после обнаружения ошибки. Оно должно информировать пользователя о проблеме.
Быть безопасным для введенных данных. Ваше приложение не должно ломать, удалять или отменять то, что ввел или загрузил пользователь в момент обнаружения ошибки.
Говорить с пользователем на одном языке. Сообщение должно давать четкое понимание, что пошло не так и почему; что пользователю нужно сделать для того, чтобы исправить ошибку?
Не шокируйте пользователей и не вводите их в замешательство. (Сообщение не должно быть сильно вызывающим).
Не теряйте контроль над системой. (Если проблема не критичная, пользователь должен иметь возможность с остальной часть приложения).
Используйте чувство юмора для смягчения проблемы.

Решения для наиболее популярных ошибок

404 ошибка (страница не найдена)

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

Проблема с логином

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

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

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

Отклонение кредитной карты

Отклонение кредитной карты может произойти по нескольким причинам: ошибка в форматировании данных (опечатка или нехватка данных) или или карта может быть отклонена по причине того, что она просрочена или похищена. Габриэль Томеску в своей статье “Анатомия формы кредитной карты”, предложил следующую стратегию для обеих ошибок: Для первой проблемы, вам следует следовать стандартной валидации строки и визуальной индикации ошибки: Однако, когда кредитная карта отклоняется платежной системой по некоторой причине, обычно это выглядит, как похищение. Вам необходимы четкие данные от пользователя. И даже после того, вам все равно необходимо уведомить пользователя о том, что произошло; сообщение об ошибке должно быть предельно ясным.

Проблема с соединением

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

Вывод

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

Найстарші коментарі (0)

Підписатися

UXPUB 🇺🇦 Дизайн-спільнота