Проектирование мобильных приложений: этапы и результаты для заказчика

Игорь Долгушевcистемный архитектор digital-агентства Notamedia

2026-11-1314 мин чтения

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

Что такое проектирование мобильного приложения

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

По итогам проектирования заказчик получает:

• концепцию — цель, аудиторию, ключевые функции и метрики успеха;

• структуру — карту экранов и связей между ними;

• пользовательские сценарии — как человек решает свою задачу шаг за шагом;

• прототип — кликабельную модель будущего продукта;

• техническое задание — подробное описание функций и требований;

• архитектуру — как устроены серверная часть, интеграции и хранение данных.

Зачем это бизнесу? Ошибка, найденная на прототипе, исправляется правкой макета за час. Та же ошибка в готовом продукте требует переделки кода, повторного тестирования и нового релиза в сторы. 

Когда приложению нужно проектирование и с чего начать

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

Место проектирования в разработке

Чтобы понять, где в процессе находится проектирование, посмотрим на основные этапы разработки приложения целиком. Срок зависит от объёма проекта. Ориентиры для разных типов приложений приведены в разделе «Сроки и стоимость проектирования»

Процесс разработки мобильного приложения поэтапно выглядит линейно, но на практике этапы пересекаются: дизайн начинается, пока дорабатывается ТЗ, а тестирование идет вместе с разработкой. Проектирование нельзя пропускать, потому что оно задает рамки всем следующим этапам. Без него разработчики оценивают проект «на глаз», дизайнер рисует экраны без понимания сценариев, а заказчик видит результат только в конце, когда вносить правки долго и дорого.

Если вы хотите, чтобы приложение прошло путь от идеи до сторов без переделок и сорванных сроков,

команда Notamedia поможет: спроектируем, нарисуем и разработаем приложение для iOS и Android, опубликуем его в App Store, Google Play и RuStore и будем развивать после запуска

Заказать разработку мобильного приложения

С чего начать: три вопроса до старта

Зачем приложение бизнесу? Цель создания мобильного приложения обычно одна из трех:

• продажи — новый канал заказов;

• лояльность — удержание клиентов, повторные покупки;

• автоматизация — замена звонков, бумажных процессов, ручной работы сотрудников.

Кто пользователь и какую задачу решает? Не «все наши клиенты», а конкретные группы: например, постоянные клиенты, которые записываются раз в месяц и хотят делать это за 30 секунд.

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

Если на эти вопросы есть ответы, можно начинать. Если нет — с них и начинается первый этап проектирования.

Этапы проектирования: работы, участники, результаты

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

Со стороны заказчика в проектировании нужны:

• владелец продукта, который принимает решения и согласует сценарии, 

• эксперты, которые знают процессы, — например, руководитель сервиса или колл-центра. 

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

Инструменты для проектирования приложений

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

Концепция и требования: сквозной пример

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

Концепция мобильного приложения: пример

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

Посмотрите на конкурентов. Скачайте 3–5 похожих продуктов и пройдите в них ключевые сценарии: как устроена запись, сколько шагов до оплаты, на что жалуются в отзывах в сторах. Отзывы с низкими оценками особенно полезны: в них пользователи сами перечисляют, чего им не хватает.

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

• экран открывается не дольше чем за 2 секунды при нормальном соединении;

• поддерживаются iOS и Android последних нескольких версий — конкретные номера фиксируют в ТЗ;

• выдерживается до 5 000 одновременных пользователей;

• персональные данные хранятся на серверах в России и передаются по защищенному каналу;

• интерфейс корректно отображается при увеличенном системном шрифте.

Такие нефункциональные требования часто забывают, а потом спорят о них при приемке.

Чтобы первая версия не растянулась на год, функции делят по методу MoSCoW: 

• Must have — без них продукт не работает; 

• Should have — важные, но можно запустить без них; 

• Could have — приятные дополнения; 

• Won’t have — не в этой версии. 

Для автосервиса запись и напоминания — Must have, оплата в приложении — Should have, программа лояльности — Could have. В разработку первой версии идет первая группа и часть второй.

О том, как определить минимальный набор функций,

