Текст книги "Человеко-компьютерное взаимодействие"

Связь по представлению пользователей важна, потому что пользователи имеют свое мнение о системе, и это мнение должно быть отражено в интерфейсе. Известно, что самый распространенный способ поиска – по классификации признаков – работает только в том случае, когда пользователи согласны с принципами этой классификации. Большинство же понятий не может быть однозначно классифицировано из-за наличия слишком большого количества значимых признаков. Также проблема состоит в том, что субъективный классификационный признак может отличаться от общепринятого. Из этой ситуации существует простой выход – способ карточной сортировки. Все понятия, которые требуется классифицировать, пишутся на карточках из расчета одно понятие – одна карточка. После этого группе пользователей из целевой аудитории предлагается рассортировать карточки (при этом каждый субъект получает свой набор карточек). Карточки нужно разобрать на составляющие и свести результаты от разных субъектов в один способ классификации.

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

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

Рис. 5.4. Пример структуры экранов

Различные экраны или страницы сайта могут быть реализованы, скажем, в виде каскадного стиля. Каскадные таблицы стилей (сокращенно – CSS) дают много преимуществ: они являются одним из распространенных шаблонов построения ПИ, позволяя «облегчить» каждую страницу, повысить пропускную способность (уменьшить время загрузки web-стра-ницы) и, главное, серьезно облегчить и ускорить процесс внесения изменений при работе над ПИ, так как можно работать отдельно над каждой страницей. Подробнее об этом можно прочитать у Шмидта Кристофера [11].

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

Результаты данного этапа обязательно отражаются в презентационных, а возможно, и в псевдореальных версиях прототипа, по которым и проводится юзабилити-тестирование (см. разд. 5.1). В соответствии с результатами последнего осуществляются корректировки ПИ.

Структура справочной системы должна не просто описывать интерфейс, но помогать пользователю решать его задачи. После разработки структуры экранов и навигации по ним составление соответствующей справочной системы обычно не вызывает трудностей. На этом этапе начинается также подготовка документации для пользователя. Это очень важная часть работы, часто несправедливо считающаяся второстепенной. Тот, кто составляет документацию для пользователя (будем называть его техническим писателем, по аналогии с установившейся традицией), обычно работает в теснейшем контакте с создателями ПИ, так как, если интерфейс прост и ясен, работы немного, а если сложен и неочевиден – то много. Технический писатель почти всегда знает о конструируемой системе не меньше, чем те, кто создает интерфейс, или, во всяком случае, знает другое. Это делает необходимым тесный контакт с писателем, более того, во многих источниках напрямую рекомендуется ставить писателя выше дизайнера интерфейса, поскольку его вклад в проект более значителен. Дело в том, что скорость обучения работе с системой является важнейшей составляющей качества.

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

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

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

Одновременно и параллельно с написанием документации для пользователя необходимо также писать документацию для разработчиков ПИ, объясняя каждое свое дизайнерское решение ПИ, большое и малое, приводя все соображения, которые вами двигали при разработке ПИ. Это в высшей степени человеколюбивое дело по отношению к тем, кто будет, отталкиваясь от вашего ПИ, делать какие-то аналоги, усовершенствования, модификации (см. разд. 5.2.3).

Низкоуровневое проектирование. На данном этапе разрабатываются интерфейсы конкретных экранов системы (состав, взаимное расположение и поддерживающие текст интерфейсных элементов). Вся эта работа может быть разделена на четыре части: проектирование основных экранов, тестирование, проектирование второстепенных экранов и, наконец, финальное юзабилити-тестирование.

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

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

При финальном юзабилити-тестировании на какой-то версии прототипа разрабатываются и выполняются тестовые задания, оставшиеся после предварительного тестирования. На основании полученных данных интерфейс либо дорабатывается, либо считается разработанным, т.е. это итерационная процедура (как и юзабилити-тестирование в целом). На этом этапе следует помнить о пользе контрольных списков (см. разд.5.1.6).

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

• уменьшить длину всех получившихся элементов;

• показать этот список любому потенциальному пользователю системой и спросить, как он понимает каждый элемент. Если текст какого-то элемента воспринимается неправильно, его нужно заменить;

• проверить, чтобы одно и то же понятие не называлось в разных местах по-разному;

• проверить текст на совпадение стиля с официальным для выбранной платформы (если вы делаете программу, эталоном является текст из MS Windows);

• убедиться, что на всех командных кнопках стоят глаголы-инфинитивы (отменить, удалить, отправить).

Создание эффективного прототипа интерфейса является чрезвычайно важной задачей. Прототип должен хорошо выглядеть, чтобы понравиться заказчику и не вызвать вопросов у субъектов тестирования, он должен быть дешев, максимально полон и, что немаловажно, с легкостью обновляться.

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

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

