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

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

Ниже — практичный разбор, как формируется стоимость веб-дизайна и UX/UI-дизайна приложения, какие диапазоны цен подтверждаются источниками, что закладывать в ТЗ и смету, и как сравнивать предложения студий и фрилансеров без иллюзий. Фокус — на управляемости бюджета и измеримом результате, а не на «красоте ради красоты».

Key Takeaways

• Стоимость дизайна зависит не от «количества страниц», а от сложности сценариев, уровня проработки UX, количества состояний, адаптивов и требований к системе компонентов.
• По данным Purrweb, UI/UX-дизайн веб-платформы может начинаться от 600 000 ₽ за простой проект 5–8 страниц, а сложные экосистемы — от 2,5 млн ₽: источник.
• Для дизайна приложения в 2026 году в источниках встречаются оценки от 270–450 тыс. ₽ для простого приложения и выше для среднего/сложного: источник; также упоминается диапазон 380–750 тыс. ₽: источник.
• Чтобы не переплатить, фиксируйте объём работ через карту экранов/состояний, перечень артефактов (прототип, UI-kit, дизайн-система), критерии приёмки и формат сопровождения разработки.
• Сравнивайте предложения по структуре работ и рискам: дешёвый дизайн без UX и спецификаций часто приводит к переделкам на разработке и удорожанию проекта.

Сколько стоит дизайн сайта в 2026 году: ориентиры по рынку

Если отвечать прямо: сколько стоит дизайн сайта — зависит от типа продукта и глубины UX/UI, а подтверждённые источниками диапазоны лежат от десятков тысяч рублей за базовые решения до миллионов за сложные платформы. Например, Lead-Hub указывает вилку от 8 000 до 600 000 ₽ для дизайна сайта в целом, а также ориентиры по типам сайтов: источник. Для UI/UX веб-платформ у Purrweb простые проекты стартуют от 600 000 ₽: источник.

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

Какие типы работ скрываются под словом «дизайн» (и почему из-за этого расходятся цены)

Цена отличается потому, что «дизайн» может включать только UI (визуал) или полный цикл UX/UI с исследованиями, прототипами и поддержкой разработки. Один подрядчик считает экраны, другой — сценарии и состояния, третий — часы. Пока вы не зафиксировали состав работ и артефакты, сравнивать сметы некорректно.

UX-часть: что может входить

UX обычно включает выявление задач пользователей, проектирование структуры и сценариев, прототипирование и проверку гипотез. В B2B это часто означает интервью с продажами/саппортом, разбор воронки и формулирование требований к формам, фильтрам, ролям и правам доступа. Если UX не делается, риск «красивого, но неудобного» интерфейса резко растёт.

UI-часть: что может входить

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

Артефакты на выходе: что вы реально покупаете

Чтобы цена была управляемой, фиксируйте артефакты: карта сайта/продукта, прототипы, макеты в Figma, UI-kit, дизайн-система, спецификации для разработчиков, кликабельный прототип, набор иконок и состояния компонентов. Отдельно оговаривайте design QA — проверку реализации на фронтенде. Без этого «дешёвый дизайн» часто превращается в дорогое исправление.

От чего зависит стоимость дизайна сайта: 12 факторов, которые реально двигают бюджет

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

• Тип проекта: лендинг, корпоративный сайт, интернет-магазин, веб-платформа, личный кабинет.
• Количество уникальных страниц/экранов и глубина вложенности.
• Сценарии и роли: гость, пользователь, менеджер, админ; права доступа.
• Количество состояний: ошибки, пустые списки, загрузка, отключённые кнопки, успех/неуспех оплаты.
• Адаптивы: desktop/tablet/mobile, а также особенности iOS/Android для приложений.
• Наличие контента: тексты, фото, иллюстрации, инфографика, и кто это делает.
• Интерактивность: калькуляторы, конфигураторы, сложные формы, фильтры, сравнение.
• Требования к бренду: ребрендинг, гайдлайны, тональность визуала.
• Уровень UX: исследования, тестирование прототипов, аналитика.
• Нужна ли дизайн-система или достаточно UI-kit.
• Сроки и параллельность работ (ускорение почти всегда удорожает).
• Формат передачи в разработку: спецификации, токены, handoff, дизайн QA.

