Лого vc.ru

Почему сообщения об ошибках — зло

Почему сообщения об ошибках — зло

Каждую неделю ЦП выбирает интересные и актуальные темы мира юзабилити и UX, дополняя их мнением ведущих отечественных экспертов. В очередном выпуске рубрики «Интерфейсы» статья сооснователя Nielsen Norman Group и бывшего вице-президента Apple Дона Нормана о том, что сообщения об ошибках являются злом, которого необходимо избегать. Как всегда текст дополнен мнением ведущих отечественных экспертов.

Поделиться

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

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

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

Ответ Нормана: «Прежде всего хватит называть людей "пользователями"— это живые создания, у которых есть чувства». От слова пользователь" нужно избавляться, так как мир населен не ими, а людьми». Люди совершают ошибки, однако, обычно в этом виноваты не они, а машины, компьютерные системы, или, если точнее, их разработчики.

Технологии создаются техническими специалистами, которые хорошо знают, что нужно для их верной работы: большой объем точных и верных данных. Однако то, что хорошо для машин, совсем не хорошо для людей, заключает Норман: «Чаще всего человек не так хорош в плане точности и четкости. Если заставить людей вести себя как машины, конечно же, они наделают ошибок». Программисты обычно называют это ошибками пользователя, но вообще-то правильнее говорить об ошибке машины, или, если угодно, о плохом дизайне, считает автор статьи.

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

Отличный пример вредности сообщений об ошибке — скриншот выше. Когда-то такое сообщение получил сам Норман, когда хотел поменять название файла на своем MacBook. Кроме того, ему нужно было сделать так, чтобы файл с новым именем при сортировке по алфавиту был первым, поэтому он решил использовать символ периода, или «точку» в терминах компании из Купертино. Он вбил новое название ". Template for working documents" в полной уверенности, что теперь-то машина точно сделает все так, как нужно. Но не тут-то было. Компьютер заявил ему, если перефразировать, буквально следующее:

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

Вся проделанная работа, соответственно, была потеряна.

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

Диалоговое сообщение, которое реально помогает, по его мнению, могло бы выглядеть примерно так:

К сожалению, вы указали точку первым символом в названии файла, но такие файлы используются системой. Вы можете начать название с любой цифры, буквы или символа, кроме точки. Пожалуйста, отредактируйте название файла и нажмите «Сохранить».

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

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

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

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

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

С этим мнением, с некоторыми оговорками, соглашаются и эксперты Рунета.

Егор Гилёв,директор по UX в Acronis

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

Итак, мы все согласны, что сообщения об ошибках — зло. Установив это, перейдем к практическому вопросу: а как от них избавиться?

Варианты есть:

1. Исключить возможность «ошибки», используя специальные элементы управления, не допускающие ввод неправильных данных. Например, для числового значения с определенным минимумом и максимумом вместо обычного поля ввода можно использовать слайдер. Вместо поля ввода даты — наглядный календарь. Однако, это палка о двух концах. Может пострадать скорость работы пользователя: вместо того, чтобы быстро настучать всё с клавиатуры, приходится много двигать мышкой.

2. Расширить возможности интерпретации введенных данных. Многие «ошибки» не так уж сложно предугадать. Например, если дробные числа введены с неправильным разделителем (точка вместо запятой, или наоборот), это можно понять и простить. Дата может быть представлена по-разному: «15 мая», «15.05.2014», «ближайший четверг», или «завтра» — ошибочным не является ни один из этих вариантов, хотя компьютерные интерфейсы редко допускают такую гибкость. А зря.

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

Сергей Кудряшов,CEO Softorino

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

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

Потому для того чтобы избавиться от такого поведения надо, в первую очередь, понять, а что делает пользователь когда получает сообщение. И дать ему выполнить действие, может быть с ограничениями, но выполнить. Иногда, сообщение системы должно быть просто не модальным, как Notification Center в OS X:

Хотя еще лучше вообще не показывать никаких сообщений системы. А отображать её состояние. Решать вопрос, к примеру, доступности треков можно по-разному, но вовсе не обязательно для этого использовать какие-либо сообщения:

Универсального решения задачи «чем заменить MessageBox-ы» не существует — просто надо думать не над «поведением системы», а над «поведением пользователя». Это затратнее для разработки, но окупается их лояльностью.

