Дизайн карточек поисковой выдачи: как объяснить совпадение

Три результата поиска могут содержать одно и то же слово, но отвечать на три разных вопроса. Пользователю, который ищет «экспорт», может понадобиться пошаговая инструкция для браузера, описание конечной точки API или подтверждение того, что функция изменилась в последнем выпуске. По одному списку совпавших заголовков не всегда понятно, какой документ поможет.

Задача дизайна карточек поисковой выдачи — дать возможность сделать этот выбор ещё до перехода. Покажите понятный тип документа, укажите, куда ведёт результат, и приведите достаточно контекста, чтобы объяснить его связь с запросом. Цель не в том, чтобы украсить порядок, заданный поисковой системой, а в том, чтобы помочь читателю понять, что на самом деле содержится в каждом результате.

Начните с трёх совпадений и одной конкретной задачи

Рассмотрим вымышленный продукт для работы с отчётами. Специалисту поддержки нужно скачать отфильтрованный отчёт в формате CSV через браузер. Он вводит «экспорт» в поиске по документации и получает три результата. Заголовки и фрагменты ниже образуют единый набор примеров: сравнивая варианты макета, не меняйте их содержание.

Для этой задачи стоит начать с инструкции. Справочник API описывает программную операцию, а примечания к выпуску объясняют изменение, но не показывают весь порядок действий. Разработчик, которому нужно узнать, что возвращает запрос на экспорт, выбрал бы в том же списке другой документ. Ни один результат не является «лучшим» для всех задач.

Здесь речь идёт о выдаче, в которой уже есть результаты. Изменение фильтров или объяснение отсутствия совпадений решает задачи на других этапах. Если затруднение именно в этом, обратитесь к руководству по дизайну интерфейса фильтрации или к паттернам пустых состояний; в нашем случае подходящие документы уже найдены, и читателю нужно различить их.

Разместите тип документа и путь рядом с заголовком

Используйте короткую метку, которая объясняет характер документа: «Инструкция», «Справочник API» или «Примечания к выпуску». Значок может дополнить её, но общий символ страницы не передаёт это различие. Не помечайте инструкцию словом «Рекомендуем» только потому, что она стоит первой: такая метка приписывает результату оценку, которую карточка ничем не объясняет.

Путь добавляет другой вид контекста. «API v2 › Отчёты › Экспорт» относит конечную точку к определённой версии API. «Руководства › Отчёты › Экспорт» указывает на последовательность действий для пользователя. Длинное имя хоста, повторяющееся у каждого внутреннего результата, занимает место, но не помогает отличить документы. Показывайте домен, когда результаты действительно ведут на разные сайты и источник влияет на выбор.

Сделайте заголовок основной ссылкой на документ. Одинаковые ссылки «Открыть» в каждой строке создают лишнюю неоднозначность при навигации по ссылкам. Рекомендации W3C о назначении ссылок (на английском) допускают, что назначение определяется текстом ссылки или программно определяемым контекстом; одной визуальной близости для такой связи недостаточно. При реализации семантически объедините элементы каждого результата и согласуйте заголовок открываемой страницы с тем, что обещает выдача.

В этом примере путь — поясняющий текст, а не три дополнительные навигационные ссылки. Так основной выбор остаётся простым: открыть документ. Если продукт также позволяет просматривать материалы по категориям, оформите это как явное дополнительное действие, а не превращайте незаметно каждый короткий сегмент пути в отдельную цель перехода.

Покажите связь с запросом, не меняя смысл фрагмента

Описание документа и фрагмент, подобранный под запрос, выполняют разные задачи. Описание кратко представляет ресурс целиком, а фрагмент показывает подходящий отрывок внутри него. Предложение «Откройте отчёт» полезно тем, что обозначает действия в браузере. Фраза «Узнайте всё об экспорте отчётов» под уже содержательным заголовком почти ничего не добавляет к основаниям для выбора.

Руководство Algolia по подсветке и формированию фрагментов (на английском) описывает выделение совпавших слов и вывод соседнего текста. Эти механизмы помогают увидеть, где встречается запрос. Но сами по себе они не подтверждают, что документ отвечает на вопрос пользователя, актуален или обоснованно расположен выше другого результата.

При сокращении фрагмента сохраняйте уточняющее предложение. В результате про API должны остаться слова «идентификатор задания, а не файл CSV», иначе специалист может принять его за инструкцию по прямому скачиванию. В примечаниях к выпуску необходимо сохранить смысл «экспорт по расписанию в этом выпуске не добавлен». Обрезка отрицания или извлечение одних лишь слов «экспорт по расписанию» меняет информацию, необходимую читателю.

Выберите целое предложение или другой связный отрывок, который помещается в карточке, вместо того чтобы отсечь фиксированное число символов и добавить многоточие. Если важное для безопасности условие или ограничение всё равно не помещается, разрешите ещё одну строку либо найдите более короткий, но точный отрывок. Когда в индексе нет подходящего фрагмента, используйте настоящее описание документа и подайте его как краткое содержание, а не как выдуманную цитату или заявленное совпадение с ключевым словом.

Подсвечивайте текст умеренно, сохраняя читаемость предложения. Совпадение запроса в заголовке и фрагменте — не повод окрашивать всю карточку. MDN описывает элемент mark как обозначение текста, значимого в данном контексте (на английском), и отмечает, что большинство программ экранного доступа по умолчанию не озвучивают такую подсветку. Видимый фрагмент должен оставаться понятным без цветовых выделений: важные различия нужно передать словами.

Определите, какие поля заслуживают места

