Интерфейс мобильного приложения: правила удобных экранов

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

Начинайте со сценариев, а не с красоты

Перед рисованием перечислите три-пять главных действий пользователя. Для доставки еды — найти блюдо, оформить заказ, отследить курьера. Каждое главное действие должно быть достижимо за минимальное число касаний с главного экрана. Всё остальное вторично.

Навигация

• Нижняя панель вкладок подходит, когда разделов от трёх до пяти и пользователь часто переключается между ними.
• Боковое меню прячет разделы, поэтому ими пользуются реже. Годится для второстепенного.
• Глубина — старайтесь, чтобы до любой важной функции было не больше трёх уровней.
• Кнопка назад должна вести туда, куда ожидает пользователь, а на Android — работать системный жест и кнопка.

Зона большого пальца

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

Размеры и отступы

Кнопки и другие активные элементы должны быть достаточно крупными, чтобы в них уверенно попадал палец. Apple и Google в своих рекомендациях задают минимальные размеры касаемых областей — дизайнеру стоит на них опираться. Между соседними кнопками нужен отступ, иначе пользователь будет промахиваться.

Гайдлайны платформ

У Apple есть Human Interface Guidelines, у Google — Material Design. Это не догма, но они описывают ожидания пользователей: где искать кнопку назад, как выглядят переключатели, как работают системные листы. Если вы делаете одно кроссплатформенное приложение, решите, какие элементы адаптировать под каждую платформу.

Формы

Формы — место, где теряется больше всего пользователей.

1. Спрашивайте только необходимое. Каждое поле — повод уйти.
2. Подставляйте подходящую клавиатуру: цифровую для телефона, с собачкой для почты.
3. Подсказывайте формат прямо в поле: номер в формате +998.
4. Показывайте ошибку рядом с полем и сразу, а не после отправки всей формы.
5. Сохраняйте введённое, если пользователь случайно вышел.

Состояния экрана

Каждый экран существует в нескольких состояниях, и все их нужно нарисовать:

• Загрузка: скелетон или индикатор
• Пусто: что сказать человеку, у которого ещё нет заказов, и куда его направить
• Ошибка: понятный текст и кнопка повторить
• Нет сети: что доступно офлайн
• Частичные данные: длинные названия, отсутствующие фото

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

Тексты в интерфейсе

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

Доступность и читаемость

• Достаточный контраст текста и фона
• Поддержка увеличенного системного шрифта
• Не передавать смысл только цветом: статус «отклонено» — это и цвет, и слово
• Подписи для иконок, если их значение не очевидно

Проверка на людях

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

Чек-лист перед передачей в разработку

• Нарисованы все состояния экранов
• Проверены оба языка в макетах
• Есть дизайн-система: цвета, шрифты, компоненты
• Описаны анимации и переходы
• Учтены маленькие и большие экраны

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