Дмитрий Васильев, директор NetCat CMS

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

Я стараюсь придерживаться следующих принципов на эту тему:

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

2. Если это возможно, попытаться исправить ошибку автоматически и предложить ему варианты. Ведь человеку сразу понятно, в чем проблема в следующих адресах: vasya%yandex.ru, petya@mail.r, sasha@gmai.com — мы можем попытаться научить программу понимать эти ошибки. Или, к примеру, нам нужен телефон в формате +7ХХХХХХХХХХ, а пользователь вводит его со скобками или через восьмерку — не нужно мучить его, если мы сами можем преобразовать данные в нужный формат.

3. Не только давать пример заполнения, но и объяснять, зачем это нужно. «Ваша дата рождения нигде не будет публиковаться, она нужна нам только составления персональных предложений», «На этот номер будет выслан SMS, когда ваш заказ будет готов к отправке».

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

Константин Кичинский, технический евангелист Microsoft Russia

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

Такие ситуации встречаются сплошь и рядом. Для многих сценариев известно, как с ними бороться:

– изначальное мягкое направление в правильное русло (формирование ожиданий, обучение);

– ограничения ввода (контроль процесса, предупреждение ошибок);

– понятное человеку информирование о возникшей ситуации (минимизация стресса);

– продуманный процесс ее исправления (содействие, помощь) и т.п.

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

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

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

Банальный пример: если раньше в случае неправильного ввода информации в текстовое поле вас могли задолбать всплывающими диалоговыми окнами, то сегодня это уже моветон. Вы можете сказать, мол ну конечно! Это же плохой дизайн. Однако, когда-то это вполне было, если не нормой, то дешевым повсеместно используемым решением. Но сейчас так обычно не делают. Вставляют поля с определенными типами ввода, добавляют примеры ввода (placeholder), подсвечивают поля с неправильным вводом красненьким и помечают радом понятные текстовые сообщения. Неужели все стали сплошь правильными дизайнерами? Нет, конечно. Просто если раньше это было сложным, то сейчас это можно дешево и быстро сделать небольшой готовой библиотечкой или из коробки. Конечно, это еще и модно, и просто удобнее. Но вопрос применения конкретного решения часто лежит в плоскости экономической целесообразности.

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

Проблема «плохого» дизайна тут возникает не из-за того, что пользователя не посчитали человеком или не встали на его сторону, а потому что разработчик поставил на место пользователя себя и понял, что это приемлемое стандартное решение.

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

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

Резюмируя: надо ли бороться с сообщениями об ошибках? Конечно, надо. Но мало ругать и мало сетовать на плохой дизайн (иногда это помогает, кстати). Для массовых изменений нужны массовые дешевые решения, а пока то, что экономически оправдано более-менее работает, оно и будет работать. Просто надо исходить из того, что все хотят сделать лучше, но делают так, как могут.

Илья Александров, ведущий проектировщик интерфейсов проекта Simkomat

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

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

Вторая сторона — практическая. Если представить себя на месте проектировщика, которому нужно спроектировать взаимодействие большой сложной системы с тысячами возможных ошибок, то возникает небольшой конфликт. Конечно, идеальным будет внимательно продумать все возможные кейсы возникновения ошибок и спроектировать дружественное (collaborative в оригинале статьи) взаимодействие по устранению каждой конкретной ошибки при разнообразных исходных данных. Но в реальности продумать для каждого кейса идеальное взаимодействие может не получиться из-за различных ограничений (организационных, технических, временных) и создание неких универсальных форм с сообщениями представляется приемлемым вариантом. Конечно, стоит сделать их так, чтобы они не давили на психику человеку: не обвиняли его в тупости, не назывались error message.

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

Макс Десятых,креативный директор Redmadrobot

Когда я думаю о том, что в этом материале высказал автор, во мне борются двое: один — преисполнен гуманизмом и полностью согласен: «Время и эмоции человека — слишком ценны, чтобы тратить их на несовершенства программного обеспечения. Инженерам и дизайнерам интерфейса следовало позаботиться об этом». Второй — возмущён и брызжет слюной: «А не обнаглел ли ты совсем, дорогой Дон?! Эти ребята сделали для тебя лучший в мире компьютер, который ты купил за смешные деньги, с которым ты можешь создавать невероятные вещи, а ты сделал скриншот, пошел в интернет и оставил там этот пост!»

