Мобільний банкінг давно перестав бути додатковим способом перевірити баланс або переказати гроші. Для багатьох користувачів банківський застосунок став основним інтерфейсом для взаємодії з фінансами.

Через нього люди отримують зарплату, оплачують покупки, переказують гроші, відкривають депозити, керують картками, обмінюють валюту, аналізують витрати та вирішують проблеми з платежами. Це означає, що навіть невелика UX проблема може виникати в сценаріях, безпосередньо пов’язаних із грошима користувача.

Саме тому дизайн банківського застосунку має вирішувати складніше завдання, ніж просто зробити інтерфейс сучасним. Він повинен одночасно бути простим, зрозумілим, швидким і передбачуваним, але при цьому враховувати безпеку та складність фінансових операцій.

Розглянемо основні принципи UX, які допомагають створювати банківські та фінтех продукти, зручні для щоденного використання.

Хороший банківський UX починається з довіри

У більшості цифрових продуктів помилка може означати втрачений час або необхідність повторити дію. У банківському застосунку користувач може сприймати навіть невелику невизначеність значно серйозніше, тому що йдеться про його гроші.

Людина повинна чітко розуміти, що відбувається з рахунком, чи виконано переказ, яку суму буде списано, кому вона відправляє гроші та чи можна скасувати операцію. Якщо інтерфейс залишає користувача в невизначеності, довіра до продукту швидко зменшується.

Тому фінансовий UX повинен постійно відповідати на прості запитання: що зараз відбувається, що станеться після натискання кнопки, чи успішно завершена операція та що робити, якщо виникла проблема.

Зрозумілий статус транзакції, підтвердження платежу, інформація про комісії та нормальні повідомлення про помилки можуть бути важливішими для користувацького досвіду, ніж складні візуальні ефекти.

Основні фінансові сценарії повинні бути максимально простими

Банківський застосунок може містити десятки функцій, але більшість користувачів регулярно повертається до невеликої кількості основних сценаріїв. Перевірити баланс, знайти транзакцію, переказати гроші, оплатити рахунок, поповнити картку або переглянути реквізити.

Саме ці сценарії повинні мати найменшу кількість зайвих дій. Якщо для звичайного переказу користувачеві потрібно проходити через декілька меню, шукати отримувача та щоразу вводити однакові дані, проблема швидко стає помітною.

Це особливо важливо для операцій, які люди виконують регулярно. Один зайвий крок може здаватися незначним під час першого використання, але якщо користувач повторює цю дію десятки разів на місяць, зайва складність накопичується.

Тому роботу над банківським UX варто починати не з кількості функцій, а з основних користувацьких сценаріїв та частоти їх використання.

Головний екран повинен відповідати на головні питання

Після відкриття банківського застосунку користувач зазвичай хоче швидко отримати інформацію про свої фінанси. Йому не потрібно одразу бачити всі можливості банку.

Головний екран повинен давати зрозуміле уявлення про поточний стан рахунків. Баланс, картки, останні операції та основні дії мають бути доступними без необхідності шукати їх у меню.

При цьому одна з типових проблем фінансових продуктів полягає в поступовому перевантаженні головного екрана. У міру розвитку продукту на ньому з’являються кредити, депозити, кешбек, страхування, інвестиції, пропозиції партнерів та рекламні блоки.

У результаті основні банківські операції починають конкурувати за увагу з додатковими сервісами.

Хороша інформаційна ієрархія повинна враховувати частоту та важливість дій. Те, чим людина користується щодня, не повинно губитися серед функцій, які потрібні їй декілька разів на рік.

Складні фінансові терміни потрібно пояснювати

Банк працює зі складною фінансовою та юридичною термінологією, але користувач банківського застосунку не зобов’язаний її знати.

APR, IBAN, кредитний ліміт, доступний баланс, авторизація платежу, холд, валютний курс та інші поняття можуть бути очевидними для людей, які працюють у фінансовій сфері, але незрозумілими для частини клієнтів.

Інтерфейс повинен перекладати складність банківських процесів на зрозумілу мову. Якщо професійний термін необхідно залишити, поруч можна пояснити його значення або показати додаткову інформацію за запитом.

Особливо важливо уникати неоднозначності там, де користувач приймає фінансове рішення. Людина повинна розуміти умови продукту, розмір комісії, процентну ставку та можливі наслідки дії до того, як вона її підтвердить.

