Четвертый этап : подтверждение качества пользовательского интерфейса

Тестирование на удобство применения является клю­чевым элементом итерационного процесса разработки. Оно заключается в том, чтобы выдать продукт на руки боль­шому количеству пользователей и посмотреть, смогут ли они с ним работать! Вот почему уделяется так много вни­мания данной теме. Цель тестирования на удобство при­менения должна заключаться в оценке поведения, дейст­вий и степени удовлетворения пользователей. Многие раз­работчики обращаются к подобному виду тестирования (если вообще обращаются) ближе к концу проектирова­ния. Однако это уже слишком поздно для того, чтобы на основании его результатов вносить изменения. Даже если они и вносятся, нельзя быть уверенным в том, что исправ­ленный продукт можно использовать без проведения по­вторного тестирования.

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

Сценарии, разработанные на втором этапе, возвраща­ются «к жизни» на этапе подтверждения. Удалось ли спро­ектировать продукт, который управляется разработан­ными сценариями пользователей? Вы не можете быть уверены в этом, если не подтвердили качество вашего продукта по отношению к заранее определенным целям и задачам.

Разработчики должны обязательно присутствовать при проведении тестирования. Тогда они смогут увидеть, как пользователи работают с их продуктами. Не позволяйте им заниматься тестированием «собственноручно». Однако они должны иметь возможность оказать техническую под­держку при проведении тестирования.

Деятельность по оценке удобства применения не пре­кращается после продажи продукта или внедрения его в производство. Команда разработчиков будет с нетерпени­ем ожидать откликов пользователей. Microsoft далее про­сит клиентов отсылать свои комментарии и список поже­ланий для будущих версий продукта. В диалоговом окне About Microsoft Works (Microsoft Works) пользователей просят направлять комментарии напрямую Microsoft: «Помогите нам сделать будущие версии еще более качест­венными, отправив нам свои идеи и предложения».

Таблица 5.1 Действия по оценке удобства применения продукта

 

Стадии разра­ботки продукта	Действия по оценке возможности использования
Определение концепции	Сбор требований пользователей Концептуальное определение разработки
Подтверждение концепции	Концептуальные оценки разработки (бумага/карандаш, прототипы)
Разработка	Оценки прототипов. Отслеживание и фиксирование проблем, возникающих у пользователей

 

124

125

Человеко-машинное взаимодействие: теория и-практика

Теория

 

Окончание табл. 5.1

 

Стадии разра­ботки продукта	Действия по оценке возможности использования
Проектирование	Итерационное тестирование на ранних стадиях разработки (индивидуальные модели, ключевые задачи). Итерационное тестирование окончатель­ных вариантов разработки (целиком продукт, все задачи). Отслеживание и фиксирование проблем, возникающих у пользователей
Распространение пилотной версии. Анкета для пользователей пилотной версии	Наблюдение на месте за пользователями пилотной версии. Обратная связь с пользователями пилотной версии. Отслеживание и фиксирование проблем, возникающих у пользователей
Внедрение продукта	Наблюдение на месте за пользователями продукта. Обратная связь с пользователями продукта. Отслеживание и фиксирование проблем, возникающих у пользователей. Анкета для пользователей продукта
Поддержка и обслуживание	Сравнение показателей удобства примене­ния за длительный период времени (1-месячный, 3-месячный, 6-месячный интервалы). Обновления и внесение изменений в тесты. Тест для пилотных разработок новых продуктов

Два направления разработки

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

126

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

					Пользователь
			Интерфейс пользователя
			Инструменты для проектирования
			Операционная система
					Разработка на базе системы
			Техническая поддержка

Рис . 5.5. Два направления разработки

Разработка на базе системы может предопределить тип проектируемого пользовательского интерфейса. Пол Шворк высказывает свое мнение по этому вопросу: «Сама техно­логия (язык определен, CASE-инструментарий выбран и т.д.) часто затмевает концепцию (справочный блок дан­ных, процесс понимания, метод отображения)». Он также указывает на эволюцию данного подхода: «Выбор объект­но-ориентированного языка или CASE-инструментария сначала и последующая работа в обратном направлении по поиску подходящих потребностей бизнеса не отлича­ются от пути, по которому системы разрабатывались и внедрялись, когда еще использовались перфокарты. Ре­шение уже было готово (обычно COBOL, всегда мэйнфрейм, возможно, компьютер с набором сложных команд (CICS) для более сложных приложений), и тем или иным спосо­бом потребности бизнеса с силой «втискивались» в задан­ное решение. Более того, конечные пользователи прило-

