Мы окружены пользовательскими интерфейсами. Возможно, этот термин получил широкое распространение благодаря компьютерному программному обеспечению, однако каждая система и каждый компонент оборудования, имеющие пользователя, по определению имеют и пользовательский интерфейс. Как показал психолог и бывший исследователь компании Apple Дональд Норман (Donald Norman, 1988 [53]), мы можем многое узнать о том, как разрабатывать и строить хорошие пользовательские интерфейсы для программного обеспечения, если посмотрим вокруг. Нужно просто подумать о том, как средства управления приборами, устройствами и инструментами делают их применение проще или сложнее.

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

Пользовательские интерфейсы большинства современных автомобилей, за небольшим досадным исключением, подчиняются Великому Закону Юзабилити (Constantine, 1991 [14]). Этот закон гласит, что пользовательский интерфейс должен давать возможность пользователю, обладающему знаниями в данной области, применять систему без дополнительного обучения и штудирования руководства по эксплуатации или других инструк-ций вне самой системы. Другими словами, хороший пользовательский интерфейс дает пользователям, уже знающим то, что они делают, возможность приступить к работе без необходимости изучения чего-либо еще.

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

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

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

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

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

Четверть века назад К. Д. МакКензи удачно сформулировал Первый Закон Условностей (К. D. Mackenzie, 1966 [50]). Если есть больше одного способа сделать что-либо, а выбор между вариантами может быть произвольным, то выбирайте какой-нибудь один способ и всегда применяйте только его. Если же способы неравнозначны, то важно выбрать хороший вариант.

П. Дж. Плоджер (P. J. Plauger), принципиальный и убежденный разработчик стандартов, посвящающий их созданию значительное время, говорит о Принципе Достаточного Блага (P. J. Plauger, 1993 [58]). Стандарт для информационного обмена или для языка программирования, или для; телефонного интерфейса не обязательно должен быть идеальным или совершенным; он даже не должен быть «правильным». На практике идеальные стандарты так или иначе оказываются политически или технически невозможными. Все, что нужно, — это «достаточно хороший» стандарт. Как правило, человеческая смекалка и развивающаяся технология преодолевают большинство ограничений или недостатков.

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

Большая часть знаний и действий людей не связана с компьютерами (как это ни печально для программистов, но это суровая реальность!). Хотя некоторые механизмы действительно «зашиты» в человеческий мозг, большая часть действий, которые люди считают интуитивными, на самом деле являются обусловленными. Сегодня психологи определяют интуицию в терминах комплексных ассоциаций и процессов обработки информации, которые настолько известны мозгу, что перестали быть полностью осознаваемыми.

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

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

Приведем только один пример. Возьмем полосы прокрутки, которые применяются как метафорические механизмы для управления перемещением рабочей области относительно меньшего по размерам «окна», отображающего только часть поверхности. Полосы прокрутки для экранной навигации выполняют ту же роль, что и рычаги управления для автомобильной навигации (Constantine, 1994 [25]). Они замедляют и ограничивают работу пользователя, вводят его в заблуждение, а также вызывают лишние движения, увеличение ошибок и нарушение нормального хода мыслительных процессов. Они вынуждают пользователя выполнять такие движения, которые абсолютно противоречат работе мозга. Для перемещения влево или вправо пользователю приходится сначала переместиться вниз, а для перемещения вниз или вверх нужно сначала переместиться вправо.

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

За пределами мира компьютеров существуют системы и устройства, которые предназначены для решения аналогичных задач навигации с помощью панорамирования, прокрутки и масштабирования. С точки зрения графических пользовательских интерфейсов интересно рассмотреть два из них: аппараты чтения микрофиш и видеокамеры. Среди десятков механизмов для управления экранной навигацией (в том числе и тех, которые были разработаны автором этой книги) есть несколько явно и существенно лучших, чем полосы прокрутки (Constantine, 1994 [25]). Если вам не кажется, что это важно в реальной работе, просто подумайте, сколько раз в день вы или ваши потребители прокручивают документы, диаграммы и изображения на мониторах.

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

Из журнала Computer Language Magazine, том 9, № 11, ноябрь 1992 г.

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

