Optymalizacja UX

UX a SEO: jeden problem, dwa rachunki

Gdy klient nie może znaleźć produktu albo formularz odrzuca jego numer telefonu, płacisz dwa razy. Najpierw utraconą sprzedażą, od razu. Potem słabszą widocznością, z opóźnieniem i bez wyraźnej przyczyny w raportach.

Google nie ocenia, czy strona jest ładna, i nie ma jednego wskaźnika UX, który podnosi pozycje. Są natomiast sygnały, które z doświadczenia użytkownika wynikają wprost. Core Web Vitals, czyli szybkość wczytania, stabilność układu i reakcja na kliknięcie, należą do ocenianych elementów strony. Google przyznaje też, że korzysta z danych o tym, jak ludzie wchodzą w interakcję z wynikami.

Sprzedaż i widoczność najmocniej łączy architektura. To, jak zbudowana jest nawigacja, decyduje, czy klient dojdzie do produktu w trzech kliknięciach, i jednocześnie, jak robot rozumie serwis oraz którym podstronom przekazuje siłę linkowania wewnętrznego. Menu ułożone według schematu organizacyjnego firmy szkodzi więc jednemu i drugiemu.

Dlatego w audycie SEO oceniamy nawigację także z perspektywy klienta, nie tylko robota. Przy stałym pozycjonowaniu stron i sklepów zmiany w strukturze planujemy razem z poprawkami UX, żeby jedna nie unieważniała drugiej.

Gdzie strony i sklepy gubią użytkowników

Problemy powtarzają się w tych samych miejscach. Różni się tylko to, które z nich kosztuje najwięcej w konkretnym serwisie.

Szybkość i stabilność

Co widać w danych: Słabe wyniki Core Web Vitals w Search Console, wyjścia przed pełnym wczytaniem

Częsta przyczyna: Ciężkie slidery, nieskompresowane zdjęcia, skrypty zewnętrzne ładowane na starcie

Nawigacja i architektura

Co widać w danych: Wysoki udział wyszukiwarki wewnętrznej, krążenie między kategoriami

Częsta przyczyna: Menu według działów firmy zamiast według tego, jak szuka klient

Karta produktu

Co widać w danych: Dużo wejść, mało dodań do koszyka

Częsta przyczyna: Koszt i czas dostawy ukryte do koszyka, niejasne warianty, brak odpowiedzi na typowe pytania

Ścieżka zakupu

Co widać w danych: Porzucenia na konkretnym kroku zamówienia

Częsta przyczyna: Wymuszone zakładanie konta, niespodziewane dopłaty, za mało metod płatności

Formularze

Co widać w danych: Zaczęte, a niewysłane zapytania

Częsta przyczyna: Zbędne pola obowiązkowe, walidacja odrzucająca poprawne dane, komunikaty błędów bez treści

Wersja mobilna

Co widać w danych: Wyraźnie gorsza konwersja na telefonach niż na komputerach

Częsta przyczyna: Przycisk zakupu poniżej pierwszego ekranu, za małe pola dotyku, wyskakujące okna zasłaniające treść

Dostępność

Co widać w danych: Trudno to zobaczyć w analityce, łatwo w teście z klawiaturą

Częsta przyczyna: Zbyt słaby kontrast, brak etykiet pól, elementy niedostępne bez myszy

Jak to wygląda w praktyce

Sklep z akcesoriami ma sporo ruchu z Google na karty produktów, ale na telefonach mało kto dodaje coś do koszyka. Nagrania sesji pokazują, że przycisk zakupu leży pod galerią i trzema rozwijanymi sekcjami, a wybrany rozmiar kasuje się po zmianie koloru. Na komputerze wszystko działa, dlatego nikt w firmie tego nie zauważył. Wszyscy oglądają sklep na monitorze w biurze.

Inny częsty obraz z firm B2B: formularz zapytania ofertowego ma kilkanaście pól, w tym NIP i wielkość zatrudnienia jako obowiązkowe. Handlowcy chcą mieć te dane od razu. Tymczasem osoba, która dopiero zbiera oferty dla przełożonego, często ich nie zna i zamyka kartę. Krótszy formularz daje działowi sprzedaży mniej danych o kliencie, ale więcej rozmów.

Jak prowadzimy optymalizację UX: od danych do zmiany w kodzie

Optymalizacja UX zaczyna się u nas od liczb, a kończy na wdrożonej zmianie. Opinie, także nasze, wchodzą do gry dopiero tam, gdzie dane milczą.

Dane. Najpierw GA4: lejki, zdarzenia, podział na urządzenia i źródła ruchu. Często okazuje się, że analityka jest skonfigurowana tylko częściowo, na przykład zdarzenie zakupu liczy się dwa razy albo formularz nie raportuje wysłania. Wtedy najpierw to poprawiamy, bo na fałszywych liczbach nie da się nic zoptymalizować. Jeżeli masz nagrania sesji i mapy cieplne, dokładamy je. Jeżeli nie, możemy je wdrożyć, ale trzeba poczekać, aż zbierze się materiał.