127

Человеко-машинное взаимодействие: теория и практика

Теория

 

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

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

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

Историческим примером проектирования компьютер­ной системы на базе ее интерфейса является Apple Com­puter. Данный пример стал классикой успешной истории, где сначала был создан проект интерфейса, а затем постро­ен сам компьютер для его поддержания! Персонал компа­нии Apple всегда гордился своим дружественно настроен­ным к пользователю компьютером Macintosh. Порядок, в

котором они разрабатывали компьютерную систему, сыг­рал в этом решающую роль. Питер Джоунс (Peter Jones) писал: «Фирма Apple перевернула обычный порядок раз­работки машин, когда принялась за создание компьютеров. Сначала появился интерфейс, а машина для его функцио­нирования была спроектирована уже после. Все началось с идеи сделать компьютер, на котором было бы легко нау­читься работать. Физические действия контролируются областями человеческого мозга, которые отличаются от ис­пользуемых нами в процессе мышления. Внимание наше­го сознания фокусируется на задаче, а моторные способно­сти — на инструментах. Казалось очевидным, что успешный интерфейс должен базироваться на этих идеях, и нужно использовать принципы, в соответствии с которыми поль­зователь должен находиться в самом сердце системы».

Разработчик пользовательского интерфейса ходит по тонкой линии, разделяющей два очень различных мира — пользователей и разработчиков. Если вы слиш­ком часто натягиваете на себя шляпу «система», то може­те спроектировать то, что, по вашему мнению, необходимо пользователям. Однако вы можете оставаться в полном неведении о том, чего же на самом деле хотят пользовате­ли. Разработчики часто приходят к выводу, что проще про­ектировать интерфейсы, будучи консультантом, а не слу­жащим компании.

Наконец, помните о том, что весь этот процесс враща­ется вокруг пользователей и того, что они делают. Разра­ботка, ориентированная на пользователя, основана на ряде руководящих принципов:

♦ понимание нужд пользователей является движущей силой всего проекта;

♦ все, что пользователи видят и к чему прикасаются, должно проектироваться совместными усилиями;

♦ инновационный проект всегда является результа­том интенсивной работы;

♦ используются команды специалистов в разных об­ластях;

 

128

5. Зак 313                                                                                                 129

Человеко-машинное взаимодействие: теория и практика

Теория

 

♦ конкурентоспособный проект требует постоянного акцента на соревновании;

♦ проект, утвержденный пользователями, управляет разработкой кода;

♦ принимаемые решения должны основываться на обратной связи с пользователями;

♦ информация от обратной связи с пользователями должна собираться часто, с научной точностью и скоростью;

♦ обратная связь осуществляется как с потенциаль­ными, так и с уже существующими клиентами;

♦ последовательно должна стандартизироваться и внедряться разработка, ориентированная на поль­зователя;

♦ разработка, ориентированная на пользователя, долж­на постоянно совершенствоваться.

Примеры результатов выполнения работ на этапах разработки пользовательского интерфейса

Рассмотрим задачу гостиничного делопроизводства: клиенты могут выполнять бронирование номеров и засе­ляться в них, менеджеры должны выполнять регистрацию всех заказов.

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

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

Таблица 5.2 Первый этап: результаты анализа требований,

предъявляемых пользователями

 

 

 

 

 

 

 

 

 

 

Результаты анализа	Клиенты	Представители обслуживающего персонала
Первый шаг: профиль пользователя	Мужчины и женщины	Мужчины и женщины
	Взрослые	Взрослые
	Жители разных стран	Жители разных стран
	Русско- и англогово­рящие	Русско- и англогово­рящие
	Минимальное владение ЭВМ	Средний уровень владения ЭВМ
	Предварительные знания по программе отсутствуют	Средний уровень владения программой
Второй шаг: задачи, стоящие перед пользо­вателями	Просмотр информа­ции по гостинице и тарифам	Просмотр информа­ции по гостинице и тарифам
	Просмотреть и обно­вить бронирование	Просмотреть и обно­вить бронирование
	Сохранить информа­цию о бронировании	Проверить информа­цию о бронировании
