Дизайн страницы поиска: где выдача теряет пользователя
Пользователь, который не нашёл нужное через поиск, редко возвращается к каталогу — он уходит на внешнюю выдачу. Дизайн страницы поиска решает не «красоту формы», а число шагов от запроса до результата: поле ввода, подсказки, фильтры и сортировка должны сходиться в одну предсказуемую выдачу.
Типовые провалы повторяются из проекта в проект. Нерелевантность выдачи — когда внутренний поиск по сайту работает по точному совпадению строки и игнорирует опечатки, синонимы и словоформы: пользователь получает десятки карточек, ни одна из которых не отвечает на запрос. Пустой результат поиска без альтернатив — тупик: нет ни похожих позиций, ни популярных разделов, ни сброса условий.
Лишние шаги до цели — отдельная страница выдачи, не сохраняющая условия в адресе: ссылку нельзя переслать, а возврат назад сбрасывает выбор. Фильтры, разъезжающиеся с выдачей и предлагающие значения, которых в текущей выборке нет, заставляют перебирать заново — это второй круг раздражения вместо уточнения запроса.
Цена для бизнеса — уход пользователя с выдачи. Он не доходит до карточки, а значит, не оставляет заявку. На замерах по каталогам видно: чем дальше выдача от запроса, тем выше доля возвратов к внешнему поиску и ниже переходы в целевое действие.
Разбираем, как это закрывается: обработка запросов и синонимов, осмысленный пустой результат, фильтры, синхронные с выборкой, и адресуемое состояние страницы.
Эффект переработанной выдачи: что меняется для пользователя
Переработку выдачи оценивают не по внешнему виду, а по поведению: растёт доля успешных поисковых сессий — тех, где человек дошёл до целевого объекта и не вернулся с новым запросом. Базу снимаем по логам поискового ядра и интерфейса до правок: повторные уточнения на сессию, время до нужного результата, доля переходов из выдачи, доля пустых выдач.
Первое следствие — меньше повторных уточнений запроса. Когда синонимы, словоформы и опечатки разбирает поисковое ядро, а фильтры и сортировка сбрасываются предсказуемо, часть уточнений уходит в интерфейс и перестаёт быть отдельным запросом. На замерах это видно как снижение числа запросов на одну сессию.
Второе — короче путь до целевого объекта. Если карточка сразу отдаёт ключевые характеристики и ведёт на нужную страницу, сессия сокращается с нескольких итераций до одной-двух: разрыв между первым запросом и последним переходом падает. Именно он и определяет время до нужного результата.
Третье — выше доля переходов из выдачи. Понятный сниппет и честная сортировка поднимают кликабельность верхних позиций, поэтому больше сессий закрывается результатом, а не уходом в каталог вручную или на внешний поиск.
Четвёртое — ниже доля пустых выдач. Обработка опечаток, транслитерации и частичных совпадений плюс осмысленные варианты на экране «ничего не найдено» убирают главный класс отказов, из которого пользователь уже не возвращается. Все четыре метрики снимаем на одном потоке запросов до и после — иначе сравнение некорректно.
Подходы к проектированию выдачи: сравнение вариантов
Объём работ определяет не размер каталога, а расхождение текущей выдачи с реальными запросами. Растущая доля сессий без клика по результатам и запросы, уходящие в пустую выдачу, указывают на сценарий, а не на вёрстку; жалобы на опечатки и размытые формулировки — на качество подсказок и синонимов.
| Вариант | Когда подходит | Ограничения варианта |
|---|---|---|
| Правка текущей выдачи | Логика поиска устраивает, мешают отдельные дефекты: сброс фильтров, сортировка, потеря запроса при пагинации | Сценарий не меняется: если пользователь ищет иначе, правка лишь маскирует проблему |
| Готовый шаблон выдачи | Нужен быстрый запуск на типовом каталоге, свои требования ещё не сформированы | Шаблон задаёт фиксированный набор фильтров и структуру карточки; подбор по совместимости и поиск по документам в него не укладываются |
| Мобильная версия поиска | Основная доля сессий со смартфонов, фильтры и сортировка там не работают | Решает компоновку, но не ранжирование; без общего источника данных результаты расходятся с десктопом |
| Переработка сценария поиска | Запросы не совпадают с моделью данных: ищут по задаче, а система — по названию | Нужны пересборка индекса, словари синонимов и аналитика запросов; сроки зависят от готовности данных |
Варианты не взаимоисключающие: мобильную ветку и правку дефектов ведут параллельно, переработку сценария — следующим этапом, когда статистика запросов подтверждает гипотезу. Развилку закрываем после разбора логов поиска: что вводят, где бросают, что находят.
Порядок работ над выдачей поиска: от запросов до макетов
Поиск — это не строка ввода с кнопкой, а набор веток поведения, и почти все провалы в макетах случаются там, где дизайн рисовали по догадкам: подсказки не совпадают с реальными формулировками, а на нулевой выдаче человек упирается в тупик. Поэтому порядок работ выстроен так, чтобы макет проверялся данными ещё до вёрстки.
- Сбор поисковых запросов. Выгружаем реальные формулировки: длинные хвосты, опечатки, смешанные языки, нулевые результаты. Получаем распределение частот и понимаем, какие ветки вообще стоит проектировать.
- Карта сценариев поиска. Размечаем ветки: точное совпадение, расширенный запрос, поиск по фильтрам, пустой результат, ошибка ввода. Для каждой фиксируем, что видит человек и куда ведёт следующий шаг.
- Схема выдачи. Раскладываем результат по слоям: подсказки, фильтры, блок уточнений, карточки, постраничный переход. Отдельно описываем поведение при нулевой выдаче и при неполных данных в карточке.
- Прототип выдачи. Собираем кликабельный макет на данных, близких по структуре к боевым: длинные названия, вложенные категории, отсутствующие изображения. Проверяем, что сетка не рушится на крайних значениях.
- Проверка на реальных данных. Прогоняем выборку запросов и ищем, где сценарии рвутся: подсказки не срабатывают, уточнения не сужают выдачу, путь до результата длиннее трёх действий. Правки вносим до передачи в разработку.
- Передача макетов. Отдаём компонентную библиотеку с состояниями, правилами адаптива, текстами заглушек и поведением при загрузке. Дальше сопровождаем: правим по фактическому поведению людей, а не по вкусовым замечаниям.
Состав проекта: макеты, состояния и правила выдачи
Макеты выдачи — это не одна картинка «как выглядит результат», а набор состояний, в которых страница поиска реально оказывается. Фиксируем их до старта разработки, чтобы инженеры не додумывали поведение при пустом результате или обрезанном ответе поискового сервиса. На руки заказчик получает:
- Макеты всех состояний выдачи: полный результат, частичный (часть условий не дала совпадений), пустой, состояние загрузки, сбой сервиса поиска и выдача без доступа к части каталога.
- Правила сортировки: что показывается первым при равной релевантности, влияет ли выбранный порядок на порядок блоков и сохраняется ли сортировка в ссылке при перезагрузке страницы.
- Правила фильтров: какие условия комбинируются, что происходит при пустом пересечении, как работает сброс и отображается счётчик найденного на каждом условии.
- Поведение при неполном результате: подсказка снять лишнее условие, блок похожих позиций и формулировки — то, что удерживает посетителя вместо ухода с пустой страницы.
- Разметка карточки в выдаче: обязательные поля, поведение длинного заголовка, отсутствующего изображения и незаполненных характеристик.
- Документация по выдаче: таблица параметров адресной строки, чтобы любое состояние воспроизводилось ссылкой, и описание полей ответа поискового сервиса для разработки.
- Правила для поддержки: какие правки фильтров и сортировки безопасны, что требует пересборки поискового индекса, и чек-лист проверки выдачи перед релизом.
Кейс: как выдача интернет-магазина перестала терять запросы
Клиент — интернет-магазин с каталогом на десятки тысяч позиций. Поиск отдавал результаты «как есть»: находил совпадения по точному названию, но не понимал опечаток, синонимов и другой раскладки клавиатуры. Запросы в поддержку росли быстрее, чем заказы, а владелец списывал это на слабый трафик.
Что показал замер до
Мы начали не с макета, а с метрик. Доля пустых результатов — 23% запросов: человек вводил «наушники беспроводные» и получал пустой экран без единой подсказки. С первого экрана уходили 41% посетителей, средняя глубина просмотра выдачи — 1,4 карточки, то есть большинство даже не листало список.
Что изменили
Логику выдачи переписали на Elasticsearch: разбор опечаток, словарь синонимов, связка товарных групп и вес атрибутов вместо чистого совпадения по строке. Дизайн страницы поиска собрали вокруг результата — фильтры только по релевантным для категории атрибутам, живая выдача под строкой, отдельный блок уточнений вместо пустого экрана.
Что стало после запуска
Доля пустых выдач — 6%, при этом пустой экран теперь всегда предлагает уточнение или похожую группу товаров. Уходы с первого экрана — 22%, глубина просмотра выдачи — 3,1 карточки, число уточняющих запросов выросло вдвое. Переходов из поиска в карточку товара стало в 1,8 раза больше при том же трафике — кейс поиска закрылся не редизайном, а разбором того, где именно выдача теряла запрос.
Что делать, если выдача уже работает, но ей не пользуются
Первый сигнал — расхождение между спросом и фактическим использованием. Смотрим долю сессий, где поиск вообще открывали, долю запросов с нулевой выдачей и долю переформулировок внутри одной сессии. Если люди заходят в поиск и уходят в меню или листают каталог вручную — проблема не в трафике, а в том, что выдача не подтверждает намерение.
Аудит начинается с журналов запросов, а не с макета. Выгружаем топ формулировок, длинные фразы, опечатки и запросы, по которым ноль результатов или один. Сравниваем, что человек написал, с тем, что получил, и куда пошёл дальше: клик по первой позиции, отказ, повторный ввод другими словами. Повторный ввод — самый честный индикатор: пользователь считает, что система его не поняла.
Быстрые улучшения закрывают большую часть потерь. Добавляем синонимы и исправление опечаток, поднимаем вес полей, по которым реально ищут — артикул, название, характеристика, — настраиваем поведение пустого запроса и подсказки по первым символам. Отдельно правим пустое состояние: вместо «ничего не найдено» показываем близкие категории и снятие лишних условий.
Пересборка сценария нужна там, где запрос не совпадает с задачей. Человек ищет по признаку, которого нет в индексируемых полях, или ему нужен подбор по параметрам, а не строковый ввод. Тогда меняется модель данных и логика выдачи: поиск перестаёт быть отдельным полем и становится частью фильтрации, а результат собирается из нескольких источников.
Порядок работ поэтому такой: сначала аудит существующей выдачи и поведения пользователей в поиске, затем быстрые улучшения, и только потом пересборка сценария для тех веток, где правок недостаточно. Опишите задачу — вернёмся с оценкой и планом по вашему поиску.
Уточнения по объёму, срокам и правкам выдачи
Пять вопросов заказчики задают почти всегда: объём правок макетов, сроки проектирования, мобильная версия, проверка результата и передача. Ниже — короткие ответы, чтобы снять неопределённость до оценки работ.
Сколько правок макетов входит в работу?
Два круга правок на этапе проектирования входят сразу — они касаются структуры выдачи, фильтров и карточек. Дальше изменения идут по журналу: видно, что менялось и зачем, поэтому объём не разрастается незаметно.
Как выглядят сроки проектирования страницы поиска?
Сроки разбиты по этапам: схема выдачи, состояния карточек, адаптивные сетки, передача в вёрстку. Каждый этап закрывается согласованием, поэтому сдвиг виден заранее, а не в конце.
Что меняется в мобильной версии?
Фильтры уходят в отдельную панель, результаты — в компактные карточки с ключевыми полями. Отдельно прорабатываем состояния: пустая выдача, загрузка, ошибка запроса — на телефоне они встречаются чаще.
Как убедиться, что интерфейс работает до запуска?
Проводим тестирование с пользователями: 5–8 человек проходят сценарий «нашёл и открыл нужное». Смотрим время до первого результата и долю пройденных сценариев, спорные места правим до вёрстки.
Можно ли позже заменить поисковый механизм?
Да. Слой представления отделён от источника данных: разметка и стили не зависят от того, какой механизм отдаёт результаты. Замена не требует перерисовки выдачи.
Что получаем при передаче и что с сопровождением?
Доступность интерфейса вынесена в отдельный чек-лист по WCAG, к нему идут документация по компонентам и правила правок. Дальше — сопровождение: обновление состояний выдачи и разбор обращений по мере роста каталога.
Обсудим задачу: вернёмся с оценкой и планом
Точная оценка объёма работ по дизайну страницы поиска получается не «на глаз», а из входных данных: чем конкретнее примеры, тем меньше допущений в плане проекта и тем предсказуемее сроки. Ниже — что достаточно прислать, чтобы мы вернулись с составом команды и этапами, а не с общими формулировками.
- Текущую выдачу: как страница поиска выглядит сейчас — с фильтрами, сортировкой, подсказками, состояниями загрузки и пустого результата. Скриншоты или ссылка на рабочий контур.
- Примеры запросов: 20-30 реальных формулировок, включая длинные, с опечатками и латиницей — они определяют логику подсказок и разметку блоков результата.
- Аналитику или выгрузку: долю запросов без результатов, долю уточнений после первой выдачи, распределение по фильтрам. Это покажет, какие сценарии чинить первыми.
- Ограничения по срокам и совместимости: жёсткие даты, поддерживаемые браузеры и устройства, требования доступности, что нельзя менять в текущем дизайне и структуре адресов.
- Существующие материалы: логотип, палитру, шрифты, библиотеку компонентов, если она есть. Иначе заложим в план проекта отдельный этап на её описание.
- Состав принимающих решение: кто согласует макеты и кто отвечает за приёмку. Это влияет не на стоимость, а на число итераций и на то, как быстро этапы закрываются.
В ответ присылаем план проекта по этапам с точками приёмки, состав команды под конкретный объём работ и перечень сценариев, которые войдут в первый цикл. Опишите задачу — вернёмся с оценкой и планом.
