На заре Интернета панель поиска была роскошью, ее добавляли на сайт, когда она становилась «слишком большой» для навигации по ней щелчком мыши. Мы относились к нему как к указателю в конце книги: буквальному алфавитному списку слов, указывающему на определенные страницы. Если вы ввели именно то слово, которое использовал автор, вы нашли то, что вам нужно. Если вы этого не сделали, вас встретил экран «Найдено 0 результатов», который выглядел как цифровой тупик. Двадцать пять лет спустя мы все еще создаем панели поиска, которые действуют как учетные карточки 1990-х годов, хотя люди, использующие их, были фундаментально изменены. Сегодня, когда пользователь заходит на ваш сайт и не может найти то, что ему нужно, в глобальной навигации за считанные секунды, он не пытается изучить вашу таксономию. Они направляются к окну поиска. Но если этот стандарт их не подводит и требует, чтобы они использовали словарь вашего конкретного бренда, или наказывает их за опечатку, они делают то, что должно не дать каждому UX-дизайнеру уснуть по ночам. Они покидают ваш сайт, заходят в Google и набирают site:yourwebsite.com [запрос]. Или, что еще хуже, они просто вводят свой запрос и попадают на сайт конкурента. Лично я почти каждый раз использую Google для поиска по сайту. Это парадокс поиска по сайту. В эпоху, когда у нас больше данных и лучшие инструменты, чем когда-либо, наши возможности внутреннего поиска часто настолько плохи, что пользователи предпочитают использовать глобальную поисковую систему стоимостью триллион долларов, чтобы найти одну страницу на локальном сайте. Как информационные архитекторы и UX-дизайнеры, мы должны задаться вопросом: почему побеждает «Большая коробка» и как мы можем вернуть наших пользователей? «Синтаксический налог» и смерть точного совпадения Основная причина неудачного поиска по сайту — это то, что я называю синтаксическим налогом. Это когнитивная нагрузка, которую мы возлагаем на пользователей, когда требуем от них угадать точную строку символов, которую мы использовали в нашей базе данных. Исследование Origin Growth по поиску и навигации показывает, что примерно 50% пользователей сразу переходят на панель поиска после перехода на сайт. Например, когда пользователь вводит слово «диван» на мебельный сайт, на котором все отнесено к категории «кушетки», и сайт ничего не возвращает, пользователь не думает: «Ах, мне стоит попробовать синоним». Они думают: «На этом сайте нет того, что мне нужно». Это провал информационной архитектуры (IA). Мы построили наши системы так, чтобы они соответствовали строкам (буквальным последовательностям букв), а не вещам (концепциям, лежащим в основе слов). Когда мы заставляем пользователей использовать наш внутренний словарный запас, мы нагружаем их умственные способности.
Почему Google побеждает: это не сила, а контекст Легко поднять руки и сказать: «Мы не можем конкурировать с разработками Google». Но успех Google заключается не только в чистой силе; речь идет о контекстуальном понимании. Хотя мы часто рассматриваем поиск как техническую утилиту, Google рассматривает его как проблему IA. Данные Института Баймарда показывают, что 41% сайтов электронной коммерции не поддерживают даже базовые символы и сокращения, и это часто приводит к тому, что пользователи покидают сайт после единственной неудачной попытки поиска. Google выигрывает, потому что он использует стемминг и лемматизацию — методы IA, которые распознают «бег» и «бег», имеют одну и ту же цель. Большинство внутренних поисковых запросов «слепы» к этому контексту, рассматривая «Кроссовки» и «Кроссовки» как совершенно разные сущности. Если поиск по вашему сайту не может обрабатывать простое множественное число или распространенные орфографические ошибки, вы фактически взимаете с пользователей налог за то, что они человечны.
UX «Может быть»: проектирование для вероятностных результатов В традиционном IA мы думаем двоично: страница либо находится в категории, либо нет. Результат поиска либо соответствует, либо нет. Современный поиск, которого сейчас ожидают пользователи, является вероятностным. Речь идет об «уровнях уверенности». По данным Forresters, пользователи, использующие поиск, в 2–3 раза чаще совершают конверсию, чем те, кто этого не делает, если поиск работает. А 80% пользователей сайтов электронной коммерции покидают сайт из-за плохих результатов поиска. Мы, дизайнеры, редко выбираем золотую середину. Мы разрабатываем страницу «Результаты найдены» и страницу «Нет результатов». Мы упускаем самое важное состояние: «Вы имели в виду?» Состояние. Хорошо продуманный интерфейс поиска должен обеспечивать «нечеткие» совпадения. Вместо холодного экрана «Найдено 0 результатов» мы должны использовать наши метаданные, чтобы сказать: «Мы не нашли этого в разделе «Электроника», но мы нашли 3 совпадения в разделе «Аксессуары». Создавая дизайн для «Может быть», мы можем держать пользователя в потоке. Практический пример: стоимость «невидимого» контента Чтобы понять, почему IA является топливом дляпоисковой системе, мы должны посмотреть, как данные структурируются за кулисами. За свою 25-летнюю практику я видел, что «находимость» страницы напрямую связана с ее структурированными метаданными. Рассмотрим крупное предприятие, с которым я работал, у которого было более 5000 технических документов. Их внутренний поиск возвращал нерелевантные результаты, поскольку тегом «Название» каждого документа был внутренний номер SKU (например, «DOC-9928-X»), а не удобочитаемое имя. Просматривая журналы поиска, мы обнаружили, что пользователи искали «руководство по установке». Поскольку эта фраза не появлялась в названии SKU, движок игнорировал наиболее важные файлы. Мы внедрили контролируемый словарь, который представлял собой набор стандартизированных терминов, сопоставляющих SKU с человеческим языком. За три месяца «Показатель выхода» со страницы поиска упал на 40%. Это не было алгоритмическое исправление; это было исправление IA. Это доказывает, что поисковая система хороша настолько, насколько хороша карта, которую мы ей предоставляем. Внутренний языковой разрыв За два десятилетия работы в UX я заметил повторяющуюся тему: внутренние команды часто страдают от «проклятия знаний». Мы настолько погружаемся в собственный корпоративный словарь, который иногда называют деловым жаргоном, что забываем, что пользователь не говорит на нашем языке. Однажды я работал с финансовым учреждением, которое было разочаровано большим количеством обращений в их центр поддержки. Пользователи жаловались, что не могут найти на сайте информацию о «погашении кредита». Когда мы просмотрели журналы поиска, «выплата кредита» была поисковым запросом №1, который не дал результатов. Почему? Потому что команда IA учреждения пометила каждую соответствующую страницу формальным термином «Выпуск кредита». Для банка «выплата» была процессом, но «выдача кредита» была юридическим документом, который был «вещью» в базе данных. Поскольку поисковая система искала буквальные строки символов, она отказалась связать отчаянную потребность пользователя с официальным решением компании. Именно здесь специалист по внутреннему аудиту должен выступать в роли переводчика. Просто добавив «выплату кредита» в качестве скрытого ключевого слова метаданных на страницы выдачи кредита, мы решили многомиллионную проблему поддержки. Нам не нужен был более быстрый сервер; нам нужна была более чуткая таксономия. Четырехэтапная система аудита поиска по сайту Если вы хотите вернуть свое окно поиска у Google, вы не можете просто «установить его и забыть». Вы должны относиться к поиску как к живому продукту. Вот структура, которую я использую для аудита и оптимизации поиска: Этап 1: Аудит «нулевого результата» Возьмите журналы поиска за последние 90 дней. Отфильтруйте все запросы, которые вернули нулевые результаты. Сгруппируйте их в три сегмента:
Истинные пробелы. Контент, который хочет пользователь, которого у вас просто нет (сигнал для вашей команды по контент-стратегии). Пробелы в синонимах. Контент, который у вас есть, но описан словами, которые пользователь не использует (например, «Диван» или «Диван»). Пробелы в формате. Пользователь ищет «видео» или «PDF», но ваш поиск индексирует только текст HTML.
Этап 2. Сопоставление намерений запроса Проанализируйте топ-50 самых распространенных запросов. Являются ли они навигационными (поиск определенной страницы), информационными (поиск «как сделать») или транзакционными (поиск определенного продукта)? Ваш пользовательский интерфейс поиска должен выглядеть по-разному для каждого из них. Навигационный поиск должен «быстро связать» пользователя с пунктом назначения, полностью минуя страницу результатов. Этап 3: «Нечеткий» тест на соответствие Намеренно опечатайте 10 лучших продуктов. Используйте множественное число, распространенные опечатки и варианты написания в американском и британском английском (например, «Цвет» вместо «Цвет»). Если ваш поиск не проходит эти тесты, значит, в вашем движке отсутствует поддержка стемминга. Это техническое требование, которое вы должны отстаивать перед своей командой инженеров. Этап 4: Определение области действия и фильтрация UX Посмотрите на свою страницу результатов. Предлагает ли он фильтры, которые действительно имеют смысл? Если пользователь ищет «обувь», он должен увидеть фильтры по размеру и цвету. Обычные фильтры могут быть так же плохи, как и отсутствие фильтров. Возвращение поля поиска: стратегия для специалистов по информационному аудиту Чтобы остановить отток пользователей в Google, мы должны выйти за рамки «коробки» и взглянуть на строительные леса. Шаг А: Внедрите семантический каркас. Не просто возвращайте список ссылок. Используйте свою IA, чтобы предоставить контекст. Если пользователь ищет продукт, покажите ему сам продукт, а также руководство, часто задаваемые вопросы и соответствующие детали. Этот «ассоциативный» поиск имитирует работу человеческого мозга и работу Google. Шаг Б: Перестаньте быть библиотекарем, начнитеработа консьержем. Библиотекарь точно скажет вам, где находится книга на полке. Консьерж выслушает, чего вы хотите добиться, и даст вам рекомендации. Ваша панель поиска должна использовать интеллектуальный текст не только для завершения слов, но и для предложения намерений. Использование панели поиска Google Использование панели поиска «на базе Google», как это видно на веб-сайте Чикагского университета, по сути, является признанием того, что внутренняя организация сайта стала слишком сложной, чтобы с ней могла справиться его собственная навигация. Хотя для крупных организаций это быстрое «решение», позволяющее пользователям что-то найти, в целом это плохой выбор для компаний с глубоким содержанием.
Делегируя поиск Google, вы передаете взаимодействие с пользователем внешнему алгоритму. Вы теряете возможность продвигать определенные продукты, вы подвергаете своих пользователей сторонней рекламе и обучаете своих клиентов покидать вашу экосистему в тот момент, когда им нужна помощь. Для бизнеса поиск должен быть организованным диалогом, который ведет клиента к цели, а не общим списком ссылок, который возвращает его в открытую сеть.
Контрольный список простого поиска по UX Вот окончательный контрольный список, который пригодится вам при создании возможностей поиска для ваших пользователей. Работайте со своей продуктовой командой, чтобы убедиться, что вы взаимодействуете с нужными членами команды.
Убейте тупик. Никогда не говорите просто: «Результатов не найдено». Если точного соответствия нет, предложите похожую категорию, популярный продукт или способ связаться со службой поддержки. Исправьте совпадения «почти». Убедитесь, что поиск обрабатывает множественное число (например, «растение» или «растения») и распространенные опечатки. Пользователей не следует наказывать за упущение. Предскажите цель пользователя. Используйте меню «автоматических предложений», чтобы показывать полезные действия (например, «Отследить мой заказ») или категории, а не просто список слов. Говорите как человек. Посмотрите журналы поиска, чтобы узнать, какие слова на самом деле используют люди. Если они наберут «диван», а вы назовете это «диван», создайте мост на заднем плане, чтобы они все равно находили то, что им нужно. Умная фильтрация. Показывайте только важные фильтры. Если кто-то ищет «обувь», покажите ему фильтры по размеру и цвету, а не общий список, применимый ко всему сайту. Показывайте, а не просто перечисляйте. Используйте небольшие миниатюры и четкие метки в результатах поиска, чтобы пользователи могли сразу увидеть разницу между продуктом, публикацией в блоге и справочной статьей. Скорость – это доверие. Если поиск занимает больше секунды, используйте анимацию загрузки. Если это будет слишком медленно, люди немедленно вернутся в Google. Проверяйте журналы «неуспехов». Раз в месяц смотрите, что люди искали, но что не дало результатов. Это ваш «список дел» по исправлению навигации вашего сайта.
Вывод: панель поиска — это разговор Поле поиска — единственное место на вашем сайте, где пользователь своими словами точно говорит нам, чего он хочет. Когда мы не понимаем эти слова, когда мы позволяем «Большому ящику» Google делать всю работу за нас, мы не просто теряем количество просмотров страниц. Мы теряем возможность доказать, что понимаем наших клиентов. Успех в современном UX заключается не в наличии максимального количества контента; речь идет о том, чтобы контент был наиболее доступным для поиска. Пришло время перестать облагать пользователей налогом за их синтаксис и начать проектировать с учетом их целей. Перейдя от буквального сопоставления строк к семантическому пониманию и поддерживая наши поисковые системы надежной, ориентированной на человека информационной архитектурой, мы наконец сможем ликвидировать разрыв.
