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

5.1.6. Контрольные списки

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

Контрольный список (или checklist – «чек-лист») – это документ с перечнем требований к выполняемой работе. Каждому свойству готовой работы присваивается весовой коэффициент (например, отсутствие грамматических ошибок – 4%); работа считается выполненной, если сумма этих коэффициентов больше заданного числа (например, 97%). Благодаря этому исполнитель может не волноваться по поводу качества работы – он должен только соблюдать все изложенные в списке требования, а заказчик имеет возможность быстро проверить качество выполнения работы выборочно по отдельным пунктам.

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

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

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

Требования к контрольным спискам (равно как и многие вопросы че-ловеко-компьютерного взаимодействия) освещены на сайте http://www. usethics.ru/lib/software_checklist/index.shtml в статьях В. Головача и других.

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

Ниже приведен пример-шаблон контрольного списка для некоего пользовательского интерфейса:

ОКНА

1. Заголовки

• Заголовки короткие и адекватные содержимому окна.

• Заголовки соответствуют названиям элементов, при помощи которых окна были вызваны.

• Если окно вызывается элементом, не имеющим явного названия, в заголовке окна отражается название экранной формы.

2. Дизайн окна

• Тип окна (модальное, немодальное, возможность минимизации/ максимизации) был выбран осознанно, в соответствии с задачами пользователей.

• При проектировании было учтено, при каком разрешении, а также размере монитора и шрифтов будут работать пользователи.

• На растягивающихся окнах есть индикатор растяжимости.

• Управляющие и информационные элементы расположены достаточно далеко друг от друга.

• Информация в окне адекватно сгруппирована (связанные элементы объединены в группы).

• Кнопки находятся в секции, на которую они оказывают непосредственное воздействие. Терминационные кнопки (управляющие окном) расположены либо снизу в ряд, либо справа в колонку.

• Переход от элемента к элементу внутри окна осуществляется сверху вниз и слева направо.

3. Диалоговые окна

• В диалоговых окнах отсутствуют меню или инструментальные панели.

• Диалоговые окна открываются не в центре экрана, а в том месте, на которое в данный момент смотрит пользователь.

4. Строка статуса

• В строке статуса выводится только информация о текущем состоянии системы и кнопки (не выглядящие кнопками) для функций, предназначенных только опытным пользователям.

• Индикаторы выполнения выводятся в строке статуса. Исключение – окна-мастера, в них индикаторы выполнения можно выводить внутри самих окон.

МЕНЮ

1. Пункты главного меню

• Пункты меню имеют адекватные названия.

• Первая буква в названии пунктов заглавная.

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

• Все пункты первого уровня активизируют выпадающее меню.

• Каждому пункту меню назначены ALT-комбинации (общепринятые «горячие» клавиши выделены подчеркиванием). Эти комбинации должны быть по возможности стандартными.

• Недоступные в данный момент интерфейсные элементы заблокированы, а не скрыты.

2. Раскрывающиеся меню и элементы меню второго уровня

• Все элементы начинаются с заглавной буквы.

• Если в меню используются пиктограммы, они расположены слева от названия пункта меню.

• Пиктограммами снабжаются только самые часто используемые элементы.

• Высота меню не превышает размер экрана (меню не нужно прокручивать).

• Пункты меню адекватно сгруппированы. Осмысленно использованы разделители в меню.

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

• Используется не более двух подуровней меню.

• Каждый пункт меню имеет соответствующую «горячую» клавишу.

• Название пункта меню соответствует названию вызываемого окна.

• Пункты меню, открывающие диалоговые окна, обозначены в конце многоточием (.).

• Недоступные пункты меню обозначены серым цветом шрифта.

3. Всплывающие меню

• Каждому пункту всплывающего меню соответствует аналогичный пункт в основном меню.

• Элементы, открывающие вложенные меню, выглядят иначе, чем терминальные элементы.

4. Контекстные меню

• Для всех объектов интерфейса есть специфичное для каждого объекта контекстное меню.

• В контекстных меню не более 10 элементов.

• В контекстных меню элементы отсортированы по убыванию частоты их использования.

