Чтобы диагностировать непонятный интерфейс приложения, рассматривайте его экраны, элементы управления и отклики, пока человек пытается выполнить поддерживаемую приложением задачу. Найдите первую точку, где следующее действие становится неясным. Сравните ожидания человека с тем, что приложение делает и сообщает. Для неудачного сохранения или отсутствующей функции нужно иное исправление, чем для неясной подписи или маршрута.
Представьте, что человек пытается изменить уже существующую запись. Он открывает несколько меню, возвращается на главный экран и спрашивает коллегу. Такая последовательность служит отправной точкой для наблюдения. Сама по себе она не объясняет, удалит ли человек приложение позднее и какой экран требует переработки.
Почему люди теряют следующий шаг?
Человек может понимать цель, но не заметить неясное действие или отклик. Мы ищем первое видимое расхождение между намеченной задачей и открывшимся экраном. Не делайте окончательных выводов, пока не проверите операцию. То, что выглядит как проблема навигации, может оказаться неудачным запросом или результатом, который продукт не поддерживает.
Формулировка предполагает другое действие. После нажатия Продолжить человек может ожидать еще один экран проверки, хотя приложение сразу отправляет запрос. Руководство Apple по кнопкам рекомендует ясно обозначать назначение. Прежде чем выбирать новую подпись, сравните ожидание с реальным эффектом.
Результат остается неясным. Человек нажимает повторно, потому что не понимает, приняло ли приложение запрос. Проверьте, что действительно сохранилось и что сообщил экран. Отсутствующее подтверждение и неудавшаяся операция требуют разных исправлений.
Подсказка по вводу появляется после ошибки. Проверьте, объясняет ли поле, какое значение требуется.
Для веб-контента критерий W3C о подписях или инструкциях требует предоставлять их, когда контент предполагает ввод. Используйте этот источник для веб-экранов внутри приложения. Нативным приложениям нужна отдельная проверка по правилам платформы.
Маршрут теряет контекст. Человек возвращается с экрана подробностей и не может снова найти изменяемую запись. Зафиксируйте исходную точку, выбранное действие и итоговый экран. Опишите первый непонятный переход достаточно точно, чтобы его можно было воспроизвести.
Как диагностировать непонятный интерфейс приложения?
Начните с поддерживаемого результата и сопоставимого исходного состояния. Для действий, которые что-либо отправляют, списывают оплату, удаляют или затрагивают другого человека, используйте тестовую учетную запись и безопасные тестовые данные. Опишите цель, не называя ведущее к ней меню или элемент управления. Нужно узнать, что человек способен найти и понять до ваших объяснений.
- Определите завершение. Для изменения записи намеченным результатом будет отправленный запрос или подтвержденная новая запись? Проверьте, какой результат поддерживают эта версия и учетная запись.
- Зафиксируйте исходное состояние. Укажите версию приложения, устройство, язык, разрешения и наличие существующей записи. В учетной записи администратора может быть другой маршрут, чем в учетной записи клиента.
- Наблюдайте, не называя элемент управления. Попросите человека попытаться достичь цели. Запишите выбранный экран, прочитанную подпись и ожидание. Если вы помогаете, зафиксируйте помощь: последующее завершение ее не отменяет.
- Проверьте результат отдельно. Сравните видимый отклик с сохраненной записью. Снова откройте ее в тестовой учетной записи или проверьте тестовую запись поставщика. Нажатие или экран, похожий на сообщение об успехе, не доказывает, что намеченное обновление произошло.
Если вы проверяете приложение самостоятельно, фиксируйте то, что можете воспроизвести, и явно указывайте это ограничение. Ваше знание продукта меняет выполнение задачи. Последующее наблюдение за незнакомым с продуктом человеком даст доказательства другого рода.
Разберите вымышленную задачу изменения записи
Рассмотрим вымышленное приложение для записи на занятия, в котором можно запросить другое занятие. Поставщик должен принять запрос, прежде чем запись изменится. Следующие заметки показывают, как исследовать недопонимание. Для этого примера мы не использовали действующее приложение, учетную запись или участника и не тестировали предложенные формулировки.
| Наблюдение | Примечание |
|---|---|
| Намеченная задача | Перенести существующую запись на другое занятие. |
| Действие и точная подпись | Человек нажимает Изменить запись; кнопка отправляет запрос. |
| Ожидаемый результат | Человек считает, что новое занятие уже забронировано. |
| Фактическое состояние | Исходная запись сохраняется, пока запрос ожидает принятия. |
| Предлагаемая проверка | Испытать Запросить изменение и сообщение об отправке запроса. |
Наблюдаемое расхождение касается смысла действия. Другая подпись является гипотезой, которую нужно проверить с учетом фактической операции. Если запрос не доходит до поставщика, отдельно исследуйте сбой операции. Если продукту принципиально важно немедленное подтверждение, это отдельное продуктовое решение, которого нельзя добиться подписью кнопки.
Записывайте наблюдение до его интерпретации. “Открыл запись, нажал Изменить запись и ожидал подтверждения” описывает поведение в этом вымышленном упражнении. “Интерфейс плохой” обходит вопрос, на который еще предстоит ответить.
Внесите минимальное изменение, отвечающее наблюдению
Выберите исправление, которое устраняет зафиксированное расхождение и сохраняет намеченную операцию. Если неопределенность связана с формулировкой, инструкциями или откликом, начните с них. Изменение структуры навигации или более масштабная переработка требуют причины, основанной на задаче. Не скрывайте функциональные сбои: более ясное объяснение не должно маскировать операцию, которая по-прежнему не выполняется.
-
Подготовьте макет для этой задачи. Для вымышленной записи покажите предлагаемую подпись действия и итоговое состояние в интерактивном макете. Наши аудиты и прототипы UX приложений следуют этой последовательности от задачи к прототипу. Сравните ожидание человека до нажатия с состоянием, которое он распознает после; не называйте предложенную подпись доказанным улучшением.
-
Проверьте сценарий ошибки. Критерий W3C об идентификации ошибок для веб-контента требует, чтобы автоматически обнаруженная ошибка ввода указывала на затронутый элемент и описывалась текстом. Одной цветной рамки для этого объяснения недостаточно. Нативные элементы управления и полная проверка доступности требуют отдельных проверок по правилам платформы.
-
Проверьте отклик на экране и с помощью вспомогательных технологий. Для веб-контента критерий W3C о сообщениях состояния предусматривает доступность определенных изменений состояния для вспомогательных технологий без перемещения фокуса с текущего элемента управления. Проверьте, что появляется на экране и что могут определить вспомогательные средства. Например, программа экранного доступа может читать содержимое интерфейса вслух. Этот отдельный критерий не сертифицирует приложение, не задает целевое время отклика и не исправляет медленную операцию.
-
Проследите переход в веб-среду. Если маршрут той же учетной записи или записи переходит на веб-страницу, включите этот переход в проверку. Разработка сайтов и веб-приложений должна сохранять формулировки задачи и фактическое состояние на этой границе.
Что проверить после изменения?
Повторите ту же намеченную задачу из сопоставимого состояния и зафиксируйте произошедшее. Укажите рядом с результатом версию приложения, устройство, язык и оказанную помощь. Полезное сравнение относится к наблюдаемой задаче: нашел ли человек действие, понял ли его эффект и распознал ли фактический результат. Не делайте более широких бизнес-выводов, пока не появятся подтверждающие данные.
Фиксируйте завершение вместе с помощью, первый неверный поворот, ошибки ввода, которые человек не смог понять, и случаи, когда запрос был принят за подтверждение. Повторяйте нужные проверки с исследуемыми языковыми настройками и настройками доступности. Проверяйте более длинные подписи и информацию, доступную при этих настройках, не предполагая, что английский экран представляет все версии.
Если вы уже регистрируете действия приложения, например начало запроса на изменение записи или его поступление поставщику, убедитесь, что записи соответствуют этим фактическим состояниям. Сопоставляйте изменения в обращениях в поддержку с тем же маршрутом. Отсутствие скачиваний приложения является отдельной проблемой привлечения; наше руководство о приложении без скачиваний начинается до открытия продукта.
Успешное повторное выполнение позволяет описать это наблюдение. Оно не устанавливает, почему люди удаляют приложение, и не позволяет приписать исправлению изменение удержания. Зафиксируйте следующий нерешенный вопрос вместе с ответственным за его проверку.
Чем мы можем помочь
Мы начинаем с поддерживаемой задачи, первого непонятного перехода и доказательств, необходимых для выбора исправления. Мы можем превратить это в прототип, проверить реализованный маршрут и включить его веб-версию. Принесите описание задачи и точки остановки на обсуждение проекта. Удалите имена клиентов и другие персональные данные из любого примера, которым делитесь.
