.svg)
Коротко:
- Поиск - это целостный сценарий, а не набор отдельных компонентов. Сломать его можно на любом шаге: от строки ввода до страницы без результатов.
- Автодополнение ускоряет ввод, но плохо настроенное - сбивает пользователя и навязывает чужие запросы.
- Фильтры помогают только тогда, когда применяются сразу и не скрывают количество подходящих результатов.
- Страница с результатами должна отражать запрос: показывать, что нашла система, почему и как уточнить.
- Нулевые результаты - это не тупик, а точка принятия решения. Интерфейс обязан подсказать следующий шаг.
- Большинство проблем в этом флоу не дизайнерские, а логические: компонент выглядит правильно, но поведение не совпадает с ожиданием пользователя.
Поиск - один из тех сценариев, которые кажутся простыми до момента проектирования. Строка, кнопка, список. Что тут сложного? На практике именно этот флоу чаще всего ломается: пользователь вводит запрос, получает нерелевантную выдачу или вообще пустой экран, не понимает, почему так вышло, и уходит.
Проблема не всегда в алгоритмах поиска на бэкенде. Часто дело в том, как интерфейс ведёт пользователя через сценарий: насколько понятны подсказки, как работают фильтры, что происходит при нулевом результате и как система сообщает о своих ограничениях.
Эта статья - пошаговый разбор всего флоу: от момента, когда пользователь встаёт перед пустым полем, до момента, когда он нашёл нужное или понял, что нужно сделать иначе. Дизайн поиска в интерфейсе рассмотрен как единая система, а не как набор отдельных компонентов.
Строка поиска: первый контакт с намерением пользователя
Поле ввода - это не просто input. Это точка, в которой пользователь формулирует намерение. И уже здесь интерфейс может либо поддержать его, либо создать трение.
Несколько вещей, которые нужно решить на этапе проектирования строки:
Плейсхолдер должен объяснять, что именно можно искать, а не просто говорить «Поиск». Для маркетплейса подойдёт «Ноутбуки, смартфоны, наушники», для базы знаний - «Как настроить интеграцию», для CRM - «Клиент, сделка, контакт». Плейсхолдер исчезает при вводе, поэтому он работает только как начальная подсказка. Не стоит перегружать его - одна строка, конкретный пример или подсказка о формате.
Иконка лупы - устойчивый паттерн, который пользователи понимают без подписи. Она может стоять слева (как визуальный маркер) или справа (как кнопка отправки). Если справа кнопка - убедитесь, что нажатие Enter тоже работает. Разрыв между ожиданием и поведением здесь случается часто.
Кнопка очистки (крестик) должна появляться только после того, как пользователь начал вводить текст. Пустая строка с крестиком - это лишний элемент без функции.
Позиция строки зависит от роли поиска в продукте. Если это основной способ навигации - строка должна быть в шапке, заметной и всегда доступной. Если поиск вспомогательный, например, в настройках или справочнике, - достаточно разместить его в контексте раздела. Глобальный и локальный поиск лучше визуально разделять: пользователь должен понимать, где он ищет.
Автодополнение: когда помощь становится помехой
Выпадающий список подсказок при вводе - полезный паттерн, но его легко сломать неправильной логикой или неаккуратной реализацией.
Автодополнение решает несколько задач: ускоряет ввод, показывает доступные варианты, помогает избежать опечаток. Но оно же создаёт проблемы, если:
- Подсказки появляются раньше, чем пользователь успел ввести хотя бы 2-3 символа. Мелькание длинного списка с первой буквы отвлекает и не несёт смысла.
- Список не фильтруется по контексту. Если пользователь находится в разделе «Электроника», подсказки из категории «Одежда» вызывают путаницу.
- Подсказки не отражают реальный контент. Предложить запрос, который вернёт ноль результатов, - прямая дорога к разочарованию.
- Клавиатурная навигация не работает. Часть пользователей выбирает подсказку стрелками, не мышью. Если это не предусмотрено, они застревают.
Хорошее автодополнение показывает 5-7 вариантов максимум, группирует их по типу (запросы, категории, конкретные объекты), подсвечивает совпадение с введённым текстом и позволяет закрыть список клавишей Escape.
Представим маркетплейс одежды. Пользователь вводит «плать». Хорошая подсказка: «Платья летние», «Платья вечерние», «Платья для девочек» - конкретные популярные запросы. Плохая подсказка: «Платье», «Платье», «Платье» - три одинаковых варианта без уточнения, которые ничего не добавляют.
Отдельный вопрос - история поиска. Показывать последние запросы пользователя удобно, но только если их легко очистить и они не занимают больше места, чем реальные подсказки.
Фильтры в интерфейсе: структура vs свобода
Фильтры - самый сложный компонент в этом флоу. Они одновременно дают пользователю контроль и создают риск потеряться.
Базовое правило: фильтр должен применяться немедленно или через явную кнопку - но не оба варианта одновременно. Смешанное поведение, когда один параметр применяется сразу, а другой требует подтверждения, ломает модель ожидания.
Мгновенное применение (как в большинстве e-commerce) подходит, когда результаты обновляются быстро и пользователь хочет видеть эффект сразу. Кнопка «Применить» нужна, когда нужно выбрать несколько параметров перед обновлением выдачи - например, в сложных B2B-фильтрах, где каждый запрос дорогой.
Что ещё важно в проектировании фильтров:
- Количество результатов рядом с каждым значением. Если у фильтра «Красный» стоит (0), не давайте пользователю нажимать на него и получать пустой экран. Лучше сразу показать, что вариант недоступен, или скрыть его.
- Активные фильтры должны быть видны. Пользователь поставил три галки и забыл об этом. Он смотрит на выдачу и не понимает, почему результатов так мало. Покажите применённые параметры в виде тегов с возможностью снять каждый по отдельности.
- Кнопка «Сбросить всё» - обязательна. Но размещайте её там, где она не будет нажата случайно.
- На мобильном фильтры убираются в drawer или bottom sheet. Полноэкранная панель с длинным списком параметров на телефоне - отдельная история взаимодействия, которую нужно проектировать отдельно, не просто адаптируя десктопный вариант.
Частая ошибка: фильтры и сортировка смешиваются в один блок. Это разные действия с разной логикой. Фильтр сужает набор результатов, сортировка меняет порядок внутри уже отфильтрованного. Держите их раздельно визуально и функционально.
Страница результатов: что пользователь видит после запроса
Выдача результатов - это ответ системы на вопрос пользователя. И этот ответ должен быть понятным, а не просто списком карточек.
Несколько вещей, которые работают на доверие:
Заголовок с запросом. Простая строка «Результаты по запросу
Мобильный поиск: отдельный сценарий, а не адаптация десктопа
На мобильном устройстве сценарий ввода и просмотра результатов принципиально отличается от десктопного. Клавиатура перекрывает половину экрана, пальцы не дают точного попадания, а пользователь чаще всего держит телефон одной рукой.
Несколько вещей, которые нужно учесть отдельно для мобильного сценария:
- Строка ввода должна быть достаточно высокой. Минимальная касаемая зона по рекомендациям Apple и Google составляет 44px. Тонкое поле ввода высотой 24px технически работает, но вызывает промахи.
- Клавиатура открывается автоматически, если поиск - основной сценарий экрана. Если пользователь пришёл специально ввести запрос, не заставляйте его делать лишний тап. Если поиск второстепенный - не открывайте клавиатуру без явного действия: это раздражает.
- Результаты должны появляться ниже клавиатуры, а не под ней. Первый результат часто оказывается перекрыт клавиатурой, и пользователь не видит, что список уже обновился.
- Сортировка и параметры на мобильном убираются за отдельный элемент управления. Попытка уместить все варианты на экране телефона в виде горизонтального скролла из восьми кнопок - частая ошибка. Пользователь не видит, что список продолжается, и не знает, что там есть нужный параметр.
Отдельный момент - голосовой ввод. Если продукт рассчитан на мобильную аудиторию, иконка микрофона рядом со строкой ввода снижает трение для тех, кто предпочитает говорить, а не печатать. Особенно это актуально для сценариев в движении: за рулём, в транспорте, с занятыми руками.
Пустые и частично пустые результаты: что делать интерфейсу
Нулевая выдача - одна из самых болезненных точек в этом флоу. Пользователь сформулировал намерение, ввёл запрос и получил пустой экран. Что произошло, он не знает. Что делать дальше - тоже.
Интерфейс в этот момент обязан дать ответ на три вопроса: почему ничего нет, что можно изменить и куда двигаться дальше.
Пример хорошего пустого состояния: пользователь ищет «ноутбук красный 8GB» в магазине электроники. Ответ системы: «По запросу ничего не найдено. Попробуйте убрать цвет из параметров - мы нашли 12 подходящих ноутбуков без этого уточнения». Здесь есть объяснение, конкретное предложение и готовое действие.
Пример плохого пустого состояния: белый экран с иконкой лупы и надписью «Ничего не найдено». Пользователь не знает, то ли запрос неправильный, то ли товаров нет, то ли система сломалась.
Несколько рабочих решений для нулевой выдачи:
- Предложить похожие запросы или смягчённые варианты. Если точное совпадение не найдено, система может показать результаты по части запроса с пояснением.
- Показать популярные разделы или категории. Это не замена результата, но даёт направление.
- Предложить снять конкретные активные параметры. Укажите именно тот, который обнулил выдачу, - не просто кнопку «Сбросить всё».
- Сохранить строку с запросом видимой. Пользователь должен видеть, что именно он искал, чтобы отредактировать запрос, а не вводить заново.
Частично пустые результаты - ситуация, когда запрос вернул один-два объекта вместо ожидаемого списка. Здесь нужно показать, что система нашла то, что есть, и предложить расширить охват. Иначе пользователь может решить, что поиск сломан.
Чеклист: что проверить перед выпуском сценария ввода и выдачи
Перед тем как сдавать в разработку или выпускать обновление, стоит пройтись по ключевым состояниям. Большинство проблем вскрывается именно на этом этапе, а не на финальном тестировании.
| Состояние | Что проверить | Частая ошибка |
|---|---|---|
| Пустая строка ввода | Плейсхолдер понятен, крестика нет, поле в фокусе открывает историю или подсказки | Крестик отображается в пустом поле без функции |
| Ввод 1-2 символов | Автодополнение ещё не появляется или показывает минимальный полезный список | Длинный список с нерелевантными вариантами с первой буквы |
| Ввод полного запроса | Подсказки сгруппированы, подсвечено совпадение, работает Escape и стрелки | Дубли в подсказках, нет клавиатурной навигации |
| Выдача с результатами | Запрос отображён, количество результатов указано, активные параметры видны | Нет заголовка с запросом, параметры скрыты |
| Применение параметров | Количество результатов обновляется сразу или после явного подтверждения | Смешанное поведение: часть применяется мгновенно, часть требует кнопки |
| Нулевая выдача | Есть объяснение, предложение следующего шага, строка с запросом видна | Пустой экран без инструкций |
| Мобильный вид | Результаты не перекрыты клавиатурой, касаемые зоны достаточного размера | Первый результат под клавиатурой, тонкие поля ввода |
Этот список не заменяет пользовательское тестирование, но позволяет поймать логические дыры ещё до того, как сценарий попадёт к реальным людям. Большинство пунктов проверяются за 15-20 минут самостоятельного прогона по основным состояниям.
Поиск в реальных продуктах: сценарии, которые часто не прорабатывают
Большинство команд уделяют внимание основному сценарию: пользователь вводит запрос, получает список. Но в реальных продуктах есть несколько дополнительных ситуаций, которые остаются за кадром до первого пользовательского тестирования.
Повторный запрос. Пользователь уже вводил что-то раньше и вернулся к строке. Что он видит? Если интерфейс стирает запрос при переходе на карточку и обратно, человек вынужден вводить всё заново. Это не катастрофа для одного шага, но раздражает при нескольких итерациях. Сохраняйте состояние: запрос в строке, активные параметры, позиция прокрутки в списке.
Поиск внутри категории. Пользователь уже находится в разделе «Ноутбуки» и вводит запрос в глобальную строку. Куда его уводит система? Если на общую выдачу без учёта контекста, человек теряет место. Если продукт предполагает работу внутри разделов, стоит предусмотреть локальный вариант ввода или явно показать, в каком охвате ведётся поиск.
Нечёткий ввод и опечатки. Пользователь набрал «ноутбу» или «noutbook». Хорошая система понимает намерение и возвращает релевантный список. Плохая буквально ищет строку и возвращает ноль. Это вопрос бэкенда, но дизайнер должен предусмотреть состояние исправления: «Показаны результаты для «ноутбук». Искать точно «noutbook»?» Такая подсказка возвращает контроль пользователю.
Поиск по длинным запросам. Иногда пользователь вводит целую фразу или вопрос, особенно в базах знаний и справочниках. Длина строки ввода должна позволять это без горизонтальной прокрутки внутри поля. Строка высотой в одну строку с фиксированной шириной 200px обрезает запрос и мешает его редактировать.
Взаимодействие поиска с остальными элементами страницы
Сценарий ввода и просмотра выдачи редко живёт изолированно. Он соседствует с навигацией, категориями, промо-блоками и рекомендациями. И именно это соседство часто создаёт проблемы.
Глобальная строка и навигационные разделы. Если сайт или приложение имеет чёткую иерархию разделов, пользователь выбирает между двумя стратегиями: идти через навигацию или вводить запрос. Интерфейс не должен конкурировать сам с собой. Когда строка слишком заметна на странице каталога, часть пользователей начинает вводить то, что можно было найти через категории, и получает менее точную выдачу. Баланс между навигационным и поисковым доступом к контенту стоит проверять на реальных сценариях.
Рекомендации на странице результатов. Некоторые продукты добавляют в выдачу рекламные позиции или персональные рекомендации рядом с органическими результатами. Если они не отмечены визуально, пользователь не понимает, почему этот объект появился. Доверие к выдаче падает. Любое нерелевантное вхождение должно быть либо обосновано подписью, либо убрано из списка.
Строка в модальном окне или drawer. Иногда поиск встроен внутрь оверлея: например, выбор города, тега или получателя в форме. Поведение внутри такого контейнера отличается от поведения на полноценной странице. Клавиша Escape закрывает оверлей, а не очищает поле. Enter подтверждает выбор, а не отправляет запрос. Эти конфликты нужно прорабатывать отдельно, не копируя поведение глобального варианта.
Признаки хорошо спроектированного сценария ввода и выдачи:
- Пользователь понимает, где он ищет: в каком разделе, с какими активными параметрами.
- Каждое состояние строки (пустая, в процессе ввода, с запросом, с нулевой выдачей) имеет свой визуальный и функциональный ответ.
- При любом переходе внутри сценария состояние не теряется без явного действия пользователя.
- Система объясняет свои ограничения: почему найдено именно это, почему ничего нет, что изменить.
- Параметры и сортировка разделены визуально и логически.
Как оценить качество сценария без пользовательского тестирования
Полноценное тестирование с участниками даёт лучший результат, но не всегда доступно на нужном этапе. Несколько методов, которые позволяют выявить логические дыры самостоятельно.
Прогон по матрице состояний. Составьте таблицу: по горизонтали идут состояния строки (пустая, один символ, слово, длинная фраза, опечатка), по вертикали - контексты (десктоп, мобильный, внутри категории, в модальном окне). Пройдитесь по каждой ячейке и зафиксируйте, что происходит. Незаполненные ячейки - это либо непродуманные состояния, либо предположения, которые ещё не проверены.
Анализ реальных запросов. Если продукт уже работает, посмотрите на список актуальных запросов из аналитики. Какие из них возвращают ноль? Какие возвращают нерелевантный список? Это прямой указатель на то, где сценарий ломается прямо сейчас.
Сравнение с похожими продуктами. Возьмите три-четыре продукта в той же категории и пройдите один и тот же сценарий в каждом. Это не про копирование решений, а про выявление паттернов, к которым пользователь уже привык. Если все конкуренты показывают количество результатов над выдачей, а ваш продукт - нет, это не обязательно плохо, но требует осознанного решения, а не случайного упущения.
Тест с коллегой. Попросите человека, который не проектировал этот сценарий, найти конкретный объект. Не давайте подсказок. Наблюдайте, где он останавливается, что нажимает повторно и что говорит вслух. Даже один такой прогон на десять минут часто выявляет то, что незаметно изнутри.
| Метод оценки | Что выявляет | Когда применять |
|---|---|---|
| Матрица состояний | Непроработанные или конфликтные состояния компонентов | На этапе проектирования, до передачи в разработку |
| Анализ реальных запросов | Запросы без результатов, нерелевантная выдача | Когда продукт уже работает с реальными пользователями |
| Сравнение с конкурентами | Отсутствующие паттерны, к которым привыкла аудитория | При запуске нового сценария или редизайне |
| Быстрый тест с коллегой | Неочевидные точки трения в основном флоу | Перед выпуском, когда полноценное тестирование недоступно |
Поиск в сложных и нестандартных контентных структурах
Большинство материалов о проектировании этого сценария описывают типовой случай: однородный каталог товаров или статей. Но реальные продукты чаще имеют смешанную структуру контента, и это меняет требования к интерфейсу.
Представьте корпоративную платформу, где пользователь может искать одновременно людей, документы, задачи, проекты и события. Единая строка возвращает результаты всех типов. Как показать их без хаоса?
Несколько подходов, которые работают в таких случаях:
- Группировка по типу контента. Результаты разбиваются на секции: «Люди», «Документы», «Задачи». Каждая секция имеет заголовок и ограниченное число строк с возможностью раскрыть весь список. Пользователь сразу видит, в каком типе нашлось больше совпадений.
- Вкладки по типу. Над выдачей располагаются вкладки с количеством результатов: «Всё (47)», «Документы (12)», «Задачи (8)». Это удобно, когда пользователь заранее знает, что ищет конкретный тип объекта.
- Умный приоритет. Система показывает наиболее вероятный тип первым, исходя из контекста. Если пользователь работает с проектом, при вводе имени коллеги вероятнее всего он ищет человека, а не документ с таким словом в названии. Это требует хорошего понимания сценариев использования и нередко обсуждается совместно с командой разработки.
Отдельная ситуация - поиск по атрибутам, а не по тексту. Пользователь хочет найти «все задачи, созданные на прошлой неделе» или «документы с определённым тегом». Строка ввода в таком сценарии не справляется в одиночку. Здесь нужна или структурированная строка с синтаксисом (как в Notion или Linear), или расширенный набор параметров рядом со строкой ввода. Важно, чтобы пользователь понимал, что такая возможность вообще есть: многие не подозревают о расширенных возможностях ввода, если нет визуальной подсказки.
Переходные состояния: что показывать, пока система ищет
Между моментом ввода и появлением результатов есть временной промежуток. Для быстрых запросов он незаметен. Для медленных - критичен. И именно здесь интерфейс часто ничего не делает, хотя должен.
Несколько ситуаций, которые нужно спроектировать отдельно:
Мгновенный ввод с задержкой результатов. Пользователь вводит запрос, система начинает обрабатывать его с небольшой задержкой (debounce). Если в этот момент экран остаётся статичным, человек не понимает, произошло ли что-то. Минимальный ответ - лёгкий индикатор активности в строке или области результатов. Не полноэкранный спиннер, а небольшой сигнал.
Обновление выдачи при изменении параметров. Пользователь нажимает параметр. Список должен обновиться. Если обновление занимает секунду, старые результаты не должны исчезать мгновенно, оставляя пустой экран: это воспринимается как ошибка. Покажите предыдущий список с наложенным полупрозрачным состоянием загрузки, а затем замените его новым.
Прогрессивная загрузка большого списка. Если выдача возвращает сотни результатов, не нужно грузить их все сразу. Покажите первые двадцать и подгружайте по мере прокрутки или по кнопке «Показать ещё». Ключевое требование: пользователь не должен терять место при подгрузке. Если список резко прыгает при появлении новых элементов, это разрушает сканирование.
Пример переходного состояния при обновлении выдачи: пользователь снял один активный параметр. Список на экране слегка затемняется на 0,3-0,5 секунды - достаточно, чтобы сигнализировать об обновлении, но не достаточно долго, чтобы раздражать. Затем появляются новые результаты. Позиция прокрутки при этом сбрасывается в начало списка, потому что набор объектов изменился. Это предсказуемое поведение, которое стоит зафиксировать в спецификации при хендофе.
Разница в требованиях для B2C и B2B продуктов
Сценарий ввода и просмотра выдачи в потребительском приложении и в корпоративном инструменте устроен по разным принципам. Не потому что одно лучше другого, а потому что аудитория, контекст и критерии успеха принципиально отличаются.
| Параметр | B2C продукт | B2B продукт |
|---|---|---|
| Частота использования сценария | Непостоянная, зависит от потребности | Высокая, часто ежедневная |
| Знание предметной области | Низкое, нужны подсказки и автодополнение | Высокое, пользователь знает терминологию |
| Ожидаемая скорость ответа | Мгновенная, любая задержка воспринимается как сбой | Допустима небольшая задержка при сложном запросе |
| Глубина параметров | Минимум, 3-5 базовых значений | Развёрнутый набор, включая диапазоны и комбинированные условия |
| Нулевая выдача | Неожиданна, требует объяснения и альтернативы | Может быть нормой при узких запросах, пользователь к этому готов |
| Сохранение запросов | История последних запросов | Сохранённые шаблоны и именованные подборки |
Главное следствие этого различия: в B2C интерфейс ведёт пользователя за руку, снижает когнитивную нагрузку и скрывает сложность. В B2B - даёт контроль и скорость опытному человеку, который готов разобраться в более богатом наборе возможностей.
Ошибка возникает тогда, когда эти подходы смешиваются: в корпоративном инструменте оставляют только три базовых параметра под предлогом «простоты», а в потребительском приложении добавляют сложный синтаксис запросов, рассчитанный на продвинутых пользователей. Обе ситуации приводят к тому, что реальная аудитория получает не то, что ей нужно.
