Szybkość w UX: lekcje z XTB

Szybkość w UX: lekcje z XTB

Często spotykam się z tym, że klienci chcą mierzyć swój UX poprzez szybkość. Dzisiaj opowiem Ci, jak ta szybkość kosztowała mnie kilka tysięcy złotych dzięki platformie XTB.

Szybciej ≠ lepiej

Od lat uczymy się projektować szybkie doświadczenia. Mniej klików. Krótsza ścieżka. Jedno CTA. Jedna decyzja.

W e-commerce to działa. W produktach codziennego użytku – też.

Problem zaczyna się wtedy, gdy ten sam sposób myślenia przenosimy na obszary, w których stawką są realne pieniądze i realne konsekwencje. Na przykład na inwestycje.

Coraz więcej narzędzi finansowych obiecuje dziś „inwestowanie w kilka sekund". Jedno kliknięcie, szybka decyzja, natychmiastowe poczucie sprawczości. UX jest gładki, intuicyjny i pozbawiony tarcia.

Tylko że decyzje inwestycyjne nie są ani impulsywne, ani bezkosztowe. A przynajmniej nie powinny takie być.

W tym artykule nie będę przekonywał, że szybki UX jest zły. Będę przekonywał, że nie zawsze jest dobry, i że w kontekście inwestycji czasem warto użytkownika celowo spowolnić.

Szybkość jako ułatwienie i jako niebezpieczeństwo

Szybki UX sam w sobie nie jest problemem. Problemem jest bezrefleksyjne założenie, że zawsze prowadzi do lepszych decyzji.

W wielu kontekstach szybkość działa dokładnie tak, jak powinna: skraca czas wykonania zadania, zmniejsza frustrację, pozwala użytkownikowi „załatwić sprawę" i iść dalej.

Ale inwestowanie to zupełnie inna kategoria decyzji. To nie jest czynność rutynowa, tylko wybór obarczony niepewnością, emocjami i konsekwencjami rozciągniętymi w czasie.

W takim kontekście szybki UX przestaje być wsparciem. Zaczyna działać jak akcelerator błędów poznawczych.

I właśnie w tym miejscu pojawia się pytanie, które rzadko zadajemy w projektach finansowych: czy celem UX powinno być przyspieszenie decyzji, czy poprawa jej jakości?

Jak stracić tysiące w kilka sekund w XTB

Składam zlecenie na odpowiednią kwotę. I… po akceptacji okazuje się, że mimo zaznaczenia odpowiedniej kwoty na wykresie, domyślnie podstawiono wartość rynkową.

Chcę więc to szybko anulować, zanim transakcja zostanie sfinalizowana. Ma się na to czasem kilka sekund. Klikam więc przy jedynej zakładce wyświetlony czerwony X.

Niezależnie od tego, ile mamy tych akcji. Czy jest to wartość 100 zł, czy miliona, po prostu sprzedajecie wszystko. Nawet nie ostatni zakup. Tylko wszystkie historyczne zakupy tego aktywa.

A za tym idą już tylko konsekwencje finansowe dla użytkownika:

• Jeżeli trafiliśmy na „dołek" → możemy stracić znaczącą część oszczędności życia.
• Jeżeli trafiliśmy na „górkę" → płacimy podatek od wzbogacenia (19%).
• W obu przypadkach → jeżeli była to sprzedaż nieintencjonalna, dopłacamy aktualny spread, aby zakupić te same akcje.
• I do tego dochodzi prowizja.

Czy to wina użytkownika?

Tak. No wiecie. Wystarczy przeczytać.

Mówimy jednak o sytuacjach, w których zabezpieczamy użytkowników przed ich pochopnymi czynami. I tutaj cały na biało wchodzi mBank.

Po prostu, realnie dobrze zabezpieczają klienta przed pochopnymi decyzjami. Podczas każdego zlecenia prosi o double-check, SMS-em lub potwierdzeniem w aplikacji.

Dlaczego takie rozwiązanie?

Nie do końca wierzę, że nikt na to nie wpadł w XTB. Ludzie, którzy rozumieją UX, dane i realne zachowania użytkowników. Trudno mi uwierzyć, że ten scenariusz po prostu „nie przyszedł nikomu do głowy".

„Bo biznes na tym zarabia." I niestety bardzo często to jest odpowiedź poprawna.

W tym miejscu UX przestaje być neutralnym narzędziem. Staje się elementem modelu biznesowego, który nie chroni użytkownika przed pochopną decyzją, tylko cicho na niej korzysta.

Gdy decyzje projektowe spotykają biznes

Gdy UX jest szybki, niejednoznaczny i pozbawiony momentu refleksji, odpowiedzialność bardzo łatwo przerzucić na użytkownika. A jeszcze łatwiej zarobić na jego pomyłce.

Właśnie dlatego w produktach finansowych pytanie nie powinno brzmieć „czy da się szybciej", tylko „czy w tym miejscu użytkownik naprawdę powinien działać szybko".