Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
методические указания по выполнению практически...doc
Скачиваний:
17
Добавлен:
08.05.2019
Размер:
429.57 Кб
Скачать

2 Формализация объективных критериев успеха

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

Соответственно, на данном этапе создается реальное задание на проектирование интерфейса. Например:

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

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

– на 20% снизить количество человеческих ошибок.

На входе: доступ к пользователям, экспертам и проектной документации.

На выходе: список объективных критериев успеха.

3 Анализ целей

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

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

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

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

На входе: доступ к пользователям, экспертам и проектной документации

На выходе: перечень целей внедрения нового интерфейса с весовыми характеристиками каждой.

4 Формализация бизнес-ролей пользователей

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

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

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

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

На выходе: описание бизнес-ролей пользователей.