UX/UI-дизайн для веб-проектов

Типичная ситуация: разработчики получают макеты за два дня до старта спринта. В Figma — 80 фреймов, половина без мобильных состояний, кнопки не компоненты, цвета захардкожены hex-значениями без токенов. Итог — верстальщик принимает решения за дизайнера прямо в коде, и через три месяца поддержка UI превращается в угадайку.

Дизайн, который работает в разработке, строится иначе.

Figma как инженерный инструмент

Figma — не просто «место, где рисуют». Это среда, из которой разработчик должен получить точные значения без звонков дизайнеру.

Что это означает на практике:

Auto layout везде. Компоненты, собранные без auto layout, ломаются при изменении текста. Кнопка с фиксированной шириной, которая не растягивается под длинный лейбл — классика.

Design tokens в Variables. Figma Variables (2023+) позволяют привязать цвета, отступы, радиусы к именованным переменным. color/primary/500, spacing/md, radius/button — это то, что переводится в CSS custom properties или Tailwind config один к одному. Без токенов дизайн и код расходятся уже через месяц.

Компоненты с variants. Button/Primary/Default, Button/Primary/Hover, Button/Primary/Disabled — всё в одном component set. Разработчик видит все состояния сразу, а не спрашивает «а как выглядит disabled?» перед каждым компонентом.

Prototype для флоу. Интерактивный прототип дешевле правок после разработки. Особенно для нетривиальных флоу: multi-step форма, wizard, onboarding — их нужно кликать до того, как писать код.

Адаптивность: не три брейкпоинта, а система

Распространённая ошибка — делать «десктоп + мобильный», игнорируя планшеты и нетипичные разрешения. В 2024 году трафик с планшетов составляет 8–12% в зависимости от ниши — это не ноль.

Мы проектируем под систему брейкпоинтов совместимую с тем, что используется в коде. Если фронтенд на Tailwind CSS — брейкпоинты sm:640, md:768, lg:1024, xl:1280, 2xl:1536. Дизайнер работает с теми же значениями в Figma.

Fluid typography и fluid spacing через clamp() — это когда шрифт и отступы плавно меняются между брейкпоинтами без скачков. Не для каждого проекта нужно, но для лендингов и публичных сайтов улучшает восприятие на нестандартных экранах.

Процесс: от вайрфрейма до handoff

Полный цикл проектирования выглядит так:

1. UX-исследование и аналитика. Для существующих продуктов — анализ Hotjar / Microsoft Clarity: тепловые карты, scroll maps, записи сессий. Для новых — customer journey map, анализ конкурентов, интервью если проект крупный.

2. Information Architecture. Структура страниц, навигация, иерархия контента. На этом этапе — только схемы, никакого визуала.

3. Lo-fi wireframes. Grayscale, без деталей. Цель — согласовать расположение блоков и логику страниц. В Figma или Whimsical.

4. Design system / UI kit. Перед рисованием страниц — компоненты. Typography scale, color system, spacing scale, базовые элементы: кнопки, инпуты, карточки, модалки. Без этого дизайн расползается.

5. Hi-fi мокапы. Финальный дизайн с реальным контентом. Не placeholder text — реальные заголовки, реальные цифры. Дизайн с lorem ipsum скрывает проблемы вёрстки.

6. Handoff. Figma Dev Mode или Zeplin. Разработчик видит CSS-значения, экспортирует иконки в SVG, видит токены. Комментарии к нестандартным поведениям — в аннотациях прямо в Figma.

Что влияет на конверсию и удержание

UX — это не только про красоту. Несколько конкретных паттернов:

Форма регистрации. Каждое лишнее поле снижает конверсию. Имя + email + пароль против имя + фамилия + телефон + дата рождения + email + пароль + подтверждение пароля. Прогрессивное профилирование — собирать данные постепенно, после того как пользователь получил ценность.

Error states. Inline validation вместо submit-and-scroll-to-top. Ошибка должна появляться рядом с полем в момент blur или submit, не в тосте в углу экрана.

Loading states. Skeleton screens вместо спиннеров на контентных блоках. Пользователь видит структуру страницы пока грузятся данные — это снижает субъективное время ожидания.

Empty states. Пустой список без объяснения — это UI-баг. «У вас пока нет заказов» + CTA — нормальный empty state.

Design system: когда нужна и когда переинжиниринг

Design system оправдана если:

• Над проектом работает 2+ дизайнера
• Несколько связанных продуктов (мобильное приложение + веб + административная панель)
• Частые обновления UI со стороны продукта

Для сайта-визитки или лендинга design system — переинжиниринг. Достаточно UI kit с базовыми компонентами.

Если проект на React, design system логично строить поверх Radix UI (headless) с Tailwind CSS для стилей — это то, что делает Shadcn/ui. Компоненты полностью контролируемы, нет dependency lock-in на стороннюю библиотеку.

Ориентиры по срокам

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