Практический совет: попросите подрядчика оценивать не «страницы», а матрицу экранов (экран × состояние × адаптив). Тогда вы увидите, что «10 страниц» могут превратиться в 120 макетов, если учесть мобильную версию, ошибки и пустые состояния. Это самый частый источник конфликтов по бюджету.

Цены на дизайн сайта по типам: лендинг, корпоративный, e-commerce, веб-платформа

Ориентиры по типам проектов лучше брать из источников, где цены разнесены по категориям. Например, Lead-Hub приводит: лендинг — от 30 000 ₽, корпоративный сайт — от 80 000 ₽, интернет-магазин — от 150 000 ₽, веб-приложение — от 250 000 ₽: источник. Но для продуктовых веб-платформ с UX и дизайн-системой бюджеты в источниках достигают миллионов: Purrweb.

Таблица: что обычно входит в дизайн разных типов сайтов

Ниже — практичная «карта ожиданий». Это не прайс, а способ сверить состав работ, чтобы одинаково понимать, что именно вы покупаете. Чем правее по таблице, тем чаще нужен продуктовый UX, компоненты и спецификации, а не только визуал.

Если вы выбираете подрядчика на «корпоративный сайт», но внутри есть личный кабинет, заявки, статусы, история действий и роли — вы фактически покупаете кусок веб-платформы. В таком случае логичнее ориентироваться на подходы и цены из сегмента UX/UI для продуктов, а не на «дизайн страниц».

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

В источниках на 2026 год встречаются устойчивые вилки для дизайна приложений: Purrweb пишет, что простое приложение с базовым функционалом — 270–450 тыс. ₽, среднее — 450–750 тыс. ₽, сложное — от 750 тыс. ₽: источник. В материале Viton13 также приводится оценка Purrweb (июль 2026) 380–750 тыс. ₽ и упоминается, что у Пиробайта простое приложение начинается от 300 тыс. ₽: источник.

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

Почему дизайн приложения часто дороже, чем дизайн сайта

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

Когда веб-приложение по бюджету догоняет мобильное

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

Сайт vs веб-платформа vs приложение: как выбрать правильную модель оценки

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

1. Опишите цель: лидогенерация/бренд (сайт) или регулярная работа пользователя (продукт).
2. Составьте список ролей и ключевых задач каждой роли.
3. Набросайте карту экранов и обязательно — список состояний (ошибка, пусто, загрузка, успех).
4. Решите, нужен ли MVP по UX/UI или сразу «полный» дизайн с дизайн-системой.
5. Выберите модель контракта: фикс-прайс по артефактам или time & materials по часам.

Если у вас нет продуктового опыта, полезно привлечь внешнего консультанта на 1–2 сессии, чтобы корректно сформулировать объём и критерии. Это дешевле, чем оплачивать «исправление понимания» внутри большой дизайн-сметы. Также заранее решите, кто владеет продуктовой аналитикой и требованиями — бизнес или подрядчик.

Диапазоны цен из источников: что можно считать подтверждёнными ориентирами

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

Обратите внимание, что источники дают разные «вилки» по одному и тому же слову «дизайн сайта»: где-то это ближе к графическому оформлению, а где-то — к UX/UI веб-платформы с дизайн-системой. Поэтому ключевой управленческий навык — правильно классифицировать ваш проект. Если вы сомневаетесь, ориентируйтесь на сценарии и наличие личного кабинета/логики.

Как формируется смета: этапы UX/UI и что обычно оплачивается отдельно

Смета на UX/UI обычно складывается из этапов: погружение, UX-проектирование, UI-дизайн, подготовка к разработке и сопровождение. Отдельно могут считаться исследования, тестирование, контент, иллюстрации, анимации и дизайн-система. Чем прозрачнее разбиение на этапы и артефакты, тем ниже риск «внезапных доплат».

Типовой пайплайн работ (для сайта/веб-продукта)

1. Discovery: цели бизнеса, аудитория, ограничения, конкурентный обзор.
2. UX: информационная архитектура, пользовательские потоки, прототипы.
3. UI: визуальная концепция, компоненты, макеты ключевых экранов и состояний.
4. Handoff: спецификации, токены/стили, экспорт ассетов, описание логики.
5. Сопровождение: ответы разработке, design QA, правки по факту реализации.

