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

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

Составьте график проведения нескольких стадий тес­тирования, начиная с просмотров клиентами первоначаль­ных вариантов разработки. Когда части продукта и интер­фейса построены, предложите их пользователям и протес­тируйте снова. Окончательное тестирование всей системы проводится, когда продукт близок к завершению и все час­ти собираются вместе. У вас не будет неприятных сюрпри­зов, если вы будете проводить тестирование итерационным методом, используя результаты опроса пользователей и обратную связь. В табл. 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

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

Теория

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

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

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

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

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

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

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