Розробка дизайну сторінки пошуку сайту під ключ

Дизайн сторінки пошуку: де видача втрачає користувача

Користувач, який не знайшов потрібне через пошук, рідко повертається до каталогу — він іде на зовнішню видачу.

Дизайн сторінки пошуку вирішує не «красу форми», а кількість кроків від запиту до результату: поле введення, підказки, фільтри та сортування мають сходитися в одну передбачувану видачу.

Типові провали повторюються з проєкту в проєкт. Нерелевантність видачі — коли внутрішній пошук по сайту працює за точним збігом рядка і ігнорує одруки, синоніми та словоформи: користувач отримує десятки карток, жодна з яких не відповідає на запит.

Порожній результат пошуку без альтернатив — глухий кут: немає ні схожих позицій, ні популярних розділів, ні скидання умов.

Зайві кроки до мети — окрема сторінка видачі, яка не зберігає умови в адресі: посилання не можна переслати, а повернення назад скидає вибір.

Фільтри, що розходяться з видачею і пропонують значення, яких у поточній вибірці немає, змушують перебирати заново — це друге коло роздратування замість уточнення запиту.

Ціна для бізнесу — відхід користувача з видачі. Він не доходить до картки, а отже, не залишає заявку. На замірах по каталогах видно: чим далі видача від запиту, тим вища частка повернень до зовнішнього пошуку і нижчі переходи в цільову дію.

Розбираємо, як це закривається: обробка запитів і синонімів, осмислений порожній результат, фільтри, синхронні з вибіркою, і адресований стан сторінки.

Ефект переробленої видачі: що змінюється для користувача

Переробку видачі оцінюють не за зовнішнім виглядом, а за поведінкою: зростає частка успішних пошукових сесій — тих, де людина дійшла до цільового об'єкта і не повернулася з новим запитом.

Базу знімаємо за логами пошукового ядра та інтерфейсу до правок: повторні уточнення на сесію, час до потрібного результату, частка переходів з видачі, частка порожніх видач.

Перше следствие — менше повторних уточнень запиту. Коли синоніми, словоформи та одруки розбирає пошукове ядро, а фільтри й сортування скидаються передбачувано, частина уточнень переходить в інтерфейс і перестає бути окремим запитом. На замірах це видно як зниження кількості запитів на одну сесію.

Друге — коротший шлях до цільового об'єкта. Якщо картка одразу віддає ключові характеристики і веде на потрібну сторінку, сесія скорочується з кількох ітерацій до однієї-двох: розрив між першим запитом і останнім переходом падає. Саме він і визначає час до потрібного результату.

Третє — вища частка переходів з видачі. Зрозумілий сніпет і чесне сортування підвищують клікабельність верхніх позицій, тому більше сесій закривається результатом, а не відходом у каталог вручну чи на зовнішній пошук.

Четверте — нижча частка порожніх видач. Обробка одруків, транслітерації та часткових збігів плюс осмислені варіанти на екрані «нічого не знайдено» прибирають головний клас відмов, з якого користувач уже не повертається. Усі чотири метрики знімаємо на одному потоці запитів до і після — інакше порівняння некоректне.

Підходи до проєктування видачі: порівняння варіантів

Обсяг робіт визначає не розмір каталогу, а розходження поточної видачі з реальними запитами.

Зростаюча частка сесій без кліку за результатами та запити, що йдуть у порожню видачу, вказують на сценарій, а не на верстку; скарги на одруки та розмиті формулювання — на якість підказок і синонімів.

Варіанти не взаємовиключні: мобільну гілку та правку дефектів ведуть паралельно, переробку сценарію — наступним етапом, коли статистика запитів підтверджує гіпотезу. Розвилку закриваємо після розбору логів пошуку: що вводять, де кидають, що знаходять.

Порядок робіт над видачею пошуку: від запитів до макетів

Пошук — це не рядок введення з кнопкою, а набір гілок поведінки, і майже всі провали в макетах трапляються там, де дизайн малювали за здогадками: підказки не збігаються з реальними формулюваннями, а на нульовій видачі людина впирається в глухий кут. Тому порядок робіт вибудуваний так, щоб макет перевірявся даними ще до верстки.

