PWA jako wyzwanie UX. O czym mówiliśmy na Mobile Trends Conference 2019?

Niedawno zakończona konferencja Mobile Trends 2019 pokazuje, jak dynamicznie zmienia się krajobraz polskiego mobile. Interfejsy głosowe, mobilny e-commerce czy wyzwania związane z dotarciem do pokolenia Z elektryzowały publiczność zgromadzoną w Starej Zajezdni w Krakowie.

Cichym bohaterem wydarzenia okazało się jednak PWA. Choć nie miało własnego bloku w programie, było głównym tematem aż trzech wystąpień: Jenny Gove z Google oraz mocnej reprezentacji e-point – Michała Szklarskiego i niżej podpisanego.

Zagadnienia związane z PWA gościły już na łamach bloga e-point wielokrotnie. Tym razem chciałbym poruszyć ten temat z perspektywy, którą prezentowałem podczas Mobile Trends Conference 2019 – jako wyzwania dla UX designerów pracujących nad pozornie mało „aplikacyjnymi” projektami portali sprzedażowo-obsługowych, np. dla banków lub ubezpieczycieli.

 

Najważniejsze dla użytkowników są aplikacje do obsługi social media oraz komunikatory i to one odpowiadają za coraz dłuższy czas, który użytkownicy spędzają z aplikacjami mobilnymi. Można oczywiście spierać się, że w obszarze aplikacji mobilnych dobrze radzą sobie np. e-commerce oraz serwisy informacyjne, jednak warto pamiętać, że dla okazjonalnych użytkowników instalacja aplikacji stanowi dodatkową barierę wejścia, a budowanie i utrzymywanie aplikacji dedykowanych rozwiązań na różne systemy operacyjne może okazać się nieopłacalne.

Mimo wszystko pokusa, by tworzyć angażujące, „aplikacyjne” rozwiązanie portalowe dla firm z sektora bankowości i finansów, w którym się specjalizujemy, była ogromna. Liczba procesów obsługowych i sprzedażowych czy narzędzi interaktywnych, takich jak kalkulatory czy konfiguratory również sprawia, że dość oczywistą intuicją jest opakowanie ich wszystkich w formę aplikacji natywnej. Wątpliwe jest jednak, czy ktokolwiek ją pobierze. Z tego też powodu złotym środkiem dla nas i dla naszych klientów okazało się PWA.

PWA Checklist

Pracę nad pierwszym w historii e-point portalem sprzedażowo-obsługowym w formie PWA rozpoczęliśmy od analizy PWA Checklist przygotowanej przez Google. Wymagania te dzielą się na podstawowe (baseline) oraz wzorcowe (exemplary) i pozwalają szybko sprawdzić, jak wiele brakuje danej stronie internetowej do spełnienia standardu.

Mogłoby się wydawać, że jest to sytuacja idealna – wystarczy po kolei wprowadzić wszystkie wytyczne i mamy serwis, który zaangażuje naszych użytkowników i sprawi, że z przyjemnością wejdą w świat marki, co w konsekwencji oczywiście doprowadzi do lepszej eksploracji oferty i większej sprzedaży.

Jeśli przyjrzymy się wymaganiom z listy podstawowej, okaże się jednak, że większość z nich dotyczy wymagań technologicznych. Stosowanie bezpiecznego protokołu HTTPS, responsywność, ładowanie w trybie offline, możliwość instalacji czy szybkie działanie nawet w sieciach 3G oczywiście wpływają na doświadczenie użytkownika, jednak tylko w niewielkim stopniu zależą od projektantów user experience.

PWA UX Checklist?

Jedyne wymaganie „nietechnologiczne” z checklisty podstawowej brzmi „Page transitions don't feel like they block on the network” i nawet po zapoznaniu się z objaśnieniem (w tym wypadku: „Snappy as you tap around” – co swoją drogą byłoby świetnym tytułem piosenki) trudno jasno określić, do czego właściwie należy dążyć w projektowaniu.

Checklista rozszerzona zawiera nawet całą sekcję poświęconą zagadnieniom user experience, jednak - ponownie - zawiera ona wytyczne wpływających na doświadczenie użytkownika, ale wynikające raczej z technologii niż z pracy projektanckiej. Lektura całej checklisty pozwala jednak zrozumieć pewien kierunek w myśleniu o tym, czym jest PWA z perspektywy użytkownika według Google.