Мне, как поставщику новых идей, больше всего нужны два программных продукта: графический пакет и текстовый редактор. Эти инструменты — мои постоянные попутчики. Я хочу, чтобы мне было удобно с ними работать и чтобы они хорошо совмещались друг с другом. Они определяют границы того, что я могу сделать в плане самовыражения с помощью слов и графики; они устанавливают потолок моей продуктивности. Они помогают мне одним движением доставать до дальних ящиков или же ставят подножку в простых задачах. Подобно выбору нижнего белья или дезодоранта, мои предпочтения одних инструментов другим являются глубоко личными, категоричными и иррациональными.

Изначально я мигрировал на Windows потому, что графический пакет, который был мне нужен (или мне просто хотелось им пользоваться?), работал под Windows. Миграция ассоциируется с устойчивым прогрессом, но в моем случаем это напоминало дефенестрацию[Дефенестрация (от лат. fenestra — «окно») — выкидывание человека из окна. — Примеч. перев.

]. Решившись на такой шаг, я столкнулся с раздражающей необходимостью переключаться между текстовым редактором и пакетом инструментов, работающих под DOS, и графическим Windows-инструментом. Как и рецидивирующий артрит, это не смертельно, но причиняет постоянную боль. Для более гладкого взаимодействия с коллегами, многие из которых переходили на один и тот же текстовый редактор в Windows/Macintosh, я клюнул на одно из предложений провести апгрейд. Чтобы ощутить смысл термина «апгрейд», представьте себе подъем дороги, которая тянется… вертикально вверх![Автор обыгрывает слово «upgrade» (англ.); grade — здесь: уклон, подъем; up — вверх. —]

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

По дюжине версий на счету популярных текстовых редакторов, но проще в освоении они не стали. Такой призыв на слуху, но все сводится лишь к сокращению времени, необходимого для начала работы. Едва ли не каждый может создать что-либо полезное в первые же минуты после инсталляции. Затем вы упираетесь в стену. Лучший из современных текстовых редакторов существенно сложнее для изучения, мастерского овладения, нежели его предшественники на СР/М и Apple. Забытые жемчужины прошлого, такие как Electric Pencil и Spellbinder, с высот своих восхищают нас, пользователей пусть более мощных, но и чересчур громоздких программ.

Отчасти причина кроется в том, что первые текстовые процессоры, в основном благодаря добавленным функциям, выросли в текстовые редакторы, которые, в свою очередь, превратились в «текстовые издательства» с еще большими возможностями. Далее системы высокого класса, такие как WordPerfect и Word for Windows, стали почти неотличимы от полноценных настольных издательских программ с точки зрения их возможностей, хотя средства и методы у них довольно разные. Эти системы битком набиты фенечками и фитюльками, и нужно приложить немало усилий, чтобы заставить их работать в нужное время и в нужном месте.

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

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

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

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

Прогрессирующий функционизм часто приводит к разбросу взаимосвязанных операций или пунктов выбора по разным частям пользовательского интерфейса. После четвертой или пятой редакции внесение десятков «добавлений» и «исправлений» приводит к тому, что пользовательский интерфейс покрывается слоем небольших довесков, разнообразных переключателей и приложений к меню. Со временем форма интерфейса все больше отражает внутренние программные ограничения. В ней проявляются трудности, с которыми сталкивались программисты при поиске места для размещения функций. Бывалые пользователи, чьи пальцы загрубели и искривились за многие годы применения этих функций, настолько привыкли к ним, что редко задумываются перед нажатием Ctrl-F5-C–C. Таким образом, они поощряют недобросовестных поставщиков программного обеспечения к еще большему интерфейсному варварству, поскольку новые функции не должны мешать применению старых.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Простая технология может быть удивительно эффективной. Закрепите видеокамеру за спиной пользователя и сфокусируйте ее на клавиатуру и экран. Рядом с экраном расположите переносное зеркало таким образом, чтобы в камеру было видно лицо пользователя. Вот и все.

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

