В то же время у показателей Шнейдермана есть и недостатки:
♦ Модель неполна, т. е. учитывает не все возможные показатели. Например, некоторые интерфейсы заметно способствуют усталости оператора, что во всех отношениях плохо. Конечно, усталость проявится в человеческих ошибках и в снижении скорости работы пользователя, но где она в модели?
♦ Показатели конфликтуют между собой. Например, скорость работы пользователя с определенного предела почти всегда начинает конфликтовать со скоростью обучения, т. е. попытки сделать очень быстрый интерфейс наталкиваются на ухудшение скорости обучения и обратно.
♦ Скорость обучения навыкам оперирования сложно оценить и тем более сложно измерить. В результате этот показатель существует только номинально и почти не используется в практической работе. Ещё хуже дела у сохраняемости навыков оперирования. Мало того, что этот показатель практически невозможно проверить, так и его актуальность для многих проектов вообще стремится к нулю. Например, зачем этот показатель интерфейсу почтового клиента, если с соответствующим интерфейсом и так работают каждый день? В результате из пяти показателей остаются четыре.
♦ На практике из четырех показателей Шнейдермана почему-то можно добиться высоких показателей только по любым двум, отбрасывая два оставшихся (например, вытянуть скорость работы и количество операторских ошибок, но потерять в скорости обучения и удовлетворенности). Но из самой концепции непонятно, какие именно два показателя предпочесть в каждом конкретном случае. Например, можно прекрасно оптимизировать скорость работы пользователя, но потом окажется, что важнее была удовлетворенность (у меня однажды именно так и вышло).
♦ Модель ничего не говорит о том, какие показатели по каждой из шкал следует считать наилучшими из возможных в данном продукте.
Но достоинства показателей Шнейдермана всё-таки перевешивают недостатки. Простоту коммуникации с другими участниками проекта переоценить нельзя.
Дизайн, ориентированный на пользователей
Следующим подходом, как по сложности, так и по времени своего появления, является т. н. дизайн, ориентированный на пользователей (User Centered Design, далее ДОП). Его сущность кратко можно охарактеризовать следующим образом — если мы хорошо изучим нашу аудиторию и оптимизируем интерфейс под неё, наш интерфейс будет хорошим.
Отсюда два основных следствия ДОП:
♦ Отношение пользователей к интерфейсу является главным показателем качества интерфейса.
♦ Работа над интерфейсом невозможна без изучения особенностей аудитории, например, уровня начальной подготовки пользователей, их ожиданий, знаний предметной области и физиологических особенностей.[21]
Эти принципы действительно очень полезны:
♦ Интерфейс делается для пользователей, а не для его разработчиков. Поэтому мнение разработчиков, вообще говоря, неактуально для оценки качества интерфейса. Простейший вывод из этого соображения — если вы спроектировали интерфейс и он вам очень нравится, это ничего не решает, поскольку…
♦ …пользователи могут отличаться и, как правило, действительно отличаются от разработчиков — и ДОП помогает об этом не забывать. Например, интерфейсы продуктов для детей разрабатывают взрослые, при этом очевидно, что интерфейсы для детей разных возрастных групп должны отличаться друг от друга и тем более от интерфейсов для взрослых.[22]
Если разработчик интерфейса будет оценивать его по собственным критериям, гарантированно получится плохой интерфейс. Другой пример: разработчик медицинского устройства может прекрасно разбираться в электронике и в интерфейсах, но маловероятно, что он так же прекрасно разбирается в медицине и даже вообще представляет особенности работы практикующего врача. Но предельные случаи как раз хороши именно тем, что они предельны и, соответственно, к ним можно подготовиться. В непредельных проектах, когда интерфейсы делаются для «обычных людей», т. е. таких же, как сам разработчик, почти всегда неожиданно оказывается, что аудитория всё-таки чем-то необычна.
Учитывая это, неудивительно, что ДОП ещё недавно был основным подходом к проектированию. О его распространенности можно судить хотя бы по тому факту, что аббревиатура UCD (User Centered Design) до сих пор часто употребляется для обозначения дизайна интерфейсов вообще.
21
Например, молодые веб-дизайнеры (ещё) обладают хорошим зрением и поэтому не имеют ничего против очень мелкого набора. Адресаты их работы, как правило, несколько старше, и их зрение уже не та к остро.
Отсюда проблемы.
22
Вот характерный случай из моей карьеры.
Однажды мне нужно было разработать интерфейс для установки программы на сотовый телефон. Установка была сложной, поскольку, во-первых, включала настройки GPRS на телефоне для разных провайдеров, а во-вторых, могла выполняться на самых разных телефонах. Я потратил огромные душевные и интеллектуальные силы на эту работу, соответственно, она заняла прорву времени.
В конце же оказалось, что целевые пользователи в нормальной ситуации вообще не устанавливают эту программу — они просят сделать это кого-нибудь более сведущего, например, своего шестнадцатилетнего племянника (для целевых пользователей конкретно этой программы было более естественно просить или заставлять, нежели делать самостоятельно). Для племянника же установка не представляла никаких проблем — после всех денег, которые он потратил на картинки и рингтоны. Если бы я знал это раньше, я бы ничего не стал бы делать вовсе и КПД моего безделья достиг бы заоблачных вершин.