Коротко. Профессиональные UI/UX-дизайнеры работают в трёх типах инструментов: Figma (или аналог) — прототип и макет, отдельный сервис аналитики — проверка гипотез на реальных пользователях, UI-кит — библиотека готовых элементов для согласованности. По итогу каждого этапа подрядчик обязан показать конкретный артефакт — не «дизайн в процессе», а прототип, макет со ссылкой в Figma с правами комментирования и, для сложных проектов, интерактивный кликабельный прототип. Если подрядчик присылает только финальные картинки без промежуточных этапов — это повод спросить, где рабочие файлы.
Инструменты для прототипирования: где рождается структура
Первый этап работы дизайнера — не про цвет, а про расположение блоков. Для этого используют:
- Figma — фактический стандарт индустрии на 2026 год, работает в браузере, позволяет заказчику смотреть макет в реальном времени без установки программ и оставлять комментарии прямо на элементах;
- Miro или FigJam — доски для структуры сайта и пользовательских сценариев (user flow) на уровне схем и стрелочек, до того как появляются конкретные экраны;
- Adobe XD — встречается реже, чем Figma, обычно в компаниях, которые давно работают в экосистеме Adobe и не переходили на более новый инструмент.
Результат этого этапа — чёрно-белый прототип (wireframe), где видно расположение блоков, но нет ни цвета, ни шрифтов. Это нормально: обсуждать структуру проще, когда её не отвлекает картинка.
Инструменты для визуального макета
После утверждения структуры дизайнер добавляет визуальный слой в той же Figma — большинство студий не переключаются между программами на разных этапах, чтобы не терять данные при переносе. На этом этапе появляются:
- UI-кит — заранее собранная библиотека кнопок, полей ввода, карточек, иконок, чтобы все страницы сайта были визуально согласованы, а не собраны из разрозненных элементов;
- Auto Layout — техническая функция Figma, благодаря которой макет корректно растягивается под разную длину текста и разные экраны, а не требует ручной подгонки каждого блока;
- Библиотеки иконок и иллюстраций — готовые наборы (например, Feather Icons, Undraw) для типовых элементов, чтобы не рисовать каждую иконку с нуля.
На выходе — финальный макет с точными размерами, цветами в HEX-кодах и отступами в пикселях, который верстальщик может открыть и снять с него все параметры без дополнительных вопросов дизайнеру.
Инструменты для проверки решений на реальных пользователях
Отдельная категория — инструменты, которые проверяют, работает ли макет, а не просто красив ли он:
- Яндекс.Метрика (вебвизор, карта скроллинга, карта кликов) — бесплатный и обязательный минимум после запуска сайта, показывает реальное поведение, а не гипотезы дизайнера;
- Интерактивный прототип в Figma — кликабельная версия макета без реального кода, на которой можно провести тест с 5-8 людьми до того, как потрачен бюджет на вёрстку;
- Сервисы для юзабилити-тестирования (например, Maze) — записывают, как тестовые пользователи проходят задачу по прототипу, и показывают, на каком шаге они путаются.
Эта категория инструментов нужна не всегда — для простого лендинга обычно достаточно интуиции опытного дизайнера и последующей проверки в вебвизоре после запуска. Для сложных сценариев (многошаговая форма, каталог с фильтрами, личный кабинет) тестирование прототипа до вёрстки экономит бюджет — переделать макет в Figma дешевле, чем переделывать готовый код.
Что подрядчик обязан показать на каждом этапе
Инструменты — не самоцель, а способ убедиться, что заказчик видит процесс, а не только результат. Проверяемый минимум по этапам:
| Этап | Что должно быть показано |
|---|---|
| Прототип | Ссылка на файл в Figma с правами комментирования, а не скриншот в презентации |
| Визуальный макет | Минимум 2 варианта первого экрана или обоснование, почему предложен один |
| Адаптив | Отдельные макеты для мобильной версии, а не «и так растянется» |
| Передача в разработку | Файл с точными размерами и цветами, доступный верстальщику напрямую |
Если хотя бы один пункт студия заменяет фразой «мы всё сделаем сами, вам покажем финал» — это не обязательно признак недобросовестности, но повод уточнить условия до подписания договора на разработку сайта, а не после.
Красные флаги: когда подрядчик прячет процесс
Несколько признаков, что стоит задать уточняющие вопросы до оплаты этапа дизайна:
- Нет ссылки на рабочий файл, только PDF или картинки — значит, редактировать и проверять макет самостоятельно заказчик не может;
- Прототип и визуальный дизайн показывают одним файлом сразу с цветом — вероятно, этап проработки структуры пропущен или сделан формально;
- На вопрос «как вы проверяли, что это решение сработает» ответ сводится к «у нас большой опыт» без конкретики — опыт важен, но не заменяет проверку на данных для конкретного сайта.
Ни один из этих признаков сам по себе не значит, что работа плохая — многие опытные дизайнеры действительно полагаются на насмотренность. Но комбинация из двух-трёх признаков — повод для дополнительного разговора, прежде чем оплачивать следующий этап.
Инструменты — не гарантия результата
Важно понимать границу: Figma, UI-кит и юзабилити-тестирование — это инструменты процесса, а не гарантия конверсии. Дизайнер может идеально владеть всеми перечисленными инструментами и всё равно сделать макет, который не продаёт — потому что не разобрался в аудитории или бизнес-задаче. Проверка того, работает ли готовый дизайн на практике, происходит только после запуска, через веб-аналитику — инструменты дизайна создают гипотезу, а не подтверждают её.
Частые вопросы
Обязательно ли студия должна работать именно в Figma?
Нет, важен не конкретный инструмент, а доступ заказчика к рабочему файлу с возможностью комментировать и отслеживать версии. Figma — фактический стандарт, потому что бесплатна для базового использования и не требует установки, но студия вправе работать в другом инструменте с теми же возможностями.
Сколько стоит доступ к юзабилити-тестированию, если студия его не делает сама?
Отдельный раунд тестирования с 5-8 пользователями у стороннего специалиста стоит от 15 000 до 40 000 ₽ и занимает 3-7 дней. Для типового сайта среднего бизнеса это оправдано не всегда — чаще достаточно проверки на реальном трафике после запуска.
Можно ли самому разобраться в Figma и проверить макет подрядчика?
Да, для просмотра и комментирования не требуется навыков дизайна — интерфейс просмотра интуитивен, освоение занимает 15-20 минут. Полноценное редактирование макета — другой уровень, но заказчику это обычно и не нужно, важно уметь смотреть и оставлять замечания.
Что делать, если подрядчик отказывается давать доступ к рабочему файлу?
Это стоит прояснить на берегу, до оплаты: часть студий передаёт финальные файлы только после полной оплаты этапа как защиту от недобросовестных заказчиков, что нормально. Но полное отсутствие доступа даже к просмотру процесса на протяжении всей работы — уже нетипичная практика, о ней стоит спросить прямо.
Нужен ли интерактивный прототип для простого лендинга?
Обычно нет — интерактивный прототип с тестированием оправдан там, где у пользователя есть многошаговый сценарий (форма подбора, каталог, личный кабинет). Для лендинга с одной формой заявки хватает статичного макета и последующей проверки на реальном трафике после запуска.
Посмотреть, как устроен процесс дизайна на практике
Покажем прототип, макет и логику принятия решений на конкретном примере, а не только готовую картинку.