Что часто забывают включить (а потом это превращается в «допработы»)

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

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

Дизайн-система: когда она нужна и почему может стоить дорого

Дизайн-система нужна, когда продукт развивается, команд несколько, экранов много и важно удерживать консистентность без постоянных «перерисовок». По источнику о ценах 2026 дизайн-система может оцениваться в диапазоне 800 000 ₽ — 10 млн ₽: источник. Это не «набор кнопок», а набор правил, компонентов, токенов и процессов.

Признаки, что дизайн-система окупится

• Есть продуктовая дорожная карта на 6–12 месяцев и регулярные релизы.
• Над интерфейсом работают 2+ дизайнеров или несколько команд разработки.
• Много повторяющихся сущностей: таблицы, карточки, формы, статусы.
• Нужно быстро собирать новые разделы без потери качества.
• Есть требования к бренду и единообразию во всех каналах (web + mobile).

Когда достаточно UI-kit

Если у вас небольшой сайт или MVP приложения, часто достаточно UI-kit: набор базовых компонентов и стилей без глубокой методологии и документации. Это дешевле и быстрее, а при росте продукта UI-kit можно «эволюционировать» в дизайн-систему. Важно лишь заложить модульность и не рисовать каждый экран как уникальную картинку.

Кто делает дизайн: фрилансер, студия, in-house — как это влияет на стоимость и риски

Стоимость зависит не только от объёма, но и от модели исполнителя: фрилансер обычно дешевле, студия — дороже, in-house требует постоянных затрат. Разница проявляется в управлении рисками: наличие арт-директора, UX-ресёрчера, процесса качества и способности выдерживать сроки. Для B2B-продуктов часто важнее предсказуемость, чем минимальная цена.

Сравнение моделей исполнителя (практический взгляд)

Если вы выбираете студию, полезно смотреть не только портфолио, но и то, как они передают дизайн в разработку: спецификации, правила компонентов, и как ведут design QA. В этом контексте может помочь каталог проверенных подрядчиков — Verified IT company catalog, чтобы собрать шорт-лист и сравнить специализации.

Как оценить объём работ до сметы: быстрый фреймворк для бизнеса

До запроса сметы можно быстро прикинуть объём, если перевести идею в список сценариев и экранов. Рабочий фреймворк: роли → задачи → пользовательские потоки → экраны → состояния → адаптивы. Это занимает 2–4 часа на воркшопе, но экономит недели переписки и снижает риск, что подрядчик «не то понял».

Шаблон «матрицы экранов» (что попросить у подрядчика)

• Экран/страница: название и цель (например, «Карточка заказа — изменить статус»).
• Состояния: загрузка, пусто, ошибка, успех, нет прав, нет сети (для mobile).
• Компоненты: таблицы, фильтры, формы, модалки, уведомления.
• Адаптивы/платформы: desktop/mobile или iOS/Android.
• Источник данных: ручной ввод, API, интеграция; какие статусы возможны.

Эта матрица помогает убрать магию из оценки: вы начинаете обсуждать не вкусы, а конкретные единицы работы. Если матрица «раздувается», это сигнал либо резать scope (делать MVP), либо закладывать бюджет на дизайн-систему и компоненты. Для продуктовых команд это ещё и основа для бэклога разработки.

Практические сценарии (мини-кейсы): как меняется цена при разных вводных

Ниже — 5 иллюстративных сценариев (гипотетические примеры), чтобы показать, какие решения повышают или снижают стоимость. Они не заменяют оценку, но помогают заранее увидеть «драйверы бюджета». Используйте их как чек-лист вопросов к подрядчику при брифинге.

Сценарий 1: лендинг для B2B-сервиса с быстрым запуском

Иллюстративно: компании нужен лендинг под новый продукт и тест спроса за 2–3 недели. Чтобы удержать бюджет, команда делает один визуальный концепт, 1–2 адаптива, использует готовые компоненты и минимизирует кастомные иллюстрации. Дороже станет, если добавить квиз, калькулятор, анимации и параллельно делать бренд-гайд.

Сценарий 2: корпоративный сайт с большим объёмом контента

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

Сценарий 3: интернет-магазин с акциями и сложным каталогом

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