1. Збір пошукових запитів. Вивантажуємо реальні формулювання: довгі хвости, одруки, змішані мови, нульові результати. Отримуємо розподіл частот і розуміємо, які гілки взагалі варто проєктувати.
2. Карта сценаріїв пошуку. Розмічаємо гілки: точний збіг, розширений запит, пошук за фільтрами, порожній результат, помилка введення. Для кожної фіксуємо, що бачить людина і куди веде наступний крок.
3. Схема видачі. Розкладаємо результат за шарами: підказки, фільтри, блок уточнень, картки, посторінковий перехід. Окремо описуємо поведінку при нульовій видачі та при неповних даних у картці.
4. Прототип видачі. Збираємо клікабельний макет на даних, близьких за структурою до бойових: довгі назви, вкладені категорії, відсутні зображення. Перевіряємо, що сітка не руйнується на крайніх значеннях.
5. Перевірка на реальних даних. Проганяємо вибірку запитів і шукаємо, де сценарії рвуться: підказки не спрацьовують, уточнення не звужують видачу, шлях до результату довший за три дії. Правки вносимо до передачі в розробку.
6. Передача макетів. Віддаємо компонентну бібліотеку зі станами, правилами адаптиву, текстами заглушок і поведінкою при завантаженні. Далі супроводжуємо: правимо за фактичною поведінкою людей, а не за смаковими зауваженнями.

Склад проєкту: макети, стани та правила видачі

Макети видачі — це не одна картинка «як виглядає результат», а набір станів, у яких сторінка пошуку реально опиняється. Фіксуємо їх до старту розробки, щоб інженери не додумували поведінку при порожньому результаті чи обрізаній відповіді пошукового сервісу. На руки замовник отримує:

• Макети всіх станів видачі: повний результат, частковий (частина умов не дала збігів), порожній, стан завантаження, збій сервісу пошуку та видача без доступу до частини каталогу.
• Правила сортування: що показується першим при рівній релевантності, чи впливає вибраний порядок на порядок блоків і чи зберігається сортування в посиланні при перезавантаженні сторінки.
• Правила фільтрів: які умови комбінуються, що відбувається при порожньому перетині, як працює скидання і відображається лічильник знайденого на кожній умові.
• Поведінка при неповному результаті: підказка зняти зайву умову, блок схожих позицій і формулювання — те, що утримує відвідувача замість відходу з порожньої сторінки.
• Розмітка картки у видачі: обов'язкові поля, поведінка довгого заголовка, відсутнього зображення та незаповнених характеристик.
• Документація з видачі: таблиця параметрів адресного рядка, щоб будь-який стан відтворювався посиланням, і опис полів відповіді пошукового сервісу для розробки.
• Правила для підтримки: які правки фільтрів і сортування безпечні, що вимагає перезбірки пошукового індексу, і чек-ліст перевірки видачі перед релізом.

Кейс: як видача інтернет-магазину перестала втрачати запити

Клієнт — інтернет-магазин з каталогом на десятки тисяч позицій. Пошук віддавав результати «як є»: знаходив збіги за точною назвою, але не розумів одруків, синонімів та іншої розкладки клавіатури. Запити в підтримку зростали швидше, ніж замовлення, а власник списував це на слабкий трафік.

Що показав замір до

Ми почали не з макета, а з метрик. Частка порожніх результатів — 23% запитів: людина вводила «навушники бездротові» і отримувала порожній екран без жодної підказки.

З першого екрана йшли 41% відвідувачів, середня глибина перегляду видачі — 1,4 картки, тобто більшість навіть не гортала список.

Що змінили

Логіку видачі переписали на Elasticsearch: розбір одруків, словник синонімів, зв'язка товарних груп і вага атрибутів замість чистого збігу за рядком.

Дизайн сторінки пошуку зібрали навколо результату — фільтри лише за релевантними для категорії атрибутами, жива видача під рядком, окремий блок уточнень замість порожнього екрана.

Що стало після запуску

Частка порожніх видач — 6%, при цьому порожній екран тепер завжди пропонує уточнення або схожу групу товарів. Відходи з першого екрана — 22%, глибина перегляду видачі — 3,1 картки, кількість уточнюючих запитів зросла вдвічі.

Переходів з пошуку в картку товару стало в 1,8 раза більше при тому ж трафіку — кейс пошуку закрився не редизайном, а розбором того, де саме видача втрачала запит.

Що робити, якщо видача вже працює, але нею не користуються

Перший сигнал — розходження між попитом і фактичним використанням. Дивимося частку сесій, де пошук взагалі відкривали, частку запитів з нульовою видачею і частку переформулювань у межах однієї сесії.

Якщо люди заходять у пошук і йдуть у меню або гортають каталог вручну — проблема не в трафіку, а в тому, що видача не підтверджує намір.

