Mobile UX sklepu internetowego: lista kontroli przed publikacją

Mobilny sklep jest gotowy do publikacji dopiero wtedy, gdy na prawdziwym telefonie da się przejść od strony głównej do ostatniego kroku przed płatnością bez zgadywania, powiększania interfejsu i cofania się po utracone dane. Nie oceniaj więc tylko strony głównej ani tego, czy układ „ładnie się składa”. Otwórz podgląd sklepu, znajdź produkt, przeczytaj jego najważniejsze informacje, dodaj go do koszyka, popraw ilość, wywołaj błąd w formularzu i przejdź przez wszystkie pola dostępne przed publikacją.

Wykonaj tę samą próbę co najmniej na dwóch prawdziwych telefonach o różnych rozmiarach. Emulator w przeglądarce pomaga szybko znaleźć oczywiste problemy z szerokością, ale nie pokaże pewnie zachowania klawiatury ekranowej, gestów, paska przeglądarki, wolniejszego połączenia ani tego, czy element rzeczywiście wygodnie trafia pod kciuk.

Najpierw zapisz scenariusz i oczekiwany wynik

Test bez zadania łatwo zamienia się w oglądanie ekranów. Wybierz reprezentatywny produkt: z dłuższą nazwą, kilkoma zdjęciami, pełnym opisem i ceną, która pozwala sprawdzić sposób zapisu kwoty. Następnie zapisz jedną ścieżkę, na przykład: „Znajdź krem do skóry suchej przez menu, porównaj go z drugim produktem, dodaj do koszyka, zmień ilość, przejdź do finalizacji zamówienia i wpisz błędny kod pocztowy”.

Przy każdym kroku notuj cztery rzeczy: co tester chciał zrobić, co nacisnął jako pierwsze, gdzie się zatrzymał i co pojawiło się na ekranie. Samo „działa” jest zbyt mało precyzyjne. Wynik powinien brzmieć na przykład: „Po otwarciu menu nazwy wszystkich kategorii są widoczne bez poziomego przewijania” albo „Po błędnym kodzie komunikat wskazuje pole i mówi, jak poprawić format”.

Nie poprawiaj interfejsu podczas pierwszego przejścia. Najpierw zbierz całą ścieżkę i ustal, które problemy blokują zakup, które powodują pomyłki, a które tylko obniżają czytelność. Dzięki temu drobna korekta odstępu nie wyprzedzi naprawy zasłoniętego przycisku płatności.

Macierz urządzeń i warunków

Nie potrzebujesz szafy telefonów. Potrzebujesz celowo dobranej małej próby. Uzupełnij tę macierz nazwami urządzeń, które rzeczywiście masz, i nie wpisuj zaliczenia bez wykonania testu.

Szerokość 320 CSS px nie jest losową granicą. Kryterium WCAG 2.2 dotyczące dopasowania treści (reflow) opisuje możliwość prezentacji pionowo przewijanej treści przy szerokości odpowiadającej 320 CSS px bez utraty informacji lub funkcji i bez przewijania w dwóch kierunkach, z wyjątkami dla treści wymagających układu dwuwymiarowego. Ten test nie potwierdza zgodności z WCAG; daje konkretną próbę dla wąskiego widoku.

Sprawdź kolejność treści, zanim zaczniesz mierzyć detale

Na małym ekranie kolejność jest projektem. Nad pierwszym produktem nie powinno znaleźć się kilka obszernych sekcji, które odsuwają zakupy poza zasięg. Strona główna powinna szybko wyjaśnić, co sklep sprzedaje, dla kogo jest oferta i dokąd można przejść. Szczegółowy sposób planowania sekcji opisuje poradnik jak zaprojektować stronę główną sklepu.

