Информационное и программное обеспечение электронного бизнеса. Учебное пособие
.pdfвыделенным хостингом. Однако по сравнению со стоимостью разработки сложных сайтов, а также стоимостью трафика разница расходов на Windows и *nix хостинг может быть пренебрежимо мала.
3.2. МЕТОДЫ ПРОЕКТИРОВАНИЯ ЮЗАБИЛИТИ ВЕБ-САЙТОВ
Ранее мы уже отмечали важность обеспечения удобства использования (юзабилити) веб-сайтов для успешности электронного бизнеса. Это является довольно непростой задачей и требует соответствующей организации процесса разработки ПО (создания сайта).
На этапе анализа требований должны быть надлежащим образом собраны данные, относящиеся к взаимодействию с веб-сайтом, и зафиксированы целевые показатели качества интерфейса. Как мы отмечали ранее, юзабилити имеет смысл только в контексте категории пользователей, выполняющей определенные задачи. Соответственно важнейшим моментом данного этапа является идентификация целевой группы пользователей («портрет пользователя») и их задач. Популярным методом проектирования юзабилити на этом этапе является анализ задач пользователя.
На этапе проектирования создается проект веб-интерфейса (дизайна веб-страниц), основывающийся на требованиях к системе и учитывающий характеристики целевых пользователей. Как правило, сначала создается упрощенный прототип интерфейса (на бумаге, в виде статичного изображения на компьютере или как интерактивная программа) или даже несколько прототипов, реализующих различные проектные решения [25, с. 85]. При их создании разработчик может основываться как на собственном опыте, так и на описанных в литературе принципах организации взаимодействия, практических рекомендациях, шаблонах проектирования. Популярным методом, служащим для оценки соответствия проекта интерфейса соответствия общепринятым принципам проектирования взаимодействия («эвристикам»), является эвристическое обследование. Выявленные в ходе такого обследования ошибки учитыватся при создании следующей версии вебинтерфейса – этот подход и называется итерационным проектированием. Очевидно, что исправление юзабилити-проблем на ранних стадиях разработки (особенно в прототипах, создание которых характеризуется невысокой трудоемкостью) обходится гораздо дешевле, чем на уже полностью готовом веб-сайте.
71
Но, естественно, обеспечение удобства использования веб-сайта требует и соответствующего подхода на этапе тестирования и отладки. Тестирование интерфейса может преследовать две цели: выявление проблем, возникающих при взаимодействии, или же оценку показателей его качества. Во втором случае полученные оценки могут сравниваться с теми целевыми показателями качества, которые были зафиксированы в требованиях к ПО. Популярным методом, который может применяться для выполнения обеих целей, является юзабилититестирование. Некоторые из методов тестирования интерфейса могут быть полностью или частично автоматизированы, что находит воплощение в многочисленных инструментах, существующих в этой области (см. обзор в [82]).
После внедрения программного продукта (запуска веб-сайта) разработчики, наконец, получают потенциально неограниченные возможности по анализу поведения пользователей в ходе взаимодействия. На основе веб-аналитики и других инструментов могут осуществляться уточнение потребностей посетителей и итерационное улучшение веб-интерфейса. Качественная работа на данном этапе (а он считается наиболее трудоемким и на его долю приходится до 60 % от общей стоимости создания ПО [71]) требует соответствующего уровня юзабили- ти-культуры в компании.
Прежде чем перейти к подробному рассмотрению популярных методов проектирования юзабилити, приведем классификацию уровней юзабилити-зрелости компаний (согласно известному исследователю Я. Нильсену [83, 84]).
1.Враждебность к юзабилити. «Лучший юзер – “мертвый” юзер!», или как минимум, «безрукий».
2.Юзабилити от разработчиков. На этой стадии проектировщики полагаются на собственную интуицию при разработке интерфейсов. Однако члены команды разработчиков заведомо знают о системе, которую они создают, гораздо больше среднего пользователя. Поэтому опора на интуицию разработчика при попытке представить поведение пользователя почти всегда ошибочна.
3.Отрывочное проектирование юзабилити. Некоторые группы в компании осознают важность проектирования юзабилити и прилагают усилия по его внедрению и применению. Однако меры по улучшению юзабилити не планируются заранее и под них не выделяется конкретный бюджет. Тем не менее даже небольшие усилия могут приводить к существенному улучшению разрабатываемых продуктов.
72
4.Выделенный юзабилити-бюджет. Главный метод – юзабилититестирование, которое применяется ближе к концу процесса разработки, когда интерфейс уже как минимум частично реализован.
5.Управляемое юзабилити. Появление юзабилити-менеджера для применения и пропаганды юзабилити, архива юзабилити-отчетов и т. д.
6.Систематический юзабилити-процесс. Тестирование на ранних этапах, наличие централизованных стандартов и рекомендаций для проектирования, отслеживание показателей качества взаимодействия, связь с бизнесом.
7.Интегрированный дизайн, направленный на пользователя. Каждый шаг в процессе разработки подкрепляется данными о пользователях. Фактически, компания, принимающая решение о продуктах, которые следует разработать, начинает основываться на юзабилитипоказателях.
8.Компания, направленная на пользователя. На этом уровне данные о пользователях, их потребностях и характеристиках определяют сами проекты, которыми компания занимается. Иными словами, юзабилити проникает на уровень принятия стратегических решений –
оприоритетах развития компании.
Большинство начинающих компаний в наше время стартуют с третьего или четвертого уровня, и для достижения более высоких стадий (если это вообще происходит) в среднем требуется до 20 лет. Очевидной предпосылкой для роста юзабилити-зрелости компании является знание популярных методов проектирования юзабилити и навыков их применения.
3.2.1. АНАЛИЗ ЗАДАЧ
Предварительная стадия анализа задач – анализ контекста использования, который применяется до собственно принятия решения о запуске проекта. В ходе этого анализа собирается информация о том, кто будет являться целевыми пользователями продукта, для чего они могут пользоваться им и в каком контексте своей деятельности. Рассматриваются также основные технологические («железо») и другие ограничения, а иногда сопутствующие организационные и бизнесаспекты. Для сбора интересующих данных может проводиться встреча с заинтересованными лицами, основные из которых должны включать представителя пользователей и руководителя будущего проекта (при
73
этом существуют готовые списки вопросов, которые следует рассмотреть). Альтернативой может служить наблюдение за будущими пользователями продукта в ходе их деятельности в привычном контексте. Информация, собранная в ходе применения данного метода, может попадать в такой рабочий документ, как «Видение», и используется на стадии анализа требований и при планировании других юзабилитиметодов (например, при разработке заданий на юзабилити-тестиро- вание).
Анализ конкурентов также проводится на стадии анализа требований и помогает определить сильные и слабые стороны продуктованалогов или конкурентов. В ходе проведения этого анализа может проводиться встреча с заинтересованными лицами, на которой рассматриваются продукты-аналоги (количеством обычно от четырех до десяти, на каждый выделяется около десяти минут). Для этого производится выполнение типичных задач пользователя, выявляются конкурентные преимущества каждого из них. Анализ конкурентов позволяет, в частности, лучше понять, какую функциональность целесообразно заложить в собственный продукт при его разработке и каких ошибок следует избегать. Важным моментом является то, что рассмотрение продуктов-аналогов необходимо осуществлять с точки зрения задач и потребностей пользователей, а не технологических аспектов и т.п. Иногда анализ конкурентов может включать в себя проведение полномасштабного юзабилити-тестирования продуктов, но на практике этого обычно не требуется, если среди собираемых заинтересованных лиц есть адекватные представители пользователей.
Наконец, собственно анализ самой задачи – это набор методов, используемых для декомпозиции выполняемых пользователями задач при взаимодействии с продуктом. Анализ позволяет более глубоко и точно понять, какие действия выполняют пользователи, и облегчает автоматизацию этих действий. Другими словами, вначале нужно определить задачу и цель этой задачи, а затем перечислить те действия, которые необходимо выполнить, чтобы достигнуть этой цели. При осуществлении декомпозиции следует придерживаться принципа разумной целесообразности, чтобы не начать делать ее существенно более глубокой (затрачивая время и усилия), чем требуют потребности проекта и здравый смысл. Например, иерархия задач пользователя для такого распространенного устройства как кофейный автомат, может быть представлена таким образом, как изображено на рис. 10.
74
Получить горячийнапиток
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Выбратьнапиток |
|
Заплатитьденьги |
|
Забратьи |
|||
|
|
|
и получитьсдачу |
|
употребить |
||
|
|
|
|
|
|
напиток |
|
Рис. 10. Иерархия задач для кофейного автомата
В ходе осуществления анализа задач может осуществляться разработка «персонажей» (портретов целевых пользователей) и сценариев (прецедентов) использования. Портреты целевых пользователей (были предложены А. Купером в 1998 г.) позволяют разработчикам лучше представлять потребности пользователей, их особенности и контекст взаимодействия и могут использоваться, например, при планировании юзабилити-тестирования. Как правило, описание персонажа (составляемое по результатам интервьюирования целевых пользователей) включает в себя не только индивидуальные характеристики и факторы контекста использования, но и цели пользователя, особенности его поведения и даже некоторые вымышленные биографические или личные черты для придания описанию большей реалистичности. Считается, что использование персонажей помогает проектировщикам лучше представлять нужды и требования целевых пользователей, способствует однозначности их понимания всеми членами команды разработчиков и в итоге приводит к созданию лучшего, с точки зрения юзабилити, продукта. Как правило, количество персонажей для одного вебприложения не превышает двух-трех. Приведем пример персонажа для сайта из сферы электронного бизнеса:
Александр, 38 лет, частный предприниматель. Александр предлагает услуги в сфере ковки по металлу. У него в подчинении три сотрудника, которые являются непосредственно рабочими. Он сам является и генеральным директором, и маркетологом, и рекламистом. У него средние знания компьютера и Интернета, высшее техническое образование (машиностроение). Дела у него идут успешно, он хочет расширить бизнес – из Новосибирской области на соседние регионы. В свой бизнес он готов вкладывать деньги, но хочет четко знать, за что он платит. На сайте его может интересовать оборудование для штамповки или проката.
75
Выбрать напиток
Начало
Это похоже на кофейный автомат?
Да
Похоже, что автомат работает?
Да
Получить перечень напитков и цен
Есть ли подходящий
вариант?
Да
Осуществить выбор нажатием кнопки
Нет |
|
Конец (напиток не |
|
|
получен) |
|
|
|
Нет
Нет
Конец
Рис. 11. Сценарий использования для задачи «Выбрать напиток»
76
Заплатить деньги и получить сдачу
Начало
Определить сумму, подлежащую оплате
Определить способ внесения денег
Есть ли
достаточные
средства (монеты, банкноты)
Да
Оплатить требуемую сумму
Покупка
напитков завершена?
Да
Определить способ и получить сдачу
Конец
Нет |
Конец (напиток не |
|
|
|
куплен) |
(Переход
Нет Забрать(Перейтинапиток, Забрать напиток,
затем снова переход
затем снова к
Выбрать напиток
Выбрать напиток)
Рис. 12. Сценарий использования для задачи «Заплатить деньги и получить сдачу»
77
Забрать и употребить напиток
Начало
Определить индикатор прогресса и ждать
Определить место забора напитка
Приобретение |
Нет |
(снова |
перейти |
к |
напитков |
|
|||
завершено? |
|
Снова |
|
|
|
|
напитка) |
||
|
|
кВыбору напитка |
||
Да
Употребить напиток
Конец (успех!)
Рис. 13. Сценарий использования для задачи «Забрать и употребить напиток»
Сценарии использования являются описанием того, как пользователь будет достигать своей цели или решать задачу (они являются подвидом функциональных требований, но не нужно путать с набором ее возможностей). Они рассматривают продукт как «черный ящик», и взаимодействие с системой описывается с точки зрения внешнего наблюдателя. Примеры сценариев использования для задач, указанных на рис.10, представлены на рис. 11, 12 и 13.
78
3.2.2. ЭВРИСТИЧЕСКОЕ ОБСЛЕДОВАНИЕ
Основы этого метода исследования юзабилити были заложены американским ученым и инженером Якобом Нильсеном в середине 1990-х гг. Эвристическое обследование (англ. Heuristic Evaluation) относится к группе методов «низкобюджетного юзабилити» и обладает высокой эффективностью, во многих случаях помогающей получить существенное повышение качества взаимодействия с продуктом при низких финансовых затратах. Метод может применяться как на ранних стадиях процесса разработки (анализа и проектирования) с прототипом интерфейса, так и при тестировании готового продукта, однако очевидно, что во втором случае исправление выявленных проблем будет являться более трудоемким и дорогостоящим. Данный метод является экспертным и не подразумевает участия пользователей продукта, что может быть одновременно и преимуществом (привлечение пользователей может быть затруднительно или более затратно), и недостатком (любой эксперт лишь в ограниченной мере может воспринимать продукт с точки зрения целевого пользователя).
Основная идея метода – обследование интерфейса или его прототипа небольшой группой экспертов на предмет соответствия общепринятым принципам проектирования взаимодействия. Такие принципы часто называются «эвристиками» (так как имеют скорее широкое практическое применение, а не теоретическое обоснование), иногда – рекомендациями (англ. guidelines). «Эвристики» представляют собой перечень некоторых правил и принципов, которым должен соответствовать любой качественный интерфейс или же продукт, относящийся к некоторой области (например, веб-сайты электронного бизнеса). При составлении перечня «эвристических характеристик» можно разделить их на категории, соответствующие различным функциональным или структурным характеристикам продукта. Отдельно могут выделяться специализированные категории, т. е. соответствующие только определенной категории целевых пользователей (дети, программисты) или типу продукта (например, веб-приложение электронного правительства или развлекательный сайт). Очевидно, что перечень «эвристик» должен обладать свойствами непротиворечивости, отсутствия дублирования и полноты покрытия для продукта из обследуемой области.
Существует большое количество источников, содержащих «эвристики» (например, в виде списков вопросов для проверки веб-сайтов)
79
или рекомендации, в том числе в бесплатном и открытом доступе. Приведем пример некоторых из них для сферы электронного бизнеса.
Внешний вид страниц сайта должен позволять однозначно понять, что они относятся к одному и тому же сайту.
Главная страница должна содержать ссылки на наиболее важную «обеспечивающую» информацию: договоры, условия гарантии и возврата, стоимости доставки и т. д.
Наглядно показывать цену товаров, стоимость доставки и полную стоимость заказа, причем без необходимости предварительной регистрации.
Предоставлять полную и достоверную информацию о товарах; возможно сопровождать ее ссылками на независимые обзоры товаров.
Изображения должны демонстрировать существенные свойства
ихарактеристики товара, иметь достаточное качество и яркость. Желательно показывать товар с разных сторон.
Позволять пользователям сортировать или фильтровать позиции каталога по наиболее важным для них параметрам. Желательно позволять сравнение нескольких выбранных пользователем товаров (например, в виде таблицы характеристик).
В случае наличия у товара различных опций предоставлять пользователю выбрать их ДО помещения товара в корзину. Отображать выбранные опции у товара в корзине.
Желательно использовать горизонтальные ссылки на схожие или сопутствующие товары с целью повышения объема продаж.
Механизм (кнопка) «Купить» и корзина должны работать максимально просто. Корзина должна наглядно отображать все существенные характеристики товара и позволять изменение выбранных товаров, а также содержать легко заметную кнопку для оформления заказа.
Важным моментом в эвристическом обследовании является использование нескольких экспертов, поскольку это позволяет выявлять юзабилити-проблемы наиболее эффективно. Слишком малое количество обследующих не позволяет обеспечить достаточного разнообразия точек зрения и опыта, однако не рекомендуется задействовать и слишком много экспертов, поскольку растет вероятность того, что все они будут выявлять одни и те же проблемы. Считается оптимальным количеством три-пять участников, а если количество доступных экспертов больше, то целесообразнее разбить их на группы и провести
80
