Projektowanie UI aplikacji fintechowych: przejrzyste operacje i spokojna obsługa finansów

Pokaż saldo czytelnie i w kontekście

Duża liczba nie wyjaśnia się sama. Wskaż konto, do którego należy, i pokaż walutę znanym symbolem lub kodem. Jeśli produkt rozróżnia kwoty bieżące, dostępne, oczekujące lub zainwestowane, nazwij te pojęcia wprost i wyjaśnij, gdy potrzeba. Nie pokazuj dwóch różnych rodzajów salda niemal identycznym stylem i bez definicji.

Kontekst może też obejmować czas ostatniej aktualizacji kwoty lub oczekujące działania. Wybierz szczegół pomagający zinterpretować ekran, zamiast dodawać dekoracyjne liczby. Stosuj spójny format liczb i odpowiednie odstępy, aby cyfry, separatory dziesiętne i znaki minus były łatwe do odróżnienia. Przy długich nazwach kont zachowaj dość tekstu, by je rozróżnić, zamiast polegać wyłącznie na kolorze lub ikonie.

• Umieść wyraźną etykietę konta i walutę blisko kwoty.
• Wyjaśnij specjalistyczne terminy, takie jak „dostępne” czy „oczekujące”, prostym językiem.
• Zadbaj, by ta sama kwota i stan były zrozumiałe przy większym tekście oraz z technologią wspomagającą.

Pokazuj status transakcji jako zmieniający się stan

Transakcja to proces, nie tylko wiersz historii. Gdy to właściwe, podaj przy każdej pozycji zwięzły status, datę, kwotę i drugą stronę lub miejsce docelowe. Status powinien być widoczny tekstem; kolor lub ikona może go wzmacniać, ale nie może być jedynym nośnikiem znaczenia. Rozróżniaj działania oczekujące, ukończone, odrzucone i wymagające uwagi zgodnie z rzeczywistymi stanami produktu.

Na przykład hipotetyczny przelew 45,00 EUR do Alexa może najpierw mieć opis „Zaplanowano na 4 listopada”, potem „Przetwarzanie”, a później „Ukończono”. Jeśli po wysłaniu upłynie limit czasu połączenia, nie ogłaszaj pewnie sukcesu ani porażki bez dowodu. Powiedz, że status nie jest jeszcze dostępny, wyjaśnij, jak sprawdzić go ponownie, i zaznacz, czy ponowienie mogłoby utworzyć drugie żądanie. Dokładne słowa i działania zależą od rzeczywistego zachowania transakcji w produkcie.

Projektuj formularze finansowe zapobiegające niepotrzebnym niejasnościom

Proś o informacje wtedy, gdy są potrzebne do zadania, i grupuj powiązane pola w logicznej kolejności. Używaj trwałych etykiet, takich jak „Odbiorca” czy „Kwota”; tekst zastępczy jest przykładem, nie zamiennikiem etykiety. Jeśli pole wymaga określonego formatu, powiedz o tym przed wpisaniem danych — na przykład czy kwota przyjmuje grosze lub jaki identyfikator należy wpisać. Wytyczne Apple dotyczące wprowadzania danych zalecają jasne określanie wymaganych informacji, ograniczanie zbędnego wpisywania i sprawdzanie wartości w trakcie ich podawania.

Dobieraj kontrolki do danych i pozwalaj poprawiać wpisy. Pola opcjonalne wyraźnie oznacz jako opcjonalne, a wymagane jako wymagane. Jeśli wybór ma konsekwencje, opisz możliwości prostym językiem, zamiast kazać zgadywać znaczenie krótkich kodów. Wskazówka dotycząca pola powinna być na tyle blisko niego, by pozostawała zrozumiała po zmianie układu lub powiększeniu ekranu.

Zapewnij przydatny etap sprawdzenia i potwierdzenia

