Различные концепции usability продолжают привлекать внимание дизайнеров и разработчиков
программного обеспечения
и Internet-проектов, и это внушает определенный оптимизм.
Если на момент публикации этим летом статьи "Поговорим о usability"
("Компьютерное Обозрение",
# 26) на запрос "usability" поисковые машины выдавали всего лишь
несколько полезных ссылок, в основном, с сайта Usability.ru, то при подготовке
этого материала удалось найти рубрику "Уроки usability" на сайте Mags.ru,
причем посвящен он электронной коммерции и торговле в Internet, т. е. не одной
лишь теорией живет русскоязычная Сеть.
В последнее время концепция usability постепенно обрастает новыми понятиями и областями применения, отчего новичку, желающему понять принципы данной отрасли науки, становится еще труднее. В статьях, посвященных usability, вам могут рассказывать, как правильно настроить сервер, обучить персонал, написать сопроводительную документацию к программному продукту и т. д. Вот здесь хотелось бы остановиться и четко определить то, о чем пойдет речь в статье, — наука usability занимается вопросами создания и воплощения пользовательского интерфейса. И не более. Сюда не включены принципы построения систем "сервер-клиент" (для этих целей существует системный анализ), вопросы оптимизации кода разработчиков (чем занимаются информатика и прикладные науки), модели создания платежных систем (что также входит в компетенцию системных аналитиков и соответствующих консультантов) и многие другие аспекты, хотя, безусловно, слово usability применимо и к перечисленным проблемам — плохо разработанная система имеет меньшие шансы на успех, нежели качественный продукт, однако, снова-таки, это выходит за рамки обсуждаемого вопроса.
Пользовательский интерфейс и его соответствие нуждам пользователя — вот основные
задачи usability. Ян Соммервилль (Ian Sommerville), автор монографии "Разработка
программного обеспечения", предлагает собственную модель создания пользовательского
интерфейса (хотя Соммервилль концентрирует свое внимание на программных продуктах,
данная модель применима и в Web-дизайне).
Из
рисунка видно, что основным компонентом разработки пользовательского интерфейса
становятся сами пользователи, и это вполне понятно. Удивительно лишь то, насколько
часто данным фактором пренебрегают, полагая, что опытный дизайнер или программист
и так более или менее ознакомлен со всеми пользовательскими требованиями и поэтому
никаких дополнений в плане верификации программного продукта в области usability
не требуется. Если программное обеспечение или Web-продукт делается для конкретного
клиента (скажем, банковское ПО или корпоративная сеть intranet), то здесь знаниям
дизайнера и программиста, пожалуй, можно доверять, так как в крайнем случае клиенту
придется переучиться или привыкнуть пользоваться тем интерфейсом, который ему
предложат. В случае же, если продукт нацелен на более массовый рынок (коммерческое
ПО или Web-сайт), то здесь ошибки в интерфейсе могут стоить очень дорого, а экономия
на usability скажется на уровне продаж или количестве посетителей.
Мифы usability
Пожалуй, дочитав до этой строки, читатель подумал: "Ну не стоит рисовать
картину в таких мрачных тонах, в конце концов, хороший Web-дизайнер всегда держит
ухо востро и наблюдает за тенденциями в своей сфере деятельности, а программист
является прежде всего пользователем других программ, и поэтому концепции простоты
и эффективности интерфейса ему прививаются автоматически". Между тем в своей
книге "Usability
Engineering" Джейкоб Нильсен, на работы которого я неоднократно ссылался
и раньше, пробует дать определение мифам о usability, бытующим на производстве.
Чтобы разобраться получше в том, как и почему делаются ошибки, рассмотрим нижеприведенный
список "мифов", созданный не исследователем-теоретиком, а бывшим сотрудником
Bell Communications Research, который сегодня занимается консалтингом по usability
для многих крупных компаний.
Миф 1. Даже самое лучшее представление о том,
чего хочет посетитель, не дает точной картины того, что именно он хочет
Данный миф довольно часто упирается в некоторые психологические особенности
работы коллектива и желания самоутверждения — дизайнер или программист практически
никогда не признает, что дизайн или интерфейс, им сделанный, прекрасен в художественном
и эстетическом плане, однако является малопригодным с точки зрения полезности
и эффективности использования. Не хотелось бы в этой статье приводить конкретные
примеры и прослыть рупором чьих-то идей, однако среди знакомых мне Web-проектов
наиболее удачным в плане usability в номинации "Internet-сервис" представляется
поисковик Google (Нильсен входит в правление компании), а в номинации "Корпоративный
сайт" я бы отдал предпочтение ALG.
Довольно часто и дизайнер, и разработчик могут рассказать и доказать, как следует
что-то делать и как это делают другие, однако при этом они будут мыслить как дизайнер
и как разработчик, хотя вам нужен образ мышления пользователя.
Миф 2. Пользователь всегда прав
Вероятно, идеальным вариантом создания пользовательского интерфейса была
бы поставка продукта с полностью настраиваемым интерфейсом, где дизайнер или разработчик
просто предоставили бы посетителю возможность самому выбрать, где разместить определенную
панель и какие кнопки на ней должны быть, или как должна осуществляться навигация
сайта — вертикально или горизонтально. Между тем подобный продукт практически
наверняка будет пользователями отвергнут, так как в большинстве случаев психология
требует наличия базового интерфейса, который можно персонализировать под свои
нужды позже, но не с самого начала. Именно поэтому исследования usability практически
всегда проводятся над несколькими группами потребителей, а приглашение в компанию
пользователя на должность консультанта по usability может оказаться неэффективным
— лично мне, допустим, очень нравится размещать панель задач в Windows на рабочем
столе по правую сторону, а не внизу, однако большинство пользователей, работающих
с этой операционной системой, наверняка бы возмутились, узнав, что следующая версия
продукта выйдет именно с таким расположением панели (несмотря на то, что данную
возможность легко настроить).
Миф 3. Пользователь ничего не понимает
В одной из своих статей на сайте Alert Box Нильсен называет несколько причин,
почему разработчикам и пользователям лучше не встречаться за одним столом, в частности
то, что программисты могут оскорбить пользователя, выражая свое удивление его
непониманием простых (с точки зрения программистов) истин и принципов применения
программы. Да, возможно, не всегда компании удается подобрать идеальный контингент
клиентов, с полуслова понявших бы предназначение определенного элемента пользовательского
интерфейса. Однако в случае, если продается программный продукт, то именно те
пользователи, для которых данная проблема насущна, будут звонить по бесплатным
телефонным линиям в службу поддержки и требовать предоставления дополнительных
инструкций или вообще возврата денег.
Миф 4. Дизайнер в какой-то мере сам является
пользователем
Данная ошибка описана выше и во многом перекликается с первым мифом. Разработчик
программы или автор Web-сайта, заняв соответствующую должность, уже имеет некий
накопленный багаж знаний и опыт, причем чем ответственнее должность, тем более
весомыми становятся эти два качества. Особенность же знания состоит в том, что
человеческий мозг работает в одну сторону — в сторону развития. Даже самый лучший
разработчик не может временно абстрагироваться от своего опыта и представить себе,
что он видит программный продукт впервые. Когда в 1991 г. в штате Орегон проводилось
исследование по usability такого банального продукта, как расписание автобусов,
то выяснилось, что только 18% пользователей смогли успешно выполнить поставленную
задачу. Ларчик в данном случае открывался просто — расписание подготовили сотрудники
департамента транспорта, для которых оно было чрезвычайно удобным и соответствовало
их понятиям о usability. В своей статье "Можно ли разработчиков считать людьми?"
("Are
Developers People?") Джейкоб Нильсен пишет: "Если вы разработчик,
то я могу предположить, что вы принадлежите к тому одному проценту населения планеты,
которое знает о компьютерах больше, чем остальные. Вы также умны, можете абстрактно
мыслить и в поисковых системах употребляете булевые запросы. Но не хвалите себя
слишком сильно — вы абсолютно некомпетентны в оценке пользовательского поведения.
Возможно, я слишком много внимания уделяю поисковым системам, но практика показывает,
что поисковик со сложным, но мощным интерфейсом используется двумя типами людей
— разработчиками этого же поисковика и библиотекарями, за спиной которых четыре
года образования в данной области. Пользователей любое проявление сложности пугает".
Миф 5. Пользователь в какой-то мере сам является
дизайнером
Как было показано выше, передача управления в руки пользователя также обычно
ни к чему хорошему не приводит. Причиной тому является опять-таки накопленный
опыт или его отсутствие, если талантливый и опытный разработчик знает необходимые
требования и status quo индустрии, где он работает, то пользователь, которому
предоставлена возможность создания интерфейса, будет основывать свои решения на
неких личных факторах, которые не обязательно окажутся приемлемыми для остальных
клиентов. В одном из исследований испытуемым было предложено для команд текстового
интерфейса использовать собственные аббревиатуры (старожилы, помнящие эпоху DOS,
и пользователи Unix наверняка поймут, о чем идет речь) вместо стандартных. В результате
пользователями было сделано почти в два раза больше ошибок, чем в случае применения
стандартных команд (навязанных компанией-производителем).
Миф 6. Чем больше, тем лучше
Данный миф, похоже, взяли на вооружение производители микроволновых печей
и создатели порталов. Количество функций и возможностей, присутствующих в вышеуказанных
продуктах, пожалуй, поражает неискушенное воображение посетителя магазина или
пользователя Internet, однако в плане usability подобное "могущество"
в большинстве случаев отпугивает. Вероятно, именно поэтому Web-дизайнеры лучшим
редактором считают Notepad, а производители ПО стараются в новых версиях представить
интерфейс с меньшим количеством кнопок.
Методы оценки usability
После всех вышеприведенных мифов начинающий специалист по usability может
усомниться в том, что он способен найти верный путь, и резонно спросить: "Так
что же теперь делать? Дизайнерам доверять нельзя, пользователям, выходит, тоже,
проводить масштабные исследования или заказывать их у известных компаний слишком
дорого". Между тем способы оценки usability не всегда предусматривают проведение
таких исследований или найм высокооплачиваемого специалиста. Безусловно, сегодня
каждая компания, работающая в данной сфере, имеет собственную методику оценки
usability, так как если определенный метод подходит для какой-то одной среды,
то это вовсе не означает, что те же знания с успехом можно применять в любой другой
ситуации. Тем не менее рассмотрим некоторые рекомендации экспертов индустрии.
1. Наблюдение за пользователями
Расхожее мнение о том, что конечный продукт производится не для удовлетворения дизайнерского самолюбия и даже не для вице-президента компании, который курирует данный проект, уже, наверное, набило оскомину большинству читателей. Между тем, как часто в реальности разработчики продукта наблюдают за реакцией пользователей, насколько часто программисты, пишущие под заказ, приходят в офис к своему клиенту и просят разрешения просто посмотреть, как они работают? Реже, чем того хотелось бы. А ведь именно данный тип исследования, пожалуй, дает наиболее четкое представление о том, как и в каких целях используется продукт, каких функций в нем не хватает, а какие следовало бы упростить или обеспечить более быстрый доступ к ним.
2. Мысли вслух
Мотивация действий пользователя и сегодня продолжает оставаться "черным
ящиком" для большинства разработчиков, хотя каждый руководитель проекта при
представлении его вышестоящему начальству непременно будет употреблять слово "пользователь"
и пытаться высказать собственные предположения о том, какие ассоциации у клиента
вызовет та или иная иконка или как он видит тот или иной раздел сайта. При тестировании
usability с помощью данного метода пользователя просят сесть перед компьютером
и комментировать свои действия вслух. При этом предпочтительно оставить его в
тестовой комнате одного, обеспечив полную конфиденциальность полученной от него
информации и анонимность тестирования (не думаю, что вам будет очень приятно,
если весь город узнает, что вы сохраняете файл самым сложным и неожиданным способом
вместо использования "горячей клавиши"). По возможности следует также
записывать движения мыши, чтобы получить дополнительные сведения о психологии
пользователя.
3. Постановка задач
Пожалуй, лучший способ проверить эффективность пользовательского интерфейса
— это найти представителя целевой группы и попросить его выполнить некую конкретную
задачу. Компания Vividence, специализирующаяся на исследовании usability для крупных
Web-сайтов, использует для этого собственный броузер, регистрирующий все действия
пользователя. При посещении сайта перед ним ставится конкретная задача (скажем,
приобрести наиболее дешевый сканер), а затем учитываются время, затраченное на
выполнение задачи, количество щелчков мышью, необходимое для достижения нужной
цели, и ряд других факторов, которые могут интересовать разработчиков. Также интересно
подобные исследования проводить в виде соревнований, где приз получит пользователь,
быстрее всех выполнивший задачу, — в данной ситуации на него оказывается давление,
и он вынужден принимать только интуитивные решения.
Вместо заключения
Тема usability никогда не утратит актуальности. Пожалуй, с развитием информационных
технологий, появлением все большего количества Web-сайтов и экспоненциальным ростом
производимого программного обеспечения вопросы usability все чаще будут подниматься
при обсуждении достоинств и недостатков продуктов информационной эпохи. Если психологи
постоянно утверждают, что о незнакомом человеке судят по его внешности, то о программном
продукте или сайте сегодня можно сказать то же самое — встречают по одежке, а
провожают… Впрочем, если одежка неприемлема, то обычно по ней же и провожают.