Użytkownik wpisuje nazwę usługi, naciska „Szukaj” i widzi pusty ekran. Formalnie wyszukiwanie się zakończyło. W praktyce rozmowa z witryną urwała się dokładnie w momencie, w którym odwiedzający najjaśniej określił, co go interesuje. Proponujemy projektować ten moment nie jako błąd użytkownika, lecz jako osobny scenariusz: co ta osoba zrozumie i co będzie mogła zrobić dalej?
Najpierw określ, gdzie dokładnie szuka witryna
Pole z lupą często obiecuje więcej, niż oferuje. Jeśli przeszukuje tylko tytuły artykułów, a nie usługi, dokumenty i pełną treść stron, powinno to być jasno wyjaśnione obok pola. „Szukaj w dzienniku” jest precyzyjniejsze niż ogólne „Szukaj”, gdy inne materiały pozostają poza zakresem wyszukiwania. W niewielkiej witrynie dobrze uporządkowane archiwum artykułów bywa przydatniejsze niż rozbudowany formularz, który ukrywa swoje ograniczenia.
Przed rozpoczęciem prac przygotuj kilka typowych zapytań: dokładny tytuł, ogólny temat, inny zapis, słowo, którego nie ma w witrynie. Ustal, jakie materiały powinny pojawić się w każdym przypadku. To ustalenie redakcyjne, a nie obietnica, że algorytm odgadnie każdy zamiar.
Zachowaj zapytanie i rozróżnij poszczególne stany
Po wyszukaniu warto pozostawić tekst w polu. Użytkownik może wtedy zmienić jedno słowo, zamiast wpisywać wszystko od nowa. Puste zapytanie, ładowanie, brak dopasowań i błąd techniczny wymagają różnych komunikatów. „Nic nie znaleziono” nie powinno maskować niedostępnego serwera: w takiej sytuacji jeszcze nie wiemy, czy istnieją wyniki.
W wyszukiwaniu z filtrami pokaż aktywne ograniczenia. Brak materiałów w wybranej kategorii nie oznacza, że nie ma ich w całej witrynie. Zaproponuj osobną akcję „Wyczyść filtry”, która nie usuwa wpisanego tekstu. Dzięki temu odwiedzający rozumie, co dokładnie zmieni się po kliknięciu.
Zaproponuj kilka uczciwych dróg zamiast ściany porad
Zwięzły komunikat o braku wyników może zawierać samo zapytanie, wyjaśnienie zakresu wyszukiwania i dwa kolejne kroki: zmianę sformułowania lub przejście do działu tematycznego. Nie trzeba od razu pokazywać dziesiątek przypadkowych kart. Jeśli proponujesz pokrewne tematy, nazwij je rekomendacjami, a nie dokładnymi dopasowaniami.
Hipotetyczny przykład dla studia: dla słowa „restart” nic nie znaleziono, ale dostępne są działy dotyczące wsparcia i aktualizacji witryny. Można zaproponować je jako alternatywną drogę, nie podmieniając odpowiedzi i nie ogłaszając znalezionym czegoś, co nie odpowiada zapytaniu. Teksty odnośników powinny wyjaśniać, do jakiej treści prowadzą, tak jak opisujemy to w naszym artykule o zrozumiałych linkach.
Pole tekstowe nie jest gotowym mechanizmem wyszukiwania
MDN opisuje input type="search" jako pole do wpisywania zapytania wyszukiwania. Sam typ pola nie tworzy indeksu i nie określa sposobu dopasowywania słów do materiałów. Tę logikę trzeba zaimplementować osobno. Pole potrzebuje też zrozumiałej etykiety: przykład widoczny wewnątrz pustego pola nie powinien być jedynym wyjaśnieniem jego przeznaczenia.
Jeśli wyniki aktualizują się bez przeładowania strony, krótki komunikat o ich liczbie lub braku powinien być dostępny dla technologii wspomagających bez wymuszonego przenoszenia fokusu. Właśnie takie komunikaty W3C omawia w wyjaśnieniu kryterium 4.1.3. Nie oznacza to, że całą listę wyników należy odczytywać jako jeden komunikat.
Sprawdź ścieżkę użytkownika, a nie tylko obecność lupy
Przejdź cały scenariusz na wąskim ekranie oraz przy użyciu klawiatury: wpisz zapytanie, uruchom wyszukiwanie, popraw je, wyczyść filtr, otwórz wynik i wróć. Upewnij się, że przyciski nie znikają za klawiaturą ekranową, długie tytuły nie zasłaniają sąsiednich elementów, a komunikaty nie przeskakują przed oczami po wpisaniu każdego znaku.
Osobno sprawdź zapytania w językach witryny i nie ukrywaj granic między wersjami językowymi. Dobre wyszukiwanie nie musi odgadywać wszystkiego. Jego praktyczna wartość polega na tym, że użytkownik widzi granice odpowiedzi, nie traci tego, co już zrobił, i ma jasny kolejny krok nawet wtedy, gdy liczba wyników wynosi zero.