— в статье «Что такое MVP и каковы принципы его создания»

Читать статью

Структура экранов и пользовательские сценарии

Структура мобильного приложения — это карта экранов и переходов между ними. Для нашего автосервиса основной путь выглядит так:

Онбординг → Авторизация → Каталог услуг → Карточка услуги → Выбор времени и мастера → Оформление и оплата → Подтверждение → Личный кабинет

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

Пользовательский сценарий описывает, как человек решает задачу по шагам. Например, сценарий «Записаться на замену масла»:

1. Открыть приложение и выбрать «Записаться».

2. Выбрать услугу «Замена масла» и ближайший филиал.

3. Выбрать удобный день и время из свободных слотов.

4. Подтвердить запись — данные автомобиля подставляются из профиля.

5. Получить подтверждение и напоминание за день до визита.

На тестировании проверьте, где пользователь затрудняется, ошибается или совершает лишние действия. Для сложных продуктов сценарии собирают в карту пути клиента (CJM) — с действиями, ожиданиями и проблемами на каждом этапе.

Прототип и проверка на пользователях

Прототипирование приложения — создание модели продукта до разработки. Прототип позволяет «потрогать» продукт, проверить логику и показать его пользователям.

Уровни прототипа:

• скетчи — наброски экранов от руки или на доске, чтобы быстро обсудить идеи;

• wireframe — черно-белые схемы экранов: расположение элементов без визуального стиля;

• кликабельный прототип — связанные экраны, по которым можно «пройти» сценарий, как в настоящем продукте.

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

Чтобы проверить прототип, покажите его 5–7 представителям целевой аудитории и дайте задания: «Запишитесь на замену масла на пятницу», «Найдите историю обслуживания». Наблюдайте, где человек ошибается, сомневается или ищет нужную кнопку. Эти места и нужно исправить.

Подробно о методах — в статье «UX-исследования: что это, методы и когда их проводить»

Читать статью

Обычно нужно 2–3 круга «тест — правки — тест». Первый находит крупные проблемы в логике, второй — детали, третий подтверждает, что все работает. Прототипирование мобильных приложений экономит время: правка в прототипе занимает часы, правка в коде — дни. Кликабельный прототип полезен и за пределами команды: его можно показать руководству, инвесторам или ключевым клиентам до того, как потрачен основной бюджет.

Что дальше: этапы дизайна приложения

Когда логика проверена, начинается дизайн. Этапы дизайна приложения:

1. UI-концепция — визуальный стиль на 2–3 ключевых экранах: цвета, шрифты, иконки, характер интерфейса.

2. UI-кит или дизайн-система — библиотека элементов: кнопки, поля, карточки, навигация.

3. Макеты всех экранов и состояний — включая ошибки, загрузку, пустые списки.

4. Передача в разработку — спецификации, ресурсы, описание анимаций.

В чем разница между UI-китом и дизайн-системой, мы разбирали в статье «UI Kit и дизайн-система: в чем разница и что выбрать для проекта»

Читать статью

Дизайнер учитывает гайдлайны платформ: Apple Human Interface Guidelines для iOS и Material Design для Android. Пользователи привыкли к стандартным паттернам своей системы, а соблюдение гайдлайнов помогает пройти ревью магазинов приложений.

ТЗ и критерии приемки

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

Структура ТЗ:

1. Цели проекта — бизнес-задачи и метрики успеха.

2. Роли пользователей — кто пользуется продуктом: клиент, сотрудник, администратор.

3. Функциональные требования — описание функционала приложения: что делает продукт.

4. Нефункциональные требования — скорость, безопасность, нагрузка, поддерживаемые версии ОС.

5. Пользовательские сценарии — пошаговые пути решения задач.

6. Интеграции — с какими системами обменивается данными.

7. Требования к дизайну — ссылки на прототип, гайдлайны, брендбук.

8. Платформы — iOS, Android, планшеты, веб-версия.

9. Критерии приемки — как проверить, что функция сделана правильно.

Пример ТЗ на разработку мобильного приложения: фрагмент