Затем исследователь просматривает отрывки из этой записи вместе с пользователем. Это необходимо для прояснения намерений или реакций пользователя, его мыслей и действий при работе с тестируемым программным обеспечением. Именно здесь зеркало оказывается полезным. Когда при просмотре люди видят самих себя, особенно выражение своего лица, они часто могут с поразительной точностью вспомнить свой «внутренний диалог» и собственные ощущения, которые были во время записи. Если постараться получить эту информацию и понять ее, то такие данные могут показать, что именно нужно вашим пользователям.

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

Из журнала Computer Language Magazine, том 9, № 12, декабрь 1992 г.

Один современный мастер Дзен спрашивает: «Каков цвет хлопка одной ладонью?» Здесь есть о чем подумать, тем более что сейчас мы будем говорить о роли цвета в пользовательском интерфейсе.

Цвет стал важным аспектом графических пользовательских интерфейсов, по крайней мере с точки зрения продаж программного обеспечения. Многие годы я отказывался от приобретения цветного монитора, поскольку моя работа в основном была связана с обработкой текстов. Древняя Негси1ев-совместимая видеокарта давала мне все необходимое, и за этим плоским монохромным монитором янтарного цвета я мог часами работать без головных болей и усталости глаз. Зачем же тогда переходить на блеклые краски, меньшую разрешающую способность и мерцающее изображение? У меня был цветной монитор — огромный индюк CGA, который шел в придачу к моему первому лэптопу. Но обычно он служил в качестве стола. Я не видел мир программного обеспечения во всем цвете до тех пор, пока не пересел на мою теперешнюю рабочую лошадку. В этой системе есть монитор с прогрессивной разверткой: 72 Гц, 256 цветов, 1024x768 пикселов. Мои глаза открылись.

До того времени я считал цвет только хитрой уловкой при продаже видеоигр и программ для поддержки принятия решений, которые зачастую мало чем отличались друг от друга. Хотя я никогда не сходил с ума от палитры рабочего стола в Windows («Смотри, Мод, какие яркие цвета!»), я подверг переоценке роль цвета в коммуникации. Цвет может быть не просто украшением. Он может стать важной частью взаимодействия между пользователем и программным обеспечением. Суть, естественно, только в том, когда и как его использовать.

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

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

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

В системе Гатагно (Gatagno) «слова в цвете» цвет применялся как дополнительный ключ к «декодированию» звуков в слове. Все формы звука «ау»¹

(«eigh», «ei», «ai», «еу», «а» и т. д.) печатались одним цветом и служили своего рода визуальными тренажерами, на которых дети могли учиться.

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

Дети и другие человекообразные существа воспринимают понятия более легко и более точно, если процесс подкрепляется информационными средствами, вовлекающими различные каналы восприятия, особенно если абстрактные понятия представлены яркими и ощутимыми предметами, которые можно подержать в руках. Дети легче изучают алфавит, если они могут взять в руки цветные буквы и поиграть с ними. Хорошие учителя годами применяют такие методы. Успех так называемых CRC-карт в объектно-ориентированном проектировании (Wirfs-Brock и др., 1990 [68]) отчасти объясняется тем, что эти маленькие (3 на 5 или 4 на 6) заменители объектных классов являются конкретными предметами, с которыми разработчик может поиграть при обдумывании различных архитектур и сценариев.

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

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

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

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

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

Ваши сотрудники, озабоченные хорошим «видом» и хорошим «ощущением», находятся на неверном пути. Восприятие формы зависит от контрастности. Как правило, чем больше контраст, тем легче читать. Уже давно известно, что при нормальном освещении текст удобнее всего читать, если он напечатан черным шрифтом на белом фоне. Светлое на темном (и другие сочетания цветов) читать значительно труднее.

Это поднимает другой вопрос: шрифты. По шрифтам пользовательского интерфейса иногда можно определить возраст людей, занимавшихся его разработкой. Слишком часто в программном обеспечении применяются или устанавливаются по умолчанию шрифты, которые я на» ываю «до 40», — небольшой размер символов и маленький междустрочный интервал. Эти шрифты могут читать только те, кому меньше 40! Проблема усугубляется дисплеями высокого разрешения, поскольку системные шрифты обычно являются растровыми. Не раз я был свидетелем того, как проваливалась демонстрация замечательного программного обеспечения, так как собравшиеся в демонстрационной кабине не могли прочитать текст меню и диаграмм; они только вежливо кивали головами, как будто понимали, что происходит.

