Masz formularz rejestracji, który wygląda prosto, a mimo to część osób odpada przed jego wysłaniem? Najczęściej pomaga rozrysowanie ścieżki użytkownika, czyli user flow, choć sama mapa nie pokaże jeszcze, dlaczego ktoś utknął. Czasem problemem jest dodatkowy ekran, a czasem jedno niejasne pole.
Dobra ścieżka pokazuje, jak użytkownik osiąga cel i gdzie może utknąć
- User flow mapuje kroki, decyzje i reakcje interfejsu w obrębie konkretnego zadania.
- Cel zadania powinien być punktem wyjścia, nie lista ekranów do narysowania.
- Flow użytkownika różni się od mapy podróży klienta zakresem i poziomem szczegółowości.
- Test użyteczności pozwala sprawdzić, czy zaplanowana ścieżka działa dla ludzi, a nie tylko na diagramie.
- Błędy formularza wymagają czytelnego komunikatu i wskazówki, jak je poprawić.
User flow opisuje kroki potrzebne do wykonania jednego zadania
Wyobraź sobie osobę, która chce zapisać się na kurs Pythona. Wchodzi na stronę kursu, wybiera termin, podaje dane i czeka na potwierdzenie. User flow pokazuje ten ciąg działań, a także reakcje systemu i miejsca, w których ścieżka może się rozgałęzić.
Mapa nie powinna być katalogiem wszystkich podstron serwisu. Jej osią jest cel: na przykład „zapisz się na kurs”, a nie „odwiedź stronę główną, ofertę i formularz”. Uważam, że właśnie ten szczegół oddziela użyteczny diagram od dekoracyjnego schematu, który niewiele pomaga przy projektowaniu interfejsu.
Na diagramie prostokąt może oznaczać ekran lub działanie, romb - decyzję, a strzałki - przejścia między stanami. Zaznacz również odpowiedzi systemu: co dzieje się po błędnym haśle, braku wolnych miejsc albo poprawnym wysłaniu formularza. Bez tych reakcji mapa pokazuje połowę doświadczenia.
Cel i punkt wejścia porządkują mapę lepiej niż lista ekranów
Najpierw zapisz cel językiem użytkownika: „chcę odzyskać dostęp do konta”, „chcę znaleźć przykład użycia biblioteki” albo „chcę zapisać się na szkolenie”. Potem określ, skąd osoba może rozpocząć zadanie i jaki stan oznacza jego zakończenie. Jeden diagram powinien odpowiadać na jedno główne pytanie.
Przykład zapisu dla kursu może wyglądać tak: strona kursu → wybór terminu → formularz → walidacja danych → potwierdzenie. Przy braku miejsc ścieżka prowadzi do alternatywnego terminu; przy błędnym adresie e-mail interfejs wskazuje pole i podaje instrukcję korekty. Takie odgałęzienia są użyteczniejsze niż rozrysowywanie każdego możliwego kliknięcia.
Jeśli formularz jest długi, pokaż przejścia między etapami oraz możliwość powrotu do poprzedniego kroku. Przy zapisie na kurs przerwanie procesu na etapie płatności powinno mieć zrozumiałą konsekwencję: czy dane zostają zachowane, czy trzeba zacząć od początku? To pytanie łatwo pominąć na makiecie, a trudno zignorować w gotowym produkcie.
Flow użytkownika, task flow i user journey odpowiadają na różne pytania
Te nazwy bywają stosowane zamiennie, ale opisują inne poziomy szczegółowości. Task flow skupia się na jednej, zwykle prostej sekwencji działań; user flow może uwzględniać różne wejścia, decyzje i warianty w obrębie produktu; user journey obejmuje szersze doświadczenie, często rozciągnięte na wiele kanałów i etapów.
Jeśli projekt dotyczy wyłącznie odzyskiwania hasła, task flow może wystarczyć. Przy rejestracji z kilkoma wariantami - na przykład kontem indywidualnym i firmowym - przydatniejszy będzie user flow, bo widać na nim rozgałęzienia. Gdy pytanie dotyczy całej drogi od poznania oferty do kontaktu z obsługą, lepsza będzie mapa podróży klienta.
Jeszcze inny artefakt, wireflow, łączy diagram z uproszczonymi widokami ekranów. Przydaje się, gdy sam opis kroków nie wystarcza i zespół musi zobaczyć, jak układ formularza wpływa na przejście dalej. Definicje user flow i user journey rozróżnia także Nielsen Norman Group.
Pięciu uczestników może ujawnić wiele problemów, ale nie da wyniku statystycznego
Diagram opisuje zamierzoną drogę, a test sprawdza, co dzieje się w praktyce. W modelu opisanym przez Jakoba Nielsena i Thomasa Landauera test z pięcioma osobami wykrywał około 85% problemów użyteczności w badanym interfejsie. Wynik dotyczy jakościowego szukania problemów, nie precyzyjnego oszacowania, jaki odsetek wszystkich użytkowników ukończy zadanie.
To rozróżnienie chroni przed częstym błędem: mała grupa może pomóc znaleźć miejsca dezorientacji, ale nie potwierdzi liczbowo skuteczności całej usługi. Jeśli projekt ma kilka wyraźnie różnych grup docelowych, każdą trzeba rozpatrywać osobno. Dane i ograniczenia tego podejścia omawia Nielsen Norman Group w artykule o badaniach jakościowych i ilościowych.
W sesji poproś uczestnika o wykonanie zadania, na przykład „zapisz się na kurs w wybranym terminie”, i obserwuj, gdzie się zatrzymuje. Nie podpowiadaj od razu, gdzie kliknąć. Jeśli uczestnik szuka informacji o cenie, a formularz ją ukrywa, problem może leżeć w kolejności ekranów, nie w samym przycisku.
Powtarzające się przestoje wskazują, którą część flow poprawić
Nie każdy problem wymaga przebudowy całej ścieżki. Najpierw połącz obserwowany objaw z jego prawdopodobną przyczyną, a dopiero potem zmieniaj interfejs. Taka diagnoza ogranicza ryzyko, że zespół poprawi widoczny detal, pozostawiając prawdziwą przeszkodę bez zmian.
| Co dzieje się podczas zadania | Możliwa przyczyna | Co sprawdzić lub poprawić |
|---|---|---|
| Użytkownik wraca kilka razy do poprzedniej strony | Brakuje informacji potrzebnej do podjęcia decyzji albo nie widać, co będzie dalej | Dodaj potrzebny kontekst przed przejściem i sprawdź nazwy przycisków |
| Formularz odrzuca dane bez wskazania pola | Komunikat błędu jest ogólny albo widoczny wyłącznie kolorem | Wskaż błędne pole tekstem i podaj sposób poprawy |
| Osoba porzuca formularz po pierwszym ekranie | Nie zna wymaganych danych lub nie rozumie, dlaczego są potrzebne | Usuń zbędne pytania, dodaj zwięzłe instrukcje i pokaż postęp |
| Użytkownik nie wie, czy operacja się powiodła | Brakuje informacji o wyniku, na przykład potwierdzenia zapisu | Pokaż jednoznaczny stan końcowy i dalszy krok, jeśli jest potrzebny |
Przy formularzach techniczna poprawność nie wystarczy. WAI, inicjatywa dostępności W3C, zaleca czytelne etykiety i instrukcje, informowanie o błędach oraz dzielenie długich formularzy na logiczne etapy. W praktyce oznacza to, że komunikat „Coś poszło nie tak” powinien ustąpić informacji, które pole wymaga poprawy i jak ją wprowadzić.
Najlepszy diagram jest na tyle prosty, by dało się go sprawdzić
Jeśli mapa ma kilkadziesiąt gałęzi, prawdopodobnie obejmuje zbyt wiele zadań naraz. Rozbij ją na mniejsze flow i zachowaj wspólne punkty wejścia lub zakończenia tam, gdzie rzeczywiście występują. Każde rozgałęzienie powinno wynikać z decyzji użytkownika lub odpowiedzi systemu, a nie z chęci pokazania całej architektury produktu na jednej planszy.
Po aktualizacji interfejsu wróć do testu. Zmiana etykiety przycisku, dodanie kroku albo przeniesienie pola może ujawnić nową przeszkodę, nawet jeśli poprzedni wariant działał poprawnie. Gdy osoba bez podpowiedzi potrafi przejść od wejścia do potwierdzonego celu, diagram przestaje być planem na papierze i zaczyna opisywać działające doświadczenie.