Аудит починається з журналів запитів, а не з макета. Вивантажуємо топ формулювань, довгі фрази, одруки та запити, за якими нуль результатів або один.

Порівнюємо, що людина написала, з тим, що отримала, і куди пішла далі: клік за першою позицією, відмова, повторне введення іншими словами. Повторне введення — найчесніший індикатор: користувач вважає, що система його не зрозуміла.

Швидкі покращення закривають більшу частину втрат. Додаємо синоніми та виправлення одруків, піднімаємо вагу полів, за якими реально шукають — артикул, назва, характеристика, — налаштовуємо поведінку порожнього запиту та підказки за першими символами.

Окремо правимо порожній стан: замість «нічого не знайдено» показуємо близькі категорії та зняття зайвих умов.

Перезбірка сценарію потрібна там, де запит не збігається із задачею. Людина шукає за ознакою, якої немає в індексованих полях, або їй потрібен підбір за параметрами, а не рядкове введення.

Тоді змінюється модель даних і логіка видачі: пошук перестає бути окремим полем і стає частиною фільтрації, а результат збирається з кількох джерел.

Порядок робіт тому такий: спочатку аудит наявної видачі та поведінки користувачів у пошуку, потім швидкі покращення, і лише потім перезбірка сценарію для тих гілок, де правок недостатньо. Опишіть задачу — повернемося з оцінкою та планом щодо вашого пошуку.

Уточнення щодо обсягу, термінів і правок видачі

П'ять питань замовники задають майже завжди: обсяг правок макетів, терміни проєктування, мобільна версія, перевірка результату та передача. Нижче — короткі відповіді, щоб зняти невизначеність до оцінки робіт.

Як виглядають терміни проєктування сторінки пошуку?

Терміни розбиті за етапами: схема видачі, стани карток, адаптивні сітки, передача у верстку. Кожен етап закривається узгодженням, тому зсув видно заздалегідь, а не в кінці.

Що змінюється в мобільній версії?

Фільтри йдуть в окрему панель, результати — в компактні картки з ключовими полями. Окремо опрацьовуємо стани: порожня видача, завантаження, помилка запиту — на телефоні вони трапляються частіше.

Як переконатися, що інтерфейс працює до запуску?

Проводимо тестування з користувачами: 5–8 осіб проходять сценарій «знайшов і відкрив потрібне». Дивимося час до першого результату і частку пройдених сценаріїв, спірні місця правимо до верстки.

Чи можна пізніше замінити пошуковий механізм?

Так. Шар представлення відокремлений від джерела даних: розмітка та стилі не залежать від того, який механізм віддає результати. Заміна не вимагає перемальовування видачі.

Що отримуємо при передачі та що із супроводом?

Доступність інтерфейсу винесена в окремий чек-ліст за WCAG, до нього йдуть документація за компонентами та правила правок. Далі — супровід: оновлення станів видачі та розбір звернень у міру зростання каталогу.

Обговоримо задачу: повернемося з оцінкою та планом

Точна оцінка обсягу робіт з дизайну сторінки пошуку виходить не «на око», а з вхідних даних: чим конкретніші приклади, тим менше припущень у плані проєкту і тим передбачуваніші терміни.

Нижче — що достатньо надіслати, щоб ми повернулися зі складом команди та етапами, а не із загальними формулюваннями.

• Поточну видачу: як сторінка пошуку виглядає зараз — з фільтрами, сортуванням, підказками, станами завантаження та порожнього результату. Скріншоти або посилання на робочий контур.
• Приклади запитів: 20-30 реальних формулювань, включно з довгими, з одруками та латиницею — вони визначають логіку підказок і розмітку блоків результату.
• Аналітику або вивантаження: частку запитів без результатів, частку уточнень після першої видачі, розподіл за фільтрами. Це покаже, які сценарії лагодити першими.
• Обмеження за термінами та сумісністю: жорсткі дати, підтримувані браузери та пристрої, вимоги доступності, що не можна змінювати в поточному дизайні та структурі адрес.
• Наявні матеріали: логотип, палітру, шрифти, бібліотеку компонентів, якщо вона є. Інакше закладемо в план проєкту окремий етап на її опис.
• Склад тих, хто ухвалює рішення: хто узгоджує макети і хто відповідає за приймання. Це впливає не на вартість, а на кількість ітерацій і на те, як швидко етапи закриваються.

У відповідь надсилаємо план проєкту за етапами з точками приймання, склад команди під конкретний обсяг робіт і перелік сценаріїв, які увійдуть у перший цикл. Опишіть задачу — повернемося з оцінкою та планом.