Większość problemów z użytecznością, które znajduję na stronach i w sklepach, nie wynika ze złego wyglądu. Wynika z tego, że ktoś zaprojektował interfejs na podstawie własnych założeń, zamiast sprawdzić, jak korzystają z niego ludzie. Proces projektowania UX istnieje po to, żeby te założenia zweryfikować, zanim trafią do kodu. Poniżej opisuję, jak wygląda on u mnie w praktyce, krok po kroku, także w projektach, w których nie ma osobnego zespołu badawczego ani dużego budżetu.
Zanim zacznę: cel biznesowy i cel użytkownika
Każdy projekt zaczynam od dwóch pytań. Co ma osiągnąć firma, np. więcej zapytań ofertowych, mniej porzuconych koszyków, mniej telefonów do obsługi klienta? I co chce zrobić użytkownik, który wchodzi na stronę? Jeśli te cele się rozjeżdżają, żaden projekt graficzny tego nie naprawi.
Na tym etapie ustalam też, po czym poznamy, że projekt się udał. Wybieram dwa, trzy mierzalne wskaźniki, np. odsetek osób kończących formularz, czas znalezienia produktu albo liczbę zapytań przez stronę. Bez tego po wdrożeniu zostają tylko opinie, a nie wyniki.
Krok 1. Badania użytkowników w realnym budżecie
Pominięcie badań prawie zawsze kończy się kosztowną poprawką po wdrożeniu. Nie potrzeba do tego laboratorium. W większości projektów korzystam z kilku źródeł, które są dostępne od ręki:
- Analityka. Sprawdzam, którymi ścieżkami użytkownicy przechodzą przez stronę, gdzie wychodzą i na jakich urządzeniach. Często już tu widać, że kluczowa podstrona jest prawie nieodwiedzana, bo nie ma do niej drogi z menu.
- Nagrania sesji i mapy kliknięć. Pokazują, gdzie ludzie klikają w elementy, które nie są linkami, jak daleko przewijają i w którym polu formularza się zatrzymują.
- Wyszukiwarka wewnętrzna i zapytania z Google. Frazy, które ludzie wpisują, mówią, czego szukają i jakim językiem to nazywają.
- Rozmowa z obsługą klienta i sprzedażą. Osoby odbierające telefony wiedzą, o co klienci pytają najczęściej i czego nie mogą znaleźć na stronie.
- Kilka wywiadów z użytkownikami. Nawet pięć rozmów z prawdziwymi klientami zwykle obala któreś z założeń, na których opierał się pierwotny pomysł.
Krok 2. Problem, persony i najważniejsze zadania
Z badań wyciągam konkretne problemy i zapisuję je jednym zdaniem, np. „klient firmowy nie wie, czy może zamówić z fakturą, więc dzwoni przed zakupem”. Taka lista jest znacznie bardziej użyteczna niż ogólne hasło „poprawić UX”.
Na tej podstawie tworzę proste persony, czyli opisy kluczowych grup użytkowników: czego potrzebują, czego się obawiają i w jakiej sytuacji korzystają ze strony. Nie dopisuję im hobby i zdjęć z banku, bo to nie wpływa na decyzje projektowe. Najważniejsza jest lista zadań, które każda grupa chce wykonać, uszeregowana od najczęstszych. Te kilka najważniejszych zadań wyznacza priorytety na wszystkich kolejnych etapach.
Krok 3. Architektura informacji
Zanim narysuję pierwszy ekran, układam strukturę: jakie strony są potrzebne, jak się grupują i jak użytkownik dotrze do każdej z nich. Nazwy w menu biorę z języka użytkowników, a nie z wewnętrznej nomenklatury firmy. Jeśli klienci szukają „cennika”, menu nie może mówić o „ofercie handlowej”.
Przy większych serwisach pomaga sortowanie kart, w którym uczestnicy sami grupują tematy, oraz test drzewa, w którym szukają informacji w samej strukturze, bez grafiki. Tak przygotowana struktura dobrze współgra z SEO, bo te same grupy tematów stają się podstawą do silosowania tematycznego.
Krok 4. Ścieżki, makiety i prototyp
Dla każdego najważniejszego zadania rysuję ścieżkę użytkownika: od wejścia na stronę do osiągnięcia celu. Liczę kroki i szukam miejsc, w których można je skrócić. Dopiero potem powstają makiety o niskiej szczegółowości, bez kolorów i zdjęć, żeby rozmowa dotyczyła układu i treści, a nie odcienia przycisku.
Projektuję od ekranu telefonu, bo tam brakuje miejsca i od razu widać, co jest naprawdę ważne. Na tym etapie zapadają też decyzje, które później trudno zmienić w kodzie, np. jak prezentować długie listy produktów. Przy sklepach zawsze porównuję paginację i infinite scroll pod kątem tego, czy użytkownik szuka konkretnego produktu, czy tylko przegląda.
Z makiet powstaje klikalny prototyp, zwykle w Figmie. Wystarczy, że obsługuje najważniejsze ścieżki, bo jego celem są testy, a nie prezentacja dla zarządu.
Krok 5. Testy użyteczności
Prototyp testuję z kilkoma osobami z grupy docelowej. Daję im konkretne zadania, np. „znajdź buty do biegania w rozmiarze 42 i dodaj je do koszyka”, i proszę, żeby mówiły na głos, co myślą. Nie podpowiadam i nie tłumaczę interfejsu, bo na prawdziwej stronie też nikt tego nie zrobi.
Notuję, czy zadanie się udało, ile trwało i gdzie pojawiły się wahania. Już pięć sesji zwykle ujawnia najpoważniejsze problemy. Po poprawkach testuję ponownie, bo zmiana, która rozwiązuje jeden problem, potrafi stworzyć kolejny. Dwie, trzy takie rundy na prototypie są nieporównywalnie tańsze niż przebudowa gotowego serwisu.
Krok 6. Wdrożenie i pomiar po starcie
Jako webdeveloper widzę, ile dobrego projektu ginie przy wdrożeniu. Dlatego pilnuję kilku rzeczy, które w makietach nie są widoczne. Szybkość działania to część doświadczenia użytkownika: przycisk, który reaguje z opóźnieniem, frustruje tak samo jak źle opisany, więc projekt sprawdzam również pod kątem Core Web Vitals. Dostępność z klawiatury, czytelny kontrast i komunikaty błędów w formularzach wdrażam od razu, a nie w osobnym etapie „na później”.
Uważam też na efekty, które dobrze wyglądają w prezentacji, a w praktyce spowalniają stronę i rozpraszają użytkownika. Rozbudowane animacje to częsta forma overengineeringu, który pogarsza UX zamiast go poprawiać.
Po starcie wracam do wskaźników ustalonych na początku. Jeśli mam wątpliwości między dwoma rozwiązaniami, np. dwiema wersjami formularza, sprawdzam je w testach A/B, zamiast rozstrzygać spór opiniami. Proces UX nie kończy się w dniu wdrożenia, tylko zamienia w cykl: pomiar, wnioski, poprawka, kolejny pomiar.
Błędy, które najczęściej widzę w projektach
- Projekt bez kontaktu z użytkownikami. Decyzje zapadają na spotkaniu na podstawie opinii najważniejszej osoby w pokoju.
- Projektowanie tylko na dużym monitorze. Makiety wyglądają świetnie na komputerze, a większość klientów korzysta z telefonu.
- Zbyt wiele kroków. Dodatkowe pola w formularzu i obowiązkowe zakładanie konta przed zakupem to najprostszy sposób na utratę klientów.
- Pominięta dostępność. Brak obsługi klawiatury i za niski kontrast wykluczają część użytkowników i są trudne do naprawienia po fakcie.
- Brak pomiaru po wdrożeniu. Bez danych nie wiadomo, czy nowy projekt jest lepszy od starego, czy tylko inny.