Особый интерес представляют первые две, третья и четвертая используются редко, так как почти не отличаются от готовой программы. Первая версия – бумажная, вторая – презентационная, третья – псевдореальная, четвертая – реальная.

Бумажная версия прототипа. Достоинствами ее являются исключительная простота и скорость рисования. Польза начального прототипи-рования на бумаге заключается, во-первых, в исключительной простоте модификации по результатам тестирования, а во-вторых, в относительной простоте привлечения представителей целевой аудитории. Кроме того, бумага помогает не думать о том, как интерфейс выглядит, позволяя сосредоточиться на том, как интерфейс работает. Поэтому не следует делать такой прототип очень реалистичным, он должен просто отражать функциональность.

Бумажная версия прототипа рисуется на этапах постановки задачи и высокоуровневого проектирования (см. выше). Она является предварительной, предстоит еще множество корректировок, поэтому не следует пытаться утвердить ее у заказчика. Не следует также часто использовать ее для тестирования. Тестирование на бумажном прототипе – проявление неуважения к участнику тестирования. На перекладывание бумажек уходит много времени. От скучающего участника ожидать сотрудничества не приходится. Можно в начале работы провести только пробное тестирование восприятия системы пользователем и ее основной логики.

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

Бумажный прототип многое искажает. Можно нарисовать на бумаге прекрасный интерфейс, а потом обнаружить, что он не вмещается в отведенное для него пространство. Поэтому всякий раз, создавая интерфейс на бумаге, нужно помнить, что прототип вам немного врет. В компьютерном прототипе таких проблем нет – его можно нарисовать совпадающим по размерам с реальным. Таким образом, бумажные прототипы не могут полностью заменить прототипы экранные.

Для создания бумажного прототипа необходимо нарисовать на бумаге все экраны и диалоговые окна (или распечатать соответствующие части схемы). Нужно только убедиться, что все интерфейсные элементы выглядят единообразно и сколько-нибудь похожи на реальные. Эта распечатка и является первым прототипом, который используется для пробного тестирования. При рисовании прототипа очень важно не стараться нарисовать его красиво, например не нужно стараться рисовать линии прямыми. На понимание работы интерфейса это не повлияет, зато очень замедлит работу. Так что основным критерием живописности должна стать скорость работы.

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

Рис. 5.5. Вариант бумажной версии интерфейса

Презентационная версия прототипа. После того как исчерпаны возможности бумажной версии прототипа, стоит создать новую версию. Для этого точно так же рисуется интерфейс, но уже не на бумаге, а в какой-либо презентационной программе. С этой версией прототипа можно тестировать значительно более сложное взаимодействие человека с системой, нежели с бумажной. В то же время исправлять ошибки значительно труднее. Такая версия прототипа может создаваться уже на этапе высокоуровневого проектирования, но на этапе низкоуровневого проектирования ПИ она обязательна (см. разд. 5.2.1).

Достаточно распространенными инструментами для создания прототипов этого вида являются на сегодняшний день MS PowerPoint и MS Visio. Пакет PowerPoint обладает многими преимуществами для прототи-пирования. Наиболее существенные преимущества – его широкая известность, дешевизна и массовое применение. Он не требует специальных знаний (в HTML или в программировании), достаточно прост и интуитивно понятен. Несмотря на некоторые ограничения, для значительной доли реальных задач он вполне достаточен. Использование возможности гиперсвязей объектов (вариантов интерфейсов) с множеством слайдов позволяет оперативно менять интерфейс, сосредоточиваясь именно на нем, а не на сложных видеоэффектах. Хотя PowerPoint и не предназначен для анимационных эффектов, их можно получить путем предъявления серии последовательно изменяющихся изображений и их яркости и/или величины. Это создает иллюзию движения, особенно при быстрой смене слайдов (максимальная скорость – 4 слайда в секунду). Одним из недостатков этого метода является ограничение количества слайдов, требуемых для прототипа. Некоторые авторы указывают, что, если количество слайдов превышает 300, существенно возрастает риск утраты ранее созданных гиперсвязей (это связано с особенностями программного обеспечения). Кроме того, данный пакет требует весьма тщательного управления конфигурацией дерева слайдов.

Конечно, такие пакеты, как MS FrontPage или Macromedia Dreamweaver, обладают широкими возможностями для создания интерактивных прототипов, они способны, в частности, оперировать не только линейными, но и иерархическими структурами. Пакеты Macromedia Flash и Director имеют возможность для продолжительной и достаточно сложной анимации с большим количеством объектов. Но все такие пакеты намного дороже PowerPoint (Director, например, стоит около тысячи евро) и сложнее в освоении.