Przewiń ekran od góry i po każdej sekcji odpowiedz: jaką decyzję klient może teraz podjąć? Sprawdź, czy najważniejszy komunikat nie zależy wyłącznie od tekstu na grafice, czy główne wejścia do kategorii pojawiają się odpowiednio wcześnie i czy dowody zaufania są konkretne oraz prawdziwe. Na stronie produktu nazwa, zdjęcie, cena, kluczowy wariant oferty i działanie zakupowe powinny tworzyć zrozumiałą sekwencję. Nie kopiuj mechanicznie kolejności z desktopu, jeśli na telefonie rozdziela ona cenę od produktu albo przycisk od informacji potrzebnej przed zakupem.

Czytelność i obsługa dotykiem

Czytaj ekran z normalnej odległości, w świetle dziennym i bez powiększenia. Tekst nie może wymagać szczypania ekranu, a nagłówki, cena, treść przycisku i informacje o dostawie muszą mieć wyraźne role. Zwróć uwagę na długie polskie słowa, wartości promocyjne, przekreślone ceny oraz tekst nakładany na zdjęcia. Sprawdź też, czy stały pasek u dołu nie przykrywa ostatniego wiersza treści, komunikatu o błędzie albo przycisku formularza.

Każdy element interaktywny naciśnij kciukiem: otwarcie menu, zamknięcie okna, zdjęcie, wybór kategorii, zmianę ilości, usunięcie produktu i główne przyciski. W3C w kryterium 2.5.8 podaje minimalny rozmiar celu 24 × 24 CSS px, z określonymi wyjątkami, między innymi dotyczącymi odstępu i równoważnego sterowania. Traktuj tę wartość jako konkretne kryterium do sprawdzenia, nie jako automatyczny przepis na wygodny interfejs. W kluczowych działaniach rozsądnie jest projektować większy aktywny obszar i testować go palcem, zwłaszcza gdy obok siebie są przyciski „minus”, „plus” i „usuń”.

Menu i karty produktów

Otwórz menu jedną ręką, przejdź do kategorii, wróć i zamknij je. Nazwy muszą zapowiadać zawartość, a nie zmuszać do zapamiętywania ikon. Sprawdź, czy rozwinięta nawigacja mieści się w widoku, przewija się niezależnie, gdy jest długa, oraz nie pozostawia niewidocznej warstwy blokującej stronę. Logo, koszyk i przycisk menu powinny zachować stabilne położenie między ekranami.

Na liście produktów obejrzyj najkrótszą i najdłuższą nazwę, najniższą i najwyższą cenę, produkt przeceniony oraz brakujące lub nietypowe zdjęcie. Karta powinna pozwolić rozpoznać produkt i porównać go z sąsiednimi bez otwierania każdego elementu. Nie dodawaj odznak, ocen ani obietnic, których nie potwierdzają dane. Naciśnij zdjęcie, nazwę i ewentualne działanie na karcie; wynik każdego naciśnięcia ma być przewidywalny.

Obrazy oraz obserwacja ładowania

Przygotowanie właściwych kadrów zaczyna się przed budową sklepu; skorzystaj z listy zdjęć produktów i materiałów marki. W podglądzie sprawdź pionowe i poziome zdjęcia, jasne produkty na jasnym tle, detale przy krawędzi oraz serię zdjęć na stronie produktu. Kluczowy fragment produktu nie może wypaść poza automatyczny kadr. Galeria nie powinna przejmować gestu w sposób, który uniemożliwia zwykłe przewijanie strony.

Odśwież stronę przy ograniczonym połączeniu i patrz, nie tylko mierz. Czy najpierw pojawia się sensowna treść? Czy puste miejsce zachowuje rozmiar zdjęcia, czy układ skacze po jego pobraniu? Czy można odróżnić ładowanie od awarii? Czy kliknięcie „Dodaj do koszyka” daje natychmiastowy, jednoznaczny stan oczekiwania i nie zachęca do wielokrotnego naciśnięcia?