Укрепляющаяся гегемония «презентационных пакетов» порождает и другие трудности. Такие пакеты создают, как я это называю, «шестизарядные слайды» — ну, вы знаете: маркер, маркер, маркер, маркер, маркер, маркер. Наглядные пособия должны быть именно наглядными пособиями. Они должны способствовать пониманию и запоминанию, визуально иллюстрировать, расширять или подкреплять комментарии докладчика. Шестизарядные визуальные материалы являются очень слабым и наименее эффективным методом применения потенциально мощного инструмента. От использования красивых цветов мало толку. Возможности цвета и графики необходимо применять для достижения конечной цели передачи информации, а не просто так, волей-неволей следуя дизайнерскому принципу сэра Эдмонда Хилари (Edmond Hillary) — раз уж они есть.

Подобно Сискелу (Siskel) и Эберту (Ebert), я убежден в том, что некоторые компоненты лучше всего воспринимаются в своей оригинальной, нецветной форме. Иногда цветной язык лучше всего переводить в простой чер-но-белый. А что касается цвета хлопка одной ладонью, я думаю, он может быть цвета окна.

Из журнала Software Development, том 1, № 1, январь 1993 г.

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

Катание на лыжах помогает узнать многое о взаимоотношениях между пользователями и системами и о том, как разработчики программного обеспечения могут улучшить эти взаимоотношения. Это было бы жестоким испытанием — учиться катанию на лыжах на каком-нибудь из тех крутых бугристых склонов, которые предназначены для опытных лыжников. Некоторые новички, в основном подростки до двенадцати лет, после легких склонов норовят сразу же отправиться на трассы для могу-ла[Могул — разновидность фристайла, езда по крутым горкам. — Примеч. ред. ], но я всегда подозревал, что они просто-напросто биомутанты. Для начального обучения большинству из нас подойдут широкие и легкие склоны, обозначенные этими милыми зелеными кружочками.

С другой стороны, вы сможете научиться только элементарным приемам, если весь день будете проводить на простых склонах. Рано или поздно, вам придется перейти к более сложным синим и черным (иногда черно-синим) трассам.

Опытные лыжники, эксперты, одолевающие слалом и перелетающие через бугры, внушили нам, что это единственный способ катания на лыжах. Но совершенствующиеся середнячки тоже могут наслаждаться необыкновенными минутами, спускаясь с Небесной долины (Heavenly Valley). Внизу вы видите жемчужину — сияющее бирюзовое озеро Тахо (Lake Tahoe), к востоку — пустыню и коричнево-желтое море, простирающееся до горизонта. Морозный утренний воздух щиплет лицо, а под лыжами скрипит свежевыпавший снег.

Хорошо, но какое отношение это имеет к разработке программного обеспечения? Мечтая о катании на лыжах у Тахо, я хотел рассказать о трехфазной модели пользовательского интерфейса (Constantine, 1994 [13], 1994 [24]). Согласно трехфазной модели, у пользователей системы есть различные потребности на различных стадиях своего развития, а значит, пользовательский интерфейс должен разрабатываться с учетом этих изменяющихся потребностей. Для этого в программном обеспечении необходимо предусмотреть разные виды интерфейса для пользователей с разными уровнями владения продуктом. Каждый из этих вариантов должен иметь свои характерные черты и отдельные технические задачи. Как и сеть трасс на хорошем лыжном курорте, эти компоненты интерфейса должны быть не разделены, а тесно связаны между собой.

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

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

Если система полезна и хорошо разработана, то пользователи перестанут быть в ней новичками. Лишь некоторые из них со временем станут экспертами или очень опытными пользователями, а большинство, вероятно, будет проводить свои дни в качестве совершенствующихся середнячков. Их потребности отличаются от запросов экспертов или новичков; им нужен пользовательский интерфейс, позволяющий постоянно и последовательно увеличивать свои знания о данном программном продукте и улучшать навыки его применения. Такой интерфейс не должен наказывать за незнание. Он не должен неожиданно швырять их на склоны диалогов с двойным черным ромбом, которые понравятся только программисту, пишущему на С++.

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

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

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

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

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

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

