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

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

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

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

В этой статье мы рассмотрим первый вид ошибок при проектировании взаимодействия: Потеря фокуса с задачи пользователя.

Ошибки в проектировании взаимодействия 1 – “Утечка” внутренней работы

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

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

Избежать обнажения реализации можно, если проверять интерфейс на утечки “внутренней реализации”. А также, заблаговременно проектировать интерфейс с учётом удобства для пользователей, а не разработчиков.

Ошибки в проектировании взаимодействия 2 – Ненужные ограничения

Например, длина имени пользователя не более 16 символов, сортировка в таблице не более чем по 3 колонкам, или отмена действия только для последних 3 операций (Рис.2).

Ограничение на длину имени файла в Windows принесло миллионы потраченных часов на придумывание короткого имени для файла. А потом, чтобы потом понять, что это за информация.

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

Помните ограничение числа колонок – 256 было в Excel до 2007 версии (Рис.3)?

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

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

Ошибки в проектировании взаимодействия 3 – Сбивающие с толку концепции

Например, две реализации Заметок в MacOS X. Старая реализация в виде отдельной программы для десктопа и новая реализация в виде виджета для дашбоарда. Пользователи предыдущей версии продолжают пользоваться старыми заметками, новые пользователи – новыми. Когда пользователи узнают, что есть 2 версии, им непонятно какая между ними связь (Рис.4).

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

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

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