Ошибка, которая дорого обходится: относиться к дизайну как к декоративному этапу, который «наводит красоту» на уже придуманный интерфейс. На деле на этом шаге проверяется, работает ли сама логика — понятно ли, куда вести пользователя дальше, не потеряется ли он между экранами. Изменить макет в редакторе прототипов стоит часа работы. Изменить ту же логику после того, как под неё написан код, — уже дни работы программиста и тестировщика.
Дизайн мобильного приложения — это последовательность проверяемых артефактов, а не один файл с картинками экранов. Разберём, что должно получиться на каждом шаге, чем кликабельный прототип отличается от финального макета и как понять, что дизайн готов к передаче в разработку.
Что получается на выходе
У этапа дизайна есть конкретные измеримые результаты — заказчику стоит заранее понимать, каких документов и файлов он должен получить, чтобы принять этап, а не просто «посмотреть, как красиво».
| Артефакт | Что это | Зачем нужен | Кто проверяет |
|---|---|---|---|
| Карта пользовательских путей (user flow) | Схема: с чего пользователь начинает сценарий и какими шагами приходит к результату | Показывает логику до того, как отрисован хоть один экран | Заказчик и продуктовая команда — совпадает ли путь с реальным сценарием |
| Карта экранов | Список всех экранов приложения и переходов между ними | Не даёт забыть промежуточные состояния — пустые списки, ошибки, подтверждения | Заказчик — ничего не упущено; разработчик — оценивает объём работы |
| Вайрфреймы | Схематичные, обычно чёрно-белые макеты с расположением блоков без финального оформления | Быстро проверить структуру экрана, не отвлекаясь на цвет и шрифты | Заказчик — на этом этапе дешевле всего вносить структурные правки |
| Кликабельный прототип | Связанные между собой макеты, по которым можно «пройти» пальцем как по живому приложению | Проверка сценария на реальных людях до написания кода | Участники юзабилити-теста, заказчик |
| UI-кит / дизайн-система | Набор переиспользуемых компонентов (кнопки, поля, карточки) и правил их использования | Единообразие интерфейса и ускорение и дизайна, и разработки новых экранов | Дизайнер и разработчик — сверяют, что все экраны используют одни и те же компоненты |
| Финальные макеты | Полностью оформленные экраны для каждого состояния и обеих платформ (или адаптированные под платформу) | То, что разработчик будет верстать | Заказчик утверждает перед передачей в разработку |
| Спецификация для разработки | Документ или разметка в самом файле: отступы, размеры, цвета, поведение при разных состояниях экрана | Разработчик реализует именно то, что задумано, без домысливания деталей | Разработчик — сверяет реализацию со спецификацией |
Если подрядчик показывает только «красивые» финальные макеты без промежуточных шагов, стоит спросить про карту экранов и вайрфреймы: без них сложно проверить, учтены ли нетипичные сценарии — ошибка сети, пустой список, отменённый заказ.
От сценария к карте экранов
Карта экранов вырастает из пользовательского сценария, а не наоборот. Возьмём условный пример — приложение записи к мастеру (маникюр, стрижка, ремонт техники — сценарий похож в любой из этих сфер).
Сценарий: пользователь открывает приложение → выбирает услугу → выбирает мастера или время → подтверждает запись → получает уведомление-напоминание. На каждый шаг сценария приходится минимум один экран, а часто — ещё и промежуточные состояния этого экрана:
- Экран каталога услуг — с состояниями «услуги загружаются», «список пуст», «есть услуги».
- Экран выбора мастера и времени — с состоянием «свободных слотов на выбранный день нет».
- Экран подтверждения записи — с итоговыми данными перед отправкой.
- Экран успешной записи — подтверждение с деталями и кнопкой «добавить в календарь».
- Экран ошибки — если запись не удалось создать (например, слот уже заняли, пока пользователь оформлял запись).
- Push-уведомление и экран, на который оно ведёт — напоминание за день или за час до визита.
- Экран моих записей — с возможностью отменить или перенести.
На этом уровне ещё не важно, как выглядят экраны — важно, что все переходы и развилки перечислены явно. Забытая ветка сценария («а что, если слот заняли параллельно») обычно обнаруживается не на дизайне, а во время тестирования готового приложения, когда исправление стоит дороже.
Вайрфреймы и кликабельный прототип
Вайрфреймы намеренно рисуют схематично: серые прямоугольники вместо фотографий, условный текст вместо финальных формулировок, минимум цвета. Причина не в экономии времени дизайнера, а в том, чтобы заказчик и тестируемые пользователи оценивали структуру экрана — что где расположено, в каком порядке идёт информация, — а не отвлекались на оттенок кнопки. Если показать человеку сразу цветной макет, обсуждение почти всегда соскальзывает на оформление вместо того, понятен ли сам сценарий.
Кликабельный прототип — следующий шаг: те же экраны связывают переходами в редакторе прототипирования, чтобы по ним можно было «пройти», нажимая на элементы, как в настоящем приложении. Разница с реально работающим приложением в том, что за кнопками нет логики — только заранее заданный переход на нужный экран. Это позволяет проверить сценарий на людях за недели до того, как написана хоть одна строка кода.
Детализация прототипа должна соответствовать вопросу, который он проверяет. Чтобы понять, находит ли пользователь кнопку записи на главном экране, хватит серого прототипа. Если тестируется доверие к оформлению — нужны уже близкие к финальным макеты.
Юзабилити-тест прототипа
Кликабельный прототип создают не для того, чтобы заказчик один раз одобрил его на встрече, а чтобы проверить на людях, которые видят интерфейс впервые. Разработчики и дизайнеры слишком хорошо знают логику своего же продукта, чтобы объективно оценить, насколько она понятна со стороны.
- Сформулировать задачи, а не вопросы. Не «удобно ли вам такое меню», а конкретное действие: «запишитесь на маникюр на пятницу к любому мастеру».
- Набрать 5–8 респондентов из целевой аудитории. Больше на этом этапе обычно не нужно: основные проблемы интерфейса всплывают уже на первых нескольких участниках, а дальше находки начинают повторяться.
- Попросить думать вслух. Респондент проговаривает, что видит и почему нажимает именно сюда — это показывает не только результат, но и ход мысли, включая моменты сомнения.
- Не подсказывать во время задачи. Если человек застрял — это данные о прототипе, а не повод объяснить, «как на самом деле надо».
- Фиксировать каждую заминку. Где задержался взгляд, где нажал не туда, где переспросил — записывать дословно, а не пересказывать своими словами по памяти.
- Приоритизировать находки после теста. Не каждая заминка — критическая проблема: сначала чинят то, что мешает завершить сценарий, потом — что просто неудобно.
Чего юзабилити-тест прототипа не покажет: вернутся ли люди к приложению через неделю и готовы ли платить. Это вопросы к следующему этапу проверки — например, к MVP или более ранним способам проверить идею без кода. Прототип отвечает только на вопрос «понятен ли интерфейс», не «нужен ли продукт вообще».
Особенности iOS и Android
У Apple и Google — собственные руководства по дизайну: Apple публикует Human Interface Guidelines, Google — Material Design (актуальная версия — Material Design 3). Это не формальность, а свод паттернов, которые пользователь уже знает по другим приложениям на своей платформе, — отступление от них считывается как «что-то не так», даже если конкретную причину человек не сформулирует.
- Навигация назад. На iOS основной способ вернуться — кнопка «Назад» в левом верхнем углу и жест свайпа от левого края экрана. На Android за возврат дополнительно отвечает системная функция «назад» — жест или кнопка операционной системы, а не только самого приложения. Поэтому на Android важно явно продумать в дизайне, куда ведёт системная кнопка «назад» с каждого экрана, — иначе разработчику придётся додумывать поведение самому.
- Нижняя навигация и системные жесты. Обе платформы используют нижние панели вкладок для основных разделов, но по-разному резервируют зону системных жестов у нижнего края — это стоит учитывать при размещении важных кнопок.
- Типографика. На iOS принято ориентироваться на системный шрифт San Francisco, на Android — на Roboto или альтернативы Material 3; системные шрифты упрощают поддержку динамического размера текста, о котором ниже.
Отдельный вопрос — единый визуальный дизайн для обеих платформ или адаптация под особенности каждой. Единый стиль проще поддерживать и он сильнее закрепляет узнаваемость бренда, но может ощущаться «чужеродным», если на Android используются типично iOS-паттерны. Адаптация под платформу удобнее привычному к своей системе пользователю, но требует больше ресурсов на старте. Выбор стоит обсуждать вместе с решением о технологии — нативная разработка под каждую платформу или кроссплатформенная (см. «Нативная или кроссплатформенная разработка»: кроссплатформенные фреймворки чаще тяготеют к единому визуальному языку).
Доступность и удобство
Доступность — не факультативное требование «для инвалидов», а условие, при котором интерфейсом удобно пользоваться в принципе: на ходу, одной рукой, при ярком солнце на экране, при плохом зрении или просто уставшими глазами вечером.
- Размер нажимаемых элементов. Apple Human Interface Guidelines рекомендуют минимальный размер интерактивного элемента 44×44 пункта (pt), Material Design 3 — минимум 48×48 dp. Смысл общий: кнопка, ссылка или иконка должны быть достаточно крупными, чтобы попасть по ним пальцем с первого раза, даже если сам значок внутри визуально меньше, — недостающую площадь добирают padding вокруг элемента.
- Контраст текста. Согласно WCAG 2.2 (уровень AA), контраст обычного текста с фоном должен быть не ниже 4.5:1, для крупного текста (от 18 pt, либо от 14 pt для полужирного начертания) — не ниже 3:1. Это касается и подписей на кнопках, и текста поверх фотографий, где фон часто оказывается недостаточно контрастным.
- Динамический размер шрифта. Обе платформы позволяют увеличить системный размер текста в настройках телефона. Если интерфейс жёстко завязан на фиксированный размер и не тестировался с увеличенным текстом, у части пользователей экраны будут обрезаться или наезжать друг на друга.
- Тёмная тема. Если приложение поддерживает системную тёмную тему, в дизайне нужен отдельный набор цветов для неё, а не автоматическая инверсия — иначе часть сочетаний цвета и фона теряет контраст именно в тёмном варианте.
- Состояния экрана. Загрузка, пустой список, ошибка, отсутствие сети — их нужно нарисовать так же, как основной «счастливый путь», а не оставлять на усмотрение разработчика в последний момент.
UI-кит и дизайн-система
UI-кит — это набор переиспользуемых компонентов интерфейса (кнопки, поля ввода, карточки, модальные окна) с зафиксированными состояниями — обычное, нажатое, отключённое, с ошибкой. Дизайн-система — понятие шире: помимо компонентов она включает токены (переменные цвета, отступов, размеров шрифта) и правила их применения.
Даже для небольшого проекта дизайн-система окупается быстро: без неё каждый новый экран дизайнер собирает заново, слегка по-разному подбирая отступы и оттенки, а разработчик тратит время на то, чтобы понять, реализована ли уже похожая кнопка в другом месте приложения. С системой добавление экрана — это в основном компоновка уже готовых компонентов. Это же облегчает поддержку: изменение цвета основной кнопки в одном месте применяется сразу везде.
Инструменты прототипирования и дизайн-систем (Figma и аналогичные редакторы) — рабочий инструмент дизайнера, а не то, что должен уметь заказчик. Важнее не название программы, а результат: файл с компонентами, к которому можно вернуться, а не набор картинок в мессенджере.
Передача в разработку
Между «дизайн одобрен» и «разработчик приступил к вёрстке» должен быть явный шаг передачи, а не файл с макетами, скинутый в чат без пояснений.
- Спецификация. Отступы, размеры шрифтов, цвета в виде кода (hex или переменных дизайн-системы), поведение компонентов при разных состояниях — то же самое, что описывалось для UI-кита, но применительно к конкретным экранам.
- Экспорт ресурсов. Иконки и изображения — в нужных форматах и разрешениях под обе платформы, а не одна картинка «на глаз».
- Анимации и переходы. Если в дизайне заложены анимации между экранами, для них нужна отдельная спецификация (длительность, тип перехода) — иначе разработчик реализует переход «как получится».
- Согласование состояний. Финальная сверка, что для каждого экрана есть макет всех состояний из карты экранов — загрузка, пустой список, ошибка, — а не только основной вариант.
Отдельно стоит заранее зафиксировать в договоре, кому принадлежат права на макеты и исходные файлы после оплаты, и получить сами исходники (не только скриншоты или PDF) — без них внести правки в будущем сможет только тот же подрядчик. Это стоит сверить со списком вопросов в статье «Как выбрать подрядчика для разработки приложения». Требования к макетам и состояниям экранов лучше заранее описать в техническом задании — см. «Техническое задание на мобильное приложение», — тогда на этапе передачи не возникает разногласий.
Частые ошибки
- Рисовать экраны без предварительного сценария. Отдельные красивые экраны без карты переходов почти всегда оставляют дыры в логике, которые всплывают позже.
- Прорабатывать только «счастливый путь». Если нарисован только идеальный сценарий без ошибок и пустых состояний, разработчику приходится додумывать эти экраны на ходу.
- Дизайн под один размер экрана. Проверка макета только на одном разрешении приводит к обрезанным элементам на других устройствах — от маленьких экранов до планшетов.
- Пропустить юзабилити-тест. Показать прототип только заказчику и команде — не то же самое, что проверить его на людях, которые видят интерфейс впервые.
- Вносить правки после начала разработки. Изменение структуры экрана, когда под него уже написан код, стоит дороже правки макета и обычно сдвигает сроки проекта.
Частые вопросы
Сколько итераций правок макетов — это нормально?
Единого числа нет, но стоит закладывать хотя бы 1–2 раунда правок после показа вайрфреймов и ещё 1–2 — после финальных макетов: часть замечаний появляется, только когда экран увиден целиком. Если правок заметно больше и они касаются структуры, а не деталей, — сценарий не был до конца согласован на этапе карты экранов.
Можно ли обойтись без дизайнера?
Для простого сценария и небольшого личного проекта можно собрать интерфейс на готовых компонентах no-code-конструктора или библиотеки компонентов платформы. Но если интерфейс — часть ценности продукта для пользователя, профессиональный дизайн обычно окупается меньшим числом ошибок на юзабилити-тесте и более простой доработкой в будущем.
Нужен ли отдельный дизайн для планшетов?
Зависит от доли пользователей с планшетов. Минимум — проверить, что интерфейс не обрезается и не растягивается некрасиво на большом экране; полноценная адаптация макетов под планшет — отдельный объём работы, который стоит закладывать в план заранее.
Сколько времени занимает этап дизайна?
Ориентировочно от одной до нескольких недель на вайрфреймы и прототип с юзабилити-тестом, и ещё от нескольких недель на финальные макеты и UI-кит — срок зависит от числа экранов и того, делается ли дизайн-система с нуля. Сроки по всем этапам — в статье «Этапы разработки мобильного приложения», факторы стоимости — в статье «Из чего складывается стоимость разработки мобильного приложения».
Нужны ли исходники макетов после завершения работы?
Да, стоит настоять на передаче исходных файлов дизайна (не только скриншотов или PDF) и зафиксировать это в договоре заранее — без исходников вносить изменения в будущем сможет только тот же дизайнер.
Как оценить работу дизайнера, если сам не разбираешься в дизайне?
Ориентируйтесь не на личный вкус по поводу цвета кнопок, а на то, есть ли карта экранов, проработаны ли состояния ошибок и пустых списков, проходили ли макеты юзабилити-тест на живых людях и получили ли вы файл дизайн-системы, а не только картинки готовых экранов.
Дизайн готов к передаче в разработку, если…
- есть карта пользовательских путей и карта экранов, включая нетипичные ветки сценария;
- для каждого экрана нарисованы все состояния — загрузка, пустой список, ошибка, отсутствие сети;
- кликабельный прототип прошёл юзабилити-тест минимум на 5–8 людях из целевой аудитории;
- интерактивные элементы не меньше рекомендованного платформой размера, а текст и фон соответствуют минимальному контрасту;
- есть UI-кит или дизайн-система с переиспользуемыми компонентами, а не набор разрозненных экранов;
- подготовлена спецификация для разработки — отступы, цвета, поведение компонентов, экспортированные ресурсы;
- зафиксировано, кому принадлежат права на макеты, и получены исходные файлы.
Итог
Дизайн мобильного приложения — это последовательность проверяемых шагов: от карты сценария и вайрфреймов до кликабельного прототипа, юзабилити-теста и финальных макетов с готовой спецификацией для разработки. Каждый из этих артефактов существует не для отчётности, а чтобы находить и исправлять проблемы там, где это дешевле всего — до того, как решение превратилось в код.
Заказчику стоит требовать не «красивую картинку», а весь набор артефактов из этой статьи, включая состояния ошибок и пустых экранов, проверку на реальных пользователях и передачу исходных файлов. Это и есть признаки того, что дизайн действительно готов к разработке, а не просто выглядит готовым.