Сценарий 4: веб-платформа (кабинет партнёра) с ролями и правами

Иллюстративно: у продукта есть партнёр, менеджер, админ; разные права на документы и отчёты. Здесь дизайн быстро становится продуктовым: нужна информационная архитектура, таблицы, фильтры, экспорт, уведомления, аудит действий. Экономить разумнее через MVP по сценариям и дизайн-систему на ключевых компонентах, чем через сокращение UX-этапа.

Сценарий 5: мобильное приложение с подписками и онбордингом

Иллюстративно: приложение требует регистрации, восстановления доступа, подписки, paywall и работы без сети. Цена растёт из-за платформенных различий, юридических экранов, сценариев отмены/возврата и множества ошибок. Чтобы не переплатить, фиксируйте список обязательных экранов для релиза 1.0 и переносите «приятные» улучшения в следующий спринт дизайна.

Как не переплатить за дизайн: 10 управленческих приёмов

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

1. Начинайте с MVP по сценариям, а не с «урезанного дизайна» на всех экранах.
2. Фиксируйте состав артефактов: прототип, UI-kit/дизайн-система, спецификации, дизайн QA.
3. Ограничьте итерации: например, 2 раунда правок на концепт и 1 раунд на каждый ключевой экран.
4. Согласуйте референсы и критерии «нравится/не нравится» до начала UI-фазы.
5. Разделите задачи: дизайн и контент (тексты/фото) — разные потоки с владельцами.
6. Используйте компонентный подход: один раз проработать таблицу/форму, затем переиспользовать.
7. Раннее прототипирование: кликабельный прототип выявляет ошибки дешевле, чем правки на фронтенде.
8. Закладывайте время на handoff: без спецификаций разработка будет задавать вопросы и тормозить.
9. Договоритесь о правилах изменений: что считается change request и как оценивается.
10. Планируйте дизайн-спринты синхронно с разработкой, чтобы не было «дизайн готов, но уже устарел».

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

Как правильно составить ТЗ на UX/UI-дизайн, чтобы получить точную цену

Точная цена появляется там, где есть чёткое ТЗ: цели, аудитория, состав экранов, ограничения и критерии приёмки. Хорошее ТЗ не обязано быть на 40 страниц — достаточно структуры, которая исключает двусмысленность. Чем меньше «додумываний» остаётся подрядчику, тем меньше риск, что смета вырастет после старта.

Минимальная структура ТЗ (подходит и для сайта, и для приложения)

• Цели проекта: метрики (лиды, регистрации, заявки, покупки) и приоритеты.
• Аудитория и сегменты: кто пользователь и в каком контексте использует продукт.
• Список ролей и прав доступа (если есть кабинет/админка).
• Карта экранов + матрица состояний (что обязательно в релиз 1).
• Контент: кто пишет тексты, кто готовит фото/иллюстрации, требования к стилю.
• Технические ограничения: CMS/фреймворк, интеграции, сроки, требования безопасности.
• Артефакты: прототип, макеты, UI-kit/дизайн-система, спецификации, дизайн QA.
• Процесс согласований: кто утверждает, сроки ответа, количество итераций.

Критерии приёмки: как сделать так, чтобы «готово» было измеримо

Критерии приёмки — это не «нравится/не нравится», а проверяемые условия: макеты для всех экранов из списка, все состояния и адаптивы, согласованный UI-kit, кликабельный прототип ключевых сценариев, спецификации для разработчиков. Для приложений отдельно фиксируйте платформы (iOS/Android) и особенности компонентов. Это защищает обе стороны: вы получаете ожидаемый объём, подрядчик — понятные границы.

Как проверять подрядчика и коммерческое предложение: чек-лист для закупки

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

1. Какие артефакты вы передаёте и в каком виде (Figma, спецификации, прототип)?
2. Как вы считаете объём: экраны, сценарии, часы, компоненты? Покажите пример оценки.
3. Кто будет на проекте: UX, UI, арт-директор, менеджер, и сколько времени каждого?
4. Как устроены согласования и сколько итераций включено?
5. Есть ли опыт в нашей нише (B2B, e-commerce, SaaS) и что из него переносится?
6. Как вы обеспечиваете качество передачи в разработку (handoff, дизайн QA)?
7. Что считается изменением scope и как оно оценивается?
8. Как вы работаете с контентом и микрокопирайтом?
9. Какие риски вы видите в проекте и как предлагаете их снять?

