Projektowanie UX dla bankowości.

W ciągu ostatnich 10 lat pomogliśmy wymyślić, zaprojektować i wdrożyć ponad 10 systemów transakcyjnych oraz kilkadziesiąt serwisów informacyjnych i sprzedażowych dla wielu banków. Ponad 10 milionów klientów korzysta na co dzień z naszych rozwiązań, włączając w to klientów dwóch największych banków w Polsce: PKO Banku Polskiego oraz Banku Pekao S.A.

Co jest najważniejsze w projektowaniu dla bankowości? Oto kilka historii z naszych projektów i kilka wskazówek na podstawie naszych doświadczeń.

Proces jest tak samo ważny jak produkt.

Zacznijmy od tego, że cyfrowe projekty dla bankowości to często projekty gigantycznej wielkości. Duże banki oferują setki produktów finansowych dla wielu grup klientów, a serwisy bankowe liczą tysiące stron. Systemy transakcyjne składają się z setek ekranów (ponad 500 nie jest liczbą zaskakującą) i w przeciwieństwie do serwisów informacyjnych nie ma tam szablonów, każdy ekran jest przynajmniej częściowo unikalny.

Weźmy teraz pod uwagę Responsive Web Design i pomnóżmy to wszystko przez 2, może 3 lub 4, w zależności od projektu i liczby breakpointów. Nie zapominajmy o iteracjach, zmianach, poprawkach.

Produkcja tysięcy layoutów w Photoshopie i zarządzanie zmianą to szaleństwo. Więc odpowiedni proces pracy jest niezwykle ważny.

To, co chcemy osiągnąć, to:

• Zminimalizować liczbę plików graficznych tak bardzo, jak to możliwe…
• …ale developerzy ciągle potrzebują wiedzieć, jak ma wyglądać każdy z ekranów, jak to wszystko się łączy i jak ma działać.

Te dwie rzeczy stoją ze sobą w sprzeczności. Jak to zrobić?

Pierwszym projektem bankowym, nad którym pracowałem, był redesign systemu transakcyjnego Pekao24 dla Banku Pekao S.A. w latach 2008–9. Chociaż trochę się już zestarzał, system ten jest ciągle w użyciu i ciągle wygląda prościej i czyściej niż wiele dużo nowszych systemów bankowych.

Podczas tego projektu stworzyliśmy zaledwie około 20 projektów graficznych oraz listę styli dla wszystkich elementów interfejsu, jednak musieliśmy przygotować każdy niepowtarzalny ekran (było ich prawie 500) jako makietę.

Oczywiście dużo szybciej można przygotować surowe makiety, używając do tego biblioteki wcześniej zaprojektowanych elementów, niż składać perfekcyjne co do piksela projekty w Photoshopie. Developerom wystarczyło kilkanaście projektów, lista stylów, plus nasze makiety jako dokumentacja.

Na początku projektanci UX pracowali nad koncepcją, strukturą i nawigacją, a potem projektant graficzny wkroczył, żeby przygotować kilka kluczowych ekranów, jak strona główna, czy formularz przelewu. Następnie projektanci UX zaczęli pracę nad makietami dla wszystkich ekranów, konsultując się na bieżąco z projektantem graficznym. Jeżeli potrzebne były nowe elementy graficzne dla nowych ekranów lub funkcji, projektant graficzny przygotowywał je i dodawaliśmy je do naszej biblioteki, aby móc używać ich przy tworzeniu makiet.

Pracowaliśmy w sprintach i prezentowaliśmy klientowi nowe efekty naszej pracy raz w tygodniu. Raz na kilka tygodni odbywało się spotkanie komitetu sterującego, w którym uczestniczyli wszyscy dyrektorzy z Banku zaangażowani w projekt. Na tych spotkaniach podejmowane były najważniejsze decyzje projektowe.

