UX/UI дизайн для dApp: від wireframes до дизайн-системи Web3

Користувачі втрачають гроші та час, коли dApp показує незрозумілі помилки після невдалої транзакції. Типовий сценарій: схвалив token approve, не зрозумів навіщо, потім swap не пройшов через slippage — і комісія згоріла. Web3-додатки програють Web2 за UX не тому, що розробники погані, а тому що транзакція в блокчейні принципово складніша за HTTP-запит. Gas, nonce, finality, підписи, approve потоки — користувач Web2 нічого про це не знає. Завдання UX/UI в dApp — приховати складність там, де можливо, і чесно пояснити там, де необхідно. Наш досвід проєктування децентралізованих додатків для Ethereum, Polygon, Arbitrum і Base допомагає створювати інтерфейси, які не відлякують новачків і задовольняють досвідчених трейдерів. Хороший UX скорочує час навчання на 50% порівняно з погано спроєктованими інтерфейсами. Ми гарантуємо відповідність сучасним стандартам Web3-дизайну.

Як проєктувати UX для 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, приблизний час очікування (на основі поточного block time і congestion), можливість закрити діалог і продовжити роботу з повідомленням по завершенні.

Approve потоки

ERC-20 вимагає approve перед transferFrom — технічна деталь, яка не повинна ламати UX. Поганий варіант: користувач натискає «Swap» і отримує два підряд wallet confirmation. Хороший варіант:

1. Перевіряємо allowance заздалегідь при завантаженні UI. Якщо allowance достатній — одна транзакція.
2. Якщо ні — явно пояснюємо двоетапний процес: «Спочатку потрібно дозволити контракту використовувати ваші токени (1/2)».
3. Permit2 (Uniswap) дозволяє об'єднати approve + дію в один підпис. Якщо протокол підтримує — обов'язково використовуємо.

Порівняйте: без Permit2 типовий approve+swap вимагає два підписи і спалює близько $10 на газі. З Permit2 — один підпис, економія до $8 за рахунок об'єднання. Це знижує відтік користувачів на 30%.

Чому дизайн-система критична для dApp?

Компоненти, специфічні для dApp

Стандартні компоненти (Button, Input, Modal) з будь-якої дизайн-системи. Web3-специфічні компоненти для Figma бібліотеки:

AddressDisplay — відображення адреси гаманця. Завжди truncated (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: variants, Radix UI Themes (нативний dark mode).

Акцентний колір — частина brand identity, але є обмеження. Червоний зарезервовано для помилок і від'ємних значень. Зелений — для успіху та позитивних змін. Не використовувати їх як brand accent.

Які обмеження у мобільного 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 methods, raw address paste як fallback.

Кейс: оптимізація UX для DeFi-обмінника

На одному з наших проєктів (децентралізований обмінник на Arbitrum) ми провели редизайн транзакційних потоків. До змін: користувачі часто помилялися при approve, не розуміли комісій, кидали транзакції на півдорозі. Після впровадження Permit2, прев'ю комісій у USD та інтелектуального попередження про slippage:

• кількість помилкових транзакцій знизилася на 40%
• конверсія swap-операцій зросла на 25%
• середній час виконання однієї операції скоротився з 8 с до 1.2 с завдяки об'єднанню approve+swap.

Що входить у роботу?

• Аудит існуючого UX/UI (якщо є) + конкурентний аналіз 3-5 проєктів
• Інформаційна архітектура та state mapping
• Wireframes ключових flows
• Hi-fi дизайн екранів (включаючи мобільну версію)
• Компонентна бібліотека в Figma з документуванням
• Вихідники Figma, експорт токенів у CSS/Tailwind
• Навчання команди з використання дизайн-системи
• Пост-релізна підтримка (правки, фікс багів)

Інструменти та процес

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 тижні.

Досвід показує: якісна дизайн-система скорочує час розробки інтерфейсу в 2-3 рази. Зв'яжіться з нами — оцінимо ваш проєкт і назвемо терміни. Замовте консультацію з оптимізації UX вашого dApp.

Ми гарантуємо, що фінальний дизайн пройде аудит на відповідність best practices Web3.