- •Содержание практического цикла
- •Практическое занятие 1 процесс проектирования пользовательского интерфейса. Начало работы над проектом Теоретические сведения
- •1 Оценка объема предметной области
- •2 Изучение предметной области
- •3 Экспертная оценка текущего интерфейса системы
- •Практическое занятие 2 процесс проектирования пользовательского интерфейса. Постановка задачи Теоретические сведения
- •1 Формализация контекста использования
- •2 Формализация объективных критериев успеха
- •3 Анализ целей
- •4 Формализация бизнес-ролей пользователей
- •5 Формализация функциональности
- •6 Формализация сценариев действий пользователей
- •7 Обзор интерфейса конкурирующих систем
- •8 Формализация привычек и ожиданий пользователей
- •Практическое занятие 3 процесс проектирования пользовательского интерфейса. Высокоуровневое проектирование Теоретические сведения
- •1 Проектирование структуры экранов системы
- •2 Проектирование навигационной системы
- •3 Проектирование второстепенных экранов
- •4 Финальное тестирование
- •Практическое занятие 5 построение прототипа пользовательского интерфейса Теоретические сведения
- •1 Этапы построения прототипа
- •2 Первая версия. Бумажная
- •3 Вторая версия. Презентационная
- •4 Третья версия. Псевдореальная
- •5 Четвертая версия. Реальная
- •Практическое занятие 6 юзабилити-тестирование. Подготовка и проведение тестирования Теоретические сведения
- •1 Подготовка к тестированию
- •1.1 Цели исследования
- •1.2 Проектирование исследования
- •1.3 Подбор участников тестирования
- •1.4 Подготовка необходимого инструментария
- •1.5 Подготовка тестовой группы
- •2 Проведение тестирования
- •2.1 Подготовка участника к тестированию
- •2.2 Действия ассистента во время тестирования
- •2.3 Действия наблюдателя во время тестирования
- •1.2 Отчет о наблюдении
- •1.3 Анализ полученных данных
- •2 Методики тестирования
- •2.1 Метод фокусных групп
- •2.2 Проверка посредством наблюдения за пользователем
- •2.3 Мыслим вслух
- •2.4 Проверка качества восприятия
- •2.5 Измерение производительности
- •2.6 Карточная сортировка
- •3 Контрольные списки
- •3.1 Контрольный список интерфейса по
- •1. Окна
- •2. Заголовки
- •3. Дизайн окна
- •4. Диалоговые окна
- •5. Меню
- •6. Инструментальные панели
- •7. Управляющие элементы
- •8. Взаимодействие с пользователем
- •3.2 Контрольный список Веб-интерфейса
- •4 Методики
- •4.1 Предсказание скорости
- •4.2 Измерение эффективности интерфейса
- •4.3 Определение пользовательских профилей
2 Формализация объективных критериев успеха
На этом этапе выделяются объективные критерии оценки эргономичности интерфейса, такие как показатели эффективности, продуктивности, удовлетворенности пользователей (на более ранних этапах выделить эти критерии невозможно).
Соответственно, на данном этапе создается реальное задание на проектирование интерфейса. Например:
– Группа пользователей постоянно меняет свой состав, и предполагаемый образец использования используется нечасто. Необходимо акцентировать внимание на простоте понимания интерфейса.
– Одна и та же задача повторяется многократно, а группа пользователей довольно большая. Необходимо акцентировать внимание на эффективности использования.
– на 20% снизить количество человеческих ошибок.
На входе: доступ к пользователям, экспертам и проектной документации.
На выходе: список объективных критериев успеха.
3 Анализ целей
Разработчику необходимо четко осознавать, что пользователям не нужны инструменты сами по себе, нужны лишь результаты их работы. Никому не нужен текстовый процессор – нужна возможность с удобством писать тексты. Никому не нужна программа обработки изображений – нужны уже обработанные изображения. Это значит, что сами по себе функции никому не нужны и не важны. Людям нужно средство вообще, делающим возможным выполнять какую-либо работу.
Разницу подходов к выбору функциональности удобно проиллюстрировать на примере тостера. Стандартный подход, при котором функции выбираются фактически произвольно, в лучшем случае приведет к такому заданию: «Нужен ящик с узкой прямоугольной дыркой и нагревателем внутри». Анализ целей пользователя приведет к другой формулировке: «Нужен поджаренный хлеб. Похоже, что проще всего добиться этого созданием ящика с дыркой по форму куска хлеба и нагревателем внутри. С другой стороны, похоже, что этот способ не единственный». Второй вариант при полном развитии этого метода может привести не только к созданию тостера, но и также и ростера (т.е. устройства, в котором можно поджаривать не только хлеб).
Результатом этого процесса должен являться список целей, например, для тостера финальный список целей должен выглядеть очень просто: «Должен поджаривать мелкие кусочки пищи, преимущественно хлеб».
На выходе: рекомендации по оптимизации интерфейса, перечень удачных и неудачных интерфейсных решений (основное внимание уделяется решениям не удачным). Если на этом этапе проводилось юзабилити-тестирование текущей версии, отчет содержит краткие протоколы и перечень выводов исследования.
На входе: доступ к пользователям, экспертам и проектной документации
На выходе: перечень целей внедрения нового интерфейса с весовыми характеристиками каждой.
4 Формализация бизнес-ролей пользователей
Функциональность любой системы разделяется на несколько ролей пользователей: разным пользователям нужны разные блоки функциональности (в системах автоматизации эти роли называются бизнес-ролями). Навигация по системе прямо зависит от этих ролей, поскольку в пределах одной роли в навигацию не желательно включать функции из чужой роли. Соответственно, на этом этапе выделяются основные роли пользователей с относящимися к этим ролям функциям. Так же, на этом этапе проводятся собеседования с каждым из представителей определенной роли на предмет выявления особенностей данной роли и выяснения, какие дополнительные (по отношению к формальным) возможности следует предусмотреть.
На этом этапе можно применять метод наблюдения за людьми, выполняющими свою задачу, пользуясь уже имеющимися инструментами, и именно система конкурентов (если они есть) и предметами реального мира. Неплохим источником материала для анализа часто служит даже не наблюдения за людьми, но анализ результатов их работы – если оказывается, что результат работы практически не зависит от используемого инструмента, это значит, что нужна только та функциональность, которая оказала воздействие на результат (т.е. функции, которыми никто не воспользовался, не нужны).
Обычно есть несколько разных способов реализации одной и той же функции. Анализ действий пользователей как раз и позволяет определить, какой именно способ следует реализовать. Поскольку на этом этапе мы узнаём, какая именно функциональность нужна для каждой бизнес-роли, можно избрать верный путь по правилу «чем меньше действий требуется от пользователя, тем лучше».
На входе: доступ к пользователям, экспертам и проектной документации, знание основных аспектов предметной области.
На выходе: описание бизнес-ролей пользователей.