• Все элементы контекстных меню присутствуют и в других фрагментах интерфейса; нет команд, вызываемых только из контекстнъгх меню.

5. Инструментальные панели

• Каждому элементу инструментальной панели соответствует всплывающая подсказка.

• Элементы упорядочены и сгруппированы в соответствии с задачами

пользователей.

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

УПРАВЛЯЮЩИЕ ЭЛЕМЕНТЫ

1. Переключатели (Check boxes)

• В одном окне используется не более 10 переключателей.

• Переключатели сгруппированы, и каждой группе присвоено название.

• Внутри группы переключатели расположены строго вертикально.

• Переключатели не применяются для частого, оперативного использования.

• В названиях используется только позитивная, утвердительная форма.

• Ни один элемент не называется по-разному в разных местах (интерфейсный глоссарий не просто сделан в явной форме, но и выверен).

• В тексте всех подтверждений дается наименование объекта, над которым совершается подтверждаемое действие.

2. Командные кнопки (клавиши)

• Все кнопки, запускающие действия, имеют текст в инфинитивной форме глагола (пример: искать), а не другую часть речи либо форму глагола (пример: готово).

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

• Кнопки, которые выглядят одинаково, не могут быть в разных состояниях.

• Часто используемые кнопки снабжены не только текстом, но и пиктограммами, а редко используемые – только текстом.

• Кнопки имеют краткие и ясные названия.

• В каждом диалоге используется не более шести кнопок.

• Кнопки, выполняющие в разных диалогах идентичные функции, имеют одинаковые названия.

• Типовые кнопки имеют общепринятые названия и общепринятые «горячие» клавиши.

• Кнопки, вызывающие продолжение диалога во вложенных формах, обозначены многоточием (…).

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

• Опасные для пользователя кнопки не являются кнопками по умолчанию.

• Обработка формы запускается не только нажатием на термина-ционую кнопку, но и на клавишу «Enter» на последнем поле этой формы.

• Для наиболее частых элементов управления (включая меню) установлены клавиши быстрого вызова.

• Кнопка «Отмена» всегда самая правая.

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

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

• Кнопки находятся в области ПИ, к которой они непосредственно относятся.

• Терминальные кнопки (управляющие окном) расположены либо снизу в ряд, либо справа в колонку.

• Кнопки, относящиеся ко всему блоку вкладок, расположены за пределами блока.

3. Редактируемые поля со списком (Combo Box)

• Имеют функцию автовыбора.

4. Раскрывающиеся списки

• Высота выводимого на экран списка ограничена 3-8 элементами.

• Если список содержит более 50 элементов, используется фильтр или режим поиска.

• Если все элементы не умещаются в одном фрагменте списка, автоматически появляется полоса прокрутки.

5. Группы элементов

• Каждая группа имеет осмысленное название, помимо рамки отделена от других групп и элементов свободным пространством.

6. Подписи (Labels)

• Все элементы имеют подписи.

• Учтена возможность увеличения (уменьшения) длины подписей при использовании large fonts (small fonts).

• Подписи выровнены по левому краю поля (если они находятся над полем).

• Подписи расположены посередине высоты поля (если название находится сбоку).

• Если элемент недоступен, подпись отображается серым шрифтом.

7. Списки

• Все списки содержат более одного элемента.

• Любому списку предшествует, по меньшей мере, один абзац текста.

• Если список содержит более 50 элементов, используется фильтр или режим поиска. Если в списке более 50 отсортированных по алфавиту элементов, первыми тремя элементами являются наиболее часто используемые элементы. Они также повторяются на своих алфавитных местах.

• Высота ограничена 3-8 элементами.

• Если все элементы не умещаются, автоматически появляется полоса прокрутки.

• В списках уже стоят наиболее вероятные значения.

• Нет часто используемых коротких списков (менее пяти элементов); такие списки представлены как группы радиокнопок или чекбоксов.

• Ширина списков не меньше ширины входящих в них элементов.

• Элементы списка отсортированы либо структурно, т.е. по общим признакам, либо по алфавиту, либо по частотности (только списки меньше 7 элементов).

• Многострочные списки множественного выбора снабжены чекбок-сами возле каждого элемента (списки старого стиля отсутствуют).