Mieliśmy dostęp do wewnętrznego serwera testowego systemu, ale raz na jakiś czas napotykaliśmy na procesy, których nie dało się łatwo wywołać. W przypadku tak dużych i złożonych systemów nikt nie wie wszystkiego, a uzyskanie informacji może zająć dnie albo nawet tygodnie. Jednak podczas pracy z Pekao wystarczyło, że zadzwoniliśmy do klienta z pytaniami i w ciągu kilku godzin otrzymywaliśmy pełną dokumentację całego procesu przygotowaną specjalnie dla nas. Osoby po stronie Banku były w 100% dedykowane projektowi, co dawało nam niesamowity komfort pracy. Projekt był trudny, ale poczucie partnerstwa było wspaniałe.

Innym przykładem procesu zorientowanego na minimalizację pracy koniecznej do wykonania przy bardzo dużym projekcie jest nasz niedawny redesign głównego serwisu informacyjnego PKO Banku Polskiego. Zaprojektowaliśmy ten serwis po raz drugi po naszym pierwszym podejściu do tego tematu w latach 2009–2010 (więcej o tym później). Serwis jest ogromy — ponad 15 000 stron z setkami produktów finansowych dla różnych grup odbiorców: klientów indywidualnych, małych i średnich firm, dużych korporacji i instytucji, i tak dalej. Tym razem chcieliśmy wprowadzić Responsive Web Design i wiele innych usprawnień. I zgadnijcie, co?

Nie przygotowaliśmy ani jednej makiety w tym projekcie (nie licząc kilku na etapie tworzenia koncepcji, których klient nigdy nie zobaczył).

Jeśli Twoi projektanci UX wiedzą co robią i dobrze dogadują się z projektantami graficznymi, to możesz od początku pracować na projekcie graficznym. Wszystko czego potrzebowałem przy tym projekcie, to szybkich burz mózgów na kartce papieru z naszym Art Directorem, i tyle. Finalnym produktem było kilkadziesiąt plików PSD z szablonami, lista stylów oraz spis zasad skalowania serwisu od desktopu, przez tablet, do telefonu. I oczywiście wielki arkusz Excela ze strukturą wszystkiego.

Efekty? Kilka miesięcy temu PKO Bank Polski został nagrodzony jako bank najbardziej przyjazny dla użytkowników za swój serwis, aplikację mobilną, oraz system transakcyjny iPKO (który też pomogliśmy zaprojektować) przez magazyn Puls Biznesu, który przeprowadził audyt cyfrowych punktów styku wszystkich polskich banków. Fajnie jest być częścią tego sukcesu, który nie byłby możliwy bez zaufania i ciężkiej pracy wielu pracowników Banku.

Projektuj system.

Duże banki nie tylko mają bardzo skomplikowane serwisy, ale mają ich też bardzo wiele. Trzeba myśleć globalnie.

Kiedy pracowaliśmy nad pierwszą wersją naszego portalu dla PKO Banku Polskiego z 2010 roku, stworzyliśmy język projektowy możliwy do zastosowania dla wielu cyfrowych punktów styku: serwisów internetowych, aplikacji mobilnych, bankomatów.

System był oparty na koncepcji kafelków pełniących rolę nawigacji i został pomyślany w ten sposób, aby można było go łatwo adaptować do różnych kontekstów i rozdzielczości. Była to w tym czasie dość innowacyjna idea (Ethan Marcotte dopiero co stworzył pojęcie Responsive Web Design w maju 2010!) i nasz CEO myślał, że jestem szalony. Niestety nasz projekt nie został nigdy wdrożony jako prawdziwe RWD (myślę, że było na to zbyt wcześnie), jednak wypracowany wtedy język wizualny został wykorzystany w kilkudziesięciu serwisach różnych spółek Banku, i w serwisach transakcyjnych iPKO, SKO i PKO Junior.

Wspomniana poprzednia wersja głównego serwisu PKO Banku Polskiego została nominowana do prestiżowego konkursu IxDA Awards w 2011 roku, jako pierwszy i jedyny projekt z Polski do tej pory.