Благодаря хорошему проектированию и всестороннему юзабилити-тести-рованию в некоторых ГПИ удалось создать разумный интерфейс приобретения. Например, интерфейс в Apple Macintosh был разработан так, что-бы с момента открытия упаковки до начала выполнения полезной работы проходило не более 20 минут.

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

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

Ладно, поеду кататься на лыжах!

Из журнала Software Development, том 1, № 2, февраль 1993 г.

2.70! Это число может вам ни о чем не говорить, но курс машиностроения, который обозначен этими цифрами в Массачусетском технологическом институте, довольно знаменит. Студенты получают наборы разнообразных деталей и затем соревнуются в проектировании и построении лучшего робота, собирающего шарики для пинг-понга, или компьютеризированного передвижного моста, или другого устройства, выдуманного преподавателями. Профессор Вуди Флауэрз (Woody Flowers), научный сотрудник Государственной службы радиовещания (Public Broadcasting System, PBS) и основатель курса 2.70, хочет помочь будущим конструкторам и инженерам создавать более практичные продукты, которые действительно работают для человека. Его университетские курсы способствовали организации соревнований между студентами высшей школы. Даже учеников средней школы он вооружает видеокамерами для того, чтобы вокруг себя они находили и документировали недружелюбные для пользователя или просто непригодные конструкции и схемы.

Если бестолковое проектирование так легко распознать, то почему на миллионах индикаторов видеомагнитофонов или микроволновых печей по всему миру загораются цифры 12:00 или 88:88? Почему программное обеспечение, основанное на ГПИ, не ускоряет нашу работу? Несмотря на созданные «отделы изучения человеческих факторов» и «лаборатории юзабилити-тестирования», ведущие производители продолжают выпускать глупое программное обеспечение с серьезными изъянами в юзабилити, которые даже двенадцатилетний ребенок может заметить с другого конца комнаты.

Представьте: мой компьютер сообщает, что 8 283 файла занимают почти 550 Мбайт дискового пространства (о, конечно, это были старые добрые времена… еще до появления Win95 и 98). Для удержания лидерства в области консультирования необходимо разбираться в этих цифровых джунглях и находить в них нужный материал. Размер файла и дата его создания зачастую помогают быстрее найти нужную версию или вариант, поэтому нам нужно видеть эти данные, когда мы собираемся открыть файл из приложения. При открытии или сохранении файлов, когда мы видим их и думаем о них, нам удобнее всего заниматься уборкой в доме — перемещением файлов или папок, переименованием или удалением. Каждый знает об этом, но только небольшая часть продуктов предоставляет такую возможность. Нам необходимо расширение/дополнение, способное стандартизировать и расширить набор диалогов «Открыть», «Сохранить», «Сохранить как» в Windows. Каждое приложение должно отображать информацию о статусе файлов и их описание непосредственно в диалоговых окнах, а также поддерживать в них выполнение рутинных операций с файлами.

Это хорошая идея. В некоторых больших продуктах эта возможность предусмотрена. В одном из таких чудесных пакетов вы можете нажать Ctrl-O, и в верхней левой части диалогового окна открытия файла (там же, где и всегда) появляется знакомое комбинированное окошко для выбора имени файла. Внизу располагается прокручиваемый список файлов, в котором, как всегда, видно слишком мало файлов и совсем не видно их статуса. Выделите одно из имен файлов, и в сером окне внизу справа (!) появится дата, время создания и размер выделенного файла. За раз можно увидеть описание только одного файла. Нужно постоянно переключать внимание между верхней левой и нижней правой областями экрана. Два разных и далеко отстоящих друг от друга визуальных элемента приходится мысленно совмещать; описания файлов нельзя сравнивать без запоминания; вместо быстрого и легкого просматривания списка нужно выполнять неудобную, последовательную, механическую операцию. Такая неразумная конструкция нарушает основные принципы дизайна интерфейсов и не позволяет пользователю выполнять свою работу.

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

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

