Пользователи теряют деньги и время, когда 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 require approve перед transferFrom — техническая деталь, которая не должна ломать UX. Плохой вариант: пользователь нажимает «Swap» и получает два подряд wallet confirmation. Хороший вариант:
- Проверяем allowance заранее при загрузке UI. Если allowance достаточен — одна транзакция.
- Если нет — явно объясняем двухшаговый процесс: «Сначала нужно разрешить контракту использовать ваши токены (1/2)».
- 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.
| Компонент | Варианты | Примечание |
|---|---|---|
| AddressDisplay | truncated, full, with ENS | Всегда truncated в UI |
| TokenAmount | compact, full, usd-equivalent | Иконка токена обязательна |
| NetworkBadge | static, clickable | Цвета сетей фиксированы |
| TransactionStatus | pending, success, error | Ссылка на explorer |
Цветовая схема
Dark mode — стандарт для DeFi/crypto UI. Причины: длинные сессии у трейдеров, восприятие «профессионального» инструмента, меньше утомляемость при мониторинге. Основные фреймворки: Tailwind CSS с dark: variants, Radix UI Themes (нативный dark mode).
Акцентный цвет — часть brand identity, но есть ограничения. Красный зарезервирован для ошибок и отрицательных значений. Зелёный — для успеха и позитивных изменений. Не использовать их как brand accent.
| Состояние | Цвет | Применение |
|---|---|---|
| Ошибка | Красный | Failed transaction, error message |
| Успех | Зелёный | Confirmed transaction, positive balance |
| Предупреждение | Жёлтый | Slippage warning, low gas estimation |
| Информация | Синий | Pending transaction, info tooltip |
Какие ограничения у мобильного 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/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 перед запуском
- Все состояния кошелька обработаны? - Превью транзакции показывает gas в USD? - Approve потоки объединены через Permit2 (если возможно)? - Мобильный интерфейс использует WalletConnect v2? - Компоненты дизайн-системы проверены на accessibility?Ориентиры по срокам
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.