Розробка UX/UI дизайну для dApp
Web3 додатки програють Web2 за UX не тому що розробники погані — а тому що транзакція в блокчейні принципово складніша за HTTP запит. Gas, nonce, finality, підписи, approve потоки — користувач Web2 нічого про це не знає. Завдання UX/UI в dApp — приховати цю складність де можливо та чесно пояснити де необхідно.
Специфіка проектування для Web3
Стани гаманця як основа інформаційної архітектури
Перше що потрібно спроектувати — не «екрани», а стани. Користувач dApp знаходиться в одному з:
- Немає гаманця (новий користувач)
- Гаманець встановлений, не підключений
- Підключений, не на правильній мережі
- Підключений до правильної мережі, немає потрібних токенів
- Повністю готовий до роботи
Кожен перехід між станами — це окремий UX flow. У більшості dApp ці переходи спроектовані погано: користувач нажимає кнопку, отримує помилку «Wrong network», не розуміє що робити. Правильно: кнопка «Switch to Base» з іконкою мережі повинна з'являтися превентивно до спроби транзакції.
У Figma це проектується через States в Auto Layout компонентах: один компонент кнопки з варіантами idle / wrong-network / insufficient-balance / pending / confirming / success / error.
Транзакційні потоки
Кожна транзакція — це мінімум 3 кроки: підготовка → підписання → очікування. UX повинна супроводжувати користувача через кожен:
Підготовка. Показуємо preview: що станеться, скільки токенів уйде/прийде, приблизний gas. Gas — особлива проблема: користувачі не розуміють «0.003 ETH gas fee». Розв'язання — показувати в USD: «~$4.50 за транзакцію». Дані з EIP-1559 maxFeePerGas + maxPriorityFeePerGas дозволяють розрахувати worst-case cost.
Підписання. Діалог гаманця відкривається поза нашим контролем. Наше завдання — не створювати візуальний конфлікт (наш модал поверх гаманця). Затемнюємо фон, показуємо легкий індикатор «Очікування підтвердження в гаманці».
Очікування. Транзакція відправлена, чекаємо confirmations. Для хорошого UX — не просто спіннер, а посилання на Etherscan/Blockscan, приблизний час очікування (на основі поточного block time та congestion), можливість закрити діалог та продовжити роботу з сповіщенням по завершенню.
Approve потоки
ERC-20 вимагає approve перед transferFrom — це технічна деталь, яка не повинна ломати UX. Поганий варіант: користувач нажимає «Swap» та отримує два підряд wallet confirmation'и. Хороший варіант:
- Перевіряємо allowance заздалегідь при завантаженні UI. Якщо дозволу достатньо — одна транзакція.
- Якщо ні — явно пояснюємо двохкроковий процес: «Спочатку потрібно дозволити контракту використовувати ваші токени (1/2)».
- Permit2 (Uniswap) дозволяє об'єднати approve + дію в одну підпис. Якщо протокол підтримує — обов'язково використовуємо.
Дизайн-система для Web3
Компоненти, специфічні для dApp
Стандартні компоненти (Button, Input, Modal) з будь-якої дизайн-системи. Web3-специфічні компоненти для Figma бібліотеки:
AddressDisplay — відображення адреси гаманця. Завжди скорочений (0x1234...5678), клік копіює в clipboard, hover показує ENS якщо резолвується. Ніколи не показувати повну адресу в UI.
TokenAmount — сума токена з іконкою. Варіанти: compact (1.23K), full (1,234.56), usd-equivalent (≈$2,469). Від'ємні суми червоним кольором.
NetworkBadge — іконка мережі + назва. Критично для мультичейн dApp. Кольори мереж стандартизовані: Ethereum #627EEA, Base #0052FF, Arbitrum #12AAFF, Polygon #8247E5.
TransactionStatus — stateful компонент для lifecycle транзакції. Містить іконку статусу (spinner/checkmark/cross), текст стану, посилання на explorer.
Кольорова схема
Dark mode — стандарт для DeFi/crypto UI. Причини: довгі сесії трейдерів, сприйняття «професійного» інструменту, менше утомляємості при моніторингу. Основні фреймворки: Tailwind CSS з dark: варіантами, Radix UI Themes (нативний dark mode).
Акцентний колір — частина brand identity, але є обмеження. Червоний зарезервований для помилок та від'ємних значень. Зелений — для успіху та позитивних змін. Не використовуйте їх як brand accent.
Mobile-first у Web3: обмеження та розв'язання
Mobile Safari не підтримує browser extension гаманці. WalletConnect v2 через deep link — єдиний шлях на мобілі. Це означає: весь UI повинен працювати з WalletConnect flow (окремий додаток відкривається для підписання).
Специфіка тач-інтерфейсу: кнопки мінімум 44px height, немає hover states як primary interaction, keyboard pushes layout вверх при вводі адрес. Введення адреси на мобілі — окрема проблема: camera scan QR code + ENS resolving як primary input методи, raw address paste як fallback.
Інструменти та процес
Figma з Figma Variables для дизайн-токенів (кольори, типографія, spacing). Tokens Studio плагін для синхронізації токенів з CSS/Tailwind. Radix UI або shadcn/ui як основа компонентної бібліотеки — уникаємо винаходження базових accessibility паттернів (focus rings, ARIA). Storybook для документування Web3-специфічних компонентів.
Процес: аудит існуючого dApp (якщо є) → конкурентний аналіз 3-5 подібних проектів → інформаційна архітектура та state mapping → wireframes ключових flows → hi-fi дизайн → компонентна бібліотека → handoff розробникам.
Графік розробки
UX/UI для одного flow (наприклад, staking: deposit + withdraw + claim) від wireframes до hi-fi — 3-5 днів. Повна дизайн-система для dApp з 5-10 основними flows, мобільною версією та компонентною бібліотекою в Figma — 2-3 тижні.