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

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

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

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

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

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

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

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

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

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

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

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

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

Главным недостатком здесь является то, что в лаборатории люди ведут себя не так, как у себя дома, не говоря уже о затратах на создание и функционирование такого отдела. Если вы хотите узнать, как люди работают с тем или иным программным обеспечением, такие исследования нужно проводить в контексте. Для этого можно применить какой-нибудь вариант контекстного опроса, например метод, впервые предложенный Карен Холтцблатт (Karen Holtzblatt) и ее коллегами из Digital Equipment Corporation (Holtzblatt и Beyer, 1993 [40]).