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 + пароль + підтвердження пароля. Progressive profiling — збирати дані поступово, після того як користувач отримав цінність.
Error states. Inline validation замість submit-and-scroll-to-top. Помилка повинна з'являтися поруч із полем при blur або submit, не в tosте в кутку екрана.
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 на стороннюю бібліотеку.
Орієнтири за термінами
| Етап | Термін |
|---|---|
| UX-дослідження + IA | 3–7 робочих днів |
| Wireframes (10–20 екранів) | 5–10 робочих днів |
| UI kit / design system | 5–15 робочих днів |
| Hi-fi дизайн (10–20 екранів) | 7–14 робочих днів |
| Адаптивні версії | +30–50% до часу на мокапи |
Терміни залежать від кількості унікальних екранів та складності компонентної бази. Вартість розраховується індивідуально.