Cokolwiek robisz, warto myśleć o kontekście szerszym, niż Twój obecny projekt i zaprojektować system. Poniżej przykład systemu projektowego przygotowane przez nas podczas redesignu głównego serwisu Raiffeisen POLBANK w 2012 roku.

Pracując nad tym projektem, inspirowaliśmy się pracami Otla Aichera, niesamowitego niemieckiego projektanta graficznego, autora logo Raiffeisen, logo Lufthansy, identyfikacji igrzysk olimpijskich z 1972 roku i wielu innych wspaniałych projektów. Proste, płaskie elementy i ikonografia— flat design na wiele lat wcześniej, zanim stał się modą w webdesignie.

Zaplanuj czas na innowację i eksperymenty na samym początku.

Realizacja wielkich projektów dla banków zajmuje przeważnie rok lub dłużej. Jest dużo czasu do premiery, a poza tym duże projekty powinny mieć długi czas życia. Warto więc myśleć o tym, jak zmienia się sieć, jak będzie ewoluować, jak mogą zmieniać się potrzeby biznesowe i wymagania klientów, jaka będzie przyszłość?

Warto poeksperymentować na początku i spróbować przygotować kilka różnych rozwiązań. Bo po paru miesiącach w projekcie wszyscy będą nim zmęczeni i nie będą już myśleć o innowacji, ale o tym, żeby tylko skończyć.

Kiedy projektowaliśmy system transakcyjny iPKO dla PKO Banku Polskiego w latach 2012–14 przygotowaliśmy na początku pracy aż 26 różnych konceptów! Poniżej kilka niewykorzystanych projektów graficznych.

W czasie redesignu głównego serwisu PKO Banku Polskiego w 2016 roku także przygotowaliśmy przynajmniej 5 albo 6 kompletnie różnych konceptów na samym początku. Przez dłuższy czas rozwijaliśmy jeden z nich, który nazwaliśmy “Focus”. Chcieliśmy skupiać uwagę użytkowników, chowając wszystkie rozpraszające elementy. I chcieliśmy też zrezygnować z typowej strony głównej, zastępując ją zestawem najpopularniejszych stron produktowych. Projekt opierał się na niestandardowej nawigacji wykorzystującej przybliżenia i oddalenia (zoom-in i zoom-out).

W końcu zrezygnowaliśmy z tej koncepcji, ale pracując nad nią, wiele się nauczyliśmy i wykorzystaliśmy z niej wiele elementów w finalnej wersji.

Poznaj swoich użytkowników.

Zrozumienie potrzeb, problemów i zadań większości użytkowników bankowości nie powinno sprawiać problemu designerom. W końcu wszyscy jesteśmy klientami banków. Ale co z niektórymi specyficznymi grupami klientów, jak małe firmy, korporacje i instytucje, profesjonalni inwestorzy, zamożni klienci bankowości prywatnej, studenci, nastolatki lub dzieci, albo osoby starsze? Banki zawsze próbują zwiększać swój zasięg i docierać do klientów z wyspecjalizowanymi rozwiązaniami. W takich przypadkach warto poświęcić trochę czasu, aby lepiej zrozumieć naszą grupę docelową.

Kiedy Bank Pekao S.A. poprosił nas o przeprojektowanie i ulepszenie interfejsu systemu transakcyjnego dla klientów korporacyjnych, PekaoBIZNES24, musieliśmy poznać i zrozumieć potrzeby i codzienne zadania księgowych, dyrektorów finansowych i managerów z dużych korporacji, którzy korzystają z tego serwisu.

Zebraliśmy wymagania od ponad setki klientów Banku, użytkowników systemu. Te informacje pomogły nam w przygotowaniu wizji nowego interfejsu.

Bankowość korporacyjna bardzo różni się od bankowości dla klientów indywidualnych. Ci ostatni logują się do banku od czasu do czasu na parę minut, ale niektórzy klienci bankowości korporacyjnej spędzają całe dnie korzystając ze swoich systemów transakcyjnych: to ich praca.