Одним из путей к поддержанию такой сосредоточенности является проведение систематических юзабилити-инспекций (Constantine, 1994 [23]). Они напоминают традиционный анализ программ и проектных решений, но особое внимание они уделяют пользовательскому интерфейсу и юзабилити — для выявления изъянов в этой области. Такие инспекции заставляют разработчиков думать о пользователях и юзабилити программного обеспечения. Одной-единственной инспекции, проводимой непосредственно перед принятием окончательной версии продукта, недостаточно. Разработчики и специалисты по построению интерфейсов должны внимательно проверять модели рабочих процессов, первые бумажные прототипы, начальные варианты дизайна, рабочие прототипы, а также альфа- и бета-версии программного продукта. Как показал Якоб Нильсен, юзабилити улучшается с каждой инспекцией (Jacob Nielsen, 1993 [52]). С каждой новой инспекцией разработчики узнают немного больше о хорошем дизайне пользовательского интерфейса и ошибках, которых следует избегать.

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

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

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

Разработка программного обеспечения сводится к созданию различных функций. На рынке выигрывает тот, кто предлагает наибольшее количество функций или самые необычные возможности. Однако программное обеспечение с притягательной 3D-графикой, перегруженное функциями, может оставаться несовершенным с точки зрения пользовательского интерфейса. Юзабилити программного обеспечения касается общей организации пользовательского интерфейса. При анализе юзабилити не рассматриваются функции программы и их взаимодействие, призванное облегчить работу пользователя, А значит, каждый участник команды должен обращать внимание на архитектуру и детали интерфейсов в течение всего процесса разработки.

Возможно, производители программного обеспечения уделяют столько внимания композиции и внешнему виду не потому, что это так важно для юзабилити, а потому, что кроме этого они ничего не умеют отлаживать.

Из журнала Software Development, том 2, № 4, апрель 1994 г.

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

Я всегда завидовал писателям, чьи пальцы с легкостью парят над клавиатурой, создавая первые черновики, которые можно считать окончательным вариантом. Я пишу медленно, иногда мучительно, зачастую нерегулярно, а первые плоды моего труда редко бывают съедобными. К счастью, я довольно хороший редактор. За многие годы я научился «отключаться» от своих сочинений, чтобы спустя время окинуть их свежим придирчивым взглядом и найти места, требующие переделки. Статья может пройти через четыре или пять раундов безжалостной редактуры, прежде чем я смогу с удовлетворением сказать, что теперь она готова.

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

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

Некоторые люди от рождения пишут грамотно. Но не я. Программист-писатель П. Дж. Плоджер (P. J. Plauger) однажды заметил, что он органически не способен писать слова неправильно. Он сказал это перед тем, как предложить мне приглашать кого-либо для вычитки моих рукописей. Вместо того чтобы последовать его совету, я сам научился писать правильно.

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

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

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

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

Редакторы журналов часто подходят к своей работе с позиции заведомо несведущего читателя. Пит Бикфорд (Pete Bickford), который некогда носил титул чемпиона по пользовательским интерфейсам (User Interface Champion) в Apple, так же оценивает пользовательские интерфейсы. Он говорит, что его работа подразумевает вхождение в роль самого глупого пользователя на планете. Это такой настрой ума, при котором вы отключаете все, что вам известно о компьютерах, или приложениях, или программировании. Если вы сможете посмотреть в верхний правый угол окна Windows-приложения и увидеть кнопку для увеличения, то у вас есть перспектива стать более эффективным редактором интерфейсов.

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

Вам даже нужно научиться видеть то, чего нет. Примером может слуi жить отсутствующая обратная связь для пользователя или функция, ко¹ торая не видна в нужном месте и в нужное время.

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

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

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

Из журнала Software Development, том 3, № 11, ноябрь 1995 г.

