Перевод: сообщение об ошибках это антипаттерн

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

Не надо рассматривать пользователя как источник ошибок

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

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

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

предсказание появления ошибок и устойчивый к ошибкам дизайн

Немного общей теории:

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

В общих чертах задачей устойчивого дизайна является построение надежной системы на основе множества менее надежных компонентов и подсистем. Например, в недрах огромных дата-центров жесткие диски ломаются по постоянно десятки раз в день, но из-за используемых там технологий распределения, эти события не являются опасными для целостности данных. Таким образом, сотрудники дата-центра могут поддерживать систему в полном рабочем состоянии при этом пользователь не заметит никаких проблем или потери своих данных. Подобный принцип построения устойчивых к ошибкам систем позволяет таким сервисам как Google, Facebook, Etsy, Flickr, Yahoo и Amazon работать постоянно и круглосуточно.

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

Избегайте излишнего ввода данных

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

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

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

Рисунок 1 Weather Underground вебсайт во время первого посещения.

Автоматическое заполнение полей

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

Посмотрите еще раз на рисунок 1, и вы заметите, что, несмотря на пред-заполненные данные для текущего местоположения, тут есть большое и заметное поле «Search locations” наверху страницы, так же как и список популярных городов. Таким образом, посетители могут легко поменять их место-назначение на сайте.

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

Ограничение выбора

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

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

Рисунок 2 - Селектор мобильного приложения от сайта hotels.com.

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

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

Используйте поля стандартные для платформы пользователя

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

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

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

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

Рисунок 3 пример перегруженного интерфейса приложения метронома

Пишите хорошие сообщения об ошибках.

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

Я вывел несколько правил написания сообщения об исключении:

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

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

Рисунок 4 : страница логина сервиса mailChimp до и после сообщения об ошибках.

MailChimp следует правилам, описанным мной выше:

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

итоги

Не подумайте что составление хороших сообщений об исключениях решит все ваши проблемы.

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

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

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

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

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