Если вы параллельно планируете продвижение, полезно оценивать подрядчиков в связке «дизайн + маркетинг». Иногда разумнее координировать интерфейс с будущими рекламными гипотезами и посадочными страницами. Для ориентира по выбору партнёров можно посмотреть категорию Реклама и маркетинг — это помогает собрать связку «дизайн → трафик → конверсия».

Скрытые расходы и типовые ошибки, из-за которых UX/UI дорожает

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

Топ-7 причин перерасхода

• Нет владельца требований: решения принимаются «по кругу», правки бесконечны.
• Не описаны состояния и ошибки: их добавляют в конце, когда всё уже сверстано в макетах.
• Контент не готов: дизайнер вынужден «подставлять рыбу», а потом всё переделывать под реальные тексты.
• Появляется новая роль/права доступа: меняется навигация и логика интерфейса.
• Не учли аналитику и события: нужно встраивать дополнительные элементы/потоки.
• Нет handoff-спецификаций: разработка возвращает вопросы и тормозит, появляются «допчасы».
• Отсутствует design QA: баги интерфейса исправляются уже после релиза.

Ещё один практичный фактор — доступность кадров. Если вы планируете усиливать команду, заранее сверяйте рынок: какие роли нужны (UX, UI, продуктовый дизайнер) и как быстро их можно найти. В этом помогает страница Open IT vacancies: по вакансиям видно, какие компетенции востребованы и где может быть конкуренция за специалистов.

Как связаны стоимость дизайна и стоимость разработки (и почему дешевле не всегда выгоднее)

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

Что спросить у разработчиков до старта дизайна

1. Какая технологическая база и есть ли готовая компонентная библиотека?
2. Нужны ли дизайн-токены и как они будут использоваться?
3. Какие ограничения у API и какие статусы реально приходят в интерфейс?
4. Какие требования к адаптиву и поддерживаемым браузерам/устройствам?
5. Кто принимает решение, если дизайн конфликтует с техническими ограничениями?

Если у вас продукт с ИИ-функциями (рекомендации, генерация, ассистенты), UX усложняется: нужно проектировать доверие, объяснимость и обработку ошибок модели. В таких случаях полезно заранее оценить, кто будет отвечать за продуктовую часть ИИ и интерфейсные паттерны. По теме подрядчиков можно ориентироваться на категорию Разработка ИИ, чтобы понимать, как дизайн будет стыковаться с ML-частью.

Практический чек-лист: как подготовиться и запустить UX/UI-дизайн без хаоса

Ниже — пошаговый список действий, который можно взять как план на 7–14 дней подготовки. Он помогает собрать входные данные, выбрать подрядчика и зафиксировать объём так, чтобы цена была объяснимой, а результат — приемлемым для разработки. Это не «идеальный процесс», а рабочий минимум для бизнеса, который ценит время.

1. Сформулируйте цель и KPI: что должно измениться после запуска (лиды, регистрации, заявки).
2. Соберите референсы: 3–5 примеров «как надо» и «как не надо», с комментариями почему.
3. Опишите аудиторию и роли, включая внутренние роли (менеджер, админ).
4. Сделайте черновую карту экранов и матрицу состояний.
5. Определите состав артефактов: прототип, UI-kit/дизайн-система, спецификации, дизайн QA.
6. Назначьте владельца контента (тексты, изображения) и дедлайны предоставления материалов.
7. Согласуйте технические ограничения с разработкой (платформа, интеграции, сроки).
8. Запросите 3–5 КП и сравните по этапам, артефактам, рискам и процессу согласований.
9. Зафиксируйте правила изменений scope и формат коммуникаций (каналы, частота синков).
10. Запустите discovery/прототипирование и согласуйте UX до начала детального UI.

Related reading

• Лидогенерация на международных рынках: почему бизнес проигрывает ещё до запуска рекламы
• 82 заявки на бани-бочки за месяц: как мы перезапустили контекстную рекламу
• Как платежная инфраструктура влияет на рост маркетплейсов, SaaS-платформ и B2B-сервисов: разбор на примере Ozon