FinTech
Платформа проп-трейдингу · UX-аудит
Американська платформа проп-трейдингу, де люди вчаться торгувати на реальних ринках із симульованого рахунку без ризику для власних грошей, запитала, де її воронка і продукт втрачають людей. За шість тижнів я провела аудит маркетингового сайту, продукту для трейдерів і внутрішньої адмінки та передала пріоритезовану чергу, дві перевірювані гіпотези і чотири робочі прототипи. Аудит переріс у дизайн-найм.
- Країна клієнта
- США
- Платформа
- Web · сайт, продукт, адмінка
- Моя роль
- UX Practice Lead · аудит
- Тривалість
- 6 тижнів · травень–червень 2026
Огляд
Навчитися торгувати складно: треба засвоїти багато правил, частка везіння тут є, і ніхто не хоче платити за уроки реальними грошима. Платформа проп-трейдингу є симулятором саме для цього. Трейдери платять місячну підписку, щоб торгувати на реальних ринках із симульованого рахунку за правилами, а коли проходять, компанія фінансує їх і виплачує реальний прибуток. Більшість не проходить з першого разу і повертається спробувати знову.
Бізнес
Головну бізнес-ціль на старті не визначили, тому я взяла метрику, яка завжди виграє: скільки відвідувачів стають платними трейдерами і де вони відпадають до цього.
Ціль
Шість джерел доказів, і проблема потрапляла в чергу лише тоді, коли хоча б два з них вказували на одне місце.
Метод
Аудит закінчується діагнозом і чергою, а не метриками. Результатом тут є те, що клієнт зробив із чергою.
Контекст
01
Продукт
Місце, де вчаться торгувати, не ризикуючи власними грошима: симульований рахунок на реальних ринках, правила, що привчають до дисципліни (ціль прибутку, ліміт просадки, consistency), і реальні виплати після проходження. Три поверхні: маркетинговий сайт, дашборд трейдера і внутрішня адмінка.
02
Користувачі
Три трейдери, виведені з 11 000 відгуків і спільноти на 72 000 людей: Мисливець за знижкою, який купує за промокодом і швидко йде; Серйозний студент, який читає все і все одно йде в спільноту по відповіді про правила; Досвідчений скальпер, який шукає одне правило і йде, якщо його не видно. Сайт був збудований лише під першого.
03
Ринок
Конкуренти виграють тими самими двома речами: порівняння планів на головній і доказ виплат у hero.
Сім днів аналітики: 123 240 перших переглядів, 24% зникають після першої сторінки, у середньому 2 год 52 хв між головною і сторінкою планів, 0% утримання першого тижня, і жодної відстежуваної події конверсії.
Підхід
Виміряти
Воронки, джерела і 50+ записів сесій показали, куди дивитись, до будь-якої думки.
Послухати
Спільнота і відгуки: плутанина словами самих трейдерів, до покупки і після.
Перевірити
Евристики, доступність і прохід на телефоні по всіх трьох поверхнях, кожна знахідка оцінена за тим, наскільки вона шкодить.
Докази з шести напрямків. Знахідка потрапляла в чергу, лише коли дані, спільнота й екрани сходились.
Процес
Що знайшов аудит
01
Вибір плану
Проблема
Чотири плани з різними правилами і десять комбінацій плану й розміру, без порівняння на головній і без рекомендації будь-де. Найчастіше питання в спільноті: «Який план обрати? Я прочитав усе і досі не знаю». Довідковий центр відповідав на нього, відправляючи людей у спільноту.
Гіпотеза
Якщо нові відвідувачі отримають підбір плану з трьох питань, більше з них купить, бо сайт провалює те єдине рішення, яке передує кожній покупці.
Що я запропонувала
Підбір плану: три питання, один рекомендований план, таблиця порівняння поруч. Вхід стоїть під таблицею планів і всередині FAQ, там, де питання справді ставлять. Перевіряється A/B-спілтом: завершення підбору і час до покупки як вторинні метрики, bounce як запобіжник.
- Варіантів на вибір
- 10 → 1
- Кроків до плану
- прочитати все → 3 питання
- Час на сторінці планів, записаний
- 24+ хв → ≈ 1 хв
- Де живе відповідь
- спільнота → сторінка
24 хвилини: записана сесія на сторінці планів майже без кліків, одна з кількох. Хвилина після: оцінка для трьох питань в один тап. Підбір запропоновано як A/B-спліт. Головна метрика: конверсія в підписку; вторинні: завершення підбору і час до покупки; запобіжник: bounce.
2 год 52 хв
Середній час між головною і сторінкою планів: відвідувачі йдуть порівнювати деінде
24+ хв
Сесії на сторінці планів майже без кліків: читання, а не рішення
10 → 1
Комбінацій на вибір → один рекомендований план
02
Чекаут
Проблема
Картка плану обіцяла $126 з кодом, підсумок замовлення списував $157, якщо покупець не знайде код і не впише його. Поля картки показували помилки «cannot be blank» ще до того, як хтось щось набрав, поруч із таймером сесії. Підсумок казав «/month», не кажучи, чи челендж це одноразова плата, чи підписка.
Гіпотеза
Якщо показана ціна дорівнює списаній, а платіжна форма спокійна, менше покупців відпадає на останньому кроці і менше оскаржує платіж потім.
Що я запропонувала
Два кроки: обрати план, розмір і платформу з автоматично застосованим найкращим кодом, потім огляд зі знижкою окремим рядком і моделлю оплати простими словами. Валідація по blur, таймер прибраний, доки не лишилась хвилина. Прототип як робочий HTML.
- Ціна на картці проти замовлення
- $126 vs $157 → $126 = $126
- Помилок до введення
- 3 → 0
- Кодів запам'ятати і ввести
- 1 → 0
- Модель оплати
- «/month» → одне речення
Розрив у ціні став найсерйознішою знахідкою аудиту, бо веде до покупки за неправильною ціною або до оскарження. Виправлення стосується логіки, а не лейауту: застосувати найкращий код при виборі розміру і ніколи не показувати ціну, якої підсумок не дотримає.
$126 ≠ $157
Ціна на картці проти ціни в замовленні, до
3 → 0
Помилок, показаних до того, як покупець щось набрав
1
Найсерйозніша знахідка: та, яку аудит просив виправити першою
03
Купони і промо
Проблема
Сторінка промо перелічувала всі пропозиції з однаковою вагою: гаряча знижка, знижка новачкам, коди під конкретні плани, соціальні акції. Ніщо не казало, яка з них стосується обраного плану і чи вони поєднуються. «Claim» не пояснював, що станеться далі. І ніщо з цього не доходило до чекауту: покупець усе одно мав запам'ятати код і ввести його. Дві з семи знахідок критичні, і це та сама діра, яку чекаут показував з іншого боку.
Що я запропонувала
З'єднати пропозиції з покупкою. Найкращий доступний код застосовується сам, щойно обрано план і розмір; сторінка показує лише пропозиції під цей план і одну позначає як рекомендовану; одна акція домінує, решта тихі; «Claim» стає «Застосувати в чекауті». Це більше логіка, ніж лейаут, тому воно пішло в чергу разом із чекаутом, а не окремим редизайном.
2
Критичні знахідки: пропозиції відірвані від чекауту, найкраща не застосовується сама
7 → 1
Пропозицій з однаковою вагою → одна домінує, решта тихі
0
Кодів, які покупець має пам'ятати після виправлення
Знахідка → що я запропонувала
Купони відірвані від чекауту
Обрана пропозиція застосовується в замовленні
Найкраща пропозиція не застосовується сама
Код найбільшої цінності застосовано за замовчуванням
Забагато пропозицій без підказки
Одна позначка «найкраще для вас»; решта другорядні
Пропозиції для планів, яких покупець не обирає
Фільтр за обраним планом, розміром і доступністю
«Claim» без названого наслідку
«Застосувати в чекауті», «Скопіювати код»: дія каже, що робить
04
Дашборд трейдера
Проблема
Оплачений рахунок відкривався на порожніх графіках, відліку без підпису і просадці, показаній як підлога рахунку, $48 000, тоді як трейдер думає сумою, яку ще може втратити. Прибуток, збиток і ризик передавались лише кольором, сірим текстом менше 12 px на темній темі. Питання, яке веде кожну сесію, «де я стою і що далі», не мало на екрані жодної відповіді.
Гіпотеза
Якщо дашборд відкривається етапом, відстанню до проходження, залишком буфера і одним наступним кроком, трейдери перестають збирати свій статус із фрагментів, а підтримка чує про це менше.
Що я запропонувала
Керований дашборд замість стіни однакових карток. Він відповідає на питання трейдера в тому порядку, в якому їх ставлять: де я, скільки до проходження, скільки ще можна втратити, що робити далі. Це смуга статусу вгорі: фаза і позначка «на шляху», ціль прибутку як прогрес, просадка як залишок буфера в доларах, наступний крок одним реченням. І лише тоді деталі, тихіше: ряд KPI, де кожне число має знак і стрілку, крива зростання з лініями проходження і порушення, календар зі значенням у кожному дні, звіти за часом утримання угод і таблиця закритих угод, чий підсумок сходиться з P&L вище. Порожні стани кажуть, що робити першим. Усю сторінку перебудовано як робочий HTML.
- Місць, де шукати статус
- 5 → 1
- Способів писати просадку
- 3 → 1
- Сигналів лише кольором
- усі → жодного
- Найменший підпис
- < 12 px → 14 px
Смугу зібрано як робочу сторінку разом із рештою дашборда: KPI-картки зі стрілками і знаками, календар зі значенням у кожній клітинці, порожні стани з першою дією. Огляд доступності за нею містить чотирнадцять знахідок за WCAG 2.2 AA, дві з них критичні.
3 способи
Та сама просадка була записана трьома способами на різних екранах
14
Знахідок доступності, дві з них критичні: зміст лише кольором
Керований
Де я, скільки лишилось, скільки можна втратити, що далі: відповіді в цьому порядку
Знахідка → що я запропонувала
Немає чіткого «де я стою»: фаза, прогрес, ризик і наступний крок ніде не разом
Смуга статусу вгорі з усіма чотирма, словами трейдера
Просадка показана як підлога рахунку, $48 000
Просадка як залишок: «$3 842 до порушення рахунку»
Ціль, еквіті, просадка, відлік і дані рахунку розкидані з однаковою вагою
Дані рахунку в простому хедері, чотири числа в смузі, віджети нижче
Прибуток і збиток лише червоним і зеленим
Знак і стрілка поруч із кожним кольором: на картках, у календарі, в таблицях
Підписи, осі й бейджі сірим менше 12 px на темній темі
Токени читабельності: більші підписи, вищий контраст, одна ієрархія
Порожні віджети на щойно оплаченому рахунку виглядали зламаними
Порожні стани пояснюють чому і називають наступну дію: відкрити платформу
Кожен шматок інформації про рахунок у власній картці
Картки лише для справжніх віджетів; хедер як текст
Віджети розтягнуті на дивні висоти
Повна, половинна і чотириколонкова ширина однакової висоти
05
Лідерборд
Проблема
Лідерборд є соціальним доказом продукту: він має показувати, що справжнім трейдерам платять. Натомість він показував те саме ім'я з тим самим прибутком двічі, 100% виграшних угод без розміру вибірки, ані слова про те, як рейтинг рахується і як часто оновлюється, жодного зв'язку між прибутком і реальною виплатою і нічого про читача. Таблиця була щільна й плоска, тож навіть трійка лідерів не виділялася.
Що я запропонувала
Секція довіри, а не сира таблиця. Спершу твоє власне місце: у рейтингу чи ні, твій найкращий рахунок, що виводить на дошку. Три картки лідерів із позначкою підтвердженої виплати, далі повний рейтинг. Один рядок називає метод: топ-30 за реалізованим прибутком, оновлюється щодня. Частка виграшів як смужка, приріст зі стрілкою, а поруч із будь-яким екстремальним числом розмір вибірки, тож «100%» читається як «100% на 3 угодах». Зібрано як робочий HTML.
- Дубльованих рядків
- 2 → 0
- Екстремальних значень із вибіркою
- жодного → усі
- Метод рейтингу на сторінці
- немає → один рядок
- Власне місце читача
- немає → перше
Намальовано за знахідками аудиту по лідерборду і робочим прототипом. Імена замінено смужками, бо на справжній дошці були справжні трейдери; числа ілюстративні.
7
Знахідок на одному екрані: від дубльованих рядків до відсутнього «ти»
100% → 100% · 3 угоди
Екстремальне число з розміром вибірки
1 рядок
Метод рейтингу там, де починається таблиця
Знахідка → що я запропонувала
Повторені імена й однакові прибутки читаються як вигадані
Перевірити дані рейтингу; один рядок на трейдера
100% виграшів без контексту
Розмір вибірки поруч із будь-яким екстремальним значенням
Немає методу рейтингу і частоти оновлення
Один рядок: топ-30 · реалізований прибуток · щодня
Прибутки не пов'язані з реальними виплатами
Позначка підтвердженої виплати і посилання на сертифікат
Власне місце читача відсутнє
Смуга «твоє місце» перед таблицею
Щільна плоска таблиця
Три картки лідерів, далі таблиця зі смужками для сканування
06
Мобільна версія
Проблема
35% трафіку приходило з телефонів. Відвідувачі з вбудованого браузера Facebook відпадали вп'ятеро частіше за десктоп: прийшов 121, продовжили 19. У продукті два плаваючі віджети зберігали десктопну позицію і лягали на контент, зокрема на чекбокс згоди з умовами на чекауті.
Гіпотеза
Якщо мобільну головну полагодити під вбудований браузер, куди платні кампанії ведуть людей, частка продовження подвоїться, бо теперішній стан є проблемою рендерингу, а не повідомлення.
Що я запропонувала
Перша фаза: підтвердити точку тертя в теплових картах; друга: полагодити банер, цілі натискання і рендеринг, винести плаваючі віджети з контентної колонки. Викочується на весь мобільний трафік без тесту: базовий стан зламаний.
15,7%
Відвідувачів із вбудованого браузера Facebook, що дійшли до другої сторінки, проти 75% на десктопі
35%
Частка трафіку з телефонів
≥ 50%
Цільова частка продовження, на рівні мобільного Safari
07
Довіра
Один рахунок мав три назви на різних екранах. Правила в момент покупки були голими галочками і хрестиками без легенди. Та сама просадка писалася трьома способами. Кожна неузгодженість у продукті про гроші читається як ненадійність, тож це пішло в чергу як таксономія: одна назва на план, один спосіб писати просадку, легенда і підказка на кожному правилі.
Три витоки, що коштують грошей
01
Ніхто не міг сказати, який план його
Проблема
Десять комбінацій, жодної рекомендації, і довідковий центр, що відправляє по відповідь у спільноту. Параліч рішення на тому кроці, який передує кожній покупці.
Гіпотеза
Якщо підбір із трьох питань рекомендує один план, більше нових відвідувачів купують.
Що я запропонувала
Підбір плану під таблицею порівняння і всередині FAQ, як A/B-спліт із запобіжником по bounce.
Підтвердження
Клікабельний прототип підбору; план тесту з головною, вторинними і запобіжною метриками, написаний до збірки.
02
Показана ціна не була ціною списання
Проблема
$126 на картці, $157 у замовленні, якщо код не знайдено і не вписано. Передчасні помилки і відлік на платіжній формі. «/month» без моделі оплати.
Що я запропонувала
Автозастосування найкращого коду, знижка окремим рядком, модель оплати словами, валідація по blur, без таймера.
Підтвердження
Найсерйозніша знахідка аудиту, з робочим прототипом двокрокового чекауту.
03
Продукт відповідав «що сталося», а не «де я стою»
Проблема
Статус розкиданий по метриках однакової ваги, просадка як підлога, колір як єдиний сигнал, порожні стани, що виглядали зламаними.
Що я запропонувала
Смуга статусу з фазою, ціллю, буфером і наступним кроком; знаки поруч із кольорами; підписи читабельного розміру; осмислені порожні стани.
Підтвердження
Робочий прототип дашборда і 14 знахідок доступності, впорядковані за важливістю і передані однією чергою.
Результат
- 3 поверхні, знахідки з 6 джерел, кожна оцінена за впливом
- 2 гіпотези у форматі «якщо / то» з доказами, планом тесту і критеріями успіху
- 4 робочі прототипи: підбір плану, двокроковий чекаут, дашборд зі смугою статусу, лідерборд як секція довіри
- Черга поділена на роботу судження і виконання, і на проєкт поставлено сеньйор-дизайнера, щоб її вести
Аудит не рухає конверсію; він каже, де вона втрачається і в якому порядку це лагодити. Результат: те, що сталося далі. Клієнт узяв чергу, і аудит переріс у постійну дизайн-підтримку. Як UX Practice Lead я визначила ролі, яких потребувала робота, і ввела на проєкт сеньйор-дизайнера, який тепер веде цю чергу. Клієнт задоволений.
Що б я зробила інакше: Визначити бізнес-ціль із клієнтом на першому тижні замість того, щоб опиратись лише на конверсію. Це була безпечна метрика, і вона була правильною, але названа ціль упорядкувала б чергу швидше.
Наступний кейс
Аналітика звітності кампаній
Звітність кампаній для B2B-платформи маркетингових комунікацій: email, веб і відео однією мовою звітів, де одиницею порівняння є хвиля.
Переглянути кейс