Usabilfty: теория и практика

Различные концепции usability продолжают привлекать внимание дизайнеров и разработчиков программного обеспечения и Internet-проектов, и это внушает определенный оптимизм. Если на момент публикации этим летом статьи «Поговорим о usability» («Компьютерное Обозрение», N26) на запрос «usability» поисковые машины выдавали всего лишь несколько полезных ссылок, в основном, с сайта Usabilfty.ru, то при подготовке этого материала удалось наити рубрику «Уроки usability» на сайте Mags.ru, причем посвящен он электронной коммерции и торговле в Internet, т. е. не одной лишь теорией живет русскоязычная Сеть.

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

Пользовательский интерфейс и его соответствие нуждам пользователя — вот основные задачи usability. Ян Соммервилль (Ian Sommerville), автор монографии «Разработка программного обеспечения» (www.software-engin. com/), предлагает собственную модель создания пользовательского интерфейса (хотя Соммервилль концентрирует свое внимание на программных продуктах, данная модель применима и в Web-дизайне).

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

МИФЫ usability

Пожалуй, дочитав до этой строки, читатель подумал: «Ну не стоит рисовать картину в таких мрачных тонах, в конце концов, хороший Web-дизайнер всегда держит ухо востро и наблюдает за тенденциями в своей сфере деятельности, а программист является прежде всего пользователем других программ, и поэтому концепции простоты и эффективности интерфейса ему прививаются автоматически». Между тем в своей книге «Usability Engineering» Джейкоб Нильсен (www.useit.com/alertbox), на работы которого я неоднократно ссылался и раньше, пробует дать определение мифам о usability, бытующим на производстве. Чтобы разобраться получше в том, как и почему делаются ошибки, рассмотрим нижеприведенный список «мифов», созданный не исследователем-теоретиком, а бывшим сотрудником Bell Communications Research, который сегодня занимается консалтингом по usability для многих крупных компаний.

Миф 1. Даже самое лучшее представление о том, чего хочет посетитель, не дает точной картины того, что именно он хочет

Данный миф довольно часто упирается в некоторые психологические особенности работы коллектива и желания самоутверждения — дизайнер или программист практически никогда не признает, что дизайн или интерфейс, им сделанный, прекрасен в художественном и эстетическом плане, однако является малопригодным с точки зрения полезности и эффективности использования. Не хотелось бы в этой статье приводить конкретные примеры и прослыть рупором чьих-то идей, однако среди знакомых мне Web-проектов наиболее удачным в плане usability в номинации «Internet-сервис» представляется поисковик Google (Нильсен входит в правление компании), а в номинации «Корпоративный сайт» я бы отдал предпочтение ALG (www.artlebedev.ru). Довольно часто и дизайнер, и разработчик могут рассказать и доказать, как следует что-то делать и как это делают другие, однако при этом они будут мыслить как дизайнер и как разработчик, хотя вам нужен образ мышления пользователя.

Миф 2. Пользователь всегда прав

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

Миф 3. Пользователь ничего не понимает

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

Миф 4. Дизайнер в какой-то мере сам является пользователем

Данная ошибка описана выше и во многом перекликается с первым мифом. Разработчик программы или автор Web-сайта, заняв соответствующую должность, уже имеет некий накопленный багаж знаний и опыт, причем чем ответственнее должность, тем более весомыми становятся эти два качества. Особенность же знания состоит в том, что человеческий мозг работает в одну сторону — в сторону развития. Даже самый лучший разработчик не может временно абстрагироваться от своего опыта и представить себе, что он видит программный продукт впервые. Когда в 1991 г. в штате Орегон проводилось исследование по usability такого банального продукта, как расписание автобусов, то выяснилось, что только 18% пользователей смогли успешно выполнить поставленную задачу. Ларчик в данном случае открывался просто — расписание подготовили сотрудники департамента транспорта, для которых оно было чрезвычайно удобным и соответствовало их понятиям о usability. В своей статье «Можно ли разработчиков считать людьми?» («Are Developers People?», www.developer.ibnn.com/ Iibrary/articles/nielsen4.html) Джейкоб Нильсен пишет: «Если вы разработчик, то я могу предположить, что вы принадлежите к тому одному проценту населения планеты, которое знает о компьютерах больше, чем остальные. Вы также умны, можете абстрактно мыслить и в поисковых системах употребляете булевые запросы. Но не хвалите себя слишком сильно — вы абсолютно некомпетентны в оценке пользовательского поведения. Возможно, я слишком много внимания уделяю поисковым системам, но практика показывает, что поисковик со сложным, но мощным интерфейсом используется двумя типами людей — разработчиками этого же поисковика и библиотекарями, за спиной которых четыре года образования в данной области. Пользователей любое проявление сложности пугает».

Миф 5. Пользователь в какой-то мере сам является дизайнером

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

Миф 6. Чем больше, тем лучше

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

МЕТОДЫ ОЦЕНКИ USABILITY

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

1. Наблюдение за пользователями

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

2. Мысли вслух

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

3. Постановка задач

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

Вместо заключения

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

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365