Функции удобно описывать в формате пользовательских историй: «Как [роль], я хочу [действие], чтобы [ценность]» — с критериями приемки. Для нашего автосервиса:

История 1. Запись на услугу. Как клиент, я хочу выбрать услугу, дату и время, чтобы записаться без звонка. 

Критерии приемки: показываются только свободные слоты; запись занимает не больше 4 экранов; после записи приходит push-уведомление и запись появляется в разделе «Мои записи»; при потере соединения данные формы сохраняются.

История 2. Напоминание о визите. Как клиент, я хочу получить напоминание за день до визита, чтобы не забыть о записи. 

Критерии приемки: push-уведомление приходит за 24 часа; из уведомления можно подтвердить, перенести или отменить запись; если уведомления отключены, напоминание приходит в СМС.

История 3. Управление расписанием. Как администратор, я хочу закрывать слоты в расписании, чтобы клиенты не записывались на время, когда мастер недоступен. 

Критерии приемки: слот закрывается в админ-панели в один клик; изменения отображаются в приложении не позже чем через минуту; уже записанные клиенты получают уведомление об отмене.

Критерии приемки снимают главный источник споров — разное понимание того, что значит «готово».

Для государственных заказчиков и крупных компаний техническое задание часто оформляют по ГОСТ 34: так требуют процедуры закупок и приемки. Для коммерческих проектов с итеративной разработкой удобнее гибкая спецификация: набор пользовательских историй, который уточняется от спринта к спринту.

Архитектура, интеграции и ограничения

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

Упрощенная схема:

Приложение на смартфоне → API → сервер и база данных → внешние сервисы (платежи, карты, push, аналитика) ← админ-панель

• Клиентская часть на смартфоне показывает интерфейс и отправляет запросы, например «покажи свободное время» или «оформи запись».

• API — «переводчик» между смартфоном и сервером: набор правил, по которым они обмениваются данными.

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

• Внешние сервисы — платежные системы, карты, рассылка push-уведомлений, аналитика.

• Админ-панель — веб-интерфейс, в котором сотрудники управляют расписанием, заказами и пользователями без участия разработчиков.

Компоненты и интеграции

Архитектура мобильного приложения складывается из нескольких компонентов. Ниже — что входит в инфраструктуру приложения и что обычно нужно на старте.

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

Внутри приложения код тоже организуют по правилам. Самые распространенные подходы — MVVM (Model-View-ViewModel) и Clean Architecture: интерфейс, бизнес-логика и работа с данными разделены по разным слоям. Для бизнеса это может упростить сопровождение и тестирование. MVVM помогает организовать взаимодействие интерфейса и его состояния. Clean Architecture задаёт принципы разделения ответственности и зависимостей между частями системы. Эти подходы могут сочетаться. Конкретное решение выбирают под требования проекта.

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

Если сервис работает с персональными данными россиян, по 152-ФЗ их нужно хранить на серверах в России. Такие решения сложно менять после запуска, поэтому их фиксируют в архитектуре и ТЗ.

Ограничения и особенности мобильной разработки

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

• Две платформы. iOS и Android — две системы с разными правилами. Нужно либо делать два приложения, либо выбирать кроссплатформенную разработку.

• Нативная или кроссплатформенная разработка. Нативная (Swift, Kotlin) дает максимум производительности и доступа к функциям устройства. Кроссплатформенная (Flutter, React Native) — быстрее и дешевле за счет общего кода.

• Ревью сторов и публикация из России. Приложения проходят проверку App Store и Google Play, а для российской аудитории важен и RuStore. Публикация в зарубежных магазинах для российских компаний связана с ограничениями, которые нужно учитывать заранее.

• Разные размеры экранов — от компактных смартфонов до планшетов и складных устройств.

• Офлайн-режим. Решите заранее, какие функции должны работать без интернета.

• Push-уведомления — сильный инструмент возврата пользователей, но требует продуманной логики, чтобы не раздражать.

• Обновления под новые версии ОС. Apple и Google выпускают новые версии систем каждый год, и продукт нужно адаптировать.

Сроки и стоимость проектирования

Сроки проектирования зависят от числа функций, ролей пользователей и интеграций. Ориентиры по нашей практике:

Стоимость проектирования считают по часам команды: аналитика, UX-дизайнера, архитектора и менеджера. На нее влияют:

• количество ролей пользователей и экранов;

• число и сложность интеграций;

• объем исследований и тестов прототипа;

• формат ТЗ — гибкая спецификация или документ по ГОСТ;

• нужна ли детальная архитектура и оценка нагрузки.

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

Как принять и передать результаты другой команде

Прежде чем переходить к дизайну и разработке, проверьте, что у вас есть:

• концепция с целями и метриками успеха;

• карта экранов, включая состояния ошибок и пустых списков;

• кликабельный прототип ключевых сценариев, протестированный на пользователях;

• ТЗ с пользовательскими историями и критериями приемки;

• описание архитектуры и интеграций;

• оценка сроков и стоимости разработки на основе этих документов;

• исходные файлы прототипа и документов, переданные вашей компании.

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

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

• пропишите в договоре на проектирование передачу исключительных прав на документацию и макеты;

• получите исходные файлы, а не только PDF и ссылки на просмотр;

• попросите глоссарий терминов и список открытых вопросов, которые не успели решить;

• проведите встречу, на которой проектировщики проведут новую команду по прототипу и ТЗ;

• договоритесь, что проектировщики ответят на вопросы разработчиков в первые недели работы.

Ошибки и кейсы Notamedia

Частые ошибки на этапе проектирования:

• Проектирование «для себя». Команда рисует сценарии, как удобно ей, а не пользователям, и не проверяет их на реальных людях.

• Архитектура раньше целей. Технические решения принимают до того, как понятны задачи и требования, и потом подгоняют продукт под выбранные технологии.

• Слишком много функций в первой версии. Все кажется важным, и проект растягивается. Приоритизация помогает отложить второстепенное.

• Забытые состояния экранов. Ошибки, загрузка, пустые списки, отсутствие интернета — если их не спроектировать, разработчики сделают «как получится».

• Нет критериев приемки. Без них заказчик и подрядчик по-разному оценивают готовый продукт.

• Заказчик не участвует. Проектирование без регулярных встреч с бизнесом превращается в угадывание.

Госуслуги Культура. Приложение для «Пушкинской карты» в экосистеме Госуслуг. На этапе проектирования продумали полный путь пользователя: вход через Госуслуги, выпуск виртуальной карты, защита входа PIN-кодом и биометрией, поиск мероприятий по фильтрам и на карте, покупка именных билетов с QR-кодом, который защищает от перекупщиков. Проект получил «Золотое приложение» 2022 года и бронзу в номинации «Лучший usability/UX приложения».

Игра «Зима в Москве». AR-игра, в которой пользователи искали героев «Союзмультфильма» рядом с сотнями городских локаций. На этапе проектирования предусмотрели запасной сценарий для устройств без поддержки AR — сбор героев через обычную карту. Результат: 50 тысяч загрузок и обновлений за первые 3 дня и 61 929 уникальных пользователей.

Зарядье. Приложение-гид по парку для iOS и Android: интерактивная карта, прогулочные маршруты с планированием по времени и расстоянию, аудиогид, AR-функции, регистрация на события и покупка билетов.

Если вы планируете мобильный продукт,

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

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

Для госзаказчиков готовим техническую документацию по ГОСТ.

Часто задаваемые вопросы

Что входит в проектирование мобильного приложения?

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

Сколько стоит проектирование и от чего зависит оценка?

Стоимость считают по часам команды: аналитика, UX-дизайнера, архитектора и менеджера. На нее влияют количество ролей и экранов, число интеграций, объем тестов прототипа и формат ТЗ — гибкая спецификация или документ по ГОСТ. Проектирование MVP обычно занимает 3–4 недели, сложного продукта с интеграциями — до 10 недель.

Чем прототип отличается от дизайна и ТЗ?

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

Что заказчик должен подготовить до старта?

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

Можно ли заказать проектирование отдельно от разработки?

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

Какие материалы нужны для передачи другой команде?

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

Как меняются требования после начала разработки?

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