Разработка 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 require approve перед transferFrom — это техническая деталь, которая не должна ломать UX. Плохой вариант: пользователь нажимает «Swap» и получает два подряд wallet confirmation. Хороший вариант:
- Проверяем allowance заранее при загрузке UI. Если allowance достаточен — одна транзакция.
- Если нет — явно объясняем двухшаговый процесс: «Сначала нужно разрешить контракту использовать ваши токены (1/2)».
- Permit2 (Uniswap) позволяет объединить approve + действие в одну подпись. Если протокол поддерживает — обязательно используем.
Дизайн-система для Web3
Компоненты, специфичные для 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.
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 methods, 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 недели.