Tekst powstał w ramach niewspieranej już inicjatywy internetteam.pl
Dzięki ogromnemu zaufaniu, jakim obdarzył mnie Mikołaj, miałam przyjemność uczestniczyć w dwudniowych warsztatach Google w Dublinie. Szczerze mówiąc, taki wyjazd polecam każdemu, kto chce się natchnąć atmosferą branży i dowiedzieć, że nie jest sam z najróżniejszymi wyzwaniami w firmie. I przejrzeć dużo faktów, statystyk i case study. Ponieważ tegoroczne edycje Conversions są już za nami, to naprawdę szczerze zachęcam Was do obejrzenia prezentacji na YouTube (jeśli nie chcecie obejrzeć wszystkich, to sprawdźcie przynajmniej Luka Wroblewskiego – jeszcze go nie ma na YouTube, ale podlinkuję go tu, gdy już będzie).
Przechodząc do konkretów – oto najważniejsze wnioski z prezentacji, które zostały tam pokazane.
(TL;DR na końcu)
Źródło: Shane Cassells, materiały Google@Conversions
Ciekawscy, wymagający, niecierpliwi – oto, jacy jesteśmy dlatego, że korzystamy z telefonu. Wszystko mamy na wyciągnięcie ręki – czy raczej na wyciągnięcie telefonu z kieszeni. Pisała zresztą o tym Magda – tutaj.
Jest taki żart, że jeśli chcesz sprawdzić, jaka naprawdę jest Twoja druga połówka, to daj mu/jej telefon z wolnym łączem internetowym i każ coś znaleźć. Poznasz prawdę. :>
Dlatego tak ogromny nacisk wszystkie mądre technologiczne głowy kładą na to, aby strony czy aplikacje na mobile działały jak najlepiej – a to znaczy szybko i intuicyjnie. I to dlatego podkreśla się, że projektować trzeba, mając na uwadze możliwie najwolniejsze łącza internetowe, najmniejsze ekrany i 10-letnich użytkowników po drugiej stronie. I tak, te wszystkie czynniki powinny składać się na możliwie najlepszy UX, jaki jesteśmy w stanie dać naszym użytkownikom.
Źródło: Lina Hansson, materiały Google@Conversions
Jak pokazują statystyki, sprzedaż na mobile stale rośnie. Jednak rośnie nie dlatego, że mobile jest lepszy niż desktop, tylko dlatego, że odnotowujemy globalny wzrost mobile. Użytkownicy (65%!) jednak już teraz stwierdzają, że chętniej skorzystałoby z usług firmy, z której do tej pory nie korzystało, tylko dlatego, że ma przyjaźniejszą aplikację. Czy to nie daje do myślenia?
O CZYM PAMIĘTAĆ, PROJEKTUJĄC DLA MOBILE
SZYBKOŚĆ ŁADOWANIA STRONY
Źródło: Luke Wroblewski, materiały Google@Conversions
Źródło: Lina Hansson, materiały Google@Conversions
Co jeszcze było mocno podkreślane? Projektowanie dla łączy, które są wolniejsze niż 3G, a te ciągle jeszcze dominują w Polsce i na świecie. Te łącza niestety nie ratują ludzi przed nieskończoną frustracją z powodu wolnego ładowania się stron (53% użytkowników porzuca stronę, jeśli ładuje się dłużej niż 3s*). Brak zasięgu to trzeci najważniejszy powód wszystkich porzuconych koszyków zakupowych w US, UK i DE (kolejny po problemach z wprowadzeniem danych osobowych i „ekranie za małym, by zobaczyć, co kupuję”)**. Uczyńmy z szybkości ładowania strony KPI, niech to będzie coś, do czego będziemy szczerze dążyć.
Pro info: czas ładowania strony nie może przekraczać 5 s, waga strony 1 MB, a speed index 3000.
* Lina Hansson via Doubleclick: “The need for mobile speed: How mobile latency impacts publisher revenue”.
** Shane Cassells via Addressy, ‘Fixing Failed deliveries: Improving Data Quality in Retail’, conducted by Loudhouse, Dec 5, 2017.
WYSZUKIWARKA
Źródło: Lina Hansson, materiały Google@Conversions
Gdy ludzie znajdują to, czego szukają, kupują 4 razy częściej.
Tak, dzięki wyszukiwarce mamy 4 razy większą konwersję.
PROBLEMY LAYOUTU
Źródło obu zdjęć: Luke Wroblewski, materiały Google@Conversions
Projektujemy „dla kciuka” – to kciuk jest na ekranie najdłużej, dotyka ekranu przez 90% czasu w porównaniu do innych palców. Co więcej, w większości projektujemy też dla układu pionowego – dopiero z ekranów o przekątnej 9-12” korzystamy w układzie poziomym. Pamiętajmy o tym, że jeden kciuk ma ograniczony zasięg.
Wiele aplikacji chwali się superficzerami, ale one niewiele mówią o tym, do czego służy aplikacja i jak z niej korzystać. Bo co może nam powiedzieć o aplikacji – na pierwszym ekranie – sesja zdjęciowa swetra albo obrazek z tropikalną wyspą? Co z tego, że dowiem się, że pod tym niebieskim, okrągłym przyciskiem mogę zapoznać się z opisem kawy, jeśli nie wiem, jak ją zamówić?
Intro tour wcale nie jest potrzebne – użytkownicy starają się je jak najszybciej wyłączyć. Czym jednak można je zastąpić, jeśli sądzimy, że warto poinstruować użytkownika? Spróbujmy chmurek z instrukcjami, ale pamiętając o tym, że muszą być dopasowane do UI całej aplikacji. Jeśli nie będą – zostaną pominięte w podobny sposób (overlay avoidance). Mimo wszystko nie bójmy się uczyć użytkowników, jak korzystać z naszych aplikacji.
Źródło: Anna Potanina, materiały Google@Conversions
Gdzie umieścić menu strony? A gdzie są główne przyciski nawigacyjne w telefonie? Gdzie umieszczają je aplikacje mobilne? Na dole. Menu strony czy aplikacji webowej też powinno tam być. Jeśli użytkownicy stwierdzą, że zajmuje ono za dużo miejsca – chowajmy je i wywołujmy odpowiednim gestem. I tyle.
Źródło: Lina Hansson, materiały Google@Conversions
Pokażmy na samym początku value proposition, dobre hasło, dopasowane do odbiorców. Poniżej pokażmy kategorie, a nie kampanie, które na mobile nie są najważniejsze. Jak wspomniałam, sweter nie powie nam o tym, co kupimy dzięki tej aplikacji. Stąd wynika też inna rada: pokażmy wszystkie kategorie naszego sklepu / całe menu na jednej stronie – nie każmy użytkownikom polegać na ich pamięci.
Źródło: Luke Wroblewski, materiały Google@Conversions
Pokażmy główną wartość produktu tak szybko, jak to możliwe. Pozbądźmy się rzeczy, które uniemożliwiają skorzystanie z aplikacji / strony od razu – zostawmy tylko te niezbędne dla prawidłowego funkcjonowania aplikacji. Dla map Google podstawowa wartość to mapy, a nie rejestracja do aplikacji. Jednak jeśli mapy mają powiedzieć Ci, gdzie jesteś, muszą znać Twoją lokalizację – więc o nią pytają. Proste.
We don’t want to type. We want to tap.
W przypadku zakupów czy rejestracji w mobile użytkownika nie powinny dzielić więcej niż 3-4 kliki od dokonania zakupu czy rejestracji.
TEKSTY
Teksty, polecenia muszą być zrozumiałe przez 10-latka. Pisząc, miejmy na myśli korzyść użytkownika, a nie zalety produktu. Informujmy, co użytkownik zyskuje dzięki Twojej aplikacji.
Nie każmy, przez źle dobrane słowa, angażować się użytkownikowi na etapie, na którym może zupełnie tego nie chcieć.
Przykład? Bardzo proszę:
Źródło: Anna Potanina, materiały Google@Conversions
Źródło: Anna Potanina, materiały Google@Conversions
Nazywajmy przyciski. To jest superważne. Użytkownicy na podstawie samych ikonek nie wiedzą, czego spodziewać się pod przyciskiem. Zwłaszcza, jeśli z aplikacji nie korzystają regularnie. Czym są te dwa kółeczka ułożone poziomo obok siebie? Nie wiesz? Twój użytkownik też nie.
POLA DO WPISANIA TEKSTU
Jeśli chcesz zaangażować użytkownika, daj mu pole do wpisania tekstu. +23% konwersji tylko dzięki podpowiedziom w polach do wpisania (autofill).
Ale uwaga!
Źródło: Craig Sullivan, materiały Google@Conversions
JAK POKAZYWAĆ, ŻE STRONA JESZCZE SIĘ ŁADUJE
Spinner sprawia, że ludzie myślą, że strona jest powolna.
Zastosowanie szkieletu strony wydawało się lepsze niż spinner, ale użytkownicy zaczęli odbierać taki widok negatywnie – bo czekali. Czekali, aż strona się załaduje. Strona znowu kazała im czekać, więc dochodzili do wniosku, że jest wolna i ją wyłączali.
Źródło: Luke Wroblewski, materiały Google@Conversions
Co może zadziałać najlepiej? Ficzer, który wprowadziły zdjęcia Google – część materiału ładuje się w formie szkieletu, a część pokazuje się (przynajmniej pojedynczo) jako rozpikselowane obrazy. Dzięki temu użytkownicy dostają podgląd treści, mimo że widzą, że strona się ładuje. Mają już kontekst! Nie irytują się, czekają, nie wyłączają strony.
TESTY A/B
Czy ktoś gdzieś kiedyś o tym nie mówił? Stawiajmy właściwe hipotezy i określajmy czynniki sukcesu. Musimy przemyśleć, co chcemy zmierzyć i co musimy zrobić, żeby wynik badania był prawdziwy. Możemy też skorzystać ze wzoru, zdania:
Jeśli…, to…, dlatego, że…
Właściwie segmentujmy użytkowników – dowiedzmy się dokładnie, na jakiej grupie użytkowników nam zależy i do nich kierujmy testy. Niech testy trwają odpowiednio długo – wyznaczmy granicę przynajmniej albo 200 konwersji, albo 14 dni, albo 95% istotności statystycznej.
Sprawdzajmy wartości bezwzględne – czy może nie promowaliśmy jakiś wyjątkowy produktu w danym czasie, czy nie było o nim wzmianki w mediach społecznościowych, czy nie pojawił się jakiś artykuł… Zbadajmy dobrze, skąd się bierze ta doskonała sprzedaż.
Róbmy dokumentację testów – dokładną, ze screenami, opisami i komentarzami.
Przeprowadźmy raz jeszcze testy A/B w tych samych warunkach po to, by sprawdzić, czy wyniki się pokrywają.
TL;DR:
- Nie projektujemy już dla jednego desktopu, ale dla wielu, wielu ekranów i wielu sprzętów, a każdy z nich może działać inaczej. Dlatego kluczowa jest optymalizacja stron pod mobile – i to nie tylko responsywność, ale pełna optymalizacja.
- Aplikacji nie projektujemy wyłącznie dla myszki czy dla ekranu dotykowego, z którego korzystamy całą dłonią. Projektujemy „dla kciuka” – to on jest na ekranie najdłużej, dotyka ekranu przez 90% czasu w porównaniu do innych palców. Co więcej, w większości projektujemy też dla układu pionowego. Pamiętajmy o tym, że jeden kciuk ma ograniczony zasięg.
- Testujmy i walidujmy wszystko, nawet jeśli nikt nie zgłosił, że nie działa.
- Jak testować? Na najmniejszym ekranie, z którego korzystają użytkownicy. Sprawdź, co dokładnie nie działa na tym właśnie ekranie i właśnie tym się zajmij. Tak prawdę mówiąc, do testów wystarczy 4-5 urządzeń, żeby sprawdzić najpopularniejsze przeglądarki i błędy. Zróbmy z tego KPI i sprawmy, by użytkownik każdego urządzenia był zadowolony, gdy korzysta ze strony.
- Drobne błędy mogą nas naprawdę dużo kosztować, a dostępność naszych stron dla małych urządzeń zagwarantuje nam zasięg i kasę.
- Nawet jeśli mamy bardzo dobry proces, i tak warto go zoptymalizować. Dążmy np. do 8 sekund przy rezerwacji hotelu albo realizacji zasady „3 taps and swipe”.