Разработка дизайна мобильного приложения: правильный подход к UX/UI

6 этапов UX/UI от исследования аудитории до передачи макетов в разработку: что делает дизайнер на каждом шаге, какой результат на выходе, дизайн-система, типичные ошибки заказчика и кейсы из практики FITTIN.

18 июня 2026 Дизайн 14 мин чтения

Разработка дизайна мобильного приложения — это не «нарисовать красивые экраны», а отдельный цикл UX/UI из шести этапов, каждый с конкретным результатом и набором документов. Часть этапов опциональна и опускается в зависимости от типа проекта — об этом будет в обзорной таблице ниже. От того, как именно пройден цикл, зависит, сколько денег сожжёт переделка после релиза и сколько раз пользователь откроет приложение второй раз.

Когда нужен UX/UI-дизайн и зачем

UX/UI-дизайн нужен в трёх ситуациях: новое приложение с нуля, редизайн действующего продукта, добавление крупной функциональности к работающему приложению. В каждом случае объём работ разный, но логика одна — сначала разобраться, какие задачи пользователь решает в продукте, и только потом рисовать экраны.

Этап дизайна — критическая точка проекта. Именно здесь закладывается, какие сценарии будут работать с первого релиза, а какие потребуют дорогих переделок в коде, повторной публикации в Google Play и App Store, ожидания модерации в сторах. Изменение, которое на стадии макета вносится за минуты, после релиза стоит часов работы разработчика, выкатки обновления и времени модерации. По нашему опыту на проектах FITTIN, каждый месяц работы без оформленной дизайн-системы добавляет около недели рутинной работы команды разработки на пересборку экранов: у каждого экрана свои отступы, цвета кнопок и состояния, разработчик догадывается, как должно быть.

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

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

Из чего состоит UX/UI-дизайн приложения

Полный цикл UX/UI-дизайна для мобильного приложения — это шесть последовательных этапов. Первые два — UX-блок: разобраться в пользователе и спроектировать логику. Следующие три — UI-блок: нарисовать структуру, оформить под бренд, собрать прототип. Шестой — переход в разработку.

Разберём состав работ по этапам, результат на выходе и пометку обязательности. Два этапа (Wireframes и Прототип) часто опускаются — это нормальная вариативность, а не упрощение.

Этапы 1–6 — типовая методология индустрии. На платформенных моделях (вроде модульной Flutter-платформы FITTIN) состав работ отличается — об этом отдельный раздел ниже.

Этап 1. Исследование пользователей и конкурентов

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

Состав работ обычно занимает 1–2 недели на типовое приложение для интернет-магазина. Меньше — если есть веб-аналог с данными по сценариям. Больше — если продукт принципиально новый и аналогов в индустрии нет.

Что получаем на выходе этапа исследования

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

Когда этап исследования можно сократить

Если у заказчика уже работающий веб-аналог с метриками — исследование сокращается до проверки 3–5 гипотез: какие задачи переносятся в мобильный канал, какие сценарии меняются на мобильном, что нужно добавить из-за специфики канала (push, геолокация, оффлайн). База классической методологии юзабилити-исследования — статьи Nielsen Norman Group; материал полезен для подготовки интервью и формулировки гипотез.

Чек-лист этапа исследования

• Проведено 5–8 интервью с реальными пользователями целевого сегмента.
• Изучены 3–5 конкурентов в той же нише с разбивкой по сценариям.
• Собраны метрики веб-аналога или старого приложения, если они есть.
• Зафиксированы шаги, на которых пользователь сдаётся в текущем продукте.

Этап 2. Сценарии и информационная архитектура

Информационная архитектура (IA) — это дерево экранов и переходов. На этом этапе ещё нет ни одного готового макета: есть только список экранов, их роли и связи. Хорошая IA отвечает на простой вопрос: за сколько касаний пользователь может попасть к ключевому действию (купить, оставить заявку, посмотреть статус доставки)? Если ответ — больше трёх касаний для частой задачи, IA нужно пересобирать.

Customer journey map (CJM) — карта пути по сценариям. Для каждого ключевого сценария фиксируются: точка входа (что заставило пользователя открыть приложение), шаги внутри сценария, ожидание на каждом шаге, момент завершения. Для интернет-магазина типичные сценарии — «купить впервые», «повторно купить», «посмотреть статус заказа», «оформить возврат». Каждый сценарий — отдельная цепочка экранов.

Что получаем на выходе этапа сценариев и IA

• Customer journey map по 4–6 ключевым сценариям.
• Карта экранов в виде дерева — обычно 20–60 экранов для типового мобильного приложения интернет-магазина.
• Описание навигации: вкладки нижнего меню, переходы между разделами, поведение «назад» в разных контекстах.