Полезная карточка — не миниатюрная панель со всеми сведениями о документе. Для каждого поля укажите, какое решение оно помогает принять и какая информация должна сохраниться в компактном макете. Следующие правила относятся к примеру с отчётами; каталогу файлов для скачивания понадобились бы другие сведения.

Не повторяйте одинаковые сведения в разных полях. В пути API уже есть «v2», поэтому отдельная метка версии нужна не всегда. И наоборот, не убирайте значимое различие лишь ради одинаковой высоты строк. Версия в примечаниях к выпуску может влиять на выбор сильнее, чем дата обновления инструкции.

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

Перекомпонуйте содержание, а не только рамку карточки

На узком экране начните с заголовка и типа, затем сохраните различающий документы путь и связный фрагмент. Сначала сокращайте повторяющиеся украшения, а уже потом — слова, которые помогают различить три документа об экспорте. Одна серая строка с типом, датой, автором, путём и версией трудно воспринимается, даже если технически всё помещается.

Разрешите перенос длинных заголовков и проверяйте настоящие тексты. Фрагмент в две строки — полезная отправная точка для макета, но не обещание, что в две строки поместятся любой язык и любое уточнение. В примечаниях к выпуску отрицание про экспорт по расписанию важнее, чем строго одинаковая высота всех трёх карточек.

В опубликованном разборе редизайна поиска по документации Algolia (на английском) есть конкретное сравнение: в настольном интерфейсе список результатов сочетался с предварительным просмотром, а на мобильных устройствах и планшетах вместо него использовалось краткое описание. Там же описана группировка по типу контента. Это решения конкретной реализации, а не доказательство того, что любому поисковому интерфейсу нужны предварительный просмотр или такие же группы.

Для трёх результатов может хватить меток типа в самих карточках: отдельные разделы способны добавить больше заголовков, чем полезной организации. Если в большом списке группировка помогает, сделайте названия групп и порядок обхода понятными. Необязательный предварительный просмотр должен добавлять подробности, а не быть единственным местом, где можно понять содержание результата. Пользователь должен иметь возможность выбрать и открыть полезный документ без наведения указателя.

Обеспечьте достоверность полей в момент выбора

Заголовок, фрагмент, путь и версия карточки должны описывать один и тот же документ назначения. Актуальный заголовок в сочетании с отрывком из старой редакции может создать убедительный, но вводящий в заблуждение результат. Если в нашем примере указано «API v2», переход не должен незаметно открывать документацию другой версии. Вместе с ответственными за индекс и контент определите, как показывать перемещённые, заменённые и устаревшие документы.

Не раскрывайте заголовок или подходящий фрагмент закрытого документа только потому, что они ещё хранятся в поисковом индексе. OWASP рекомендует проверять права при каждом запросе (на английском). Для поиска это означает: нужно определить, какие метаданные разрешено раскрывать, и применять это правило при возврате результатов, а не только при открытии документа. Доступ может измениться и после загрузки списка; при переходе необходимо учитывать текущие права и показывать подходящее состояние с возможностью продолжить работу, не раскрывая защищённые фрагменты.

Основное действие должно соответствовать ресурсу. Переход по заголовку «Экспорт отчёта в CSV» должен открывать инструкцию, а не запускать скачивание. Кнопка прямого действия «Экспортировать сейчас» означала бы другую операцию продукта с потенциально значимыми последствиями, для которой нужны собственная проверка прав и обработка состояний. Слово в поисковом запросе не даёт разрешения выполнить это действие.

Проверьте один и тот же контент в Pixso до визуальной доводки

Создайте компонент карточки результата в дизайн-файле Pixso с отдельными текстовыми слоями для заголовка, типа, пути и фрагмента. Заполните три экземпляра точным содержанием примера выше. Сохраните исходный фрейм только с заголовками, фрейм с дополненными результатами и фрейм для узкого экрана. Сравнение одних и тех же документов помогает понять пользу добавленного контекста; изменение заголовков между вариантами помешало бы такому сравнению.

Используйте узкий фрейм для решений о содержании, а не только об отступах. Разрешите перенос заголовка инструкции, сохраните ограничение ответа API и предложение об экспорте по расписанию в примечаниях к выпуску. Рядом с компонентом опишите условия показа полей и правила сокращения, чтобы при реализации не приходилось угадывать, какие слова можно убрать.

В прототипе свяжите заголовки результатов с соответствующими фреймами документов и предусмотрите возврат с сохранением запроса. Так моделируется выбор перехода, а не действующий поисковый индекс. Приложение для отчётов на холсте — это проверяемый дизайн, а не утверждение о том, как работает собственный поиск Pixso.

Попросите коллегу выбрать документ, который поможет скачать отфильтрованный отчёт в CSV через браузер. Затем дайте отдельную задачу узнать, что возвращает API, и ещё одну — определить, появился ли в выпуске 2.8 экспорт по расписанию. Выясните, какое поле помогает сделать каждый выбор. Переход к правильной карточке по ошибочной причине — например, из предположения, что самая свежая на вид дата всегда означает лучший ответ, — тоже указывает на проблему дизайна.

Наконец, проверьте тот же путь с клавиатуры и при увеличенном размере текста. Может ли читатель понять, куда ведёт результат, прочитать ограничение целиком и вернуться, не вводя запрос заново? Доработайте поле или фрагмент, на котором возникло затруднение. Успех — это обоснованный выбор между документами, а не просто более яркая строка или большее число кликов.

Спроектируйте содержательную страницу результатов поиска в Pixso →