web.dev zaleca podawanie responsywnych źródeł obrazów, aby przeglądarka mogła dobrać plik do widoku, oraz określanie wymiarów, by zarezerwować miejsce w układzie; zobacz materiały o responsywnych obrazach i podstawach responsywnego projektowania. Osobna wskazówka web.dev mówi, by nie opóźniać obrazów widocznych od razu, a leniwe ładowanie stosować do obrazów poza pierwszym widokiem. To wskazówki wdrożeniowe dla zespołu, nie wynik testu wydajności. Lista PL08 ma wychwycić widoczny skutek; pełna diagnoza szybkości wymaga osobnego pomiaru.

Formularze, błędy i klawiatura ekranowa

W finalizacji zamówienia każde pole wypełnij, popraw i przetestuj błędnie. Etykieta powinna pozostać widoczna po wpisaniu wartości; sam tekst zastępczy znikający podczas pisania nie wystarcza jako instrukcja. Dla telefonu, e-maila i kodu pocztowego sprawdź dopasowanie klawiatury, ale nie zakładaj, że jej układ zastąpi jasną etykietę i opis formatu. W3C wymaga etykiet lub instrukcji dla pól przyjmujących dane.

Wyślij pusty formularz, wpisz niepełny kod, błędny e-mail i wartość spoza oczekiwanego formatu. Widok powinien przenieść uwagę do problemu, zachować prawidłowe dane i opisać błąd tekstem przy właściwym polu. Sam czerwony obrys nie mówi, co się stało. Kryterium W3C dotyczące identyfikacji błędów wskazuje, że automatycznie wykryty błąd ma identyfikować pozycję i być opisany tekstowo. Sprawdź również, czy klawiatura nie zasłania pola, sugestii ani przycisku przejścia dalej.

Koszyk i finalizacja zamówienia

Koszyk jest ekranem decyzji, nie przechowalnią miniatur. Klient powinien rozpoznać produkt, cenę, ilość, sumę oraz skutki zmiany. Dodaj dwa produkty, zmień ilość, usuń jeden, wróć do zakupów i ponownie otwórz koszyk. Po każdej operacji sprawdź, czy cena i licznik aktualizują się raz, czy fokus nie przeskakuje przypadkowo oraz czy stan pustego koszyka daje sensowną drogę powrotu.

Przed ostatnim krokiem sprawdź, czy klient rozumie, jakie dane podaje, co zamawia, jaką metodę dostawy wybiera i jaki jest łączny koszt. Tutaj celem jest ciągłość interfejsu mobile od koszyka do płatności. Po publikacji wykonaj krótki live check na telefonie przed promocją sklepu. Konfigurację konta, waluty i metod opisuje osobny przewodnik po płatnościach Stripe w Setce.

Jak testować sklep wygenerowany w Setce

Setka generuje responsywny sklep, ale to nie zastępuje testu na prawdziwym urządzeniu. Otwórz aktualny podgląd i przejdź na telefonie całą ścieżkę: stronę główną, kategorię, produkt, koszyk oraz finalizację zamówienia. Sprawdź zachowanie każdego ekranu, klawiatury i przejść między krokami.

Zapisz wynik dla konkretnej wersji sklepu i urządzenia, zgłoś poprawki, a potem powtórz test. Taka próba nie gwarantuje zgodności z WCAG, dostępności, szybkości ani wzrostu konwersji. Sprzedawca nadal odpowiada za prawdziwość treści, jakość materiałów, konfigurację sprzedaży i test na rzeczywistych urządzeniach. Szerszy przegląd barier opisuje osobna lista dostępności sklepu internetowego; PL08 jej nie zastępuje.

Lista kontroli do skopiowania lub wydrukowania

Skopiuj listę do dokumentu testowego. Przy każdej poprawce dopisz urządzenie, ekran, oczekiwany rezultat, wynik rzeczywisty i osobę odpowiedzialną. Pole uznaj za zaliczone dopiero po ponownym teście.

Wejście i kolejność treści