Ścieżki. Przechodzimy główne drogi klienta tak, jak robi to on: z wyniku Google na kartę produktu albo stronę usługi, dalej do koszyka, formularza, telefonu. Sprawdzamy je na różnych urządzeniach i na wolnym łączu, a czasem przechodzimy całość samą klawiaturą. Zestawiamy to z miejscami, w których dane pokazują ucieczki.

Lista zmian według wpływu. Każda pozycja dostaje ocenę: ilu użytkowników dotyczy i jak blisko pieniędzy leży. Drugą stroną rachunku jest koszt wdrożenia. Poprawka w kroku płatności, przez który przechodzi każdy kupujący, idzie przed zmianą wyglądu stopki, nawet jeśli stopka jest brzydsza.

Wdrożenie. Mamy programistów i grafików, więc zmiany projektujemy i wdrażamy sami, w kodzie i konfiguracji: w PrestaShopie, WooCommerce, WordPressie i Next.js, a w Shoperze i Shopify w granicach, na jakie pozwala platforma. Nie zostawiamy Cię z dokumentem do przekazania komuś innemu.

Pomiar. Po wdrożeniu porównujemy ten sam fragment ścieżki przed zmianą i po niej, z uwzględnieniem sezonowości i zmian w ruchu. Jeśli coś nie zadziałało, mówimy to wprost i cofamy albo poprawiamy.

Optymalizacja UX sklepu internetowego: listing, karta, koszyk

W sklepie każdy etap ścieżki ma inne zadanie i inne typowe usterki. Pracujemy na nich po kolei, zaczynając od miejsca, w którym dane pokazują największą stratę.

• Listing i filtry: filtry odpowiadające temu, jak klient wybiera produkt, licznik wyników przy każdej opcji, brak pustych kombinacji
• Wyszukiwarka wewnętrzna: odporność na literówki i liczbę mnogą, sensowna strona braku wyników zamiast ślepego zaułka
• Karta produktu: cena z dostawą i termin wysyłki widoczne przed koszykiem, czytelne warianty, zdjęcia pokazujące skalę i detal
• Koszyk i zamówienie: zakup bez zakładania konta, brak niespodzianek w kosztach, możliwie mało kroków
• Po zakupie: potwierdzenie, które odpowiada na pytanie „co dalej”, zamiast samego numeru zamówienia

Wiele z tych zmian działa także na widoczność. Uporządkowane filtry ograniczają liczbę śmieciowych adresów w indeksie, lepsze karty produktów zatrzymują ruch z Google. Dlatego w sklepach optymalizację UX łączymy zwykle z pozycjonowaniem sklepu internetowego, żeby jedna ekipa nie psuła tego, co poprawia druga.

Jak takie myślenie przekłada się na projekt od podstaw, pokazujemy w case study sklepu PrestaShop: architektura kategorii, filtry i wyszukiwarka zaprojektowane pod ofertę, a nie pod gotowy motyw.

Czego nie robimy: redesignu dla samego wyglądu

Nie przerabiamy strony dlatego, że się znudziła albo konkurent ma nowszą. Nowy wygląd bez diagnozy przenosi stare problemy w ładniejsze opakowanie, a czasem dokłada nowe.

Nie sprzedajemy też raportu ze stu zrzutów ekranu z czerwonymi strzałkami. Taki audyt UX dobrze wygląda na prezentacji dla zarządu, a potem leży w folderze, bo nikt nie wie, od czego zacząć i kto ma to wdrożyć.

Ostrożnie podchodzimy do testów A/B. Przy kilkudziesięciu zamówieniach w miesiącu test potrafi trwać kwartał i nadal nie dać wiarygodnego wyniku. W mniejszych serwisach rozsądniej jest wdrożyć zmianę popartą danymi i ją zmierzyć. Nie obiecujemy też konkretnego wzrostu konwersji. Mówimy, co poprawiamy i dlaczego, a liczby pokazujemy po wdrożeniu.

Kiedy zamiast optymalizacji potrzebna jest nowa strona

Optymalizacja ma sens, dopóki fundament jest zdrowy. Jeśli motyw nie pozwala przenieść przycisku bez przepisywania połowy szablonu, platforma nie obsługuje zakupu bez konta, a każda poprawka wydajności psuje coś innego, łatanie kosztuje więcej niż budowa od nowa.

Wtedy mówimy to na początku, a nie po trzech miesiącach poprawek. Wnioski z analizy zachowań nie przepadają: stają się założeniami do projektu. Opisaliśmy to szerzej na stronie o stronach i sklepach budowanych pod rozwój.