♦ скоростью работы пользователя

♦ количеством человеческих ошибок субъективной удовлетворенностью

♦ скоростью обучения навыкам оперирования интерфейсом

♦ степенью сохраняемости этих навыков при неиспользовании продукта.

Эти показатели очень полезны:

♦ Они предметны и точны. Гораздо проще сделать интерфейс, с которым работать быстрее, чем интерфейс, который «удобнее» — мысли не разбегаются, критерии четче. Тем более просто объяснить другим, что интерфейс стал быстрее, чем «удобнее».

♦ Благодаря тому, что показателей качества несколько, растет производительность труда. Показатели помогают концентрироваться на отдельной задаче, не отвлекаясь и не фантазируя. Если потратить день на оптимизацию по скорости, потом ещё день на сокращение операторских ошибок и ещё день на увеличение удовлетворенности, получившийся интерфейс будет лучше, чем интерфейс, на который потратили те же три дня, делая его «вообще лучше».

В то же время у показателей Шнейдермана есть и недостатки:

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

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

♦ Скорость обучения навыкам оперирования сложно оценить и тем более сложно измерить. В результате этот показатель существует только номинально и почти не используется в практической работе. Ещё хуже дела у сохраняемости навыков оперирования. Мало того, что этот показатель практически невозможно проверить, так и его актуальность для многих проектов вообще стремится к нулю. Например, зачем этот показатель интерфейсу почтового клиента, если с соответствующим интерфейсом и так работают каждый день? В результате из пяти показателей остаются четыре.

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

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

Но достоинства показателей Шнейдермана всё-таки перевешивают недостатки. Простоту коммуникации с другими участниками проекта переоценить нельзя.

Дизайн, ориентированный на пользователей

Следующим подходом, как по сложности, так и по времени своего появления, является т. н. дизайн, ориентированный на пользователей (User Centered Design, далее ДОП). Его сущность кратко можно охарактеризовать следующим образом — если мы хорошо изучим нашу аудиторию и оптимизируем интерфейс под неё, наш интерфейс будет хорошим.

Отсюда два основных следствия ДОП:

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

♦ Работа над интерфейсом невозможна без изучения особенностей аудитории, например, уровня начальной подготовки пользователей, их ожиданий, знаний предметной области и физиологических особенностей.[21]

Эти принципы действительно очень полезны:

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

♦ …пользователи могут отличаться и, как правило, действительно отличаются от разработчиков — и ДОП помогает об этом не забывать. Например, интерфейсы продуктов для детей разрабатывают взрослые, при этом очевидно, что интерфейсы для детей разных возрастных групп должны отличаться друг от друга и тем более от интерфейсов для взрослых.[22]

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

Учитывая это, неудивительно, что ДОП ещё недавно был основным подходом к проектированию. О его распространенности можно судить хотя бы по тому факту, что аббревиатура UCD (User Centered Design) до сих пор часто употребляется для обозначения дизайна интерфейсов вообще.

Но у дизайна, ориентированного на пользователей, есть и недостатки:

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

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

♦ ДОП требует исследований. Эти исследования, по сути, являются этнографическими. В свою очередь, этнографические исследования почему-то всегда дороги и длительны, вдобавок, почему-то всегда более длительны и дороги, чем запланировано (вероятно, потому, что этнографическое исследование применительно к интерфейсу — это всегда «найди то, не знаю что»).[24] Поэтому включать в проектный цикл этнографическое исследование — верная гарантия того, что проект с управленческой точки зрения пойдет насмарку. Кроме того, до конца исследования совершенно непонятно, будет от него польза или нет, что депрессивно действует на всех участников проекта.

Суммируя, можно сказать, что ДОП негласно подразумевает: есть система (в частности — интерфейс) и есть её пользователи, которые и важны. Того, что делают пользователи в системе и ради чего они, собственно, с системой взаимодействуют, ДОП не покрывает. Зато его покрывает…