Mimo wszystko oznaczało to, że musimy jako zespół UX samodzielnie określić obszary, jakimi należy się zaopiekować w pierwszej kolejności, by osiągnąć nasz cel: stworzyć portal sprzedażowo-obsługowy, który zaangażuje użytkownika jak najlepsza aplikacja natywna.

W trakcie procesu projektowego zidentyfikowaliśmy 4 obszary stanowiące dla nas szczególne wyzwanie w projektowaniu UX dla rozwiązania PWA. Nie nawiązywały one bezpośrednio do wymogów technologicznych określonych przez Google. Miały nam jednak pomóc dotrzeć do sedna tego, czym może być “aplikacyjność” w wypadku projektu portalu. Były to:

• Architektura informacji
• Content
• Interakcje i tranzycje
• RWD w podejściu mobile-first

Architektura informacji

Aplikacje mobilne są przyjazne w użyciu, ponieważ ich architektura informacji jest powtarzalna i przejrzysta:

• w skali makro – bo zawsze możemy spodziewać się np. podobnej liczby zagłębień w poszczególnych obszarach aplikacji.
• w skali mikro – bo widoki o podobnej funkcji wyglądają i zachowują się podobnie.

W portalach sprzedażowo-obsługowych największy nacisk kładzie się na jak najlepsze dopasowanie formy prezentacji do konkretnej informacji  np. o produkcie. Z tego powodu strona konta osobistego może się diametralnie różnić od strony konta walutowego, nie mówiąc już o kredycie hipotecznym czy o ubezpieczeniu. Czasami poszczególne produkty czy usługi mogą mieć jeszcze dodatkowe podstrony, co komplikuje także architekturę informacji w skali makro.

Jest to uzasadnione z punktu widzenia komunikacji, jednak utrudnia użytkownikowi „nauczenie się” portalu i stanowi barierę w korzystaniu z niego. To tak, jakby poszczególne albumy w Spotify były prezentowane różnie zależnie od tego, do jakiego gatunku muzycznego zostały zakwalifikowane.

Warto wykonać tutaj dodatkową pracę i już na wczesnym etapie spojrzeć przekrojowo na jak najwięcej produktów z różnych kategorii, by ustalić stałe wzorce prezentacji ich szczegółów. Flagowe produkty, na których na ogół skupiamy się w projektach portalowych na pewno na tym nie ucierpią, a my ułatwiamy eksplorację oferty i sprawiamy, że używanie portalu będzie bardziej naturalne.

Content

Jeśli przyjrzymy się najpopularniejszym aplikacjom mobilnym, zauważymy, że są one wyjątkowo ubogie w content tekstowy. Nawet jeśli pominiemy skrajne przypadki jak Snapchat, okazuje się, że często w ramach jednego ekranu widzimy co najwyżej sto kilkadziesiąt znaków.

Z drugiej strony strony produktowe i dystrybucyjne w typowych portalach naszych klientów i ich konkurencji potrafią pomieścić nawet kilka stron maszynopisu.

Content w tego typu rozwiązaniach to zresztą – wcale nie przesadzam – pole walki między potrzebami użytkownika („szukam konkretnej informacji”), oczekiwaniami marketingu („chcę zakomunikować konkretną informację o promocji”) i w końcu wymaganiami prawnymi („czy możemy tutaj dać jeszcze jeden disclaimer na wszelki wypadek?”).

Prosta recepta „skracać, ile się da” oczywiście pozostaje w mocy – tym bardziej, że jest zgodna z zasadami prostego języka, które zarówno my, jak i nasi klienci staramy się wprowadzać w projektowanych rozwiązań. Nadal nie rozwiązuje jednak problemu.

Naszą ambicją było wypracowanie takiego rozwiązania, które w pewnym sensie przewiduje, czego poszukuje użytkownik i pozwala mu łatwo do tego dotrzeć. Dopiero kolejne interakcje zależne od tego, co wzbudziło zainteresowanie, prowadziły do wyświetlania kolejnych danych z wykorzystaniem wywoływanych modali czy swipe’ów. Wzorcem była dla nas rozmowa z doradcą: mówimy to, co jest najważniejsze, a z mniej istotnymi szczegółami czekamy na zadanie pytania.

Interakcje i tranzycje

