Анализ задач¶

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

Задача, сценарий и операция¶

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

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

Как формулировать задачи¶

Хорошая формулировка задачи содержит ситуацию, мотив и ожидаемый результат, например: «Когда приходит запрос на возврат, я хочу быстро понять, положен ли он клиенту, чтобы ответить в тот же день». Такой формат, близкий к подходу Jobs to Be Done, удобен тем, что сразу задаёт критерии оценки: здесь важны скорость и наличие всей информации для решения на одном экране, а вовсе не количество доступных действий с заказом.

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

Популярность и критичность¶

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

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

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

Сценарий включает отклонения¶

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

Проверка результата¶

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