Роль:
Product Designer
Срок:
2 месяца / In Dev
Команда:
Founder, разработка
Платформа:
Web, Mobile
Компания работает с CPA-партнёрами: они приводят пользователей и получают процент с оформленных подписок.
Кабинет у партнёров был — собранный на скорую руку, на сгенерированном нейросетями коде. Работал, но с багами в вёрстке и без внятной логики. Публичной точки входа не существовало вовсе: лендинга не было, партнёров заводили вручную.
Кабинет у партнёров был — собранный на скорую руку, на сгенерированном нейросетями коде. Работал, но с багами в вёрстке и без внятной логики. Публичной точки входа не существовало вовсе: лендинга не было, партнёров заводили вручную.
Финансовый кабинет с нуля: партнёр видит приведённых пользователей, следит за доходом и выводит деньги на расчётный счёт.
CPA-платформа: кабинет партнёра
Целевая аудитория
CPA-партнёр
Человек, который зарабатывает через платформу и возвращается в неё регулярно. Часто работает одновременно с несколькими сетями и сравнивает их по одному критерию: насколько прозрачно и быстро он получает деньги. Проверяет баланс с телефона мимоходом, сводит статистику за период — с десктопа. Технически подкован, интерфейс ему нужен не для обучения, а для скорости. Недоверие к цифрам в кабинете стоит дороже, чем некрасивый интерфейс. Если партнёр не может объяснить себе, откуда взялась сумма, он уходит в другую сеть.
Конкуренты
Прямые конкуренты — партнёрские кабинеты других CPA-сетей. Партнёр почти всегда работает с несколькими сразу, поэтому сравнение для него ежедневное и неизбежное.
Цели
— Дать партнёру видеть приведённых пользователей, доход и выводить деньги в одном месте
— Вернуть доверие к цифрам: сделать любую сумму прослеживаемой до источника
— Создать публичную точку входа вместо ручного привлечения партнёров
— Вернуть доверие к цифрам: сделать любую сумму прослеживаемой до источника
— Создать публичную точку входа вместо ручного привлечения партнёров
Боли
— Интерфейс не работает: элементы отваливаются, на экране много лишнего
— Устаревший вид вызывает сомнение в платформе, которая распоряжается деньгами
— Непонятно, откуда взялась сумма и что из неё доступно к выводу
— Проверить баланс с телефона неудобно
— Устаревший вид вызывает сомнение в платформе, которая распоряжается деньгами
— Непонятно, откуда взялась сумма и что из неё доступно к выводу
— Проверить баланс с телефона неудобно
Гипотезы
Если открывать кабинет динамикой подписок и отписок, а доход показывать следом как результат, партнёр будет возвращаться чаще: экран отвечает на вопрос «что делать дальше», а не только «сколько мне заплатят»
Прослеживаемость любой цифры до конкретного пользователя снизит долю обращений в поддержку по расхождениям в суммах
Ограниченный набор компонентов при vibecode-разработке даст меньше расхождений между макетом и продом, чем гибкий настраиваемый дашборд
Метрики
Аналитики на старом кабинете не существовало, метрик «до» нет. Базу для сравнения собираем вместе с запуском — метрики определены заранее, чтобы было чем мерить.
Конверсия лендинга в регистрацию партнёра
Работает ли публичная точка входа
Доля партнёров, дошедших до первого вывода средств
Проходим ли основной сценарий целиком
Обращения в поддержку по расхождениям в суммах
Г2 — прослеживаемость цифр
Доля сессий с мобильных устройств
Нужен ли был полный адаптив
Частота возвратов партнёра в кабинет
Г1 — меняет ли структура экрана поведение
Конверсия лендинга в регистрацию партнёра
Работает ли публичная точка входа
Доля партнёров, дошедших до первого вывода средств
Проходим ли основной сценарий целиком
Обращения в поддержку по расхождениям в суммах
Г2 — прослеживаемость цифр
Доля сессий с мобильных устройств
Нужен ли был полный адаптив
Частота возвратов партнёра в кабинет
Г1 — меняет ли структура экрана поведение
Роли и зоны ответственности
Интервью с партнёрами, продуктовая логика, UX, UI, лендинг, кабинет, мобильные адаптивы, библиотека состояний графиков, передача в разработку
Постановка задачи, требования, приоритеты, финальные решения
Реализация с опорой на vibecode
Основной экран построен как воронка: сначала приведённые пользователи с оформленной подпиской и отписки, затем доход, который из этого получился.
Вокруг него: лендинг, пошаговая регистрация и логин, первичный онбординг, детализация по приведённым пользователям, сценарий вывода средств, мобильные адаптивы.
Вокруг него: лендинг, пошаговая регистрация и логин, первичный онбординг, детализация по приведённым пользователям, сценарий вывода средств, мобильные адаптивы.
Ресёрч
Что было. Интервью с двумя действующими партнёрами. Оба дали один и тот же ответ: интерфейс не работает — элементы отваливаются, на экране куча лишнего, выглядит старо. Второй добавил, что такой платформе не хочется доверять деньги.
Как я это использовал. Двух интервью мало для выводов, и я это понимал. Поэтому дальше шёл не от найденных болей, а от того, чтобы они структурно не появлялись: минимум типов компонентов, явные состояния, любая цифра прослеживается до источника.
Чего не было. Количественных исследований, тестирования прототипов, аналитики до и после. Всё это отсутствовало по объективным причинам, и я фиксирую это как ограничение, а не выдаю догадки за данные.
Как я это использовал. Двух интервью мало для выводов, и я это понимал. Поэтому дальше шёл не от найденных болей, а от того, чтобы они структурно не появлялись: минимум типов компонентов, явные состояния, любая цифра прослеживается до источника.
Чего не было. Количественных исследований, тестирования прототипов, аналитики до и после. Всё это отсутствовало по объективным причинам, и я фиксирую это как ограничение, а не выдаю догадки за данные.
Временные и технические рамки
Сроки. Два месяца на 16 экранов: лендинг, регистрация и логин, онбординг, кабинет, вывод средств, мобильные адаптивы, библиотека состояний.
Разработка на vibecode. Команда собирает интерфейс с сильной опорой на генерацию кода. Нестандартные компоненты, тонкая анимация и сложные состояния либо не воспроизводятся, либо воспроизводятся с искажениями. Прямое ограничение на сложность макетов.
Отсутствие данных. Ни аналитики, ни внутренних бенчмарков, ни бюджета на исследование. Интервью с партнёрами — весь доступный источник.
Финансовая ответственность интерфейса. Кабинет показывает деньги и запускает вывод средств. Ошибка в отображении — это обращение в поддержку и потеря доверия.
Разработка на vibecode. Команда собирает интерфейс с сильной опорой на генерацию кода. Нестандартные компоненты, тонкая анимация и сложные состояния либо не воспроизводятся, либо воспроизводятся с искажениями. Прямое ограничение на сложность макетов.
Отсутствие данных. Ни аналитики, ни внутренних бенчмарков, ни бюджета на исследование. Интервью с партнёрами — весь доступный источник.
Финансовая ответственность интерфейса. Кабинет показывает деньги и запускает вывод средств. Ошибка в отображении — это обращение в поддержку и потеря доверия.
Библиотека состояний графиков
Отдельная часть работы: инфографика денежных потоков отрисована во всех состояниях — пусто, один день истории, ровный поток, всплеск, месяц простоя, суммы от пятидесяти рублей до полумиллиона. Это одновременно дизайн и набор тест-кейсов для разработки.
Пользовательский сценарий
- Партнёр приходит на лендинг, видит условия и регистрируется
- Проходит онбординг, получает свои ссылки и материалы
- Возвращается в кабинет: видит, сколько человек привёл, сколько оформили подписку и сколько отписались
- Ниже — доход за период, разложенный по источникам
- При необходимости раскрывает детализацию до конкретного пользователя
- Оформляет вывод средств на расчётный счёт
Как принимались решения
Работа шла полным циклом: разбор пользовательских сценариев, UX, прототипы, UI, внутренние тестирования у заказчика, доработка по обратной связи. Три итерации.
Основа ресёрча — разбор реальных рабочих сценариев сервисного центра: как принимается изделие, как определяется неисправность, как заказывается деталь, что попадает в документы. Требования приходили от заказчика, но логику сценариев я разбирал сам.
Временные и предметные рамки
Сроки. Три месяца на 18 экранов с библиотекой компонентов, три полных итерации с внутренними тестированиями заказчика.
Пользователь знает предметную область лучше системы. Интерфейс не может объяснять человеку то, что он знает лучше — он должен убирать шаги, а не добавлять подсказки.
Цена ошибки. Не та запчасть, не тот договор, перепутанный серийный номер — и ремонт теряет статус сертифицированного. Точность важнее скорости.
Согласование внутри крупной компании. Требования приходили и уточнялись через ЛПР, каждое решение должно было быть не просто верным, а объяснимым.
Доступ. Продукт закрытый, мой доступ ограничивался разделом дизайна. Аналитику и внутренние данные я не затрагивал.
