В этой статье
Scott
Когнитивный проход (cognitive walkthrough) помогает оценить, сможет ли новый пользователь разобраться в каждом шаге задачи. Специалисты предполагают, какие трудности возникнут при освоении интерфейса, и записывают замечания для последующей проверки с пользователями.
Подготовить экраны и обсудить замечания можно в рабочем пространстве для UX-дизайна. Начните с одной законченной задачи. В примере ниже читатель заказывает книгу для получения в библиотеке. Ключевое различие — между отправкой заказа и сообщением о том, что книгу уже можно забрать.
Когда проводить когнитивный проход
Используйте метод для незнакомого сценария, в котором новичку нужно самостоятельно понять дальнейшие действия. Эвристическая оценка проверяет более общие принципы удобства. На юзабилити-тесте наблюдают за участниками; когнитивный проход предполагает, где у них возникнут трудности.
Четыре вопроса ниже опираются на метод когнитивного прохода Nielsen Norman Group (на английском). Библиотечный сценарий — учебный пример, а не отчёт об исследовании.
Предположим, что читатель знает, какая книга ему нужна, и уже имеет учётную запись библиотеки, но ещё ни разу не заказывал книгу онлайн. Он понимает, что филиал — это конкретная библиотека, но не знает внутренних терминов сервиса. Эти условия важны: сотрудник, который ежедневно работает с каталогом, прочитает те же подписи иначе.
Определите задачу и реальный результат
Сформулируйте задачу словами читателя: «Закажите эту книгу, чтобы забрать её в Центральном филиале». Результат — оформленный заказ нужной книги в нужный филиал и понятное объяснение дальнейших действий. Это ещё не получение книги и не подтверждение того, что экземпляр уже ждёт читателя.
Подготовьте четыре состояния: карточку книги, выбор филиала, проверку заказа и подтверждение. Покажите название книги, филиал, доступность и сведения, от которых зависит решение. Если прототип начинается после входа в учётную запись, зафиксируйте это начальное условие. Нельзя незаметно пропустить авторизацию, а затем считать проверенным весь путь заказа.
Подготовьте также вариант, в котором книгу нельзя заказать. Если рассматривать только случай немедленной доступности экземпляра, самые сложные формулировки останутся без проверки. В основном примере книгу заказать можно, но её нужно доставить из другого филиала. Поэтому интерфейс должен различать успешное оформление заказа и готовность к выдаче.
Задавайте четыре вопроса для каждого значимого действия
- Цель: поймёт ли читатель, как действие помогает выполнить задачу?
- Заметность: заметит ли он нужный элемент управления?
- Смысл: свяжет ли подпись элемента с ожидаемым результатом?
- Обратная связь: после действия поймёт ли он, что изменилось и что делать дальше?
Используйте только сведения, доступные на экране. Если проверяющему нужно пояснение дизайнера, запишите, что именно осталось непонятным в интерфейсе.
Рассматривайте значимые решения отдельно. Выбор филиала для получения требует отдельного шага; движение указателя — нет.
Пример: заказ книги в библиотеке
1. Найти действие заказа
На странице книги написано «Есть в другом филиале», а кнопка называется «Отправить запрос». Читатель хочет забрать экземпляр в Центральном филиале. Кнопка хорошо видна, поэтому основная проблема не в заметности. Смысл менее ясен: запрос закажет книгу, отправит вопрос сотруднику или предложит купить новое издание?
Более конкретный вариант — «Заказать для получения», после которого открывается выбор филиала. Сведения «Есть в другом филиале» стоит сохранить. Если убрать доступность ради краткости, следующий выбор станет сложнее. Замечание должно указывать на неоднозначность действия, а не просто предлагать увеличить кнопку.
2. Выбрать место получения
Следующий экран показывает Центральный, Прибрежный и Северный филиалы. Над списком написано «Местоположение», а выделен филиал, где сейчас хранится экземпляр. Новый читатель может решить, что только там и разрешено забрать книгу.
Разделите место хранения и место получения. Назовите поле «Филиал для получения», сделайте Центральный доступным для выбора и объясните доставку, если она влияет на срок. Специалист должен указать конкретный текст, на котором основано такое понимание. Если сервис не доставляет книги между филиалами, интерфейс должен учитывать это правило, а не предлагать недоступный вариант.
3. Проверить заказ перед отправкой
Экран проверки должен повторять выбранную книгу и филиал получения. Допустим, название книги есть, а филиала нет. Читатель не может убедиться, что предыдущий выбор сохранился. Это недостаток обратной связи между шагами, даже если кнопка отправки работает.
Добавьте филиал и возможность изменить его до оформления заказа. При возвращении из списка филиалов сохраняйте выбранную книгу. Так состояние становится видимым, а исправление не запускает весь процесс заново без предупреждения.
4. Понять результат
Сообщение «Готово!» не объясняет, нужно ли уже идти в библиотеку. Для нашего сценария понятнее: «Заказ принят. Заберите книгу в Центральном филиале после уведомления о готовности к выдаче». Рядом покажите название книги и ссылку на сведения о заказе.
Различие имеет практическое значение. Принятый заказ не означает немедленную доступность книги. Если срок неизвестен, объясните, какое уведомление придёт, вместо выдуманной даты получения. Более позднее состояние «Готово к выдаче» должно отличаться по формулировке от первоначального подтверждения заказа.
5. Проверить недоступный вариант
Если доступных для заказа экземпляров больше нет, не показывайте экран успеха. Объясните, что заказ не создан, сохраните выбранную книгу и предложите полезное следующее действие — например, посмотреть другое издание, если сервис это поддерживает. Одного «Попробуйте ещё раз» недостаточно, когда повтор не меняет доступность.
Запишите эту ветку отдельно. Удобный основной путь не устраняет проблему заблокированного варианта. При этом отсутствие ответа сервера в прототипе — ограничение самого прототипа, а не доказательство неправильной работы реального библиотечного сервиса.
Записывайте замечания так, чтобы по ним можно было принять решение
Отводите каждой проблеме отдельную строку. Разделяйте наблюдаемое состояние экрана, предполагаемое затруднение и предложенное изменение. Тогда разработчик или исследователь сможет оспорить объяснение, не потеряв исходное наблюдение.
| Шаг и видимое состояние | Возможная трудность | Изменение и дальнейшая проверка |
|---|---|---|
| Карточка книги: «Отправить запрос» | Читатель не понимает, начнётся ли оформление заказа. | Назвать действие по задаче; проверить, понимают ли его новые читатели без пояснений. |
| Выбор филиала: «Местоположение», выделено место хранения | Читатель может спутать место хранения с местом получения. | Разделить понятия и явно показать условия доставки между филиалами. |
| Подтверждение: «Готово!» | Читатель может прийти раньше, чем книга будет готова к выдаче. | Различить принятый заказ и готовность к выдаче; проверить понимание результата. |
Расставляйте приоритеты по последствиям для этой задачи. Напрасная поездка в библиотеку важнее небольшого нарушения выравнивания. Если частота проблемы неизвестна, так и запишите, не придумывая процент. При разногласии специалистов выясните исходное предположение: например, пользовался ли читатель раньше другой системой заказа книг.
Подготовьте и обсудите сценарий в Pixso
Разместите карточку книги, выбор филиала, проверку и подтверждение на отдельных фреймах. Соедините нужные действия, включая возвращение к выбору филиала и недоступный вариант. Задайте подходящую начальную точку и откройте презентацию. Проверяющий должен видеть те же сведения, что и предполагаемый читатель, а не начинать с финального экрана.
Привяжите комментарий к нужной подписи или состоянию и укажите шаг из таблицы замечаний. Поместите предложенную формулировку рядом с соответствующим фреймом, чтобы команда могла сравнить варианты. Комментарии фиксируют обсуждение, но сами по себе не доказывают, что новичок успешно выполнит задачу.
С помощью инструментов прототипирования покажите изменения и повторите ту же задачу с исходного состояния. Убедитесь, что новая подпись выбора филиала, экран проверки и итоговое сообщение согласованы. Если изменить текст только на одном экране, в сценарии могут остаться противоречия.
Проверьте наиболее важное предположение с пользователями
Проблема подтверждения даёт конкретный вопрос для следующего исследования: понимает ли новый читатель после заказа, когда идти в библиотеку? Попросите его заказать книгу и объяснить дальнейшие действия. Не говорите в самом задании, что нужно дождаться уведомления: иначе вы заранее сообщите проверяемый ответ.
Используйте задания юзабилити-теста, сформулированные через цель, чтобы инструкции оставались нейтральными. Если участники по-прежнему неверно понимают результат, пересмотрите сообщение вместе со сведениями о сроках. Если результат понятен, но позднее не удаётся найти заказ, это другая задача, для которой нужен отдельный проход.
Полезный когнитивный проход заканчивается улучшенным сценарием и несколькими ясными вопросами для проверки. В библиотечном примере главное — последовательно различать выбор места получения, оформление заказа и готовность книги к выдаче. Дополнительные экраны или анимация сами по себе эту неоднозначность не устранят.
