Дизайн мобильного приложения: как создать

Перенести макет сайта на телефон, уменьшив, — самый частый и дорогой провал. Мобильный контекст другой по пяти причинам, и каждая меняет дизайн.

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

Зоны большого пальца. Телефон держат в руке: низ экрана достаётся легко, верхние углы почти нет. Главные действия уводят вниз, к зоне досягаемости.

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

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

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

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

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

Вопрос ключевой, и ответа «всегда так» не существует.

Отдельный дизайн под каждую платформу даёт максимально родное ощущение: iOS-версия выглядит и ведёт себя как образцовое iOS-приложение, Android — как образцовое Android. Цена — двойная работа и расхождения в поддержке. Оправдано там, где платформенная привычность критична.

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

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

Исследование и сценарии. К задачам пользователя добавляется контекст: где человек находится, в каких условиях, одной ли рукой держит телефон, что его прерывает. На структуру это влияет сильнее, чем в вебе. Методы разобраны в материале про UX-исследования.

Структура и прототип. Навигацию проектируют под платформенные паттерны и зону пальца, а прототип проверяют на реальном устройстве в руке. Чем отличаются вайрфрейм, макет и прототип — в материале про прототипирование интерфейса.

Визуал и компоненты. Собирают библиотеку компонентов с учётом платформенных конвенций и всех состояний. Общая теория интерфейсов — в материале про UX/UI-дизайн.

Проверка и правки. Дизайн смотрят на разных диагоналях и плотностях, особенно на Android, и правят по результатам проверки.

Главный акцент мобильного дизайна: макет живёт в руке. Всё, что не проверено на телефоне, придётся переделывать. Всё, что не проверено на телефоне, придётся переделывать.

Самая частая недоработка в макетах — нарисован только счастливый путь. Экран со списком показан заполненным, форма — с корректными данными, карточка — с картинкой. В жизни этих состояний больше, и если дизайнер их не нарисовал, их придумает разработчик по ходу.

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

Работа здесь не сводится к инверсии цветов. Нужна вторая палитра, где сохраняются контрасты и читаемость, проверяются иллюстрации и логотипы на тёмном фоне, отдельно решаются тени и разделители, которые на тёмном не работают так, как на светлом.

Это осмысленный объём работ, и его закладывают в смету на дизайн сразу. Добавить тёмную тему к готовому приложению можно, но это дороже, чем спроектировать обе палитры одновременно.

Отдельная ловушка — иллюстрации и фотографии. Картинка с белым фоном на тёмном экране превращается в светлый прямоугольник, а логотип с тёмным контуром просто исчезает. Значит нужны либо версии под обе темы, либо изображения без фона. Проверять это стоит на этапе макетов, пока контент ещё не загружен в приложение.

В макетах регулярно стоит «рыба» — заглушки вместо реальных надписей. Дальше происходит одно из двух: тексты пишет разработчик по ходу вёрстки либо их придумывают на приёмке. Оба варианта дают интерфейс, где кнопки называются «Отправить», ошибки — «Что-то пошло не так», а пустой экран молчит.

Формулировки — часть дизайна. Название кнопки определяет, поймёт ли человек, что произойдёт после нажатия. Текст ошибки решает, попробует он ещё раз или уйдёт. И длина надписей влияет на вёрстку: макет, нарисованный под слово «Оплатить», ломается на «Подтвердить и оплатить».

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

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

Доступность нужна не только людям с ограничениями. Она нужна всем, кто пользуется приложением на солнце, в движении и уставшим.

Базовые ориентиры: тап-зоны от 44 pt на iOS и 48 dp на Android, достаточный контраст текста к фону, поддержка увеличенного системного шрифта, работа с экранным диктором. Приложение, которое разваливается при включённом крупном шрифте, теряет часть аудитории и оценки в магазинах.

Адаптивность на мобильном — это не только диагонали телефонов. Это ещё планшеты и складные устройства, где экран меняет размер прямо во время работы. На iOS линейка небольшая, на Android разброс огромный, и дизайн обязан тянуться от компактного бюджетника до планшета. Закладывают это в систему компонентов, вместо подгонки под каждое устройство руками.

Момент передачи — место, где теряются недели, если о нём не договорились заранее. Готовый пакет выглядит так.

• Макеты всех экранов во всех состояниях, включая тёмную тему, — а не только показанные заказчику ключевые экраны.
• Библиотека компонентов с состояниями кнопок, полей и карточек. Как она устроена — в материале про UI Kit и дизайн-систему.
• Значения отступов, размеров и цветов в виде переменных, из которых разработчик берёт их напрямую. Разработчик не должен измерять расстояния линейкой.
• Иконки и изображения в нужных форматах и плотностях, векторные там, где это возможно.
• Описание анимаций и переходов: что происходит при нажатии, как открывается экран, что показывается во время загрузки.
• Правила адаптации под узкие и широкие экраны: что сжимается, что переносится, что скрывается.

