Дизайн интерфейса финтех-приложений: понятные денежные операции

Показывайте балансы в понятном контексте

Большое число не говорит само за себя. Укажите, к какому аккаунту оно относится, и покажите валюту привычным символом или кодом. Если продукт различает текущую, доступную, ожидающую или инвестированную сумму, прямо подпишите эти понятия и при необходимости объясните их. Не показывайте два разных типа баланса почти одинаково и без определения.

Контекст может включать время последнего обновления суммы или операции, которые ещё ожидают завершения. Выбирайте сведения, помогающие понять экран, а не добавляйте декоративные числа. Соблюдайте единый формат чисел и достаточные интервалы, чтобы было легко различать цифры, десятичные разделители и знаки минуса. Для длинных названий аккаунтов сохраняйте достаточно текста, чтобы их можно было отличить без опоры лишь на цвет или значок.

• Размещайте явную подпись аккаунта и валюту рядом с суммой.
• Объясняйте специальные термины вроде «доступно» и «ожидается» простыми словами.
• Сохраняйте понятность суммы и состояния при увеличенном тексте и работе со вспомогательными технологиями.

Показывайте статус операции как изменяющееся состояние

Операция — процесс, а не просто строка в истории. При необходимости показывайте краткий статус, дату, сумму и получателя или назначение. Статус должен быть виден текстом; цвет или значок могут усиливать его, но не передавать смысл в одиночку. Различайте ожидание, завершение, отклонение и состояния, требующие внимания, согласно реальной логике продукта.

Например, гипотетический перевод 45,00 EUR Алексу сначала может отображаться как «Запланировано на 4 ноября», затем «Обрабатывается», а позже «Завершено». Если после отправки соединение прервалось по тайм-ауту, не объявляйте уверенно об успехе или неудаче без подтверждения. Скажите, что статус пока недоступен, объясните, как проверить его снова, и уточните, может ли повторная попытка создать ещё один запрос. Точные слова и доступные действия зависят от реальной работы операций в продукте.

Проектируйте финансовые формы, которые предотвращают ненужную путаницу

Запрашивайте сведения, когда они нужны для задачи, и группируйте связанные поля в логичном порядке. Используйте постоянные подписи вроде «Получатель» и «Сумма»; текст внутри поля — пример, а не замена подписи. Если нужен определённый формат, укажите его до ввода — например, допускает ли сумма копейки или какой идентификатор требуется. Рекомендации Apple по вводу данных советуют ясно объяснять запрашиваемые сведения, сокращать лишний ввод и проверять значения по мере заполнения.

Выбирайте элементы ввода по типу данных и позволяйте исправлять записи. Ясно обозначайте необязательные поля и обязательные. Если выбор имеет последствия, описывайте варианты простыми словами, а не заставляйте угадывать смысл коротких кодов. Подсказка должна оставаться достаточно близко к полю при изменении размера экрана или увеличении текста.

Дайте возможность проверить и подтвердить действие

Перед значимым действием покажите сводку вводимых сведений: источник, назначение, сумму, дату и любые применимые комиссии или сроки, отображаемые в сценарии. Соберите наиболее важные для решения детали вместе и сделайте путь к редактированию заметным. Основная кнопка должна называть действие, например «Запланировать перевод», а не расплывчатое «Продолжить».

Экран подтверждения должен отвечать на вопросы «Что произошло?» и «Что я могу сделать теперь?». Номер операции или квитанция помогут найти её позднее. Не считайте нажатие кнопки доказательством успешного выполнения базовой операции; интерфейс должен показывать фактический результат продукта.

• Сохраняйте соответствие сводки введённым значениям и выбранным вариантам.
• Кнопки возврата и редактирования по возможности должны сохранять работу пользователя.
• После отправки сообщайте, получен ли запрос, обрабатывается ли он или есть подтверждённый результат.
• Если ответ неопределён, объясните, как проверить текущий статус, прежде чем предлагать отправить снова.

Делайте ошибки и обновления доступными

Если обнаружена ошибка ввода, укажите поле и опишите проблему словами. «Неверная сумма» менее полезна, чем объяснение допустимого формата или отсутствующего значения. Сохраняйте корректно заполненные поля, чтобы можно было исправить одну проблему без повторного начала. Рекомендации W3C по WCAG 2.2 требуют определять и описывать обнаруженные ошибки ввода и давать подписи или инструкции для обязательного ввода.

Обновления статуса тоже важны. Если страница меняется с «Обрабатывается» на «Завершено» без перемещения фокуса, представляйте изменение так, чтобы вспомогательные технологии могли его распознать. WCAG 2.2 описывает сообщения о состоянии как изменения, которые передают результат, ожидание, прогресс или ошибку без смены контекста. Используйте предупреждения соразмерно: сообщайте о значимых изменениях, не прерывая человека при каждом визуальном обновлении.

Проверяйте контрастность, масштабирование текста, доступ с клавиатуры или переключателя и названия элементов для программы чтения с экрана в готовом интерфейсе. Используйте ясные заголовки и подписи, не передавайте успех, ошибку или направление операции только цветом. Принципы дизайна Apple подчёркивают понятную обратную связь и помощь в исправлении ошибок; это полезные цели, но фактическую доступность нужно оценивать по всему продукту.

Список для проверки финтех-интерфейса

Пройдите типичную задачу от исходного баланса до окончательного статуса. Проверьте обычный путь, исправление и прерывание, например медленное соединение. Сравните похожие мобильные экраны в библиотеке, чтобы увидеть разные способы организации информации и действий, затем оцените свой сценарий по реальному поведению продукта.

• Понятно ли, к какому аккаунту и валюте относится баланс?
• Названы ли ожидающие и завершённые состояния ясно и текстом?
• Есть ли у каждого поля видимая подпись и нужная инструкция о формате?
• Могут ли люди проверить назначение, сумму и время перед отправкой?
• Указывают ли ошибки проблему и практический способ исправления?
• Остаётся ли обновление заметным без различения цвета, острого зрения или перемещения фокуса?
• Если результат неопределён, объясняет ли интерфейс, как проверить его до повторной попытки?