Третий шаг: . требования пользовате­лей	Требуется небольшой (или никакого) тренинг	Требуется минималь­ный тренинг
	Требуется мало времени	Возможность исполь­зовать программу, одновременно обща­ясь с клиентом по телефону
	Доступность 24 часа в сутки	Стиль интерфейса аналогичный продук­ту клиента

 

130

131

Человеко-машинное взаимодействие: теория и практика

Теория

 

Продолжение табл. 5.2

Окончание табл. 5.2

 

 

 

 

 

 

 

Результаты анализа	Клиенты	Представители обслуживающего персонала
	Возможность про­смотра и вывода графической и текстовой информа­ции о гостиницах	Потребность в мини­мальной технической поддержке
	Успешное выполне­ние задачи	Время ответа систе­мы, допустимое для ожидающего клиента
	Отсутствие необходи­мости в другом инструментарии и программах	Выполнение задачи может быть прервано и аннулировано
Четвертый шаг: среда пользо­вателя	ПК-программа, использующая локальную базу данных	Сетевые ПК, исполь­зуемые в среде обслуживания клиентов
	ПК-Internet-программы, исполь­зующие системную базу данных	Несколько представи­телей обслуживающе­го персонала, исполь­зующие системы одновременно
	Возможность исполь­зования дома, в офисе или в путешествии	Несколько представи­телей обслуживающе­го персонала, имею­щие доступ к сетевой базе данных одновре­менно
	Минимальные требования к компь­ютерной системе и телефонному обслу­живанию	Стандартизированные ПК, рабочие станции и телефонные систе­мы

 

 

Результаты анализа	Клиенты	Представители обслуживающего персонала
Пятый шаг: соответствие требований задачам, стоящим перед пользо­вателем	Фотографии гости­ниц, карты и другая информация должны быть доступны для просмотра и вывода на печать в соответст­вии с требованиями клиента	Сетевая ПК система должна быть в состоянии обслужить несколько запросов одновременно
	Профиль клиента и информация по состоянию счета должны обновляться для соответствия его требованиям	Аналогичные задачи должны решаться представителями сферы обслуживания и клиентами с помощью аналогично­го интерфейса для того, чтобы первые имели возможность эффективно ответить на вопросы клиентов

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

В табл. 5.3 приведены некоторые цели и задачи, стоя­щие перед системой. Именно они должны определять про­цесс разработки пользовательского интерфейса.

В табл. 5.4 представлены сценарии и задачи, стоящие перед пользователями системы.

В табл. 5.5 проиллюстрированы сценарии после иден­тификации объекта и действий для системы.

 

132

133

Человеко-машинное взаимодействие: теория и практика

Теория

 

Таблица 5.3 Второй этап: цели и задачи, стоящие перед продуктом

 

 

 

 

Цели и задачи, стоящие перед продуктом	Клиенты	Представители сферы обслужива­ния
Удобство применения	Цель: пользователи получают возмож­ность использовать программу для выполнения своих задач	Цель: пользователи получают возмож­ность использовать программу для выполнения своих задач
	Задача: 100% потребителей смогут использовать систему для решения своей задачи уже после первой попытки	Задача: 100% потребителей смогут использовать систему для решения своей задачи после прохож­дения соответствую­щего тренинга
Эффектив­ность	Цель: деятельность пользователей станет более продуктивной (по сравнению с руч­ным методом работы)	Цель: деятельность пользователей станет более продуктивной (по сравнению с руч­ным методом работы)
	Задача: 100% пользователей выполнят стоящие перед ними задачи в течение заданного промежутка времени	Задача: 100% пользователей выполнят стоящие перед ними задачи в течение заданного промежутка времени
Легкость в освоении	Цель: пользователям потребуется мини­мальный тренинг	Цель: пользователям потребуется мини­мальный тренинг
	Задача: пользователи будут в состоянии успешно работать с продуктом после про­хождения соответст­вующего обучения	Задача: пользователи будут в состоянии успешно работать с продуктом после прохождения 4-ча­сового тренинга

 

 

Цели и задачи, стоящие перед продуктом	Клиенты	Представители сферы обслужива­ния
Оценка пользователя­ми качества продукта	Цель: пользователи будут удовлетворены качеством продукта	Цель: пользователи будут удовлетворены качеством продукта
	Задача: пользователи будут высоко оцени­вать степень своего удовлетворения качеством продукта	Задача: пользователи будут высоко оцени­вать степень своего удовлетворения качеством продукта

Таблица 5.4

⇐ Предыдущая1234567Следующая ⇒

Поделиться: