Punktowe poprawki, audyt UX czy redesign aplikacji bankowej? Co robić, gdy spada konwersja, a budżet nie jest z gumy

Co warto wiedzieć?

• Ten sam spadek konwersji może mieć kilka niezwiązanych ze sobą przyczyn — problem może tkwić w samym ekranie, w informacji podanej za późno albo w braku potwierdzenia po wykonaniu działania. Dopóki nie wiadomo, która z nich odpowiada za realny spadek, trudno ocenić, czy wystarczy punktowa poprawka.
• Punktowa poprawka, audyt UX i redesign aplikacji bankowej odpowiadają na różną skalę problemu: lokalną barierę na ekranie, sygnały rozproszone między kilkoma procesami albo konstrukcję całego rozwiązania, która nie nadąża za potrzebami klientów.
• Bezpłatny UX Health Check pozwala w 48 godzin od przekazania materiałów sprawdzić, które obserwacje uzasadniają szybką poprawkę, a które wymagają szerszej weryfikacji — bez dostępu do kodu, danych klientów i bez zobowiązania do dalszej współpracy.

Miejsce porzucenia nie mówi jeszcze, co trzeba zmienić

Analityka wskazuje etap, na którym spada liczba ukończonych procesów. Dane z infolinii i obsługi klienta pokazują z kolei, z jakimi pytaniami klienci wracają po pomoc. Te sygnały pomagają zawęzić obszar poszukiwań, ale nie przesądzają jeszcze o rozwiązaniu.

Dla przykładu przyjmijmy, że klienci rezygnują podczas dodawania dokumentów do wniosku o finansowanie.

Problem może znajdować się na ekranie

W najprostszym przypadku przyczyna znajduje się dokładnie tam, gdzie spada konwersja. Przycisk dodawania pliku jest słabo widoczny, wymagany format dokumentu nie został podany albo komunikat błędu nie wyjaśnia, co należy poprawić.

W takiej sytuacji punktowa zmiana może usunąć konkretną barierę bez przebudowy całej ścieżki.

Problem mógł pojawić się wcześniej

Klient może dowiedzieć się o wymaganych dokumentach dopiero po kilku minutach wypełniania wniosku. Nie ma ich pod ręką i nie wie, czy może zapisać dane oraz wrócić do procesu później.

Rezygnuje więc na etapie przesyłania plików, choć sam ekran działa poprawnie. Zmiany wymaga wcześniejsza informacja o tym, co należy przygotować przed rozpoczęciem wniosku.

Problem może pojawić się po wykonaniu działania

Trudność może pojawić się również po wykonaniu działania. Bank nie pokazuje jasnego komunikatu „dokument został prawidłowo przesłany”, więc klient nie wie, czy wszystko przebiegło poprawnie, czy powinien zrobić coś jeszcze i kiedy otrzyma odpowiedź.

Z perspektywy systemu dokument został przyjęty i proces idzie dalej. Z perspektywy klienta brakuje jednak potwierdzenia, dlatego sprawa wraca do konsultanta.

Ten sam spadek konwersji może więc prowadzić do trzech różnych rekomendacji. Dlatego zanim nawet drobna zmiana trafi do backlogu, warto sprawdzić nie tylko, gdzie klient przerywa proces, ale także co mogło zatrzymać go w drodze do celu.

Presja na wynik nie ułatwia decyzji

Kiedy KPI się pogarszają, czasu na analizę zwykle jest mniej, a nie więcej. Zespół UX ma już własne priorytety, każda poprawka potrzebuje miejsca w backlogu IT, a większy audyt lub redesign oznacza dodatkowy budżet i udział kolejnych zespołów.

Ponadto, im dłużej trwa szukanie odpowiedzi, tym więcej klientów rezygnuje, a sprawy, które miały zakończyć się w aplikacji, trafiają do konsultantów.

Pod taką presją łatwo skierować do realizacji pierwsze prawdopodobne rozwiązanie. Bez lepszego rozpoznania problemu nie wiadomo jednak, czy poprawka wpłynie na wynik, czy tylko zajmie czas zespołów i miejsce w roadmapie.

Ryzyko działa również w drugą stronę. Decyzja o pełnym audycie lub redesignie może uruchomić duży projekt, zanim wiadomo, które elementy procesu rzeczywiście wymagają przebudowy. Zakres szybko obejmuje kolejne ekrany, integracje i interesariuszy, choć punkt wyjścia nadal sprowadza się do ogólnego stwierdzenia: klienci nie kończą procesu.

Jak więc ocenić, jaka skala działania jest uzasadniona? Poniższe zestawienie pokazuje różnicę w skrócie, a szczegóły — z konkretnymi sygnałami do rozpoznania — znajdziesz w sekcjach poniżej.

Kiedy wystarczy punktowa poprawka?

Punktowe zmiany mają sens, gdy potencjalna bariera jest lokalna i nie wynika z konstrukcji całego procesu.

Może chodzić na przykład o:

• nieczytelny komunikat,
• słabo widoczną akcję,
• brak informacji o wymaganiach,
• niezrozumiały opis błędu,
• brak potwierdzenia wykonania operacji,
• niejasny kolejny krok.

Za punktową poprawką przemawia sytuacja, w której obserwacje z ekranów, analityki i zgłoszeń klientów wskazują w podobnym kierunku, a zmiana nie wymaga ingerencji w logikę całej ścieżki.

Nadal warto potraktować ją jako hipotezę i po wdrożeniu sprawdzić, czy wpłynęła na konwersję, liczbę błędów albo kontakty z obsługą. Nawet najbardziej oczywista poprawka nie powinna opierać się wyłącznie na przekonaniu zespołu, że „teraz wygląda lepiej”.

Kiedy potrzebny jest pełniejszy audyt UX?

Audyt UX aplikacji bankowej warto rozważyć, gdy problem nie daje się sprowadzić do jednego ekranu albo dostępne sygnały nie układają się w jednoznaczny obraz.

Może tak być, gdy:

• klienci rezygnują na kilku etapach,
• podobne problemy pojawiają się w różnych procesach,
• dane analityczne i zgłoszenia do obsługi wskazują inne źródła trudności,
• nie wiadomo, czy przyczyna leży w interfejsie, logice procesu czy sposobie komunikacji,
• konieczne jest przeanalizowanie nagrań sesji lub przeprowadzenie badań z klientami,
• problem dotyczy spójności między aplikacją mobilną, bankowością internetową i obsługą telefoniczną,
• zespół potrzebuje szerszego planu zmian, a nie rekomendacji dla jednego fragmentu ścieżki.

Pełny audyt UX może objąć kilka procesów, dane ilościowe i jakościowe, badania z użytkownikami, architekturę informacji, spójność interfejsu oraz zależności między kanałami.

Daje szerszy obraz, ale wymaga też większego zaangażowania organizacji. Dlatego dobrze wiedzieć wcześniej, jakie pytania audyt ma rozstrzygnąć i które obszary rzeczywiście powinien objąć.

Kiedy warto rozważyć redesign?

Redesign ma uzasadnienie, gdy problemy nie wynikają już z pojedynczych elementów, ale z konstrukcji większej części rozwiązania.

Sygnałem może być sytuacja, w której:

• kolejne punktowe poprawki nie przynoszą trwałego efektu,
• proces powstawał etapami i stracił spójność,
• użytkownik musi rozumieć wewnętrzną logikę banku, aby przejść przez ścieżkę,
• architektura informacji utrudnia znalezienie podstawowych funkcji,
• design system nie odpowiada już potrzebom produktu,
• podobne bariery występują w wielu procesach,
• aplikacja nie wspiera samoobsługi, mimo że poszczególne funkcje technicznie działają,
• ograniczenia obecnego rozwiązania blokują realizację ważnych celów biznesowych.

Redesign aplikacji bankowej nie musi przy tym oznaczać projektowania całej aplikacji od początku. Może dotyczyć jednego procesu, grupy powiązanych funkcji lub warstwy nawigacji. Zakres powinien wynikać z problemu, a nie z samego przekonania, że aplikacja „potrzebuje odświeżenia”.

UX Health Check przed decyzją o zakresie i budżecie

Kiedy potrzebujesz szybko wrócić do organizacji z bardziej konkretną rekomendacją, możesz zacząć od bezpłatnego UX Health Checku aplikacji bankowej. Problematycznemu procesowi przyjrzy się nasz zespół projektantów i badaczy UX/UI, którzy mają doświadczenie w pracy nad aplikacjami i procesami bankowymi. Dzięki temu ocena uwzględnia nie tylko sam interfejs, ale też specyfikę ścieżek finansowych, wymagania regulacyjne i ograniczenia działających systemów.

Naszym celem nie jest postawienie ostatecznej diagnozy na podstawie kilku ekranów, ale wskazanie potencjalnych punktów tarcia, uporządkowanie hipotez oraz ocena, które obserwacje uzasadniają poprawkę, a które wymagają szerszej weryfikacji.

Do przeprowadzenia oceny wystarczą:

• screeny, makiety lub krótkie nagranie procesu;
• wspólne przejście przez wybraną ścieżkę;
• informacja, na którym etapie spada konwersja;
• najczęstsze powody kontaktu z obsługą;
• kontekst celu biznesowego procesu;
• informacja, czy problem nasilił się po konkretnej zmianie.

Nie potrzebujemy kodu, danych klientów ani dostępu do systemów produkcyjnych. Dzięki temu pierwsza ocena może powstać bez uruchamiania długiej ścieżki organizacyjnej i angażowania IT tylko po to, aby udostępnić środowisko.

Co otrzymasz w ciągu 48 godzin?

Wynik odniesie się bezpośrednio do przekazanego fragmentu procesu i obejmie:

• pięć potencjalnych punktów tarcia zaznaczonych na ekranach,
• wyjaśnienie, jak każdy z nich może wpływać na zachowanie klienta,
• wizualizacje UX i kierunki możliwych zmian,
• trzy benchmarki pokazujące inne sposoby rozwiązania podobnego problemu,
• priorytety dalszego działania,
• wskazanie obserwacji, które wymagają potwierdzenia w danych, nagraniach sesji lub badaniach z klientami.

Materiał nie kończy się więc na stwierdzeniu, że ekran jest nieczytelny albo komunikat zbyt długi. Pokazuje, dlaczego dany element może utrudniać realizację celu i jaki kolejny krok jest proporcjonalny do skali problemu.

Rekomendacje możesz przekazać do własnego zespołu, wykorzystać jako podstawę dodatkowej analizy albo potraktować jako punkt wyjścia do ustalenia zakresu pełnego audytu UX.

UX Health Check nie wiąże się z obowiązkiem kontynuowania współpracy z Altkom Software.

UX Health Check a pełny audyt UX

UX Health Check służy do szybkiej oceny jednego procesu lub jego problematycznego fragmentu. Pomaga wskazać prawdopodobne bariery, uporządkować pierwsze obserwacje i podjąć decyzję o dalszym działaniu.

Pełny audyt UX odpowiada na szersze pytania. Może obejmować kilka procesów, analizę danych, badania z klientami, architekturę informacji, spójność aplikacji oraz zależności między kanałami. Pozwala dokładniej zweryfikować źródła problemów i przygotować szczegółowy plan zmian, ale wymaga też więcej czasu, danych i zaangażowania.

UX Health Check nie jest więc skróconym audytem ani jego darmowym zamiennikiem. To pierwszy krok przed decyzją, czy pełny audyt jest potrzebny i jaki powinien mieć zakres.

Jeżeli dostępne materiały sugerują, że problem może wynikać z analityki, integracji, reguł produktu albo konstrukcji większej części procesu, wynik oceny powinien jasno wskazać, czego nie da się potwierdzić na podstawie samych ekranów i co należy sprawdzić szerzej.

Czy warto sięgnąć po zewnętrzną perspektywę?

Wewnętrzny zespół najlepiej zna produkt, uwarunkowania technologiczne i historię decyzji, które ukształtowały proces. Kiedy jednak pracuje nad nim od miesięcy lub lat, trudniej oddzielić ograniczenia, których rzeczywiście nie można zmienić, od rozwiązań, do których organizacja po prostu zdążyła się przyzwyczaić.

Rolą zewnętrznego zespołu UX/UI nie jest ocenianie pracy banku ani projektowanie procesu od nowa. Chodzi o spojrzenie na ścieżkę bez znajomości jej wewnętrznej logiki, skonfrontowanie obserwacji z zachowaniem klientów i wskazanie zmian, które mają sens w istniejących realiach.

Tak pracowaliśmy z jednym z największych banków komercyjnych w Polsce. W ramach szerszego projektu przeanalizowaliśmy wybrane procesy posprzedażowe w aplikacji mobilnej, przeprowadziliśmy badania z użytkownikami i porównaliśmy rozwiązania rynkowe. Analiza pokazała etapy, na których klienci tracili orientację lub rezygnowali, a przygotowane rekomendacje i koncepcje UX/UI uwzględniały architekturę, design system oraz sposób pracy zespołu deweloperskiego banku.

Bank otrzymał materiał do dalszego upraszczania procesów i wzmacniania samoobsługi bez projektowania całej aplikacji od początku.