Переказ грошей потребує особливої уваги до деталей

Переказ є одним із найважливіших сценаріїв банківського застосунку. Тут одночасно потрібно забезпечити швидкість, зрозумілість та захист від помилок.

Перед фінальним підтвердженням користувач повинен легко перевірити отримувача, суму, валюту, рахунок списання та можливу комісію. Ця інформація має бути візуально організована так, щоб помилку можна було помітити за декілька секунд.

Після виконання операції система повинна чітко повідомити результат. Недостатньо просто закрити екран або показати коротке повідомлення. Користувачеві важливо знати, що платіж прийнятий, обробляється або вже завершений.

Якщо операція не виконана, повідомлення має пояснювати причину та наступний крок. Текст «Something went wrong» майже нічим не допомагає людині, яка не знає, чи були списані її гроші.

Безпека не повинна робити продукт незручним

Фінансові продукти потребують значно більшої кількості перевірок та обмежень, ніж більшість звичайних мобільних застосунків. Авторизація, підтвердження операцій, біометрія, ліміти, перевірка нових пристроїв та інші механізми є необхідною частиною продукту.

UX завдання полягає не в тому, щоб прибрати ці перевірки, а в тому, щоб зробити їх зрозумілими.

Якщо застосунок просить користувача повторно підтвердити особу, варто пояснити причину. Якщо операцію заблоковано з міркувань безпеки, потрібно повідомити, що сталося та як відновити доступ.

Користувач набагато спокійніше ставиться до додаткового кроку, коли розуміє його мету. Незрозуміле обмеження сприймається як проблема продукту. Зрозуміле пояснення може сприйматися як захист.

Прозорість важливіша за ефектний інтерфейс

У банківському продукті не повинно бути сюрпризів після натискання кнопки підтвердження. Комісії, курси валют, строки проведення операції та інші важливі умови потрібно показувати до завершення дії.

Особливо це стосується операцій, де кінцева сума може відрізнятися від початкової. Наприклад, міжнародних переказів або конвертації валют.

Замість того щоб просто показати курс, інтерфейс може пояснити, скільки грошей буде списано та скільки отримає інша сторона. Це значно легше сприймати, ніж змушувати користувача самостійно рахувати кінцевий результат.

Прозорість також важлива після здійснення операції. Історія транзакцій повинна дозволяти легко зрозуміти, куди пішли гроші, коли це сталося та який статус має операція.

Історія транзакцій повинна допомагати знаходити інформацію

Зі збільшенням кількості операцій звичайний список транзакцій перестає бути достатнім. Користувач може пам’ятати, що заплатив за щось декілька тижнів тому, але не пам’ятати точну дату або назву компанії в банківській виписці.

Тому історія повинна підтримувати нормальний пошук, фільтрацію за періодом, сумою, категорією або типом операції. Хорошим доповненням можуть бути зрозумілі назви продавців, логотипи та автоматична категоризація витрат.

При відкритті транзакції користувач повинен бачити детальну інформацію без необхідності звертатися до підтримки. Дата, сума, статус, отримувач, комісія, категорія та інші важливі дані повинні бути зібрані в одному місці.

Так історія операцій перетворюється зі звичайної банківської виписки на корисний інструмент для управління фінансами.

Фінансова аналітика повинна бути зрозумілою без фінансової освіти

Графіки витрат можуть виглядати ефектно, але їхня цінність полягає не в самій візуалізації. Аналітика повинна допомагати користувачеві зрозуміти власну фінансову поведінку.

Замість десятків складних графіків краще показати декілька зрозумілих відповідей. Скільки людина витратила цього місяця? На що пішло найбільше грошей? Як витрати змінилися порівняно з попереднім періодом? Скільки вдалося заощадити?

Особливо корисними можуть бути контекстні інсайти. Наприклад, застосунок може показати, що витрати на певну категорію суттєво зросли або що регулярний платіж став дорожчим.

При цьому аналітика не повинна перевантажувати користувача цифрами. Якщо для розуміння графіка потрібно окремо пояснювати, як його читати, можливо, інформацію можна представити простіше.

Персоналізація повинна спрощувати банкінг

Банківські застосунки працюють із великою кількістю інформації про поведінку користувача. Це створює можливість адаптувати інтерфейс та рекомендації під конкретні сценарії.

