Людина вводить назву послуги, натискає «Знайти» й отримує порожній екран. Формально пошук завершився. Практично розмова із сайтом обірвалася саме там, де відвідувач найчіткіше сформулював свій інтерес. Ми пропонуємо проєктувати цей момент не як помилку користувача, а як окремий сценарій: що людина зрозуміє і що зможе зробити далі?
Спершу визначте, де саме шукає сайт
Поле з лупою часто обіцяє більше, ніж реалізує. Якщо воно переглядає лише назви статей, а не послуги, документи та весь текст сторінок, це має бути зрозуміло поруч із полем. «Пошук у журналі» точніше за універсальне «Пошук», коли інші матеріали не входять до його меж. Для невеликого сайту добре впорядкований архів статей іноді корисніший за складну форму, яка приховує свої обмеження.
Перед розробкою складіть кілька звичайних запитів: точна назва, загальна тема, інше написання, слово, якого на сайті немає. Визначте, які матеріали мають з’явитися в кожному випадку. Це редакційна домовленість, а не обіцянка, що алгоритм здогадається про будь-який намір.
Збережіть запит і відокремте різні стани
Після пошуку текст варто залишити в полі. Людина може змінити одне слово, а не набирати все заново. Порожній запит, завантаження, відсутність збігів і технічна помилка потребують різних повідомлень. «Нічого не знайдено» не повинно маскувати недоступний сервер: у такій ситуації ми ще не знаємо, чи існують результати.
Для пошуку з фільтрами покажіть активні обмеження. Нуль матеріалів у вибраній категорії не означає, що їх немає на всьому сайті. Запропонуйте окрему дію «Скинути фільтри», яка не стирає введений текст. Так відвідувач розуміє, що саме зміниться після натискання.
Дайте кілька чесних шляхів замість стіни порад
Стислий порожній стан може містити сам запит, пояснення меж пошуку та два наступні кроки: змінити формулювання або відкрити тематичний розділ. Не потрібно одразу показувати десятки випадкових карток. Якщо ви пропонуєте близькі теми, назвіть їх рекомендаціями, а не точними збігами.
Умовний приклад для студії: за словом «перезапуск» нічого немає, але доступні розділи про підтримку та оновлення сайту. Їх можна запропонувати як альтернативний маршрут, не підмінюючи відповідь і не оголошуючи знайденим те, що не відповідає запиту. Назви переходів мають пояснювати зміст, як у нашому матеріалі про зрозумілі посилання.
Поле введення не є готовим пошуковим механізмом
MDN описує input type="search" як поле для введення пошукового запиту. Сам тип поля не створює індекс і не визначає, як зіставляти слова з матеріалами. Цю логіку потрібно реалізувати окремо. Поле також потребує зрозумілої назви: приклад усередині порожнього поля не варто робити єдиним поясненням його призначення.
Якщо результати оновлюються без перезавантаження, коротке повідомлення про їхню кількість або відсутність потрібно зробити доступним допоміжним технологіям без примусового перенесення фокуса. Саме такі повідомлення W3C розглядає в поясненні критерію 4.1.3. Це не означає, що весь список результатів треба озвучувати як одне повідомлення.
Перевірте шлях, а не лише наявність лупи
Пройдіть сценарій на вузькому екрані та з клавіатури: введіть запит, запустіть пошук, виправте його, скиньте фільтр, відкрийте результат і поверніться. Переконайтеся, що кнопки не зникають за екранною клавіатурою, довгі назви не перекривають сусідні елементи, а повідомлення не стрибають перед очима після кожного символу.
Окремо перевірте запити мовами сайту й не приховуйте межі між мовними розділами. Хороший пошук не мусить вгадувати все. Його практична цінність у тому, що людина бачить межі відповіді, не втрачає зробленого і має зрозумілий наступний крок навіть за нульового результату.