• Если есть свободное место, используются расширенные комбобок-сы, а не однострочные.

8. Кнопки выбора (Option Buttons или Radio Buttons)

• В одной группе используется не более 6 кнопок.

• В пределах группы кнопки расположены по вертикали.

• Нет состояния, когда ни одна кнопка не выбрана.

• Последовательность расположения кнопок в группе учитывает частоту использования.

• Внутри группы кнопок одна обязательно установлена по умолчанию.

9. Вкладки (Tabs)

• Названия вкладок выровнены по центру.

• Каждой вкладке присвоено осмысленное название.

• Количество рядов закладок не превышает двух.

• Все связанные между собой данные находятся внутри одной закладки.

• Если окно или вкладка имеет автоматически пополняемое содержимое, например в нем перечислены приходящие сообщения, в названии элемента интерфейса, который открывает окно или вкладку, выводится число объектов в этом окне и отдельно – число новых объектов. Пример: Документы (8/3).

10. Текстовые поля ввода (Text Box or Edit Field)

• В полях ввода уже стоят наиболее вероятные значения.

• Если в поле вводится численное значение, границы диапазона выводятся во всплывающей подсказке.

• Если в поле вводится численное значение из ограниченного диапазона, поле снабжено «крутилкой» (Spinner).

• Длина полей не меньше и по возможности не больше длины вводимых в них данных.

• Если поле предназначено для ввода заметного количества текста, оно многострочное.

• Многострочные поля имеют максимально возможную высоту; нет резервов для их увеличения.

• Для недоступных полей используется серый цвет (название, текст и фон поля).

• В формах ввода нажатие табуляции ведет к правильной последовательности перемещения по форме.

• Содержимое полей выровнено по левому краю, за исключением полей с числовыми значениями (например, для вывода денежных сумм).

• Многостраничные формы организованы так, что пользователь всегда видит количество оставшихся экранов (пример: «Экран x из

• Во всех формах, служащих для сбора информации, есть пункты «Другое» и «Неприменимо» или подобные.

• В надписях отсутствуют жаргонизмы.

• В надписях отсутствуют отрицательные формулировки (например, надпись «Не показывать примечания» неприемлема, взамен нее нужно писать «Показывать примечания»).

• Для улучшения удобочитаемости длинные числа разбиваются неразрывным пробелом по три цифры: 1 234 567.

• Точка в конце фразы отсутствует в заголовке (если он отделен от текста), в конце подписи под рисунком и в таблице.

• Все поля, обязательные для заполнения, помечены, и есть соответствующее пояснение.

• Во всех формах, служащих для сбора информации, есть описание целей сбора данных, объясняется, что с этими данными будет сделано и что не будет.

• Подписи к интерфейсным элементам начинаются с прописной буквы и заканчиваются двоеточием.

11. Порядок табуляции фокуса ввода

• При открытии окна фокус попадает на элемент внутри окна.

• Схема табуляции соответствует очередности заполнения полей (слева направо, сверху вниз).

• Командные кнопки включены в табуляцию.

• Невидимые и недоступные элементы исключены из схемы табуляции.

• По нажатии клавиши «Tab» переход от элемента к элементу внутри формы осуществляется сверху вниз и слева направо.

• В таблицах все столбцы с цифрами выравниваются по правому краю.

12. Пиктограммы

• Направление теней во всех пиктограммах одинаково: снизу справа.

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

• Нет пиктограмм со стандартными значениями, но нестандартными сюжетами.

• В пиктограммах нет текста.

ВЗАИМОДЕЙСТВИЕ С ПОЛЬЗОВАТЕЛЕМ

• Система, завершив длительную операцию (больше минуты работы), пищит через встроенный динамик компьютера.

• Если в интерфейсе не используется непосредственное манипулирование, система не имеет своих курсоров. При непосредственном манипулировании свои курсоры применяются только в том случае, если аналогов из ОС не существует.

• Цифры, предназначенные для сравнения либо для копирования в буфер обмена, выводятся непропорциональным шрифтом.

СИСТЕМНЫЕ СООБЩЕНИЯ И ОТРАБОТКА ОШИБОК

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

• Сообщения о некорректности введенных данных показываются рядом с элементом управления, данные в котором некорректны.

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

• Текст сообщений о проблемах состоит из трех частей: в первой кратко описывается проблема, во второй части – как ее решить, в третьей описывается, как не допускать возникновения этой проблемы в дальнейшем.

• Статусные сообщения («Синхронизация успешно завершена») выводятся только в строке статуса.

5.2. Итерационная разработка и прототипирование ПИ

5.2.1. Общие положения и этапы разработки ПИ

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

1) придумывание воображаемых пользователей;