Użytkownicy pytani o to, co im się podoba w aplikacjach mobilnych, często wyjawiają, że jest to po prostu szeroko pojęta „fajność”. Kryją się za tym różne rzeczy, m.in. to, jak aplikacja reaguje na akcje użytkownika. Oczywiście nie korzystamy z aplikacji po to, by zachwycać się mikrointerakcjami i przejściami między ekranami, jednak może sprawiać to odrobinę radości i koniec końców poprawiać doświadczenie.

Dbając o pozytywne wrażenia, musimy pamiętać, że równie ważna jest szybkość działania oraz zgodność z różnymi systemami operacyjnymi i przeglądarkami. Z tego powodu kluczowe było dla nas wypracowanie takiego zestawu interakcji i tranzycji, które nie będą zwykłą ozdobą, a ułatwią korzystanie z serwisu i zapewnią tę snappiness zawartą w PWA Checklist.

Wiele z nich służyło właśnie do tego, by lepiej poruszać się w morzu contentu, o czym wspomniałem już powyżej. Nawet najprostszy swipe ma duży wpływ na komfort korzystania z portalu, gdy np. pozwala łatwo poruszać się między różnymi promocjami czy produktami. Naczelną zasadą dla projektantów stało się zatem „jak najmniej, by osiągnąć jak najwięcej”.

RWD w podejściu mobile-first

Jednym z większych zaskoczeń w projektowaniu portalu w formie PWA było to, jak nieoczywiste jest jego przełożenie na widoki desktopowe. Oczywiście, projektowanie w RWD oraz podejściu mobile-first to dla nas nie pierwszyzna. Okazało się jednak, że logika aplikacji na smartfon oraz logika portalu informacyjnego prezentowanego na desktopie są jak ogień i woda.

Podział informacji na jak najmniejsze cząstki informacji to duże wyzwanie w budowaniu rozwiązania, które ma dobrze wyglądać i działać na smartfonie. Proste przerzucenie tych samych treści na widok desktopowy powoduje wrażenie pustki, która może być nawet bardzo estetyczna, ale utrudnia skupienie się i lekturę serwisu.

Horror vacui to niejedyny problem. Odmienne urządzenia nie oznaczają przecież wyłącznie innej wielkości ekranu. Z ekranu dotykowego korzystamy zgodnie z nazwą - dotykając go. Otwieranie i zamykanie modali czy swipe’owanie są bardzo naturalne. W wypadku większości komputerów osobistych musimy korzystać z touchpada lub myszki, co sprawia, że taka interakcja z portalem jest zupełnie nienaturalna - użytkownicy są przyzwyczajeni raczej do scrollowania. Najpewniej zresztą nawet na laptopach z ekranem dotykowym droga, jaką pokonują nasze palce mogłaby być niekomfortowo długa.

Oznaczało to, że zasady transformacji między widokiem mobile a desktop były bardziej złożone niż zazwyczaj. Chcieliśmy zachować pełną spójność prezentowanych treści w obu kanałach, co oznaczało różne taktyki przekształcania komponentów budujących portal zależnie od ich roli w budowaniu komunikacji i funkcji dla użytkownika.

W końcu należy podkreślić coś, co nie jest związane z samym PWA, ale zasługuje na podkreślanie jak najczęściej. Mobile i desktop oznaczają inny kontekst użycia oraz inne aktualne potrzeby użytkownika, którymi jako projektanci musimy się zająć. PWA może być okazją, żeby to jeszcze dogłębniej przemyśleć, kiedy i jak mobile i desktop mogą się uzupełniać, a kiedy po prostu są używane niezależnie.

Podsumowanie

Największym wyzwaniem w naszej pracy było określenie, jakie są szczególne cechy aplikacji mobilnych, które warto przenieść do pozornie odmiennego od nich świata portali sprzedażowo-obsługowych. Okazało się, że na głębszym poziomie PWA to znacznie więcej niż tylko spełnienie konkretnych zaleceń z checklisty Google. To także przemyślenie, czym właściwie jest “aplikacyjność”, którą chcielibyśmy osiągnąć w naszych projektach.

Obecnie w e-point pracujemy nad kilkoma projektami wykorzystującymi PWA - zarówno z obszaru portali, jak i e-commerce. Niedługo opowiemy o nich więcej i pokażemy, jak nowe rozwiązania przekładają się na satysfakcję użytkownika oraz oczekiwania biznesowe. Już teraz jednak wiemy z wyników badań użyteczności oraz dyskusji z naszymi klientami, że warto włożyć dodatkowy wysiłek w mądre wdrożenie PWA.