Если отбросить эмоции и применить здравый смысл, то остается согласиться с автором в таких простых утверждениях:

– люди ненавидят сообщения об ошибках;

– люди — это не абстрактные пользователи, а человеки, живущие в своём мире, в своих ситуациях, со своими переживаниями;

– зачастую программа и интерфейс могли бы быть спроектированы так, чтобы не допускать ошибок (обратите внимание, как русский язык помогает нам здесь в понимании мысли: когда система допускает, чтобы человек ошибся, она сама допускает ошибку).

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

1. Дай человеку шанс заранее узнать, как всё сделать правильно в твоём интерфейсе. Напиши это. И нарисуй.

2. По возможности не дай человеку ошибиться. Спрячь всё, что не надо нажимать.

3. Пусть цена ошибки будет минимальной и всегда будет возможность быстро всё исправить.

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

5. Если что-то пошло не так и в системе все-таки произошел сбой, объяснись понятным сообщением: что случилось, почему это произошло, что делать дальше.

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

Статьи по теме
Почему пользователи вводят меньше данных, если в форме есть обязательные поля30 апреля 2014, 13:56
На какие вопросы нужно ответить перед началом юзабилити-тестирования07 мая 2014, 14:39
Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

"К сожалению, вы указали точку первым символом в названии файла, но такие файлы используются системой. Вы можете начать название с любой цифры, буквы или символа, кроме точки. Пожалуйста, отредактируйте название файла и нажмите «Сохранить»."

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

"Нельзя начинать имя файла с точки" и кнопка "исправить на такой-то вариант". Все!

Ну тут система же не может знать, на что вы хотели бы исправить. Поэтому выглядит более логичным дать возможность пользователю это сделать самостоятельно. Хотя есть и случаи, где можно автоматом все провернуть

Система ясно знает, что нужно убрать точку - она уберет. Естественно человек может отредактировать по своему, одно другому не мешает.

0

Если система автоматически изменит мое название/сообщения, не предупредив об этом и без объяснения почему у меня будет куда больше негатива к этой системе

Наличие кнопки = автоматически? У меня для вас плохие новости.

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

"Сила должна быть сильной"? — Да, Норман.

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

0

Это не моя ошибка. Это цитата "Диалоговое сообщение, которое реально помогает" из статьи

0

"Люди совершают ошибки, однако, обычно в этом виноваты не они, а машины"

Т.е. я не заполнил форму - виноват комп?

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Дмитрий Лимонов

потому что ресторан не означает "дорого, бохато", как привыкли в РФ. Это всего лишь пункт общественного питания. Да, есть элитные рестораны, а есть в формате закусочных. Мир не кончается там, где ваши представления о нём не совпадают с реальностью.

«Будьте нашим гостем»: кому McDonald's даёт право бесплатно есть в своих ресторанах
0
Владимир Тихомиров

Похоже, пора на собеседовании в Яндекс спрашивать, в самом конце: вилкой в глаз или в жопу раз? И оценивать креативность процесса поиска правильного ответа... Будем перенимать международный опыт с адаптацией под наши условия, так сказать

Бывший глава Google затруднился ответить на один из традиционных вопросов компании на собеседованиях
0
Александр Васильев

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

«Никому не выгодно, чтобы у вас скапливались деньги»
0
Artem Zinnatullin
Juno

Не собираюсь оправдывать ролик сбера, но если вы про вот это видео с футболистом youtu.be/VGEfNcvntno, то оно ничем не лучше, тк там блин оператор(ы) по полю бегают, сверху съемка ведется и рядом с полем люди явно не на телефон снимают. Всем участникам было понятно, что это какой-то прикол. Была бы скрытая съемка — без вопросов.

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

Видео: Герман Греф в «костюме инвалида» в отделении «Сбербанка»
0
Artem Zinnatullin
Juno

Я может не понимаю, но в чем большая разница между "в имитирующем инвалида костюме" и "под видом инвалида"?

Не вижу "небо и земля" на скриншоте. У всех одинаково желтушные заголовки.

Видео: Герман Греф в «костюме инвалида» в отделении «Сбербанка»
0
Показать еще