Введение
Пользователи DeFi‑приложений — независимо от опыта — в первой сессии сталкиваются с нагрузкой, где нужно разбираться в ключах, адресах, комиссиях, пулах ликвидности и пр., что становится причиной финансовых ошибок и высокой доли отказов.
Проверил гипотезу влияния выбора модулей приложения в онбординге на устойчивость к ошибкам, понятность и скорость сценариев перевода, обмена и стейкинга.
Проблема
Перегруженные навигация и функции в первой сессии затрудняют активацию, повышают риск ошибок и долю отказов.
Цели исследования
Оценить влияние настройки модулей приложения в онбординге на достижение целевых действий
Проверить, повышает ли такой подход удобство ключевых сценариев по критериям частоты ошибок, времени и субъективной оценки удобства
Роль и задачи
В роли UX‑исследователя и продуктового дизайнера отвечал за цикл от глубинных интервью и JTBD‑сегментации до гипотез, прототипирования и проведения модерируемых юзабилити‑тестов.
Ограничения
Выборка респондентов и сравнение сценариев с конкурентами направлены на инсайты, а не статистическую репрезентативность рынка.
Содержание
1. Анализ бенчмарков и отзывов
По открытым бенчмаркам AppsFlyer 45% финтех приложений удаляются в течение 30 дней, и половина удалений — за первые сутки. По данным CleverTap 11% удалений — из-за трудности использования. Продукты из-за удалений теряют в среднем $86 402 в месяц, и часто отказы касаются первых сессий.
Выявил высокочастотные причины жалоб из анализа по отзывам DeFi приложений в App Store и Google Play:
перегруженность функциями и внутренними разделами
непонятные статусы и результат действий
недоверие при подключении или ошибках транзакций
2. Глубинные интервью
Провёл рекрутинг и скрининг из DeFi‑сообществ. Выборка из 22 респондентов — англо- и русскоязычные инвесторы с опытом из стран: США, Россия, Грузия, Израиль, Сербия, Украина, Доминикана и др.
Контекст и конкретные задачи в приложениях
Драйверы мотивации
Паттерны проблем и ограничений
Причины отказа от конкурентов
Незакрытые потребности в текущих решения
3. Выводы и формулирование проблем
Провёл тематический анализ, — кодирование, составление кодбука и цветовую маркировку, — после чего посчитал частотность тем по доле респондентов.
Основные проблемы:
Неудобство интерфейса: скрытое управление, перегруженность, ненужные настройки (86% — 19 из 22)
Недостаточная безопасность и прозрачность рисков (64% — 14 из 22)
Негативный опыт из-за финансовых ошибок (64% — 14 из 22)
Причины отказа от конкурентов:
Сложность освоения: непонимание логики и поведения (55% — 12 из 22)
Недостаточная прозрачность условий (18% — 4 из 22)
Выводы валидны для опытных инвесторов, но могут не переноситься на новичков без опыта в DeFi
4. Сегментация по контексту
Среди мотиваций доминировали 2 группы драйверов: безопасность и удобство. Для проверки решений сфокусировался на сегменте долгосрочных инвесторов, ориентированных на безопасность и удобство самостоятельного управления капиталом. Требования для сценариев: контроль и прозрачность шагов, минимизация ошибок.
5. Job Stories сегмента
Драйвер: безопасность
Когда я подключаю кошелёк или вношу депозит, я хочу минимизировать риск серьёзной ошибки, чтобы не потерять средства
Когда я выбираю пул для стейкинга, я хочу понять соотношение риска и доходности, чтобы снизить вероятность потери капитала
Когда я делаю перевод или оплату, я хочу простой и безошибочный способ указать данные, чтобы отправить активы по верному адресу
Драйвер: удобство
Когда я анализирую актив или портфель, я хочу видеть только важную информацию и динамику, чтобы точнее принять решение
Когда я принимаю решение приобрести актив, я хочу учитывать его в оценке портфеля, чтобы отследить доходность
Когда я размещаю депозит в стейкинге, я хочу регулярно отслеживать активность и начисления, чтобы вовремя управлять позицией
6. Банк продуктовых гипотез
Сделал приоритизацию по соотношению ожидаемой ценности к частоте боли у сегмента по итогам интервью. Ожидаемый эффект гипотез указал без цифр из-за отсутствия продукта и соответственно бейзлайнов.
Однако кому-то будут полезны направления для экспериментов. Можете писать мне — поделюсь всеми артефактами исследования.
6.1 Приоритет: удобство использования
H1
Если в онбординге, сохранив только важные шаги, добавить выбор функциональных модулей для формирования границ пользовательского опыта, то повысится активация пользователей
Ожидаемый эффект
Рост Activation Rate: доли пользователей, совершивших первую успешную транзакцию после создания или импорта кошелька
H2
Если добавить объяснение ценности модулей и быстрые действия в пустых состояниях первой сессии, то ускорится активация пользователей
Ожидаемый эффект
Сокращение медианного TTV: времени до первой успешной транзакции
H3
Если добавить быстрые переводы по QR с автозаполнением полей, то пользователи будут чаще использовать переводы и реже допускать ошибки
Ожидаемый эффект
Снижение числа ошибок при вводе адреса получателя
Рост конверсии в перевод активов
Рост ARPU от комиссий (lag метрика)
6.2 Приоритет: безопасность и доверие
H4
Если в карточки и детали пулов стейкинга добавить оценку результатов аудита, то пользователи будут чаще предоставлять ликвидность
Например, сводный индекс по анализу ликвидности, риску смарт-контрактов, обеспечению пула, отзывам
Ожидаемый эффект
Рост конверсии в депозит на пулах низкого риска
Снижение D7/30 Churn Rate среди пользователей с депозитом в стейкинге
H5
Если на этапе депозита в стейкинг добавить видео от команды актива с раскрытием ценности, рисков и условий, то повысится доверие к пулу и конверсия в депозит
Ожидаемый эффект
Снижение отказов на шаге депозита
Рост конверсии в депозит на пулах с видео
Рост TVL и выручки (lag метрики)
H6
Если добавить отображение статусов транзакций в реальном времени, то пользователи будут реже обращаться в поддержку
Ожидаемый эффект
Рост CSAT по вопросу безопасности транзакций
Снижение числа тикетов техподдержки по вопросам транзакций на 1000 транзакций
6.3 Приоритет: прозрачность и информативность
H7
Если добавить гибкую настройку и контроль обмена активов, то пользователи будут чаще совершать обмены внутри приложения
Ожидаемый эффект
Снижение отказов на шагах настройки и подтверждения обмена
Рост конверсии в обмен активов
Снижение D7/D30 Churn Rate среди пользователей, совершивших обмен
H8
Если добавить к отображению баланса разделение доступных и заблокированных в пулах активов, то сократится число ошибок в сценариях с вводом суммы
Ожидаемый эффект
Снижение доли ошибок при вводе суммы
Рост CSAT по вопросу качества транзакций
H9
Если в деталях пула добавить отображение этапов и точного времени, оставшегося до награды, то пользователи будут более удовлетворены и реже обращаться в поддержку
Ожидаемый эффект
Рост CSAT по вопросу понятности условий
Снижение числа тикетов техподдержки по вопросам доходности на 1000 депозитов в стейкинге
7. Архитектурные принципы
Инкапсуляция: модуль решает конкретную задачу пользователя
Масштабируемость: модули независимы, и подключение нового не нарушает навигацию
Последовательность: навигация подчиняется выбранным модулям и сценариям
8. Прототипирование и логика
Реализовал в прототипе логику через boolean переменные и условия для модулей. Сборка n-ветки приложения происходит на основе комбинации переменных, привязанных к выбору пользователя.
В SwiftUI модули задаются в виде флагов, алгоритм учитывает состояния через битовые маски, и на основе выбранного набора модулей строит адаптированный UI в заданных рамках пользовательского опыта.
import SwiftUI struct ModuleFlags: OptionSet, Hashable { let rawValue: Int static let balance = Self(rawValue: 1 << 0) static let swaps = Self(rawValue: 1 << 1) static let staking = Self(rawValue: 1 << 2) static let analytics = Self(rawValue: 1 << 3) func normalized() -> Self { union(.balance) } } enum Module: String, CaseIterable, Identifiable { case balance, swaps, staking, analytics var id: String { rawValue } var flag: ModuleFlags { switch self { case .balance: .balance case .swaps: .swaps case .staking: .staking case .analytics: .analytics } } var title: String { switch self { case .balance: "Balance" case .swaps: "Swaps" case .staking: "Staking" case .analytics: "Analytics" } } var icon: String { switch self { case .balance: "wallet.pass" case .swaps: "arrow.left.arrow.right" case .staking: "banknote" case .analytics: "chart.line.uptrend.xyaxis" } } @ViewBuilder func screen() -> some View { switch self { case .balance: BalanceScreen() case .swaps: SwapsScreen() case .staking: StakingScreen() case .analytics: AnalyticsScreen() } } } struct AdaptiveTabs: View { let selected: ModuleFlags private var active: [Module] { let flags = selected.normalized() return Module.allCases.filter { flags.contains($0.flag) } } var body: some View { TabView { ForEach(active) { m in m.screen() .tabItem { Label(m.title, systemImage: m.icon) } } } } }
9. Сравнительный дизайн юзабилити-теста
Выборка: 13 участников
Сценарии: депозит в стейкинг, обмен, перевод
Условия:
контрольный вариант — сценарии в прототипах конкурентов, собранных из реальных экранов с разметкой зон кликов
тестовый вариант — сценарии в прототипе нового решения
Конкуренты: Bybit — стейкинг, Uniswap — обмен, Trust Wallet — перевод
Исследование проводил в 2025, когда текущая версия ByBit была недоступна. Сейчас в первой сессии предлагается выбор режимов: Lite и Pro, разделяющий интерфейс по уровню функций. Это решает их раннюю проблему
Сопоставимость: одинаковые точки старта, состояний и окончания сценариев
Метрики:
Частота ошибок: кол-во ошибок* на участника в сценарии
Время выполнения в секундах
Оценка удобства UMUX-lite после каждого условия (без нормализации в шкалу 0-100)
* критерии ошибки: провал задачи или помощь модератора; неверное понимание текста, повлекшее неверное действие; пропуск ключевого шага или переход на несвязанный экран; лишние действия без прогресса
Анализ: использовал критерий Уилкоксона для парного сравнения условий на одних и тех же участниках из-за небольшого объёма выборки (n=13) и ненормальности распределений метрик
10. Результат
Сценарий | Метрика | Δ = медиана (тест) − медиана (контроль) | p-value (Уилкоксон) |
Депозит в стейкинг | Частота ошибок | 0 | p = 0,037 |
Время выполнения | −8 сек (−28%) | p = 0,039 | |
Оценка удобства UMUX-lite | +1 пункт | p = 0,006 | |
Обмен | Частота ошибок | 0 | p = 0,346 |
Время выполнения | −6 сек (−22%) | p = 0,054 | |
Оценка удобства UMUX-lite | +0,5 пункта | p = 0,147 | |
Перевод | Частота ошибок | −1 ошибка | p = 0,048 |
Время выполнения | −17 сек (−43%) | p = 0,021 | |
Оценка удобства UMUX-lite | +0,5 пункта | p = 0,016 |
Для части сценариев индивидуализация модулей на этапе онбординга — рабочий способ снижения нагрузки на пользователей без потери функциональности. Ведь модули остаются доступными к подключению, а рекомендации новых можно выстраивать по методу прогрессивного раскрытия. Психология поведения пользователей при конструировании приложения описывается через эффект владения — endowment effect.
Что бы делал дальше, если запускать MVP
Разметку событий
Тест гипотез адаптивности пользовательского опыта в первой сессии и трекинг Activation rate, TTV
Контроль D7/30 Churn Rate в онбординге и среди пользователей совершивших обмен или депозит в стейкинг
Работу в направлении доверия пользователей
Когортный анализ, и после достаточного объёма трафика — A/B-тесты
Развитие алгоритма, новых модулей, рекомендаций на основе действий пользователей
Посвящается памяти моего отца…