Людина, яка регулярно робить переказ одному отримувачу, може отримати швидкий доступ до цього контакту. Користувач, який часто обмінює валюту, може бачити потрібні валютні рахунки ближче до головного екрана.

Але персоналізація повинна мати зрозумілу користь. Якщо вона перетворюється лише на спосіб показувати більше кредитних або партнерських пропозицій, ефект може бути протилежним.

Хороша персоналізація скорочує шлях до потрібної дії та допомагає користувачеві швидше отримати результат.

Онбординг не повинен перетворюватися на інструкцію до застосунку

Банківські продукти часто мають складніший процес реєстрації через необхідність підтвердження особи, документів та іншої інформації. Через це особливо важливо не додавати зайві кроки там, де вони не потрібні.

Користувач повинен розуміти, скільки приблизно етапів залишилося, навіщо потрібна конкретна інформація та що відбудеться після завершення перевірки.

Після реєстрації не обов’язково показувати довгу презентацію всіх можливостей продукту. Набагато ефективніше знайомити користувача з функціями в контексті його дій.

Якщо людина вперше відкриває розділ заощаджень, саме тоді можна пояснити його можливості. Якщо вона ще ніколи не користувалася міжнародними переказами, немає необхідності розповідати про них під час першого запуску.

Повідомлення та сповіщення є частиною UX

Push повідомлення в банківському застосунку мають практичну цінність. Вони можуть підтверджувати платежі, повідомляти про надходження грошей, нагадувати про регулярні платежі або попереджати про підозрілу активність.

Але якщо банк використовує той самий канал для великої кількості рекламних повідомлень, важливі сповіщення починають губитися серед маркетингових.

Користувачеві варто дати можливість контролювати типи повідомлень, які він отримує. При цьому критичні повідомлення про безпеку або рух коштів повинні залишатися чітко відокремленими від промоцій.

Навіть текст повідомлення має значення. Замість абстрактного «операцію виконано» краще показати суму, тип операції та достатньо контексту, щоб користувач одразу зрозумів, що сталося.

Доступність повинна закладатися в дизайн із самого початку

Банківські послуги потрібні людям із різними можливостями, віком та рівнем цифрового досвіду. Тому доступність не повинна бути додатковою функцією, яку команда згадує перед запуском.

Достатній контраст, читабельний текст, зрозумілі назви елементів, підтримка системного масштабування шрифтів, достатній розмір зон натискання та коректна робота зі screen reader повинні враховуватися під час створення інтерфейсу.

Важливо також не покладатися лише на колір для передачі інформації. Наприклад, позитивні та негативні транзакції краще відрізняти не тільки зеленим і червоним кольором, а також знаками, текстом або іншими візуальними ознаками.

Для фінансового продукту доступність особливо важлива, оскільки людина повинна мати можливість самостійно керувати власними грошима.

Дизайн помилок є частиною банківського досвіду

Ідеальний сценарій не є єдиним сценарієм. Картка може бути заблокована, на рахунку може не вистачити грошей, банк може відхилити операцію, користувач може втратити доступ до старого номера телефону або випадково ввести неправильні реквізити.

Тому дизайн банківського продукту потрібно проєктувати не лише навколо успішних операцій.

Хороше повідомлення про помилку пояснює, що сталося, чи є ризик для грошей користувача та що він може зробити далі. Якщо проблему можна вирішити безпосередньо в застосунку, наступна дія повинна бути доступною одразу.

Найгірший сценарій виникає тоді, коли користувач бачить помилку, але не розуміє, чи були списані гроші та куди звертатися.

Підтримка повинна бути доступною в момент виникнення проблеми

Коли йдеться про гроші, користувач не хоче шукати сторінку підтримки через декілька рівнів меню. Особливо якщо він бачить незнайому транзакцію або не може завершити важливий платіж.

Контекстна підтримка дозволяє перейти до вирішення проблеми безпосередньо з потрібного екрану. Наприклад, у деталях транзакції можна розмістити можливість повідомити про проблему або поставити питання щодо конкретної операції.

Це також дозволяє передати службі підтримки більше контексту. Користувачеві не потрібно вручну пояснювати номер транзакції, дату та суму, якщо система вже знає, з якого екрану він звернувся.

Мікроанімації повинні пояснювати, а не відволікати

