Введение

Пользователи 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. Результат

Базовые значения и процесс стат. вычислений в Jamovi

Визуализация сравнения медианных значений

Сценарий	Метрика	Δ = медиана (тест) − медиана (контроль)	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-тесты
Развитие алгоритма, новых модулей, рекомендаций на основе действий пользователей

Посвящается памяти моего отца…

UX-исследование первой сессии и активации в DeFi приложениях