Jednymi z bardziej niecodziennych projektów, nad jakim pracowaliśmy, było zaprojektowanie dwóch serwisów transakcyjnych dla dzieci dla PKO Banku Polskiego: SKO i PKO Junior.

Szkolne Kasy Oszczędności, czyli SKO, to polski program edukacji finansowej dla dzieci w wieku 6–13 lat. Został uruchomiony w 1927 roku i ciągle działa jako usługa PKO Banku Polskiego. SKO było bardzo popularne po II Wojnie Światowej, zwłaszcza w latach 80-tych, kiedy uczestnictwo w programie było obowiązkowe dla wszystkich szkół podstawowych.

W jaki sposób działa usługa? Ponieważ dzieci w wieku poniżej 13 lat nie mogą korzystać z własnego konta bankowego, konta są zarządzane przez szkoły. Nauczyciele wpłacają depozyty i wypłacają pieniądze dla swoich uczniów, a oprócz tego ich rolą jest edukowanie dzieci i motywowanie ich do oszczędzania. SKO w swojej wcześniejszej formie opierało się o papierowe książeczki, które były ręcznie wypełniane przez nauczycieli, ale w 2011 roku PKO Bank Polski postanowił odświeżyć całą usługę i poprosił nas o zaprojektowanie nowego serwisu internetowego. Papierowe książeczki SKO miały zostać zastąpione przez dwie aplikacje — jedną dla dzieci, i drugą do zarządzania finansami uczniów dla nauczycieli.

Kiedy zastanawialiśmy się nad tym, jak mogłaby wyglądać bankowości dla 6–13-latków, inspirowaliśmy się serwisami takimi jak Mint.com, ale chcieliśmy sprawić, żeby zarządzanie pieniędzmi było przystępne dla dzieci. Aplikacja powinna być przyjemna w użyciu i motywować dzieci do oszczędzania.

Warto zauważyć, że różnice w rozwoju między dziećmi w wieku 6 i 13 lat są ogromne. Sześciolatki dopiero uczą się czytać i wykonywać najprostsze działania matematyczne, a to, co jest fajne dla młodszych dzieci, szybko staje się nudne, czy nawet żenujące, dla starszych.

Nasz system musiał odpowiadać na potrzeby i zainteresowania wszystkich grup wiekowych i edukować dzieci na temat finansów w sposób dostosowany do ich poziomu.

Początkowo myśleliśmy, żeby podzielić aplikację na dwie części, dla młodszych i starszych dzieci, z odmiennymi funkcjami, ale w końcu doszliśmy do wniosku, że jest to bardziej skomplikowane i gorsze podejście. Zamiast tego zadecydowaliśmy, że podstawowe funkcje powinny być dostępne dla wszystkich grup wiekowych, ale chcieliśmy też dodać kilka bardziej zaawansowanych funkcji dla starszych dzieci. Młodsze dzieci mogą próbować z nich skorzystać, ale jeśli okaże się, że to dla nich zbyt trudne, to nie muszą ich w ogóle używać.

Po tym, jak wypracowaliśmy wstępny projekt funkcji i interakcji, przetestowaliśmy nasz prototyp z dziewczynkami i chłopcami w różnym wieku, i była to dla nas cenna lekcja, która spowodowała zmianę niektórych naszych założeń.

Główną funkcją aplikacji jest tworzenie świnek skarbonek na różne cele oszczędnościowe. Dzieci mogą wyznaczyć sobie tak wiele różnych celów, jak chcą, i przypisać do każdego z nich określoną sumę pieniędzy. Później mogą śledzić swoje postępy w oszczędzaniu na każdy cel. Aplikacja pomaga obliczyć, ile pieniędzy użytkownik powinien odkładać, żeby osiągnąć cel w wyznaczonym czasie. Dzieci nie muszą wpisywać określonej daty, mogą wybrać opcje, takie jak “przyszły miesiąc”, “letnie wakacje”, albo “święta”.

