Человеческий фактор в программировании

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

36 Назад к истокам

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

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

Желание добра

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

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

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

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

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

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

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

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

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

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

Посещение офисов

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

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

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

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

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