Анімація може бути корисною частиною банківського UX, якщо допомагає зрозуміти стан системи. Вона може показати, що операція обробляється, підтвердити успішну дію або пояснити перехід між станами інтерфейсу.

Але фінансовий застосунок не повинен перетворювати кожну дію на шоу. Надлишкова анімація уповільнює роботу та може створювати неправильне відчуття легковажності в критичних сценаріях.

Особливо обережно варто використовувати ефекти під час платежів, блокування картки, зміни лімітів та інших важливих операцій. У таких ситуаціях зрозумілий результат важливіший за емоційність.

Гейміфікація підходить не для кожного фінансового сценарію

Прогрес, цілі, досягнення та інші елементи гейміфікації можуть допомагати користувачам формувати корисні фінансові звички. Наприклад, накопичувати певну суму, регулярно поповнювати заощадження або контролювати бюджет.

Але фінансові рішення не варто перетворювати на гру заради збільшення кількості взаємодій із застосунком.

Особливо обережно потрібно працювати з кредитами, інвестиціями та іншими сценаріями, де користувач приймає рішення, пов’язані з фінансовим ризиком.

Гейміфікація має допомагати людині досягати її фінансової мети, а не просто змушувати частіше відкривати застосунок.

Візуальний дизайн також формує довіру

Функціональність і usability є основою банківського продукту, але це не означає, що візуальна частина не має значення.

Послідовна типографіка, зрозуміла ієрархія, акуратна робота з кольорами, якісні іконки та однакові компоненти створюють відчуття цілісності продукту.

Особливо небезпечно, коли різні частини банківського застосунку виглядають як різні продукти. Таке часто трапляється в системах, які розвивалися багато років і поступово отримували нові функції від різних команд.

Design System допомагає підтримувати послідовність, але сама бібліотека компонентів не вирішує проблему автоматично. Потрібні також єдині правила поведінки компонентів, структури екранів, повідомлень, форм та основних сценаріїв.

Як зрозуміти, що банківському застосунку потрібен UX редизайн

Редизайн потрібен не лише тоді, коли інтерфейс виглядає застарілим. Значно важливішими сигналами можуть бути проблеми в поведінці користувачів.

Люди можуть регулярно звертатися до підтримки з однаковими питаннями, не знаходити певні функції, залишати процес реєстрації, робити помилки під час переказів або майже не користуватися частиною можливостей продукту.

Ще один сигнал з’являється, коли продукт значно виріс, але його інформаційна архітектура залишилася такою самою. Нові функції поступово додаються в існуючі розділи, меню стає складнішим, а головний екран переповнюється.

У такому випадку косметичної зміни UI недостатньо. Потрібно досліджувати сценарії користувачів, переглядати структуру продукту та визначати, які дії справді мають бути пріоритетними.

UX дослідження для банківських продуктів

Фінансові продукти особливо небезпечно проєктувати лише на основі внутрішніх припущень команди. Те, що здається очевидним дизайнеру або банківському спеціалісту, може бути незрозумілим звичайному користувачеві.

UX дослідження допомагають побачити, як люди насправді сприймають фінансові терміни, де вони сумніваються, які елементи викликають недовіру та які сценарії виявляються складнішими, ніж очікувала команда.

Для перевірки різних частин продукту можна використовувати інтерв’ю, usability testing, аналіз поведінки, прототипування та тестування інформаційної архітектури.

Особливо важливо перевіряти критичні сценарії: реєстрацію, перекази, роботу з картками, відновлення доступу, підтвердження операцій та вирішення проблем.

Хороший банківський UX робить складні процеси зрозумілими

Банківський продукт може мати складну внутрішню архітектуру, десятки інтеграцій, правила безпеки та юридичні обмеження. Користувачеві не потрібно бачити всю цю складність.

Йому потрібно швидко зрозуміти свій баланс, виконати потрібну операцію, отримати зрозуміле підтвердження та бути впевненим, що його гроші в безпеці.

Саме в цьому полягає одна з головних задач UX банківського застосунку. Не прибрати складність фінансової системи, а правильно організувати її на рівні інтерфейсу.

Коли навігація зрозуміла, фінансові дані легко читати, критичні дії передбачувані, а система чітко пояснює свій стан, користувачеві не потрібно думати про те, як працює сам застосунок. Він може зосередитися на тому, заради чого його відкрив: керуванні власними фінансами.