MS Visio превосходит по возможностям привычный MS PowerPoint, но уступает Macromedia FreeHand. А вообще, подойдет любой иллюстративный пакет, обладающий способностью работать с несколькими страницами. Возможности MS PowerPoint для такой работы слишком малы, а возможности FreeHand, напротив, слишком велики.

При работе с Visio можно выбрать: либо рисовать все экраны на одном листе, соединяя взаимосвязанные элементы управления и экраны линиями, либо рисовать каждый экран на отдельном листе, связывая экраны ссылками. Первый вариант удобен для разработчика, поскольку позволяет оценить интерфейс в целом, второй – для заказчика и субъектов тестирования, поскольку его легче понять. Как правило, превратить второй вариант в первый оказывается гораздо легче. Если рисовать в PowerPoint, каждый экран удобно создавать как отдельный слайд, а результат нажатия на кнопки имитировать переходами между слайдами.

Большим достоинством MS Visio является возможность записывать результат в HTML-файл, что позволяет без проблем тестировать интерфейс на территории субъектов тестирования. Раньше это мог только MS PowerPoint, чем во многом и объяснялась его популярность в качестве инструмента для создания прототипов. Сейчас это умеет и Visio (сохранение в формате HTML начало нормально работать в версии Visio 2001). В то же время прототипирование интерфейсов в Visio сталкивается с серьезными трудностями.

1. Результат работы, т.е. собственно прототип, трудно передать заказчику. Visio не является стандартной программой, так что просмотреть прототип заказчик чаще всего не может. Недавно появилась бесплатная программа просмотра, но ее интерфейс неудобен (достаточно сказать, что прототип открывается внутри браузера). Можно экспортировать прототип в другой формат (при этом из прототипа получается нечто вроде сайта), но он будет фактически неработоспособен.

2. В Visio практически невозможно разрабатывать длинные (т.е. высокие) формы. При переходе на такую форму масштаб отображения прототипа изменяется так, чтобы форма вся помещалась на экране; как следствие масштаб становится слишком мелок и его приходится менять вручную. Из-за этого на прототипе почти невозможно проводить никакое юзабилити-тестирование.

3. В Visio присутствуют шаблонные страницы, но гиперссылки на этих страницах не работают. Это значит, что любое навигационное меню приходится размещать на всех страницах, на которых оно используется; при необходимости же изменить один элемент приходится менять его вручную на всех страницах.

Этих недостатков лишен пакет Adobe InDesign. Выходным форматом в InDesign является надежный и общедоступный PDF с гипертекстовыми ссылками. Проблема длинных форм в InDesign решается благодаря тому, что при установке ссылки можно указать масштаб целевой страницы. Третьей проблемы также не существует – гиперссылки на шаблонных страницах работают. InDesign имеет ряд преимуществ.

1. Интерфейс Visio проектировался для спорадической работы неспециалистов – в самом деле, много ли людей, которых нанимают специально под работу с Visio? InDesign, напротив, спроектирован в расчете на то, что с ним будут работать по восемь часов пять дней в неделю. В результате интерфейс InDesign позволяет работать гораздо быстрее – одним только использованием «горячих» клавиш обеспечивается значительное ускорение работы.

2. Работа со слоями в Visio чрезмерно сложна – окно настолько велико, что использовать его почти бесполезно. В InDesign, напротив, работа со слоями реализована прекрасно – так, только теперь появилась возможность готовить два разных прототипа – один специально для разработчиков, а другой (урезанный) – для тестов.

3. Известно, что тени – лучшие друзья web-дизайнера. В прототипах их использовать тоже очень полезно – они прекрасно отделяют примечания к интерфейсу (если они есть) от самого интерфейса. Сделать прототип без примечаний практически невозможно, проблема в том, что эти примечания в прототипе теряются. Использование теней эффективно решает эту проблему, но в Visio они настолько рудиментарны, что пользоваться ими нельзя.

Но есть и проблемы с InDesign. Так, он весьма ресурсоемок: работает медленно, требуя при этом много оперативной памяти и мощного процессора. Правда, экспорт очень быстрый, гораздо быстрее, чем в Visio. В Visio любому объекту можно назначить стиль, и после этого массово менять облик элементов управления легко и просто. В InDesign же есть только стили цветов. Кроме того, работа с гиперссылками в InDesign реализована довольно неудобно. Существуют стили ссылок, т.е. определяемые пользователем точки их назначения, но встроенная в InDesign палитра ссылок почему-то показывает не эти стили, а список уже установленных ссылок. В результате установка ссылки и в особенности поддержание стройной системы наименований страниц превращаются в весьма неочевидную задачу.

