Дизайн мобильного приложения: что входит, сколько стоит и как принять макеты
Короткий ответ: дизайн мобильного приложения — это не «красивые картинки», а пять результатов: карта экранов, кликабельный прототип, макеты ключевых экранов, UI-кит со всеми состояниями (пусто, загрузка, ошибка) и материалы для магазинов приложений. В студии дизайн входит в тариф «Мобильное приложение» от 200 000 ₽ вместе с разработкой и публикацией; правок — до 2 раундов на прототипе и до 2 раундов на готовой сборке. Принимать макеты стоит на своём телефоне, по чек-листу в конце статьи.
Что входит в дизайн приложения?
В дизайн приложения входят карта экранов, прототип, макеты ключевых экранов, набор интерфейсных элементов (UI-кит), состояния экранов, тёмная тема, иконка и заставка. Сначала проектируют логику, потом внешний вид: так ошибки сценария находят до того, как на них потрачены цвет, шрифты и код.
По шагам это выглядит так:
- Карта экранов. Список всех экранов и стрелки между ними. На ней видно, сколько касаний отделяет человека от цели: оформить заказ, записаться, найти документ.
- Прототип. Серые экраны без цвета, связанные переходами. Его проходят пальцем, как настоящее приложение, и правят сценарий, пока это дёшево.
- Макеты. Тот же прототип, но в финальном виде: фирменные цвета, шрифты, иконки, реальные тексты и фото.
- UI-кит. Кнопки, поля, карточки, вкладки, цвета и размеры шрифтов, собранные в одном месте. Разработчик берёт размеры отсюда, а не измеряет каждый экран.
- Состояния и темы. Что видит человек, когда данных ещё нет, когда сеть пропала, когда сервер ответил ошибкой, и как всё это выглядит в тёмной теме.
- Иконка, заставка и картинки для магазинов. То, что пользователь видит до установки и в первую секунду после запуска.
В базовом тарифе студии на разработку мобильного приложения это записано так: прототип и дизайн ключевых экранов с согласованием, до 6–8 экранов, светлая и тёмная тема, иконка, сплэш-экран и оформление карточек в App Store и Google Play. Тексты для экранов, переводы и наполнение контентом в тариф не входят.
| Часть работы | Что это | Как проверить заказчику |
|---|---|---|
| Карта экранов | Схема: какие экраны есть и как пользователь переходит между ними | Пройти пальцем по схеме три главных сценария: от запуска до цели |
| Прототип | Серые экраны без цвета, связанные переходами | Открыть на своём телефоне и пройти сценарии без подсказок |
| Макеты ключевых экранов | Финальный вид: цвета, шрифты, иконки, реальные тексты | Сравнить с прототипом: ничего не потерялось, текст читается |
| UI-кит | Набор кнопок, полей, карточек, цветов и шрифтов, из которых собраны экраны | Одна и та же кнопка выглядит одинаково на всех экранах |
| Состояния | Пусто, загрузка, ошибка, нет сети, нет прав, успех | У каждого экрана со списком или формой есть хотя бы три состояния |
| Тёмная тема и крупный шрифт | Варианты экранов для настроек системы | Посмотреть два-три экрана в тёмной теме и с увеличенным текстом |
| Иконка, заставка, картинки для магазинов | То, что видят до установки и при запуске | Иконка различима на рабочем столе среди других |
Зачем кликабельный прототип и как посмотреть его на телефоне?
Кликабельный прототип нужен, чтобы проверить сценарий руками до разработки: правка схемы стоит часы, правка готовой сборки — дни. Смотреть его надо на телефоне, а не на мониторе: только в руке видно, что кнопка не достаётся большим пальцем, а текст мелкий.
Смотреть прототип можно двумя способами. Первый — ссылка, открытая в браузере телефона: ничего ставить не нужно. Второй — мобильное приложение Figma: по справке Figma оно работает на iOS 16 и Android 8 или новее и требует входа в аккаунт, а показ кадров прямо из рабочего файла на экран телефона доступен только тем, у кого есть право редактирования. Заказчику обычно хватает ссылки.
Как проверять прототип, чтобы проверка дала результат:
- Дайте телефон человеку, который приложение не видел, — сотруднику, клиенту, родственнику. Назовите цель («запишитесь на пятницу») и молча смотрите, где он застрянет.
- Проходите сценарий одной рукой, стоя. Так приложением пользуются в транспорте и в очереди.
- Записывайте замечания с номером экрана и действием: «экран 4, нажал “Далее”, не понял, сохранилась ли запись». Как формулировать и собирать замечания от нескольких людей — в статье про правки по дизайну.
Прототип — это проверка логики, а не цвета. Если на этапе прототипа обсуждают оттенок кнопки, этап прошёл впустую: сценарий остался непроверенным. Подробно о том, что должно быть на прототипе и чем он отличается от макета, — в разборе прототипа сайта в нашем блоге: для приложений логика та же.
Чем дизайн под iOS отличается от Android?
Визуальный стиль у приложения из общего кода обычно один, а различаются системные привычки: кнопка «Назад», вид стандартных элементов и минимальные размеры областей нажатия. Apple описывает правила в Human Interface Guidelines, Google — в Material Design; на каждый пункт дизайна можно сослаться туда.
Два числа, которые стоит знать заказчику. В разделе Buttons руководства Apple область нажатия кнопки — не меньше 44×44 pt. В справке Google о размере целей нажатия — не меньше 48×48 dp и 8 dp между соседними целями. Иконка при этом может быть меньше: важна область, на которую реагирует касание.
Главное расхождение — навигация. На Android есть системный «Назад»: жест или кнопка, и пользователь ждёт, что он сработает на любом экране, включая открытое окно и форму. На iPhone системной кнопки нет: возвращаются стрелкой в верхней панели или жестом от левого края. Если дизайнер нарисовал экран без стрелки «Назад», на iPhone из него просто не выйти.
Отдельный дизайн под каждую платформу нужен редко: когда продукт обязан выглядеть строго «по-родному» или аудитория почти целиком на одной системе. Для большинства задач малого бизнеса хватает одного стиля плюс аккуратной работы с системными элементами. Почему приложение вообще делают из одного кода и когда это не подходит, — в статье блога о нативе, Flutter и React Native.
| iOS | Android | |
|---|---|---|
| Справочник платформы | Human Interface Guidelines | Material Design |
| Минимальная область нажатия | 44×44 pt по разделу Buttons | 48×48 dp и не меньше 8 dp между целями |
| Кнопка «Назад» | Системной кнопки нет: стрелка в верхней панели и жест от левого края | Системный жест или кнопка «Назад», работает на любом экране |
| Выбор даты, переключатели, всплывающие окна | Системные элементы iOS | Системные элементы Android, выглядят иначе |
| Крупный текст | Настройка размера текста в системе (Dynamic Type) | Масштаб шрифта в настройках системы |
| Что обычно делаем одинаково | Цвета, шрифты, иконки, порядок экранов, тексты | Цвета, шрифты, иконки, порядок экранов, тексты |
Какие экраны и состояния часто забывают?
Забывают всё, что не входит в «счастливый путь»: пустые списки, загрузку, ошибки, отсутствие сети, отказ в доступе к камере или уведомлениям, выход из аккаунта и удаление аккаунта. Эти экраны потом рисует программист на ходу, и они выглядят чужими.
Список, который стоит потребовать в макетах:
- Пустое состояние. Новый пользователь, заказов ещё нет. Вместо пустого белого экрана — фраза и кнопка, что сделать первым.
- Загрузка. Скелет экрана или индикатор: человек должен видеть, что приложение работает, а не зависло.
- Ошибка и нет сети. Понятный текст и кнопка «Повторить». Без неё человек закроет приложение.
- Ошибки в формах. Неверный телефон, занятый email, слишком короткий пароль — подсказка рядом с полем, а не всплывающее окно.
- Запросы разрешений. Экран перед системным вопросом про уведомления, камеру или геолокацию: зачем это нужно. После отказа система может больше не показать этот вопрос (на iPhone — уже после первого отказа), поэтому нужен экран «как включить в настройках».
- Длинные данные. Имя из трёх слов, адрес в две строки, цена с шестью цифрами. Макет с коротким «Иван» скрывает проблему.
- Удаление аккаунта. Если в приложении можно создать аккаунт, правила проверки App Store (п. 5.1.1(v)) требуют дать возможность удалить его прямо в приложении; экран нужно предусмотреть сразу.
Тёмная тема и крупный шрифт — отдельная строка в списке. Пользователь включает их в настройках телефона, и приложение подстраивается само. Если дизайнер нарисовал только светлую тему, в тёмной разработчик подберёт цвета наугад: серый текст на тёмно-сером фоне, пропавшие тени, логотип, который не виден. Достаточно увидеть в макетах два-три экрана в тёмном варианте и один с увеличенным текстом, чтобы понять, что правила для них продуманы. В кейсе приложения знакомств Twin дизайн делала студия, и тёмная тема входит в состав проекта.
Нужна ли дизайн-система малому бизнесу?
Полноценная дизайн-система с документацией малому бизнесу обычно не нужна. Нужен UI-кит: набор кнопок, полей, карточек, цветов и шрифтов, из которых собраны все экраны. Он недорог, если делается сразу, и экономит деньги на каждой доработке.
Разница в масштабе. Дизайн-система — это библиотека компонентов, правила их применения, тексты, тон, иногда общий код для нескольких продуктов; её заводят компании с несколькими приложениями и своей командой дизайнеров. UI-кит — её минимальная рабочая часть для одного приложения.
Что даёт UI-кит на практике:
- новый экран собирается из готовых деталей, а не рисуется с нуля;
- другой подрядчик через год продолжит в том же стиле, а не «по мотивам»;
- смена фирменного цвета — правка в одном месте, а не на сорока экранах;
- разработчик не спорит с дизайнером об отступах: они записаны.
Признак того, что UI-кита нет: одна и та же кнопка на разных экранах разного размера и с разным скруглением. При приёмке это видно за пять минут, если положить экраны рядом.
Сколько стоит дизайн?
Отдельной цены на дизайн приложения в прайсе студии нет: прототип и дизайн ключевых экранов входят в тариф «Мобильное приложение» от 200 000 ₽, срок — от 2 недель на весь проект. Цену и срок фиксируем в договоре до старта; если нужен только дизайн без разработки, объём считаем после брифа.
Что входит в эту сумму по прайсу, если говорить о внешнем виде: до 6–8 экранов (онбординг, аккаунты, основной экран, профиль, настройки), адаптивная вёрстка под разные телефоны, светлая и тёмная тема, иконка, сплэш-экран и оформление карточек в магазинах. Правки — до 2 раундов на прототипе и до 2 раундов на готовой сборке. После публикации 14 дней мелкие правки бесплатно, гарантия по договору — 30 дней с даты акта, отдельно от поддержки.
Что увеличивает объём дизайна, а значит и смету:
- экранов больше 6–8 или есть несколько ролей: клиент, курьер, администратор;
- чаты, карты, календари записи, сложные фильтры — их состояний много;
- собственные иллюстрации, анимации, фирменный стиль с нуля;
- смена концепции после согласованного прототипа: это уже новая задача, а не правка.
О правах. По типовому договору интерфейсные макеты, как и программный код, остаются за исполнителем, а заказчик после полной оплаты получает лицензию на весь срок действия исключительного права — в том числе на переработку силами других подрядчиков. Иконка приложения, логотип и элементы фирменного стиля, созданные для заказчика, переходят к нему после полной оплаты. Полную смету приложения с обязательными расходами разбирали в статье сколько стоит мобильное приложение для бизнеса.
Когда отдельный этап дизайна не нужен и какие ошибки встречаются?
Отдельный дизайн-проект не нужен, если приложение — внутренний инструмент на 10–20 сотрудников, если хватает PWA на основе сайта или если вы проверяете спрос и готовы к простому стандартному виду. Прототип при этом всё равно нужен: он дешевле ошибки в коде.
Что браузерная версия может работать как приложение, видно по игре «Час пик» из портфолио студии: кроме iOS-версии, у неё есть веб-версия, в которую играют по ссылке, без магазина приложений; она ставится на домашний экран и работает офлайн после первого открытия. Если задаче хватает такого формата, иконки и карточки для двух магазинов готовить не нужно.
Частые ошибки заказчиков:
- Принимать макеты на мониторе. На 27 дюймах всё читается; на телефоне шрифт оказывается мелким, а кнопки — слишком близко.
- Согласовывать только главный экран. Остальные потом дорисовывают в спешке, и стиль расползается.
- Рыба вместо текстов. «Lorem ipsum» и «Иван Иванов» скрывают переносы, обрезки и пустые места. Дайте реальные тексты до финальных макетов.
- Копировать чужое приложение экран в экран. Чужой сценарий решает чужую задачу, а сходство до степени смешения создаёт риск претензий.
- Не записать в ТЗ тёмную тему, состояния и ориентацию экрана. Что не записано, то не нарисовано. Как это сформулировать — в статье про ТЗ на мобильное приложение.
Как принять макеты: чек-лист
Принимайте макеты на своём телефоне и по списку: сценарии проходятся без подсказок, все состояния нарисованы, тёмная тема и крупный шрифт предусмотрены, кнопки достаются пальцем, тексты реальные. На приёмку результата по договору — 5 рабочих дней.
- Три главных сценария (регистрация, основное действие, повторный заход) проходятся в прототипе на телефоне без объяснений.
- У каждого экрана есть стрелка или жест возврата; на Android учтена системная кнопка «Назад».
- Кнопки и ссылки не меньше 44×44 pt для iOS и 48×48 dp для Android, не стоят вплотную друг к другу.
- Для списков и форм нарисованы пустое состояние, загрузка, ошибка и нет сети.
- Есть экраны перед запросом уведомлений, камеры, геолокации и экран на случай отказа.
- Если есть аккаунт, есть выход из него и удаление.
- Два-три экрана показаны в тёмной теме; текст и логотип читаются.
- Один экран показан с увеличенным системным шрифтом; ничего не обрезается.
- Тексты в макетах реальные или близкие по длине, имена и адреса длинные.
- Одинаковые элементы выглядят одинаково на всех экранах: это признак UI-кита.
- Иконка различима на рабочем столе рядом с другими приложениями, заставка не дублирует первый экран.
- Вам понятно, в каком виде вы получите макеты: ссылка на файл, доступ на просмотр или передача файла — это стоит записать в ТЗ.
Замечания соберите в один список с номерами экранов и отправьте одним сообщением: так раунд правок не расходуется на мелочи по частям. После того как макеты превратятся в сборку, проверка продолжается уже на приложении — по чек-листу приёмки перед релизом. Если хотите обсудить свой проект, опишите задачу на странице мобильных приложений.
Короткие ответы на частые вопросы
Можно ли заказать только дизайн мобильного приложения, без разработки?
В прайсе студии дизайн приложения отдельной строкой не продаётся: прототип и дизайн ключевых экранов входят в тариф «Мобильное приложение» от 200 000 ₽. Если нужен только дизайн под другого разработчика, объём и цену считаем после брифа.
Сколько экранов рисуют в базовом тарифе?
Тариф рассчитан на приложение до 6–8 экранов: онбординг, аккаунты, основной экран, профиль, настройки. Если экранов больше или есть чаты, карты, сложные формы, стоимость считаем после брифа и фиксируем в договоре до старта.
Нужно ли делать отдельный дизайн для iOS и для Android?
Обычно нет: одно приложение из общего кода получает общий визуальный стиль, а различия сводятся к системным элементам, кнопке «Назад» и размерам областей нажатия. Отдельный дизайн под каждую платформу имеет смысл, когда продукт должен выглядеть строго «родным» на каждой из них.
Как посмотреть прототип на телефоне?
Проще всего открыть ссылку на прототип в браузере телефона. В мобильном приложении Figma прототип открывается на весь экран, но для этого нужен вход в аккаунт Figma, а приложение работает на iOS 16 и Android 8 или новее.
Кому принадлежат макеты и иконка приложения?
По типовому договору студии интерфейсные макеты, как и код, остаются за исполнителем, а заказчик после полной оплаты получает лицензию на весь срок действия исключительного права, включая доработку силами других подрядчиков. Иконка приложения, логотип и элементы фирменного стиля, созданные для заказчика, переходят к нему после полной оплаты.
Услуги и кейсы по теме: мобильные приложения · кейс Twin · цены и сроки
Пришлите список экранов или ссылку на похожее приложение — скажем, укладывается ли дизайн в базовый тариф, и назовём цену и срок до старта.
Рассчитать проект →Оценку срока и цены по брифу делаем бесплатно, обычно отвечаем в течение часа в рабочее время. Типовой договор — посмотреть до оплаты.
