Lunora – мій власний проєкт, на якому я пройшла повний цикл: опитування, кабінетний аналіз, гіпотеза, сценарії, стани, UI kit, чотири юзабіліті-тести прототипу і план метрик. Фокус – на тому, що в навчальних проєктах зазвичай пропускають: помилки, таймаути й повторні спроби.
Що показало дослідження
Аналіз банкінгу й менеджерів підписок показав те саме: processing часто «порожній», а помилка без наступного кроку забирає довіру. Звідси гіпотеза: якщо пояснити статус, причину й наступну дію, людина відчуватиме більше контролю.
Бачили списання за підписку, про яку забули
8 з 9 мають дві й більше карти чи акаунтиХочуть один застосунок для підписок, рахунків і витрат
Четверо – за умови, що інтерфейс буде простийОбережні з AI: «залежить від безпеки»
Негативно – ніхто. 6 довіряли б більше, якби функції можна було вимкнутиОбрали нейтральний тон: «Ваші витрати зросли на 10%»
4 з 9 найважчим у фінансах називають стресНазвали фінансові поради головною потребою
Тому AI – контекстне пояснення, а не центральний чат-ботХочуть уникати неочікуваних списань
9 з 9 контролюють фінанси через банківські застосункиВибірка мала й однорідна: усі девʼятеро працюють у найомі, восьмеро – віком 21–40. Це напрям для рішень, а не перевірка гіпотези.
Від інсайтів до рішень
| Що зʼясувалось | Рішення |
|---|---|
| Кілька фінансових джерел | Один Dashboard і вибір гаманця |
| Забуті підписки | Огляд підписок, дата наступного платежу, нагадування |
| Запит на простоту | Головна інформація першою, стримана ієрархія |
| Поради не є головним пріоритетом | Контекстне AI-пояснення замість центрального чат-бота |
| Невизначеність платіжного статусу | Окремі стани з відповідними поясненнями та діями |
Стани платежу
Кожен стан відповідає на три питання: що відбувається зараз, чому це сталося і що робити далі.
Статус, next payment, метод оплати
Пояснення замість порожнього лоадера, фонові дії заблоковано
Коротке підтвердження і швидке закриття
Без звинувачення: Retry payment або Change payment method
Окремо від Failed: статус ще не фінальний, повторно не платимо
Retry / Change method → назад у Processing
Оновлений статус і нова дата оплати
Processing пояснює, що відбувається
- Чому
- Під час тестування прототипу двоє з чотирьох учасників зазначили, що обробка платежу триває надто довго. Це звернуло мою увагу не лише на тривалість очікування, а й на те, як інтерфейс повідомляє про поточний стан операції: коли людина не розуміє, що відбувається, очікування здається довшим і викликає невизначеність.
- Що зробила
- Раніше кроки «Checking card → Confirming payment → Almost done» були лише текстом. Я додала кільце прогресу й галочки на пройдених кроках, а наступний крок виділила. Відсотків немає: тривалість залежить від зовнішніх платіжних систем.
- Результат
- Видно, на якому кроці платіж і що він рухається далі, а не завис.
СтатусЗміни внесено в прототип. Повторне тестування їхньої ефективності поки не підтверджене.
До тестуванняПісля тестуванняTimeout – це не Failed
- Чому
- Під час таймауту людина не знає, чи списалися гроші, і не впевнена, чи повторювати платіж. Якщо показати таймаут як помилку, вона може заплатити двічі.
- Що зробила
- Два різні стани. Failed – повідомлення без звинувачення й дві дії: Retry або Change payment method. Timeout – нейтральне «Ми все ще обробляємо платіж».
- Результат
- Таймаут більше не виглядає як помилка, тож немає причини платити вдруге.
СтатусСпільний патерн в UI kit з однаковою логікою CTA.
Наступний крок на кожному стані
- Чому
- Коли платіж не пройшов, людина не бачить зрозумілого next step і не розуміє, коли підписка знову активна.
- Що зробила
- Деталі підписки показують статус, суму, дату наступної оплати й метод. Після успіху – коротке підтвердження і повернення в стан Active з новою датою.
- Результат
- Після будь-якого результату оплати людина знає, чи активна підписка і коли наступний платіж.
СтатусУ прототипі через Smart Animate.
Онбординг і гаманці без тиску
- Чому
- Фінансові застосунки часто тиснуть, а 4 з 9 опитаних найважчим у фінансах називають стрес.
- Що зробила
- Онбординг питає, що людина хоче відстежувати, запит на сповіщення пояснює користь, а гаманець можна підключити або пропустити.
- Результат
- Людина сама обирає, що підключати і коли, без обовʼязкових кроків.
СтатусУ прототипі.
Компроміси
У фінансах правильних відповідей часто дві. Ось між чим я обирала і що перемогло.
| Між чим | Що обрала | Де |
|---|---|---|
| Швидкість і безпека | Навмисне тертя там, де помилка дорога: під час processing фонові дії заблоковані | Processing |
| Ясність і когнітивне навантаження | Інформація розкривається поступово | Деталі підписки, онбординг |
| Автоматизація і контроль | Критичні дії лишаються явними й видимими | Retry, Change payment method |
| Деталі й швидке завершення | Мінімалістичний success-стан, щоб швидко закрити сценарій | Success |
AI – помічник, а не джерело істини
AI задуманий як контекстний помічник: коротке пояснення поточної ситуації та доступні дії в bottom sheet. Він не визначає сам, чи відбулося списання: статуси мають надходити від надійної платіжної інфраструктури, а в концепті такої інтеграції немає.
Індикатори прогресу
У Lunora я розділила два типи процесів: початкове налаштування продукту та обробку фінансових транзакцій.
- Wallet setup – визначений прогрес
- На екрані Setting things up використано індикатор 0–100%, який у прототипі демонструє очікувану поведінку інтерфейсу під час налаштування. У реальному продукті такий індикатор має бути привʼязаний до фактичного виконання етапів. Якщо бекенд не може надати достовірні дані про прогрес, передбачено використання індикатора без відсотків.
- Payment processing – невизначений прогрес
- Під час обробки платежу тривалість операції залежить від зовнішніх платіжних систем. Тому відсотковий індикатор може створювати хибне очікування щодо часу завершення. Для цього сценарію я обрала статусний інтерфейс із поясненням поточного процесу без штучного відображення відсотків.
Принцип: індикатор прогресу має відображати достовірну інформацію, а не створювати ілюзію контролю.
Доступність закладена в систему: високий контраст у темному інтерфейсі, чітка ієрархія тексту, великі зони натискання й короткі повідомлення «що сталося → що робити». Тестів з асистивними технологіями ще не було – далі WCAG-ревʼю і сценарії зі screen reader.
Як міряти
Це запропоновані метрики, а не виміряні результати: продукт не запущений. Наступний крок – usability-тестування прототипу на сценаріях невдалої оплати, таймауту й зміни платіжного методу.
| Метрика | Що показує |
|---|---|
| Status comprehension | Чи розрізняють люди Failed і Timeout |
| Time to resolve | Час від виникнення проблеми до її вирішення |
| Payment recovery rate | Частка успішних оплат після помилки |
| Retry drop-off | Частка людей, які залишають сценарій повторної оплати |
| Duplicate attempts | Частота повторних спроб до підтвердження результату |
| Дизайн-рішення | Очікуваний ефект |
|---|---|
| Окремі стани платежу | Менше паніки, менше виходів із флоу |
| Чіткі CTA на кожному стані | Швидші рішення, менше хаотичних повторів |
| Timeout окремо від Failed | Менше подвійних платежів, більше довіри |
Прототип
Прототип
Онбординг і підключення гаманця
Екрани й анімації з прототипу у Figma: інтро зі стосом карток, реєстрація, перший гаманець і прогрес налаштування. Прототип гортається сам, а в режимі «Спробувати самій» його можна проклікати.
- Сплеш
- Інтро: три кроки
- Реєстрація і вподобання
- Перший гаманець
- Тип гаманця
- PayPal
- Налаштування
- 01
Опитування показало інтерес до одного місця для фінансів, але й обережність щодо AI – тому ставка на прозорість статусів, а AI лишився концептом асистента.
- 02
Свідомо поза межами: банківські інтеграції, юридичні сценарії, монетизація й ML-реалізація.
- 03
Далі – протестувати з людьми новий Processing і Timeout (повторно їх ще не перевіряли) і міряти payment recovery rate та drop-off під час retry.