Хорошая практика — отдавать не всё сразу, а по частям, в том порядке, в котором идёт разработка. Первым уходит то, что делается в первом спринте, и по нему сразу видно, полон ли пакет. Ошибки в составе выясняются на трёх экранах, а не на пятидесяти.

Проверка простая: разработчик собирает экран, ни разу не спросив дизайнера. Если вопросы возникают на каждом втором экране, передача не состоялась. Дальше начинается мобильная разработка, и в ней такие вопросы стоят дороже.

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

Иконка приложения — отдельная задача. Логотип, уменьшенный до 60 пикселей, ею не является. Она должна читаться на маленьком размере, отличаться от соседних на экране и работать на светлой и тёмной подложке. Систем требований две, и размеров в каждой несколько.

Экран запуска — первое, что видит пользователь. Он должен совпадать по фону с первым экраном приложения, иначе при старте будет заметное мигание.

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

Всё это дизайнерская работа, и она занимает не один день. Заложить её стоит в тот же этап, что и макеты.

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

Макет на большом мониторе врёт. Одни и те же элементы, которые в Figma выглядят просторно, в ладони оказываются мелкими, а расстояния, казавшиеся достаточными, приводят к промахам.

Что проверяют на реальном телефоне:

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

Делать это стоит начиная с прототипа. Проверять готовое приложение тоже нужно, но это уже тестирование мобильного приложения — другая работа и другая стадия.

Дизайн приложения средней сложности занимает от трёх до шести недель при условии, что сценарии определены и заказчик отвечает в течение пары дней. Разброс задают четыре вещи: количество уникальных экранов, наличие готовой айдентики, необходимость исследований и число платформ, если решено рисовать отдельно.

Что удлиняет сроки предсказуемо: согласование макетов по кругу без назначенного ответственного, правки визуала после утверждения структуры, добавление новых сценариев в процессе.

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

Дизайн и проектирование интерфейсов у нас начинается от 300 тыс. ₽ — без брендинга и разработки фирменного стиля, это отдельная область, которой мы не занимаемся. Точная цифра зависит от числа экранов и глубины исследований, оценка по вашей задаче бесплатная.

Заказчик обычно смотрит на макеты глазами «нравится или нет». Это худший из возможных критериев. Полезнее пройти по списку.

• 1. Есть ли макеты всех состояний, включая пустые экраны и ошибки.
• 2. Нарисована ли тёмная тема, если приложение её поддерживает.
• 3. Стоят ли в макетах реальные тексты вместо заглушек.
• 4. Проходит ли ключевой сценарий на телефоне без подсказок дизайнера.
• 5. Соблюдены ли платформенные паттерны навигации.
• 6. Собран ли пакет для передачи разработчику полностью.

Отдельно стоит пройти основной сценарий самому, с телефона, ни разу не спросив, что делать дальше. Заминка на этом проходе означает недоработку макета.

Ужать сайт вместо дизайна под мобильное. Перенос десктопного макета игнорирует касание, зоны пальца и контекст.

Игнорировать платформенные конвенции. iOS-приложение с Android-навигацией ощущается чужим, даже если красивое.

Мелкие тап-зоны и элементы впритык. Кнопки меньше 44 pt или 48 dp без воздуха между ними дают постоянные промахи.

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

Нарисовать только счастливый путь. Без состояний загрузки, ошибки и пустого экрана приложение ломается на первом же нестандартном сценарии.

Оставить «рыбу» вместо текстов. Формулировки допишут при вёрстке, и они будут случайными.

Проектировать на мониторе и не проверять в руке. Удобное в окне на десктопе в ладони может оказаться недосягаемым.

• 1. Опишите ключевой сценарий: что человек делает в приложении и в каких условиях.
• 2. Решите вопрос платформ: единый дизайн или отдельный под каждую.
• 3. Проверьте, есть ли готовая айдентика, или её предстоит собрать в рамках дизайна.
• 4. Соберите список экранов и честно отметьте, у каких есть состояния кроме основного.
• 5. Договоритесь о составе пакета для передачи разработчику до начала работ.
• 6. Назначьте одного человека, который утверждает макеты.

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

Мы проектируем и разрабатываем мобильные приложения в одной команде: дизайнер, аналитик и разработчики работают над продуктом вместе, поэтому макеты не расходятся с тем, что реально соберётся в коде.

Цену и срок фиксируем до старта, кликабельный прототип показываем на первой неделе — по нему видно, как работает интерфейс, задолго до того, как появится первая сборка. Брендингом и фирменным стилем не занимаемся: делаем интерфейсы продуктов.

Обсудить проект →