• Pierwszy ekran wyjaśnia ofertę i pokazuje zrozumiały następny krok.
• Najważniejsze ścieżki do kategorii lub produktów pojawiają się bez długiego wstępu.
• Kolejność sekcji ma sens po ułożeniu ich w jedną kolumnę.
• Cena, produkt i działanie zakupowe pozostają razem w logicznej sekwencji.
• Żaden ważny komunikat nie istnieje wyłącznie jako tekst na obrazie.

Czytelność i dotyk

• Tekst można przeczytać bez ręcznego powiększania strony.
• Długie nazwy, ceny i etykiety nie nachodzą na inne elementy.
• Powiększony tekst nie ukrywa treści ani funkcji.
• Wszystkie kontrolki da się pewnie nacisnąć kciukiem.
• Sąsiednie cele, zwłaszcza zmiana ilości i usuwanie, nie powodują pomyłek.
• Stałe paski i banery nie zasłaniają treści ani działań.

Menu, listy i strony produktów

• Menu otwiera się, przewija, prowadzi do kategorii i zamyka bez blokowania strony.
• Nazwy pozycji menu zapowiadają zawartość bez zgadywania ikon.
• Karty pokazują zdjęcie, nazwę i cenę w spójnej kolejności.
• Najdłuższe nazwy i ceny promocyjne nie psują siatki.
• Zdjęcie, nazwa i przycisk na karcie mają przewidywalne działanie.
• Strona produktu pokazuje informacje potrzebne przed dodaniem do koszyka.

Obrazy i ładowanie

• Najważniejsza część produktu pozostaje w kadrze na każdym testowanym ekranie.
• Galerię da się obsłużyć bez utraty zwykłego przewijania strony.
• Miejsce na obraz jest zachowane przed jego pojawieniem się.
• Pierwszy widoczny obraz nie czeka bez wyraźnego powodu.
• Stan ładowania i rezultat działania są jednoznaczne.
• Wolniejsze połączenie nie prowadzi do wielokrotnego dodania produktu.

Formularze i błędy

• Każde pole ma trwałą, zrozumiałą etykietę oraz potrzebną instrukcję formatu.
• Typ klawiatury pasuje do wpisywanych danych.
• Klawiatura nie zasłania aktywnego pola, komunikatu ani przycisku.
• Pusty i błędnie wypełniony formularz wskazuje konkretne pola.
• Błąd jest opisany tekstem, a nie wyłącznie kolorem.
• Po błędzie prawidłowo wpisane dane pozostają w formularzu.
• Poprawa błędu prowadzi dalej bez ponownego wypełniania całego kroku.

Koszyk i finalizacja zamówienia

• Dodanie produktu daje natychmiastowe i jednoznaczne potwierdzenie.
• Koszyk pokazuje właściwy produkt, cenę, ilość i sumę.
• Zmiana ilości i usunięcie aktualizują wynik dokładnie raz.
• Pusty koszyk zawiera jasną drogę powrotu do zakupów.
• Przejście do finalizacji zamówienia jest widoczne i niezasłonięte.
• Dane produktu i kwoty pozostają spójne między koszykiem a kolejnym krokiem.
• Metoda dostawy, wymagane dane i widoczny koszt są zrozumiałe na właściwym etapie.
• Test nie używa prawdziwych danych płatniczych.

Pokrycie testu

• Cała ścieżka przeszła na co najmniej dwóch prawdziwych telefonach.
• Sprawdzono wąski ekran, duży ekran i zmianę orientacji.
• Sprawdzono powiększony tekst lub zoom.
• Sprawdzono odświeżenie przy ograniczonym połączeniu.
• Każdy błąd ma zapisany ekran, urządzenie, rezultat i właściciela poprawki.
• Po poprawkach wykonano ponowny pełny test, a nie tylko test zmienionego ekranu.

Otwórz podgląd Setki na dwóch prawdziwych telefonach, wybierz jeden reprezentatywny produkt i wykonaj pełny test mobile przed publikacją. Dopiero zaliczenie całej ścieżki — wraz z błędami formularza i ponowną próbą po poprawkach — daje użyteczną decyzję o publikacji.