Każde konto SKO to prawdziwe konto bankowe, które ma swój numer rachunku i rodzice mogą na nie przelewać pieniądze, ale nie można wypłacić środków bez pozwolenia rodziców. Nauczyciele odpowiadają za wpłaty gotówkowe i wypłaty.

Projekt SKO okazał się dużym sukcesem. Ponad 4500 szkół uczestniczy obecnie w programie (1/3 wszystkich szkół podstawowych w Polsce).

W późniejszym czasie zaprojektowaliśmy także system transakcyjny PKO Junior, który jest w całości zarządzany przez rodziców, nie przez szkoły, i jest bardzo podobny do SKO, choć ma trochę inne funkcje. W systemie założono ponad 16 000 kont.

Przyszłość jest teraz.

Jaka będzie przyszłość bankowości? Jedną z odpowiedzi jest na pewno mobile. Bankowość mobilna jest rosnącym trendem.

Pracowaliśmy nad mobilnym system transakcyjnym już w 2009 roku, projektując mobilną bankowość dla Banku Pekao S.A., a w 2013 pomogliśmy im stworzyć mobilny system płatności PeoPay.

PeoPay to nowoczesny i wygodny sposób na płacenie bez gotówki. Pozwala na dokonywanie płatności w sklepach i punktach usługowych, płatności internetowe, oraz szybkie przelewy między użytkownikami aplikacji. PeoPay idzie o krok dalej, niż inne systemy płatności mobilnych, oferując także aplikację dla sprzedawców. Pozwala ona na przyjmowanie płatności na telefonie bez potrzeby używania dodatkowego sprzętu lub terminala.

Ważnym elementem całego doświadczenia użytkownika jest interfejs aplikacji. Jest on oparty o gesty i pozwala na obsługę jedną ręką, tylko przy użyciu kciuka. Korzystając z oprogramowania Adobe Air przygotowaliśmy prototyp aplikacji, co pozwoliło nam na bardzo szybkie przetestowanie interfejsu na telefonie.

Większość banków w Polsce zdążyła już przebudować swoje serwisy informacyjne, tak aby były responsywne i dobrze działały na telefonach. Pomogliśmy w tym Bankowi Raiffeisen w 2012 roku i PKO Bankowi Polskiemu w 2016. Złożyliśmy propozycję wdrożenia RWD w ich głównym serwisie informacyjnym Bankowi Pekao S.A., ale pozostała ona niestety niezrealizowana i do dzisiaj serwis jest dostępny tylko na desktopie.

Jeżeli chodzi o systemy transakcyjne, to przejście do podejścia Responsive Web Design przebiega wolniej. Wiele banków uważa, że wystarczy zaoferować klientom aplikacje mobilne. Oto nasza kolejna niezrealizowana propozycja responsywnego systemu transakcyjnego Pekao24 dla Pekao S.A.

Jednak dla nas przyszłość bankowości to omnichannel — bankowość webowa na desktopie i mobile’u, aplikacje mobilne, smart zegarki, smart głośniki, komunikatory… I nie powinniśmy zapominać o tradycyjnych punktach styku, jak placówki bankowe, które także stają się coraz bardziej “cyfrowe” — zdarzyło nam się pracować nad konceptem “placówki bankowej przyszłości”.

Jest to myślenie, które stoi za naszym ostatnim projektem K2 Banku: prototypu cyfrowego wielokanałowego systemu bankowego, którego interfejs jest w całości oparty o robota-asystenta, wykorzystującego technologię sztucznej inteligencji. Jest to również nasza wizja przyszłości bankowości po tym, jak dyrektywa unijna PSD2 zostanie wdrożona w Europie. PSD2 zmusi banki do udostępnienia API z danymi klientów, co z pewnością otworzy wiele nowych, ekscytujących możliwości w bankowości!

Autor: Maciej Lipiec.