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