Мобильное приложение оценивают в первые минуты: понятно ли, что делать на экране, и не приходится ли гадать, куда нажать. Ниже разобран порядок, в котором мы проектируем интерфейсы мобильных приложений — от сценариев до проверки на реальных устройствах. Это не перечень приемов из подборок, а те решения, которые чаще всего определяют, останется человек в приложении или закроет его.
Начинаем со сценариев, а не с набора экранов
Проектирование начинается не с макета главного экрана, а со списка задач, ради которых человек открывает приложение. Для сервиса доставки это «повторить прошлый заказ» и «узнать, где курьер»; для банковского приложения — «перевести по номеру телефона» и «посмотреть, куда ушли деньги». Каждый такой сценарий мы расписываем по шагам и считаем количество действий от запуска до результата.
Дальше сценарии ранжируются по частоте. Частый сценарий должен быть доступен с первого экрана без погружения в меню, редкий — может жить в настройках. Ошибка, которую мы регулярно встречаем при аудите: все функции вынесены на верхний уровень, потому что каждая казалась заказчику важной. В результате главный экран превращается в справочник, а основное действие теряется среди второстепенных.
- Одна цель на экран: если целей две, чаще всего это два экрана.
- Основное действие — заметная кнопка, второстепенное — текстовая ссылка.
- Все, что можно не спрашивать у пользователя, не спрашиваем: подставляем из профиля, из прошлого заказа, из геопозиции.
- Шаг, который нельзя убрать, стараемся сделать необязательным на входе и предложить позже.
Навигация: таб-бар, стек и жесты
В мобильных приложениях устоялись три механики, и путать их не стоит. Таб-бар внизу — переключение между разделами одного уровня, обычно от трех до пяти вкладок; при переключении состояние раздела сохраняется. Стек — движение вглубь раздела с кнопкой возврата в шапке. Модальные окна — короткие сценарии, которые прерывают текущий: подтверждение, выбор из списка, форма в один шаг.
Жесты удобны, но невидимы. Смахивание для удаления или свайп между вкладками можно оставлять только как ускорение для опытных пользователей: у любого жеста должен быть видимый дубль в интерфейсе. Отдельно проверяем, не конфликтует ли жест приложения с системным — смахивание от левого края на многих устройствах означает «назад».
Еще одно правило: пользователь должен в любой момент понимать, где он находится и как вернуться. Заголовок экрана, подсвеченная вкладка и предсказуемая кнопка возврата закрывают этот вопрос без дополнительных подсказок.
Зоны досягаемости и размеры элементов
Телефон обычно держат одной рукой, и большой палец уверенно достает до нижней трети экрана. Верхние углы — самая неудобная зона, особенно на аппаратах с крупной диагональю. Поэтому основные действия мы размещаем внизу, а в верхнюю часть выносим то, к чему обращаются редко: заголовок, поиск, служебные иконки.
Минимальный размер зоны нажатия — примерно 44 пункта на iOS и 48 независимых пикселей на Android. Важно, что это размер именно области нажатия, а не иконки: визуально элемент может быть меньше, но невидимая зона вокруг него должна дотягивать до нормы. Между соседними кнопками оставляем зазор, иначе на ходу человек будет попадать не туда, и часть таких промахов вы никогда не увидите в аналитике — они выглядят как обычные действия.
Отдельно смотрим на нижнюю кромку: на устройствах с жестовой навигацией там проходит системная полоса, и кнопку, прижатую к самому краю, задеть трудно.
Состояния экрана, про которые забывают
Макеты обычно рисуют для идеального случая: данные пришли, список полный, сеть есть. В работе экран живет в нескольких состояниях, и каждое нужно спроектировать заранее — иначе разработчик придумает их сам, и вы увидите пустой белый экран вместо объяснения.
| Состояние | Что должно быть предусмотрено |
|---|---|
| Загрузка | Каркас будущего содержимого вместо крутящегося индикатора, если ожидание дольше секунды |
| Пустой экран | Объяснение, почему пусто, и кнопка первого действия: добавить, найти, оформить |
| Ошибка запроса | Понятная формулировка без кода ошибки, кнопка повтора, сохраненный ввод пользователя |
| Нет сети | Сообщение о разрыве, показ ранее загруженных данных, автоматический повтор при восстановлении связи |
| Долгая операция | Прогресс с понятным окончанием и возможность продолжить работу в другом разделе |
| Нет прав доступа | Что именно недоступно и как это включить, со ссылкой в системные настройки |
| Успешное действие | Короткое подтверждение и очевидный следующий шаг вместо возврата в никуда |
Формы, клавиатуры и разрешения
Форма в мобильном приложении — самое хрупкое место. Мы проверяем, что для каждого поля выбран правильный тип клавиатуры: цифровая для телефона и кода, почтовая для адреса, обычная для имени. Автозаполнение и вставка кода из СМС должны работать; ручной ввод шестизначного кода из уведомления — верный способ потерять часть пользователей.
- Поле, которое заполняется, не должно закрываться клавиатурой — экран прокручивается к активному полю.
- Ошибку показываем рядом с полем и после ухода из него, а не на каждом введенном символе.
- Введенные данные сохраняются при сворачивании приложения и при повороте экрана.
- Длинные формы делим на шаги с индикатором прогресса, а не растягиваем в одну простыню.
Разрешения на геопозицию, камеру, уведомления и контакты запрашиваем в момент, когда они действительно нужны, и объясняем зачем — своим экраном перед системным диалогом. Системный запрос показывается один раз, отказ на старте закрывает функцию надолго: вернуть ее можно только через настройки телефона, куда пойдут единицы.
Тексты, доступность и различия платформ
Интерфейсные тексты — часть проектирования, а не то, что дописывают в конце. Кнопка называется действием («Оплатить заказ»), а не «Далее»; сообщение об ошибке говорит, что сделать, а не «что-то пошло не так». Для локализации закладываем запас: перевод на русский обычно длиннее английского, и надпись, помещавшаяся в одну строку, начинает обрезаться.
По доступности проверяем базовое: контраст текста и фона, работу интерфейса при увеличенном системном шрифте, подписи для элементов, которые озвучивает экранный диктор, и отсутствие смысла, переданного только цветом. Увеличенный шрифт ломает верстку чаще всего — макеты с фиксированной высотой блоков этого не переживают.
Платформенные различия трогаем осознанно. Общая логика и структура одинаковы, но кнопка возврата, шрифты системы, поведение переключателей и вид выбора даты берутся из платформы. Приложение, целиком перенесенное с одной платформы на другую пиксель в пиксель, выглядит чужим на обеих.
Производительность, первый запуск и проверка на устройствах
Ощущение скорости — часть интерфейса. Экран должен показывать хоть что-то мгновенно, а не ждать полного ответа сервера. Помогают кэш последних данных, оптимистичная реакция на нажатие и подгрузка длинного списка порциями. Анимации оставляем короткими: длинная анимация приятна один раз и раздражает на сотом повторе.
Первый запуск проектируем отдельно. Три экрана приветствия и обязательная регистрация до того, как человек увидел пользу, — самый дорогой барьер в приложении. Мы стараемся пускать внутрь сразу, а регистрацию просить в момент, когда без нее не обойтись: при оформлении заказа или сохранении данных.
Проверяем на реальных устройствах, а не только в эмуляторе: на недорогом Android с медленным интернетом, на маленьком экране, на телефоне с крупным системным шрифтом и при ярком свете. Отдельный прогон — на устройстве с почти полной памятью и слабым сигналом: там всплывают состояния, которых в макетах не было.
Если приложение или сайт уже собирает жалобы на неудобство, начинать стоит с разбора сценариев и прототипа, а не с перерисовки экранов. Мы занимаемся этим в рамках услуги проектирование интерфейсов: собираем сценарии, проектируем экраны и состояния, тестируем прототип на людях. Напишите нам, посмотрим ваш случай.
Если интерфейс уже мешает продажам, разбираем его по шагам: проектирование интерфейсов с прототипом и тестированием.
