К нам регулярно приходят с запросом: нужен современный дизайн сайта в Figma. Через пару встреч обычно выясняется, что проблема не в визуале. Люди заходят на сайт, не понимают предложение, теряются в структуре и уходят до заявки.
Я бы смотрел на подрядчика не по слову Figma в презентации, а по тому, как он собирает весь путь от идеи до верстки. В 2026 году сам инструмент уже не дает преимущества. Преимущество дает процесс: меньше переделок, быстрее запуск, понятный результат для бизнеса.
Figma стала базой, но решает то, что вокруг нее
Вопрос «вы делаете дизайн в Figma?» сейчас звучит примерно как «вы пользуетесь почтой?». Почти все делают. Разница в другом: Figma у команды - это просто набор экранов или рабочая система, где есть карта страниц, компоненты, статусы согласования и handoff для разработки.
Если в проекте лежит папка с файлами «финал», «финал 7» и «точно финал 7.2», дальше почти всегда начинаются лишние созвоны и догадки. Мы предпочитаем с самого начала собирать карту экранов в FigJam, потом wireframes, потом UI и библиотеку компонентов. Так снижается количество решений, которые приходится принимать уже в коде.
На редизайне B2B-сайта для промышленной компании у клиента было около 40 экранов без общей системы. После перехода на компоненты и единые состояния число уточнений от фронтенда сократилось примерно на 35%, а согласование типовых блоков заняло на 2 недели меньше.
Просто макеты:
- каждый экран собран отдельно
- кнопки и поля отличаются по размерам
- нет состояний hover, error, disabled
- разработка уточняет логику по каждому блоку
Система в Figma:
- единые компоненты и варианты
- токены цветов и типографики
- описаны состояния элементов
- handoff понятен без догадок
Сайт теряет заявки раньше, чем пользователь оценит красоту
На практике конверсию чаще ломает не цвет кнопки, а слабый маршрут пользователя. Человек должен за 5-7 секунд понять, куда попал, что ему предлагают и какой следующий шаг. Если этого не происходит, даже сильный UI-дизайн работает как дорогая упаковка без продаж.
У нас был проект в сфере услуг, где трафик шел стабильно, но заявок было мало. Мы не меняли рекламу и не трогали CMS. Пересобрали первый экран, сократили меню, вынесли форму выше и поставили рядом понятный CTA, сроки и блок доверия. Через 6 недель после запуска обращений стало на 18% больше.
До и после выглядело довольно просто:
- До - общий заголовок, перегруженное меню, форма ниже первого экрана
- После - конкретный оффер, короткий путь к действию, кейсы и отзывы рядом с формой
- Результат - рост заявок на 18% без увеличения рекламного бюджета
Для малого бизнеса этого обычно достаточно. Не нужен идеальный путь для всех сегментов. Нужны 3-4 основных сценария: заявка, звонок, запись, запрос КП.
CTO логистической платформы хорошо сформулировал это на созвоне: «Самый дорогой экран - тот, который пришлось перепроектировать уже в коде».
Сильный UI собирают как систему
Самая частая ошибка - воспринимать дизайнера сайтов как человека, который рисует уникальные страницы одну за другой. Для бизнеса это дорогой путь. Каждая новая секция начинает жить по своим правилам, а любая доработка тянет цепочку правок в макетах и верстке.
Мы обычно фиксируем сетку, типографику, карточки, формы, таблицы, меню и состояния элементов еще до того, как готовы все внутренние страницы. Для контентного проекта с 25+ шаблонами это сократило время дизайна новых страниц примерно на 25%. Фронтенд на Node.js 20 + Next.js 15 пошел быстрее, потому что блоки уже были стандартизированы.
Здесь хорошо работают interactive prototypes. Особенно на меню, формах и мобильных сценариях, где статичный экран часто искажает реальное поведение интерфейса. Один раз мы решили сэкономить на этом этапе в личном кабинете для сервиса бронирования и потом потеряли почти 2 недели на переделку навигации. После этого спорные сценарии проверяем раньше.
Нормальный дизайн-процесс идет вместе с разработкой
Когда дизайнер, UX/UI-дизайнер и разработка работают по очереди, ошибки накапливаются незаметно. Визуально все может выглядеть отлично, но потом выясняется, что фильтр тяжело поддерживать в админке, таблица не помещается на мобильном, а сложный блок неудобно редактировать в CMS.
Мы подключаем разработчиков на уровне структуры и прототипа. На проекте с Laravel 11 и PostgreSQL 16 это помогло убрать сложную механику фильтров еще до UI-этапа. Пользователь почти не заметил разницы, а трудозатраты на разработку снизились примерно на 20%.
Зрелую студию видно по артефактам. После работы у клиента остаются не только красивые макеты, но и user flow, карта экранов, библиотека компонентов, правила адаптива и понятный handoff. Макеты выглядят убедительно, но именно процесс потом определяет, сколько раз сайт придется собирать заново.
Когда выбираете подрядчика, попросите показать не главную страницу из портфолио, а последний пакет передачи в разработку. Если там пусто, вопрос будет не в том, кто нарисует сайт, а в том, кто потом будет разбирать последствия.
