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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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