Приложение открывают на ходу, одной рукой, с плохой связью и на полминуты. За это время человек должен понять, где он, и сделать то, ради чего пришёл: заказать, записаться, оплатить, проверить статус. Если не получилось, приложение удаляют, и второго шанса обычно нет.
Поэтому дизайн мобильного приложения начинается не с цветов и иконок, а со сценариев: кто пользуется, в какой ситуации и за сколько шагов решает задачу. Разберём, как мы проходим путь от целей до макетов, которые можно отдать в разработку, и что важно учесть в интерфейсе под iOS и Android.
С чего начинается разработка дизайна приложения
Первый вопрос — зачем приложение бизнесу и пользователю. У бизнеса цель может быть в повторных покупках, снижении нагрузки на колл-центр или переводе процесса в цифровой вид. У пользователя цель всегда проще: быстро сделать конкретное дело. Если эти цели не сформулированы, спорить о макетах бесполезно: не с чем сравнивать.
Дальше разбираем аудиторию: кто эти люди, где и когда открывают приложение, насколько уверенно обращаются с телефоном. Курьер в перчатках, менеджер между встречами и покупатель вечером на диване — три разных интерфейса, даже если функции похожи.
Пользовательские сценарии и карта экранов
Сценарий — это путь человека к цели: «открыл приложение по пуш-уведомлению, увидел статус заказа, связался с поддержкой». Для каждого ключевого сценария мы описываем шаги, данные, которые нужны на каждом шаге, и места, где человек может сбиться.
Из сценариев собирается карта экранов: все экраны приложения и переходы между ними. На ней сразу видно, какие экраны лишние, где сценарий слишком длинный и какие разделы должны быть доступны из любой точки. Карта экранов дешевле любых макетов, и ошибки в ней исправляются за минуты.
Навигация и интерфейс мобильного приложения
Навигация отвечает на два вопроса: где я и как попасть туда, куда нужно. В мобильных приложениях для этого есть несколько устоявшихся паттернов, и пользователи их уже знают.
- Таббар или нижняя навигация. 3–5 главных разделов внизу экрана, переключение в одно нажатие. Подходит большинству приложений с несколькими равноправными разделами.
- Стек экранов. Переход вглубь: список, карточка, детали. Назад — кнопкой в шапке или жестом.
- Модальные экраны и шторки. Для коротких отдельных задач: фильтр, выбор адреса, подтверждение. Закрываются, не сбивая основной путь.
- Жесты. Свайп назад, свайп по элементу списка, потянуть для обновления. Жест не должен быть единственным способом выполнить действие: его не все найдут.
Зона большого пальца и размеры тач-целей
Большую часть времени телефон держат одной рукой, и большой палец легко достаёт до нижней и средней части экрана. Верхние углы на крупных смартфонах — самая неудобная зона. Поэтому основные действия ставят ближе к низу: таббар, главная кнопка экрана, кнопка оплаты. Вверху остаются заголовок, поиск и редкие действия.
Тач-цель — область, на которую можно нажать. Apple рекомендует минимум 44×44 pt, Google — 48×48 dp. Иконка может быть меньше, но кликабельная зона вокруг неё должна быть не меньше этих размеров, а соседние цели не должны слипаться.
Главные действия должны быть там, куда достаёт большой палец, а не там, где для них нашлось место.
Онбординг в приложении и запросы разрешений
Онбординг — первые экраны после установки. Его задача — довести человека до первого полезного результата, а не рассказать обо всех функциях. Три слайда с картинками, которые все пролистывают, редко что-то дают. Лучше работают подсказки в контексте: в момент, когда человек впервые видит функцию.
Регистрацию тоже стоит откладывать, где это возможно. Если каталог, расписание или цены можно посмотреть без входа, пусть человек сначала увидит ценность, а потом оставит телефон или почту.
Как просить разрешения
Уведомления, геолокация, камера, контакты — каждое разрешение запрашивает система, и на iOS повторно показать системное окно нельзя: после отказа включить доступ можно только в настройках. На Android с 13-й версии разрешение нужно и для уведомлений. Поэтому запрос задают в момент, когда он понятен: доступ к камере — при нажатии «Сканировать», геолокацию — при выборе адреса доставки.
Human Interface Guidelines и Material Design
У Apple и Google есть свои руководства по интерфейсам: Human Interface Guidelines для iOS и Material Design для Android. Это не обязательный стиль, а описание того, как ведут себя системные элементы и чего ждут пользователи платформы. Бренд и визуальный язык у приложения могут быть свои, но базовое поведение лучше не ломать.
| iOS (HIG) | Android (Material) | |
|---|---|---|
| Минимальная тач-цель | 44×44 pt | 48×48 dp |
| Основная навигация | Таббар внизу | Нижняя навигация или боковое меню |
| Назад | Кнопка в шапке и свайп от левого края | Системный жест или кнопка «Назад» |
| Системный шрифт | San Francisco, Dynamic Type | Roboto, масштаб шрифта в sp |
| Главное действие | Кнопка в шапке или внизу экрана | Часто плавающая кнопка (FAB) |
| Выбор из списка, даты | Колёса-пикеры, шторки | Диалоги и выпадающие меню |
Общего больше, чем различий: оба руководства требуют крупных тач-целей, читаемого текста, понятной иерархии и поддержки системных настроек. Дизайн приложения под iOS и Android чаще всего делают на одной дизайн-системе, а различия закладывают в навигацию, системные элементы и жесты. Так приложение остаётся узнаваемым и при этом не кажется чужим ни на одной платформе.
Состояния экранов: пусто, загрузка, ошибка, офлайн
В макетах экран обычно нарисован в идеальном виде: данные загрузились, список заполнен, связь есть. В жизни всё иначе, и именно здесь приложения чаще всего выглядят сломанными. Для каждого экрана мы проектируем состояния:
- Пустое. Нет заказов, избранного, сообщений. Экран объясняет, что здесь появится, и предлагает первое действие.
- Загрузка. Скелетоны на месте будущего контента вместо бесконечного спиннера. Если операция долгая — прогресс.
- Ошибка. Человеческий текст о том, что случилось и что делать, и кнопка «Повторить». Без кодов ошибок.
- Офлайн. Что из уже загруженного можно посмотреть без сети, какие действия встанут в очередь и отправятся позже.
Состояния — не мелочь для разработчика. Если их не нарисовать, их придумают на ходу, и в каждом разделе они получатся разными.
Доступность: шрифт, контраст, тёмная тема
Многие пользователи увеличивают системный размер шрифта. Интерфейс должен это выдерживать: текст переносится, кнопки растут, ничего не обрезается. Проверить просто — включить крупный шрифт в настройках телефона и пройти основные сценарии.
Контраст текста и фона по WCAG — не ниже 4,5:1 для обычного текста и 3:1 для крупного. Серый текст на светло-сером фоне красиво смотрится в презентации и плохо читается на улице. Информация не должна передаваться только цветом: ошибку в поле отмечают и текстом.
Тёмную тему пользователи включают на уровне системы и ждут, что приложение её поддержит. Это не инверсия цветов: нужны свои оттенки фона, приглушённые акценты, проверка контраста и иллюстраций. Если цвета изначально заданы токенами в дизайн-системе, тёмная тема становится вторым набором значений, а не перерисовкой всех экранов.
Прототип приложения и тесты с пользователями
Прототип — кликабельная модель приложения, на которой можно пройти сценарии до начала разработки. Сначала мы собираем его из простых серых блоков, чтобы обсуждать логику, а не цвета. Потом, когда структура согласована, кликабельным становится и дизайн.
Тест не требует лаборатории. Достаточно пяти-шести человек из целевой аудитории, телефона с прототипом и списка задач: «найдите ближайший пункт выдачи», «перенесите запись на завтра». Наблюдаем, где человек замешкался, куда нажал не туда, что пропустил. Каждая такая точка — правка, которая в прототипе стоит часы, а в готовом коде — недели.
Дизайн-система и передача в разработку
Разработчики получают не набор картинок, а систему: компоненты, правила и токены. От того, насколько она полная, зависит, совпадёт ли приложение с макетами.
- Компоненты. Кнопки, поля, карточки, списки, шторки — со всеми состояниями: обычное, нажатое, неактивное, с ошибкой, загрузка.
- Отступы и сетка. Шаг отступов, например 4 или 8, поля экрана, правила для разных размеров телефонов и безопасных зон вокруг выреза и жестовой полосы.
- Типографика и цвета. Стили текста и цветовые токены для светлой и тёмной темы.
- Анимации. Переходы между экранами, появление шторок, отклик на нажатие: длительность, кривая, что с чем связано. Лучше показать прототипом или видео, чем описать словами.
- Иконки и иллюстрации. В векторе, в нужных размерах, с понятными названиями.
Дизайнер остаётся на связи во время разработки: отвечает на вопросы, проверяет сборки и принимает экраны. Дизайн приложения заканчивается на проверке сборки, а не на макетах.
Ассеты для сторов: иконка и скриншоты
Страница в App Store и Google Play — тоже часть дизайна: по ней человек решает, устанавливать ли приложение. Иконка должна читаться в маленьком размере и на любых обоях: один простой образ, без мелкого текста. App Store принимает иконку 1024×1024 пикселя, Google Play — 512×512.
Скриншоты — не просто снимки экранов, а короткая история: на каждом одна польза и крупная подпись. Первые два-три кадра видны в выдаче сразу, поэтому туда ставят главное. Для Google Play дополнительно нужна обложка 1024×500. Требования к размерам и количеству скриншотов сторы периодически меняют, поэтому перед публикацией их сверяют с актуальной документацией.
Другие частые ошибки:
- перенос сайта в приложение один к одному, с бургер-меню и длинными страницами;
- один дизайн для обеих платформ без учёта жестов и системной навигации;
- запрос всех разрешений на первом экране;
- онбординг из пяти слайдов перед любым полезным действием;
- непродуманные состояния ошибок и офлайна.
Этапы и чек-лист дизайна мобильного приложения
- Цели и аудитория. Формулируем задачи бизнеса и пользователей, разбираем конкурентов и ситуации, в которых открывают приложение.
- Сценарии и карта экранов. Описываем ключевые пути и собираем структуру приложения.
- Прототип. Собираем кликабельную модель и проверяем её на пользователях.
- Визуальный стиль. Предлагаем несколько вариантов на ключевых экранах и выбираем направление.
- Макеты и дизайн-система. Рисуем все экраны и состояния под iOS и Android, собираем компоненты и токены.
- Передача и авторский надзор. Готовим ассеты для сторов, сопровождаем разработку и проверяем сборки.
Перед передачей в разработку пройдите короткий список:
- главные сценарии проходятся за минимальное число шагов и проверены на людях;
- основные действия в зоне большого пальца, тач-цели не меньше 44 pt и 48 dp;
- навигация и жест «назад» работают так, как привычно на каждой платформе;
- разрешения запрашиваются в контексте, с объяснением;
- для каждого экрана нарисованы пустое состояние, загрузка, ошибка и офлайн;
- интерфейс выдерживает крупный системный шрифт, контраст соответствует WCAG;
- есть тёмная тема или осознанное решение без неё;
- компоненты, отступы, цвета и анимации описаны в дизайн-системе;
- готовы иконка, скриншоты и графика для App Store и Google Play.
Мы делаем приложения целиком: от исследования аудитории и сценариев до дизайна, разработки и публикации в сторах. Примеры можно посмотреть на странице с нашими работами.
Частые вопросы
Нужно ли делать отдельный дизайн для iOS и Android?
Обычно нет. Делают одну дизайн-систему и общий визуальный стиль, а различия закладывают в навигацию, системные элементы, жесты и диалоги. Так экономится время, а приложение на каждой платформе ведёт себя привычно.
Можно ли начать дизайн без технического задания?
Можно, если есть понятные цели и аудитория. Сценарии, карта экранов и прототип сами становятся основой для ТЗ: по ним проще оценить разработку, чем по текстовому описанию.
Сколько экранов нужно нарисовать?
Зависит от сценариев. Считать стоит не только основные экраны, но и их состояния, модальные окна и онбординг: на одно «окно» из карты экранов часто приходится несколько макетов.
Чем прототип приложения отличается от дизайна?
Прототип проверяет логику: какие экраны есть, что на них и как между ними переходить. Дизайн отвечает за внешний вид, компоненты и детали. Сначала согласуют прототип, потом рисуют дизайн, иначе логику приходится переделывать в готовых макетах.