Этап занимает 1–2 недели работы дизайнера. Дольше — если приложение мультиролевое (B2B-кабинет + клиентский интерфейс в одном приложении) или включает сложные процессы вроде многошагового оформления. Если в проекте предусмотрен корпоративный модуль для сотрудников и клиентский интерфейс одновременно — этап удлиняется, потому что роли проектируются отдельно.

Чек-лист этапа сценариев и IA

• Описано 4–6 ключевых сценариев в формате customer journey.
• Каждый сценарий проверен: ≤3 касаний до целевого действия.
• Карта экранов нарисована до начала UI-этапа.
• Поведение «назад» прописано для каждой точки навигации.

Этап 3. Wireframes — структура без графики

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

В типовой методологии wireframes делаются на 15–30 ключевых экранов — главные точки сценариев, сложные формы, состояния ошибок. Остальные экраны (более типовые) собираются позже сразу в финальном UI на основе утверждённых паттернов.

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

Что получаем на выходе этапа wireframes

• Wireframes ключевых экранов в одном Figma-файле (обычно 15–30 экранов).
• Подписи к каждому экрану: что это за состояние, какие данные показываются, какие действия доступны.
• Заметки по навигации между экранами — как именно пользователь попадает с одного на другой.

Когда wireframes можно пропустить

Этап опускают на проектах, где платформа уже задаёт структуру (например, типовой интернет-магазин с базовыми сценариями каталога и корзины). В этом случае дизайнер сразу переходит к UI на основе утверждённых паттернов. На типовое приложение этап занимает 1 неделю работы; если структура принципиально новая (нет аналога в индустрии) — 2 недели.

Этап 4. UI-дизайн и дизайн-система

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

Дизайн-система — это не отдельный документ «на потом», а параллельный продукт этапа. По мере того как дизайнер прорабатывает экраны, в Figma формируется библиотека компонентов: кнопки, поля ввода, карточки, чипы, состояния. Каждый компонент имеет варианты — обычное состояние, нажат, неактивен, ошибка, загрузка.

Что входит в дизайн-систему

• Токены — цвета (основной, второй, акценты, текст, фоны, ошибка, успех), типографика (размеры заголовков, основного текста, подписей), отступы (сетка 4 или 8 px).
• Компоненты — переиспользуемые элементы (кнопки, поля, карточки) с состояниями.
• Паттерны — типовые сборки экранов (списочный, карточный, форма, пустое состояние, экран ошибки).
• Гайдлайны — правила: когда использовать какой стиль кнопки, как формулировать ошибки, как показывать загрузку.

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

Инструменты этапа UI

Стандартный инструмент дизайна и совместной работы команды — Figma: макеты, библиотека компонентов, комментарии и сверка с разработкой живут в одном файле. Альтернативы (Sketch, Adobe XD) используются реже — российские команды стандартизировались на Figma.

Этап 5. Прототип и тестирование

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

Юзабилити-тестирование строится по простому принципу: пользователю даётся задача («оформите заказ на 3 000 рублей с самовывозом»), и наблюдатель смотрит, как именно человек её выполняет. Не «нравится ли вам?», а «сделайте». Все шаги, где пользователь задумывается дольше 3–5 секунд или делает не то, что ожидал дизайнер, — потенциальные точки переделки.

Этап обычно занимает 1–2 недели: подготовка прототипа, рекрут пользователей, проведение сессий, сведение правок.

Что получаем на выходе этапа прототипирования

• Интерактивный прототип в Figma с переходами между экранами на ключевых сценариях.
• Список правок по итогам юзабилити-сессий — что нужно поменять и почему.
• Опционально — короткие записи сессий (с согласия пользователей), на которые можно сослаться при обсуждении правок.

Когда этап прототипирования можно пропустить

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

Этап 6. Передача дизайна в разработку и поддержка дизайн-системы

Передача в разработку — это формальная сдача макетов команде разработки. Минимум — расшаренный Figma-файл с финальными экранами и доступ к слоям. Хорошо — Figma плюс дизайн-система с описанием отступов, состояний компонентов, поведения в разных размерах экрана. Идеально — синхронизация Figma-библиотеки и UI-кита разработчика: когда дизайнер добавляет новый компонент, он подтягивается в кодовую базу.

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

Что входит в полную передачу дизайна

• Финальный Figma-документ с актуальными версиями экранов.
• Описание состояний компонентов (нажат, неактивен, загрузка, ошибка, пустое состояние).
• Спецификация анимаций и переходов: длительность, easing, что движется.
• Гайдлайны по типографике, отступам, иконографике.
• Регламент: как добавлять новые экраны в дизайн-систему, чтобы она не разваливалась.

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

Дизайн на платформе FITTIN: чем отличается состав работ