2) продумывание видов деятельности пользователей;

3) построение модели пользователя – как он будет осуществлять деятельность;

4) разработка первого наброска дизайна;

5) изменение дизайна в сторону упрощения до тех пор, пока продукт не окажется полностью в рамках возможностей воображаемых пользователей;

6) наблюдение за тем, как реальные пользователи работают с вашим продуктом. Определение областей, в которых они испытывают трудности. Эти области скорее всего и демонстрируют несоответствие моделей ПИ и пользователя.

Рис. 5.2. Последовательность разработки ПИ

Разработка ПИ, как и почти любая разработка, не свободна от давления заинтересованных лиц. Это давление влияет на темпы разработки (как правило, требуют все сделать поскорее) и, конечно, на решения по ПИ. Требуется иногда значительное упорство в отстаивании своих позиций. Недаром популярным остается лозунг разработчиков: «Дадим заказчику не то, что он хочет, а то, что ему действительно надо!» На рис. 5.3 показаны наиболее характерные «источники» давления на разработчика ПИ.

Рис. 5.3. «Источники» давления на разработчика ПИ

В конце 1990-х годов группа исследователей из Государственного университета Северной Каролины в США предложила семь базовых универсальных принципов любой разработки. Они были предназначены для охвата всех областей человеческой деятельности, в том числе и для интерактивных систем. Эти принципы дают направление для более конкретных разработок.

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

2. Гибкость в использовании. Разработка ориентирована на возможно широкий диапазон пользователей путем возможности выбора методов использования и адаптивности к скорости работы пользователя, к его точности и к другим его индивидуальным особенностям.

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

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

5. Устойчивость к ошибкам (минимизация ущерба от ошибок и непреднамеренных действий). Потенциально опасные ситуации не должны допускаться вообще или быть труднодостижимыми, кроме того, при возможности возникновения они должны сопровождаться заблаговременными предупреждениями.

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

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

Эти принципы задают определенные рамки для множества более конкретных разработок человеко-компьютерного взаимодействия. Конечно, не все они одинаково применимы ко всем ситуациям. Скажем, 6-й и 7-й принципы жизненно важны для информационных будок, но менее важны для текстовых процессоров. Но все они образуют крайне полезный для разработчиков «чек-лист», своего рода памятку вопросов, ответы на которые необходимы во всех случаях. Говоря очень обобщенно, особенностями дизайна интерфейса являются:

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

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

• интерфейс не самоценен. Опять сближение с книжным дизайном (никто ведь не покупает книгу из-за качества ее верстки);

• интерфейс передает информацию своему пользователю. Это опять сближает его с коммуникационным дизайном, и с книжным в частности. Интерфейс обычно предназначен для длительного использования. Это серьезно отличает его от графического дизайна вообще (никто не будет рассматривать журнальный разворот часами), но зато сближает опять с книжным дизайном и дизайном среды обитания;

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

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

Разработку ПИ можно разделить на четыре основных этапа:

1) начало работы над проектом;

2) постановка задачи;

3) высокоуровневое проектирование;

4) низкоуровневое проектирование.

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

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

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

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

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

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

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

• характеристики пользователей – их опыт работы с компьютером, знание предметной области, мотивы, размер/важность групп пользователей, образцы (типовые ситуации) использования;

• цели и задачи пользователей;

• задачи проекта – что послужило причиной создания проекта, этапы создания проекта, какие результаты должны быть получены, какая информация необходима и когда;

• технологии разработки и платформа, на которой будут работать пользователи;

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

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

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

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

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

• надо снизить количество человеческих ошибок.

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

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

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

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

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

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