Анализ задач

Когда использовать

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

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

Не путайте анализ задач с разбором должности одного сотрудника во времени и с разбором того, как работу делят несколько человек. Это другие методы. Анализ задач смотрит на одного пользователя и его цель.

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

Что нужно для старта

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

Как провести

1. Цель и задачи

   Отделите цель от задачи. Задача — наблюдаемое действие с началом и концом. Цель — результат, ради которого человек действует. Выберите одну цель и одного пользователя. Выясните четыре вещи. Что запускает задачу, какого результата человек ждёт, какие знания ему нужны и какие материалы или инструменты.

2. Наблюдение

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

3. Фиксация шагов

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

4. Иерархия

   Верхний уровень — цель, ниже задачи, ещё ниже подзадачи. Нумеруйте узлы. К каждому уровню запишите план, то есть в каком порядке и при каких условиях выполняются части. Бывают последовательные, условные и повторяющиеся планы.

5. Глубина

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

6. Что отметить

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

7. Вывод для дизайна

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

Результат

Схема на каждую цель. Это может быть список, блок-схема или иерархическая диаграмма с последовательностью подзадач, планами и отметками, где люди принимают решения и ошибаются. Её держат как живой документ и обновляют по мере исследований. К схеме прикладывают выводы: какие шаги лишние, где интерфейс расходится с реальной работой.

Типичные ошибки

• Задачу принимают за цель

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

• Опираются на слова и разыгранные сценарии

  Люди рассказывают об идеальном процессе. Реальный виден только при наблюдении в среде.

• Пропускают редкие ветки

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

• Считают пользователей одинаковыми

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

• Пытаются описать всё

  Все факторы, влияющие на задачу, учесть нельзя. Остановитесь, когда дальнейшая детализация не даёт выводов для дизайна.

• Начинают слишком поздно

  Анализ задач начинают в ходе исследования пользователей, пока основные решения по дизайну не приняты.

• Проектируют вокруг неверной проблемы

  Если решение не совпадает с реальными задачами людей, даже хороший интерфейс не сработает.