Это можно назвать вниманием к клиенту или «голосом покупателя», но речь идет о сервисе. Я получил возможность узнать об этом больше, когда впервые открывал банковский счет в Австралии. Я послушно заполнил все бланки, предъявил все документы и внес первый вклад. Буду ли я пользоваться чеками? Да, конечно. Нужна ли мне карточка-ключ? Какая карточка? Карточка для EFTPOS (читается «эфтпос»). Слово EFTPOS в Австралии является повседневным. «Эта очередь по EFTPOS?» — такой вопрос можно услышать в супермаркете. Или покупатель может сказать: «Я хотел бы оплатить этот заказ по EFTPOS». Работники финансовых служб знают, что EFTPOS означает Electronic Funds Transfer, Point Of Sale (терминал системы электронных платежей). В Австралии покупка продуктов, оплата счетов, получение наличных — все это осуществляется при помощи EFTPOS.

Конечно, я попросил, чтобы банк выдал мне эту карту, тем более что по правилам я мог получить ее только лично. Я получил карту, и она неделю пролежала у меня в кармане, пока я не пошел снять немного денег.

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

Я не понимал, что означало это сообщение. Может быть, я ввел неверный PIN-код или совершил какую-то другую ошибку. За мной уже выстраивалась очередь, но я попытался еще раз. И снова неудачно. То же самое произошло и на другой машине. В конце концов я зашел в один из филиалов моего банка, где у справочной стойки коротким «Да?» меня приветствовала сотрудница сервисной службы.

Я объяснил, что у меня не работала EFTPOS-карта. «Хорошо, что вы делали?» — спросила она таким тоном, как будто со мной говорили в кабинете директора школы. Я ответил, что попытался получить наличные деньги. «Нет, что вы делали?» — спросила она опять с сильным ударением на последнем слове. И вот, призвав на помощь все свои способности, я начал пересказывать ей в точности все то, что я делал: выбрал клавишу «Снять деньги» из зеленых клавиш, потом выбрал «Основной чековый счет» из синих клавиш… «А, ну вот». Что вот? «Ну, вот видите. У вас же нет чекового счета». Я стал объяснять, что уже открыл чековый счет, в подтверждение доставая чековую книжку из кармана пальто. «Нет, это не чеки. Мы не открываем чековые счета частным лицам. У вас сберегательный счет. Если бы вы правильно нажимали на клавиши, у вас не было бы этой проблемы». Я был готов потребовать ее начальника, когда увидел надпись на ее карточке — как раз она и была этим начальником. Я что-то пробурчал, повернулся и ушел.

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

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

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

Все может быть и по-другому. Хорошее программное обеспечение помогает людям оказывать более качественные услуги. Расскажу о своем опыте общения с представителями винного клуба «Cellar Door Direct» в Южной Австралии. Через несколько месяцев после получения рекламного объявления я решил позвонить им и заказать немного вина. Все, что у меня было, — это листок с моими каракулями. К сожалению, код того вина, которое было мне нужно, не отображался на экране у телефонного оператора. Я слышал, как она «листала» файлы с данными, пока не нашла то, что нужно. «Это Jarrondale'92 Shiraz, правильно?» Она назвала цену, которая показалась мне слишком большой, — я напомнил, что это вино было выставлено на распродажу. «А какая цена указана у вас?» — спросила она. Я назвал ей верную, на мой взгляд, сумму. «Я больше не вижу здесь этой цены, но давайте я сделаю исправление». Клик, клик. И через пару дней у моей двери стоит посылка. Сочетание гибкого программного обеспечения с гибким персоналом позволило укрепить отношения с покупателем.

Приведу еще пример. В Сиднее впервые создали замечательную службу под названием «Cuisine Courier». Вы выбираете блюда из меню местных ресторанов, и за какие-то $2 заказ доставляют прямо к вашей двери. Позвонив в эту службу, вы просто сообщаете им свой телефон, а система предоставляет остальные данные. «Мистер Константин? Вы живете по тому же адресу? Хорошо, по какому меню вы хотели бы сделать заказ?» Вы называете краткий код, и оператор подтверждает его, сообщая полное название ресторана, — и так для каждого блюда. «Заказ будет доставлен через 45 минут». Через 45 минут в дверь стучат, и можно начинать пиршество.

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

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

Из журнала Software Development, том 4, № 3, март 1996 г.