Типы ошибок

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

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

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

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

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

Суммируя, при борьбе с ошибками нужно направлять усилия на:

- плавное обучение пользователей в процессе работы

- снижение требований к бдительности

- повышение разборчивости и заметности индикаторов.

- снижение чувствительности системы к ошибкам.

Для этого есть три основных способа, а именно:

- блокировка потенциально опасных действий пользователя до получения подтверждения правильности действия

- проверка системой всех действий пользователя перед их принятием

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

При этом самым эффективным является третий способ. К сожалению, этот способ наиболее труден в реализации.

Два уровня ошибок и обратная связь

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

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

С ошибками из четвертого пункта всё ясно. Всякий раз, когда мы теряем возможность, по крайней мере, проверить корректность данных или самой системы, мы вступаем на слишком уж скользкий путь. Межпланетные зонды, из-за ошибок в ПО улетающие не туда, коммерческие договоры, в которых обнаруживаются ошибки, ошибочные номера телефонов в записной книжке – всё это примеры неисправляемых ошибок. Разумеется, такие ошибки всегда обнаруживаются, проблема в том, что к моменту их обнаружения становится поздно их исправлять. Именно поэтому такие ошибки гораздо хуже ошибок, которые исправить трудно, но которые, по крайней мере, сразу видны. Единственной индустрией, научившейся получать пользу от необнаруженных ошибок, является производство почтовых марок – марки с опечатками стоят у филателистов многократно дороже марок без оных. Это было знание программистов. Теперь пора перейти к интерфейсу и определить, почему ошибки первого типа («исправляемые во время») гораздо лучше ошибок второго типа («исправляемых после»).

Вообще говоря, объяснение этого факта двояко. Объяснение есть как субъективное, так и объективное, при этом сказать, какое сильнее, затруднительно. При этом объяснения еще и складываются. Но, по порядку.

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

- понять, что ошибка совершена

- понять, как её исправить

- потратить время на исправление ошибки.

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

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

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

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

К сожалению, это простое соображение имеет существенный недостаток: вводить в систему обратную связь получается не всегда. Дело в том, что её ненавидят программисты. Мотивируют они своё отношение тем, что она плохо влияет на производительность системы. Обычно они врут. На самом деле им просто лень её реализовывать. Иногда, впрочем, соображения о производительности системы и вправду имеют место. Так что если вы чувствуете, что программисты правы, когда кричат о том, что система «будет безбожно тормозить», вспомните, что производительность связки «система-пользователь» всегда важнее производительности системы просто. Если же и это не помогает, попробуйте спроектировать обратную связь иначе, более скромно. Иногда так получается даже лучше. Например, с помощью ползунков на линейке в MS Word можно менять абзацные отступы, при этом обратная связь есть, но не полная: вместо перманентного переформатирования документа по экрану двигается полоска, показывающая, куда передвинется текст. Благодаря этому изображение на экране особенно не перерисовывается, что хорошо, поскольку такое «дрыганье» раздражает.

12. Критерии качества интерфейса. Скорость обучения.