Компонент получает смысл в сценарии
Одинаковая кнопка может создавать запись, подтверждать изменение или закрывать окно. Её подпись должна помогать понять действие в конкретном месте. Важно также определить результат нажатия и возможность исправить ошибку. Если внешний вид выбран раньше сценария, в макете легко появляются элементы без ясного назначения. Для списка заметок полезно сначала описать простую последовательность: открыть список, выбрать запись, изменить текст и увидеть подтверждение сохранения. Затем подбирают элементы, которые поддерживают эти действия. Готовая библиотека не освобождает от объяснения каждого перехода.
Состояния показывают, что происходит
Пустой список отличается от списка, который ещё загружается, и от ошибки получения данных. Если все три случая выглядят как пустой экран, человеку приходится угадывать причину. Полезно заранее определить, какую информацию сообщает каждое состояние и какое действие доступно дальше. Сообщение об ошибке должно быть понятным, а не состоять только из технического кода. При повторном действии важно не создавать впечатление, что прошлое нажатие пропало без следа. Даже на бумажном прототипе можно проверить, достаточно ли обратной связи и не возникает ли бессмысленного повторения одних шагов.
Доступность меняет геометрию
В iOS люди могут увеличивать размер текста с помощью Dynamic Type, поэтому макет следует проверять с более длинными строками и крупными надписями. Жёстко заданная высота способна обрезать важное сообщение. Также нельзя передавать значение только цветом: признак ошибки или выбранного состояния должен оставаться понятным и другими способами. Контраст, расположение элементов и понятные подписи работают вместе. Использование стандартно выглядящего компонента само по себе не подтверждает доступность всего экрана. Необходимо проверить его в контексте, включая порядок чтения и взаимодействие с вспомогательными технологиями.
Попробуйте на практике
Нарисуйте четыре состояния вымышленного списка заметок. Для задания не нужны дизайн-программа, устройство Apple или готовый набор компонентов.
- Создайте обычный экран с тремя заметками и одной понятной основной кнопкой. Запишите, какой результат она должна давать.
- Нарисуйте пустое состояние и отдельно состояние загрузки. Укажите, чем пользователь различает их без догадки.
- Добавьте экран ошибки с ясным объяснением и осмысленным следующим действием. Не ограничивайтесь красным цветом или техническим номером.
- Увеличьте надписи и замените короткое название заметки длинным. Проверьте, сохраняются ли важные сведения и доступность действий.
- Пройдите сценарий по бумажным экранам и отметьте переход, в котором не хватает подтверждения результата. Исправьте его.
Как проверить результат. Прототип готов, если четыре состояния различимы, кнопки имеют понятное назначение и крупный текст не уничтожает смысл. Внешняя согласованность элементов должна поддерживать сценарий, а не заменять его.
Частые вопросы
Можно ли взять набор компонентов и считать дизайн завершённым?
Нет. Набор задаёт часть визуальных решений, но данные, состояния и действия относятся к конкретному приложению. Их необходимо спроектировать и проверить отдельно.
Почему длинный текст стоит проверять заранее?
Он обнаруживает зависимость от случайно удобного примера. Реальные названия, переводы и настройки размера текста могут отличаться, поэтому устойчивый макет должен учитывать такие изменения.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.