Дизайн мобильного приложения — это сценарии, размеры и состояния экранов, а не подбор цветов и шрифтов. Мобильная специфика начинается там, где заканчивается веб: палец вместо курсора, жесты, занятые системой, безопасные зоны и вырезы, разрешения и работа без сети. Apple и Google описали эти правила письменно, и проектирование начинается с них.
Коротко
Отличий три: ввод пальцем вместо курсора, письменные правила платформы вместо свободной вёрстки и жизнь продукта вне сети. Из-за этого приёмы, привычные в вебе, на телефоне ломаются: мелкая иконка не нажимается, наведение курсора не существует, а свайп спорит с системным жестом.
| Что сравниваем | Мобильное приложение | Сайт |
|---|---|---|
| Ввод | Палец и жесты: попадание приблизительное, состояния наведения нет | Курсор и клавиатура: попадание точное, есть наведение и фокус |
| Правила оформления | Рекомендации Apple и Google плюс проверка при публикации в магазине | Стандарты W3C и решение команды |
| Навигация | Часть жестов занята системой: возврат, переключение приложений, шторка | Кнопка «назад» и адресная строка браузера |
| Связь | Экран открывается и без сети, данные живут в кеше на устройстве | Без сети страница не открывается |
| Обновление | Через магазин: часть аудитории месяцами сидит на старой версии | Все видят новую версию при следующем заходе |
Что такое UX и UI, как интерфейс влияет на конверсию и удержание и из каких этапов состоит работа над продуктом — в статье про UX/UI-дизайн сайтов и цифровых сервисов. Дальше здесь — только мобильная часть.
Нижние границы заданы тремя документами: рекомендациями Apple для iOS, рекомендациями Android и стандартом доступности WCAG 2.2. Это единственная часть мобильного дизайна, где есть точные числа, и спорить с ними бессмысленно — по ним же приложение оценивают на проверке.
Apple формулирует правило коротко: элементы управления делают не меньше 44 × 44 точек, чтобы по ним можно было точно попасть пальцем, а текст — не мельче 11 точек, иначе его придётся увеличивать. Android просит для каждого интерактивного элемента область не меньше 48 × 48 dp и добавляет, что больше — лучше.
WCAG 2.2 — стандарт Консорциума W3C, принятый 12 декабря 2024 года. Он требует контраст 4,5:1 для обычного текста и 3:1 для крупного, а критерий 2.5.8 задаёт минимальную цель нажатия 24 × 24 CSS-пикселя на уровне AA. Платформенные 44 pt и 48 dp строже, поэтому на телефоне равняются на них.
Ошибка Иконку рисуют размером 24 × 24 и оставляют её же областью нажатия. Видимый элемент может быть маленьким — увеличивать нужно область, которая реагирует на палец, прозрачными отступами вокруг иконки.
Различается не внешний вид, а поведение: как человек возвращается назад, где лежат основные разделы и какие края экрана занимает система. Единый визуальный стиль при этом сохраняется — переносить между платформами нужно правила бренда, а не системные элементы.
| Элемент | iOS | Android |
|---|---|---|
| Возврат назад | Кнопка слева вверху и свайп от левого края экрана | Системный жест от бокового края или кнопка в навигационной панели |
| Основные разделы | Панель вкладок внизу экрана | Нижняя панель навигации или выдвижное меню |
| Главное действие экрана | Кнопка в верхней панели или в содержимом | Плавающая кнопка действия поверх содержимого |
| Аппаратные особенности | Индикатор домашнего экрана внизу, вырез или островок сверху | Разные вырезы и края у сотен моделей, складные экраны |
| Выход из приложения | Сценарий заканчивается закрытием экрана | Жест «назад» с первого экрана закрывает приложение |
Отсюда практическое правило: в макетах рисуют не «один экран», а его поведение на обеих платформах. Чем больше общих компонентов, тем дешевле поддержка — это отдельный аргумент при выборе между нативной и кроссплатформенной разработкой.
Безопасная зона — часть экрана, которую не перекрывают системные элементы: статус-бар, вырез камеры, индикатор домашнего экрана, зоны системных жестов. Всё, что человек нажимает, живёт внутри неё, фон — за её пределами.
С Android 15 это перестало быть пожеланием: приложения, собранные под API 35, по умолчанию рисуются на весь экран, и содержимое уходит под системные панели, если разработчик не обработал отступы. Дизайнер отдаёт макет, в котором видно, где кончается фон и начинается безопасная зона.
Первый запуск теряет больше пользователей, чем любой другой экран, и почти всегда по двум причинам: длинное знакомство перед первой пользой и запрос разрешений без объяснения. Обе лечатся порядком шагов, а не текстом на слайдах.
Правила магазина здесь совпадают со здравым смыслом. Apple в разделе 5.1.1 требует, чтобы пояснение к запросу разрешения ясно и полно описывало, как используются данные, запрещает просить доступ к тому, что не нужно основной функции, и отдельно запрещает вынуждать человека соглашаться. Там же правило 5.1.1(v): если приложение позволяет завести аккаунт, удалить его тоже должно быть можно внутри приложения.
Разрешение на уведомления — отдельный разговор: когда его просить, как устроены каналы и какие сценарии работают, разобрано в статье про push-уведомления в приложении.
Экран — это не одна картинка, а набор состояний, и половина работы дизайнера приходится на те, которые не попадают в презентацию. Если состояние не нарисовано, его придумает разработчик — обычно в виде пустоты или системного сообщения об ошибке.
Отдельный пункт для Узбекистана — три языка интерфейса. В Syntra Health весь интерфейс существует на русском, узбекском и английском, и длина строки в них отличается: кнопка, которая помещается по-русски, по-узбекски переносится на две строки.
Порядок работ один и тот же для приложения любого размера, меняется глубина каждого шага. Ниже — этапы и результат, который остаётся у заказчика после каждого.
Дизайн-система окупается не на первом экране, а на десятом: в кейсе QADAM брендбук из четырнадцати разделов описал знак, палитру, иконки и состояния до старта разработки, и собирать новые экраны стало механической работой.
Ошибки повторяются от проекта к проекту, и все они видны на макете — до того, как попадут в код и в отзывы магазина.
Отдельная ошибка — редизайн без разбора причин. Если люди не доходят до оплаты, менять палитру бесполезно: сначала смотрят, на каком шаге они уходят, и чинят шаг.
Качество интерфейса измеряется поведением, а не мнением о макете. Для мобильного приложения набор показателей отличается от сайта: к воронке добавляются установки, разрешения и оценки в магазинах.
Числа показывают, где проблема, но не объясняют её. Причину находят на живых людях: короткий тест сценария на нескольких пользователях до вёрстки обходится дешевле, чем переделка собранных экранов, — как это устроено, описано в статье про UX/UI-дизайн цифровых продуктов. Требования магазинов к сборке и метаданным — в материале про публикацию в App Store и Google Play.
Мы начинаем не с макета, а со сценария и данных: какие экраны человек проходит до цели, что он уже знает и что приложение обязано у него спросить. Дальше собирается прототип, на нём проверяется логика, и только после этого появляется визуальный слой — вместе с дизайн-системой, чтобы следующие экраны собирались быстро.
Так сделано приложение КручуВерчу: конфигуратор блюда с честной ценой каждой добавки, карточка с весом и составом, корзина на виду и трекинг курьера — набор экранов, собранный вокруг одного сценария заказа. Отдельной услуги «дизайн интерфейса» у нас нет: он входит в разработку продукта, как и в разработке сайтов и платформ, где проектирование, вёрстка и аналитика идут одним пакетом.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Визуальный стиль переносится целиком, поведение — нет. Разными остаются возврат назад, размещение основных разделов, главное действие экрана и системные жесты. На практике рисуют общую дизайн-систему и два набора навигационных экранов, а не два отдельных приложения.
Считают не экраны, а состояния: один экран каталога — это загрузка, пустой результат, нет сети, ошибка, обычный список и список с фильтрами. Если в смете только «экраны», половина работы дизайнера в ней не видна, и эти состояния потом придумывает разработчик.
Небольшому продукту хватает базового набора: кнопки, поля, карточки, уведомления, правила отступов и цвета состояний. Полноценная система нужна тогда, когда над приложением работает больше одного человека или планируется регулярный выпуск новых разделов.
Без прототипа ошибку в структуре найдут уже в собранном приложении. Тогда исправление потянет вёрстку, серверную часть и новую проверку в магазине, а часть пользователей ещё месяцами будет сидеть на старой версии. На прототипе — черновых экранах, которые уже можно нажимать, — та же ошибка правится за один подход.
Сначала смотрят данные: на каком шаге люди уходят, о чём спрашивают в поддержке, что пишут в отзывах. Если проблема в двух-трёх сценариях, дешевле починить их. Полная переделка оправдана, когда новая функция не встраивается в текущую структуру.
До сборки по макету проверяют три вещи: читается ли текст на фоне (контраст не ниже 4,5:1 по стандарту доступности WCAG 2.2), не мельче ли кнопки минимума платформ — 44 × 44 pt у Apple и 48 × 48 dp у Android — и не разваливается ли экран, если человек увеличил шрифт в настройках телефона. После сборки проверки повторяют на устройстве.
Источники