Przed ważnym działaniem podsumuj informacje, które użytkownik zamierza wysłać: źródło, odbiorcę, kwotę, datę oraz wszelkie pokazane opłaty lub terminy istotne dla ścieżki. Zgrupuj szczegóły najważniejsze dla decyzji i ułatw znalezienie edycji. Główne działanie powinno nazywać czynność, na przykład „Zaplanuj przelew”, zamiast niejasnego „Kontynuuj”.

Ekran potwierdzenia powinien odpowiadać na pytania „Co się stało?” i „Co mogę teraz zrobić?”. Numer referencyjny lub widok potwierdzenia może pomóc później odnaleźć operację. Nie uznawaj naciśnięcia przycisku za dowód powodzenia operacji; interfejs powinien pokazywać rzeczywisty wynik zwrócony przez produkt.

• Zadbaj, by podsumowanie zgadzało się z wpisanymi danymi i wybranymi opcjami.
• Jeśli to praktyczne, powrót i edycja powinny zachowywać pracę użytkownika.
• Po wysłaniu powiedz, czy żądanie dotarło, jest przetwarzane czy ma potwierdzony wynik.
• Przy niepewnej odpowiedzi wyjaśnij, jak sprawdzić aktualny status przed ponownym wysłaniem.

Zadbaj o dostępność komunikatów o błędach i aktualizacji

Po wykryciu błędu danych wskaż pole i opisz problem tekstem. „Nieprawidłowa kwota” pomaga mniej niż komunikat wyjaśniający akceptowany format lub brakującą wartość. Zachowaj poprawne wpisy, aby można było naprawić jeden problem bez zaczynania od nowa. Wytyczne W3C do WCAG 2.2 wymagają wskazania i opisania wykrytych błędów wprowadzania oraz zapewnienia etykiet lub instrukcji, gdy dane są wymagane.

Aktualizacje statusu też są ważne. Jeśli strona zmienia się z „Przetwarzanie” na „Ukończono” bez przeniesienia fokusu, udostępnij tę zmianę w sposób rozpoznawalny dla technologii wspomagających. WCAG 2.2 określa komunikaty statusu jako zmiany informujące o wynikach, oczekiwaniu, postępie lub błędach bez zmiany kontekstu. Zachowaj proporcję w alertach: ogłaszaj istotne zmiany, nie przerywając użytkownikowi wielokrotnie przy każdym odświeżeniu wizualnym.

W gotowym interfejsie sprawdź kontrast, powiększanie tekstu, dostęp klawiaturą lub przełącznikiem oraz nazwy dla czytnika ekranu. Używaj jasnych nagłówków i etykiet kontrolek; nie oznaczaj sukcesu, błędu ani kierunku transakcji samym kolorem. Zasady projektowe Apple podkreślają jasną informację zwrotną i pomoc w naprawianiu błędów; to przydatne cele, ale rzeczywista dostępność wymaga oceny całego produktu.

Lista kontrolna interfejsu fintechowego

Przejdź typowe zadanie od salda początkowego po końcowy status. Sprawdź zwykłą ścieżkę, poprawkę i przerwę, na przykład wolne połączenie. Porównaj powiązane ekrany mobilne w bibliotece, by zobaczyć, jak różne interfejsy układają informacje i działania, a potem oceń własną ścieżkę względem rzeczywistego zachowania produktu.

• Czy użytkownik wie, jakiego konta i waluty dotyczy saldo?
• Czy stany oczekujące i ukończone są jasno nazwane oraz pokazane tekstem?
• Czy każde pole ma widoczną etykietę i potrzebną instrukcję formatu?
• Czy przed wysłaniem można sprawdzić odbiorcę, kwotę i termin?
• Czy błędy wskazują problem i proponują praktyczną poprawkę?
• Czy aktualizacja pozostaje dostrzegalna bez koloru, ostrego wzroku lub przenoszenia fokusu?
• Czy przy niepewnym wyniku interfejs wyjaśnia, jak sprawdzić status przed ponowieniem?