Главным преимуществом Visio является наличие библиотеки объектов (stensil) со стандартными элементами управления. Можно не рисовать интерфейс с нуля, а просто расположить элементы управления в правильном порядке, тем самым существенно увеличивая скорость работы. Но имеющиеся ограничения таковы, что эта библиотека на практике бесполезна. Дело в том, что в текущей версии Visio стандартные объекты растровые, поэтому они хорошо выглядят только в одном масштабе. Стоит его изменить, как прототип искажается до неузнаваемости. Кроме того, из-за чрезмерной детализации стандартных объектов с ними мало что можно сделать. Например, если надо выделить цветом какие-то объекты (скажем, обозначив тем самым в прототипе их кликабельность), то сделать это невозможно. Конечно, можно нарисовать свою библиотеку объектов, но зачем тогда Visio?

Некоторые достаточно продвинутые разработчики не могут избежать соблазна воспользоваться для создания прототипа средствами быстрой разработки приложений (Delphi, Visual Basic и т.д.). В этом случае прототип интерфейса воспринимается лишь как вспомогательная оболочка над программным кодом. Как следствие возникают следующие недостатки.

1. Для тестирования прототипа на пользователях крайне желательно, чтобы он хоть немного работал, т.е. нажатие на кнопку вызывало другое окно или из выпадающего списка можно было выбрать значение. Но в данном случае любое взаимодействие как между отдельными элементами интерфейса, так и между различными формами реализуется только с помощью написания программного кода. Что совершенно не нужно в данном контексте. Зачем усложнять то, что можно сделать проще? Ведь основное достоинство прототипа – это скорость.

2. Чрезвычайно сложно создать принципиально новый элемент интерфейса либо модифицировать уже имеющийся. Подобные задачи часто встречаются на практике, так как для хорошего интерфейса стандартных элементов, как правило, не хватает. Затраты же на создание/модификацию собственного элемента управления в данных средах разработки нельзя назвать адекватными.

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

4. Естественный недостаток: нельзя разрабатывать web-интерфейс. Фактически для большинства случаев этой презентационной версии прототипа оказывается вполне достаточно.

Псевдореальная версия прототипа. В тех случаях, когда в интерфейсе появляются нестандартные элементы или необходимо проверить реальную скорость взаимодействия пользователя с системой, создается еще одна версия прототипа – реально выглядящая, но лишенная каких-либо алгоритмов и, соответственно, не показывающая реальных данных. Делать этот вариант можно как в средах разработки, благо в них есть визуальные инструменты создания интерфейсов, так и в редакторах изображений, что обычно быстрее. Фактически при этом создаются фальшивые снимки экрана, на которых и производят тестирование. Понятно, что как-то модифицировать эти экраны затруднительно, так что лучше не увлекаться такой работой, не получив каких-либо гарантий ее правильности. Эта версия прототипа больше соответствует этапу низкоуровневой разработки ПИ, но может применяться и на этапе высокоуровневой разработки (см. разд. 5.2.1).

Вместе с тем появились средства разработки прототипов, предельно близких к реальности. Сейчас имеется множество вполне доступных инструментальных средств, которые позволяют быстро создавать псевдореальные прототипы и моделировать разные ситуации. Эти средства значительно ускоряют разработку качественного ПО. Для компьютеров Apple Macintosh, например, таковым средством является широко известный и вполне успешный пакет HyperCard. Этот пакет во многом подобен другим инструментальным средствам анимации. В нем пользователь может создать графическое описание некоторой системы, скажем видеомагнитофона, обычными графическими средствами. Графические изображения сохраняются в картах, а создаваемые связи между картами управляют последовательностью предъявления карт, позволяя реа-лизовывать разные анимационные клипы. Помимо этой возможности HyperCard может моделировать достаточно сложные виды интерактивного поведения путем «прикрепления» к любому объекту определенных сценариев, написанных на языке HyperTalk. Так, для видеомагнитофона можно «прикрепить» сценарий к любой кнопке панели управления, чтобы пометить ее или даже сделать слышимым характерный шум видеомагнитофона, когда пользователь «кликает» мышью по его иконке. Тогда область функциональных возможностей этой кнопки отражается в специальном окне видеомагнитофона на экране. Наряду с пакетом HyperCard аналогичные возможности имеют и Macromedia Flash, и Director (см. выше).

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

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

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

Понятно, что прототип в таких условиях практически не будет отличаться от готового ПИ. Поэтому лучше всего написать нужные участки программы до создания всего остального и проводить юзабилити-тести-рование на реальной версии прототипа ПИ. Разумеется, прототип такой версии, если он все-таки разрабатывается, возможен только на этапе низкоуровневого проектирования (см. разд. 5.2.1).