Описанная выше методология — это полный цикл UX/UI-дизайна с нуля. На модульной Flutter-платформе FITTIN базовая UX-сетка типового приложения интернет-магазина уже отрисована: каталог, корзина, оформление заказа, личный кабинет, программа лояльности — типовые сценарии для e-commerce реализуются на готовых модулях. Дизайнер не проектирует структуру с нуля, а кастомизирует базовую сетку под бренд.

Что это меняет в составе работ:

• Этапы 1–2 (исследование и сценарии) — сокращаются. Базовые сценарии интернет-магазина уже учтены в архитектуре платформы, исследование нужно только для специфики бренда: уникальная программа лояльности, специфические сценарии возврата, особенности оформления заказа.
• Этап 3 (wireframes) — на платформе не делается отдельно. Базовая структура экранов уже зашита в модулях, дизайнер сразу переходит к UI-этапу.
• Этап 4 (UI-дизайн и дизайн-система) — основной этап. Дизайнер кастомизирует базовую UX-сетку под бренд: цвета, шрифты, иллюстрации, иконографика, состояния. На выходе — комплект готовых макетов на ключевые экраны (обычно 20–40 макетов для типового e-commerce) и обновлённая дизайн-система с фирменными токенами.
• Этап 5 (прототип и тестирование) — не входит в состав платформенного дизайна. Базовые сценарии платформы уже протестированы на ранее реализованных проектах. Тестирование требуется только для специфических, нестандартных сценариев бренда — выносится в отдельную работу.
• Этап 6 (передача в разработку) — сокращается, потому что у дизайнера и команды разработки общая база: дизайн-система платформы и UI-кит Flutter-кода построены на одних и тех же компонентах. Дизайнер обновляет фирменные параметры (цвета, шрифты, иконки, отступы) в дизайн-системе, разработчик переносит изменения в код вручную — пересоздавать сами компоненты с нуля не нужно.

Для проектов вне платформенной модели — кастомных приложений, MVP, продуктов с нетиповой структурой — мы работаем по полному циклу UX/UI с шестью этапами, как описано выше.

Чем платформенная модель полезна для заказчика

Если сложить сроки этапов из таблицы, на типовое e-commerce-приложение полный цикл с нуля занимает около 7–10 недель работы дизайнера (1–2 + 1–2 + 1–2 + 3–6 + 1–2 + сопровождение). Платформенный цикл — около 3–4 недель (3–5 дней + сокращённые сценарии + 2–3 недели UI + сокращённая передача в разработку). Отсюда и разница в сроках в 2–3 раза для типового проекта. Сэкономленное время — это либо более ранний релиз, либо больше итераций на специфической части (то, что отличает бренд от типового магазина). Если в проекте нужны и мобильное приложение интернет-магазина, и сайт на той же кодовой базе, дизайн готовится единый — типографика, цвета и компоненты переиспользуются между двумя продуктами.

Сколько стоит UX/UI-дизайн приложения

Стоимость UX/UI-дизайна зависит от двух факторов: объём экранов и зрелость существующей дизайн-системы. Дизайн с нуля для типового e-commerce-приложения — 200 000–500 000 ₽ по рынку, по нашей практике. Редизайн действующего продукта с сохранением логики — обычно 150 000–300 000 ₽, потому что не нужна стадия исследования и проектирования сценариев.

На что приходятся основные расходы:

• Исследование (этап 1) — 10–15% бюджета. Интервью, анализ конкурентов, сбор данных по существующему продукту.
• Сценарии и IA (этап 2) — 10–15% бюджета. Customer journey, карта экранов, навигация.
• Wireframes (этап 3) — 10% бюджета. Низкодетализированные макеты ключевых экранов.
• UI-дизайн и дизайн-система (этап 4) — 50–60% бюджета. Самая трудоёмкая часть цикла.
• Прототип и тестирование (этап 5) — 10% бюджета. Интерактивный прототип, юзабилити-сессии.
• Передача в разработку и сопровождение (этап 6) — 5–10% бюджета. Передача макетов, поддержка дизайн-системы.

На платформе FITTIN стоимость дизайна для типового интернет-магазина ниже за счёт сокращения этапов: исследование сокращено до специфики бренда, wireframes не делаются, прототип не входит в стандартный состав работ. Биллинг — по ставке дизайнера и часам работы; со сметой и оценкой по часам перед стартом задачи. Подробности по тарифам — на странице стоимости разработки.

Как выбрать дизайн-команду

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

Семь критериев для оценки:

1. Состав работ на проекте. Команда должна чётко описывать, какие этапы из шести выше она делает, какие — нет, и почему. Если в составе работ только «дизайн макетов» — без исследования и без дизайн-системы — это не полный цикл, а декоративная стадия.
2. Дизайн-система как самостоятельный документ. Спросите, что заказчик получает помимо макетов: есть ли библиотека компонентов в Figma, описаны ли состояния, есть ли регламент развития системы. Без этих документов команда поддержки воспроизводит экраны по своему чутью.
3. Опыт работы с разработчиками. Хороший дизайнер знает, что в коде, и не рисует невозможное. Опросите про работу с разработкой: как передавал макеты, как решал конфликты, как обрабатывал «дорисовать срочно три экрана».
4. Реальные кейсы в нише. Дизайн интернет-магазина и дизайн корпоративного приложения — разные миры. У команды должны быть проекты в близкой нише — fashion, e-commerce, доставка, услуги. Перед стартом полезно посмотреть список реализованных проектов с возможностью открыть страницу кейса с метриками.
5. Детализированная декомпозиция бюджета. Команда должна расписать, сколько часов уходит на каждый этап и почему. Единая цифра «дизайн — 350 000 ₽» без декомпозиции — повод задать вопросы.
6. Гайдлайны и платформенные стандарты. Дизайнер должен знать iOS Human Interface Guidelines и Material Design 3 для Android. Не цитировать наизусть, а уметь объяснить, почему в этом проекте мы соблюдаем гайдлайны, а где сознательно отступаем.
7. Доступ к работающим приложениям. Лучшее портфолио — приложение, которое сейчас в магазине и которым пользуются. Скачайте, посмотрите, как оно работает: совпадает ли макет с реальностью.

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

Кейсы FITTIN: примеры дизайна интерфейсов

Три проекта из практики, где дизайн интерфейса определял результат — от детского fashion до премиального сегмента и от программы лояльности до сложного каталога.

DAISYKNIT — миграция fashion-бренда с готового решения на собственное приложение

Российский fashion-бренд. Задача — перевести бренд с готового стороннего приложения на собственное кроссплатформенное, не потеряв при этом существующую клиентскую базу. Дизайн разрабатывался с двойной целью: с одной стороны сохранить узнаваемый стиль бренда для старой аудитории, с другой — внедрить новые сценарии, которых не было в стороннем решении. Из нестандартного UX — игровая механика адвент-календаря с бонусами, отдельно спроектированная как часть фирменной коммуникации. По данным страницы кейса — миграция прошла с сохранностью клиентской базы 100%, проект — финалист Workspace Digital Awards 2026.

Gulliver — мультибрендовый магазин детских товаров

Один из крупнейших российских ретейлеров детских товаров. Задача дизайна — персонализированная витрина и понятные сценарии программы лояльности. UI собран под крупный каталог: компактные карточки, фильтрация по нескольким атрибутам одновременно, акцент на быстрый поиск. Дизайн-система включает много типов карточек: товар, акция, рубрика, бренд внутри магазина. По данным страницы кейса — на приложение приходится 50% дохода бренда и 80% мобильного трафика.

IDOL — приложение премиального fashion-бренда

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

Полный список реализованных проектов — на странице кейсов. По нашей практике на проектах в e-commerce и ритейле дизайн-система формируется параллельно с первым релизом и остаётся с продуктом на годы.

Частые ошибки заказчика на этапе дизайна

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

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

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

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

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

5. Заказывают много итераций правок «как получится». Без зашитого в договор лимита (например, 1–2 итерации на экран) количество правок раздувается, бюджет растёт, контрольный срок уезжает. Лучше зафиксировать число итераций заранее и строго следовать.

FAQ

Итог: чек-лист правильного подхода

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

• Этап 1 (исследование) — проведён или сознательно пропущен с обоснованием.
• Customer journey по 4–6 ключевым сценариям описан.
• Карта экранов нарисована до начала UI-этапа.
• Wireframes — сделаны для ключевых экранов или сознательно пропущены, если структура заранее задана платформой.
• Финальные макеты привязаны к дизайн-системе с описанными состояниями компонентов.
• Дизайн-система передаётся заказчику как отдельный документ.
• Юзабилити-тестирование прототипа проведено либо запланировано на post-launch (если этап в проекте предусмотрен).
• Передача дизайна в разработку формализована: Figma-документ плюс описание состояний плюс библиотека компонентов.
• Зафиксировано число итераций правок в контракте.
• Дизайнер остаётся на проекте до релиза для дополнительных вопросов.

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

Что ещё почитать рядом с темой

• Услуги: аудит UX/UI, аудит мобильного приложения, разработка ТЗ.
• Для интернет-магазинов: приложение интернет-магазина, сайт и приложение на одной базе, сайт интернет-магазина.
• Сценарии вне e-commerce: корпоративные приложения для сотрудников, разработка MVP, кастомные сайты и лендинги.
• Параметры проекта: калькулятор стоимости, тарифы по разработке, реализованные проекты.
• Внешние гайдлайны: правила доступности Material Design 3.

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации. Цены и сроки актуальны на 18 июня 2026 и могут меняться; точная смета собирается после согласования ТЗ.

---