Все статьи
24 сентября 2026 г.9 мин чтения

Поиск в мобильном приложении: как оформить запрос, подсказки и результаты

Поиск в мобильном приложении: как оформить запрос, подсказки и результаты

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

Сначала разделите четыре состояния поиска

Экран поиска не сводится к строке с лупой. В нём есть как минимум четыре разных состояния: пустой запрос, ввод, список предложений и выдача результатов. Иногда добавляются загрузка, ошибка сети, отсутствие совпадений и поиск внутри выбранного раздела. У каждого состояния свой смысл, поэтому одинаковая заглушка или один стиль строки для всего экрана скрывает важные переходы.

Перед отрисовкой типографики зафиксируйте, какое событие меняет состояние: фокус в поле, первый символ, пауза при вводе, выбор предложения, отправка клавиатурой или нажатие кнопки. В макете отметьте также, остаётся ли поле закреплённым при прокрутке результатов и куда пользователь возвращается после открытия найденной карточки. Это помогает решить, что должно иметь самый заметный текстовый уровень.

Оформите поле так, чтобы запрос оставался главным

В строке поиска текст запроса — рабочее содержимое, а подсказка внутри пустого поля — только объяснение. Например, «Название, адрес или номер заказа» сообщает предмет поиска лучше, чем одно «Поиск». Как только пользователь начинает вводить фразу, placeholder должен уступить место запросу; не дублируйте его отдельной серой подписью поверх текста.

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

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

У поля должны быть различимы обычное, активное и недоступное состояния. Активность можно показать курсором, контуром и сохранением достаточного контраста; нельзя полагаться только на едва заметный оттенок фона. Не превращайте размер букв в единственный сигнал фокуса: он должен оставаться стабильным, чтобы интерфейс не дёргался при нажатии.

Покажите подсказку как предложение, а не как уже готовую выдачу

Подсказка помогает сформулировать или уточнить запрос до показа результатов. Это может быть недавняя фраза, вариант завершения, исправление опечатки или конкретный объект из каталога. Эти варианты отвечают на разные вопросы, поэтому добавьте короткий контекст там, где один текст двусмысленен: например, вторую строку с типом объекта или путь категории.

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

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

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

Соберите результаты для быстрого сравнения

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

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

Подсветка совпадения полезна, когда она показывает место совпадения в названии или фрагменте, но не должна менять форму букв, перекрывать диакритику или ломать кириллические пары. Используйте выделение фона или начертания с достаточной контрастностью. Сначала проверьте реальные строки вроде «Ёлочные игрушки» и смешанных кодов «AB-42/ёж», а не только латинское слово из макета.

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

Продумайте загрузку, пустой результат и ошибку

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

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

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

Проверьте строку и выдачу на реальных ограничениях

Один скриншот с коротким словом не проверяет поиск. Составьте небольшую тестовую коллекцию запросов и результатов: короткий и длинный запрос, строка только на кириллице, имя с «Ё», смешанный буквенно-цифровой код, длинное название, одинаковые первые слова и отсутствие совпадений. Добавьте запрос с пробелами, дефисом и пунктуацией, если такие данные действительно ищут в вашем продукте.

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

Проверьте также смену ориентации или размера окна, если продукт поддерживает такие режимы. После возврата из карточки поиска поле и прокрутка должны вести себя предсказуемо: сброс допустим, если это явно следует сценарию, но случайная потеря фразы заставляет вводить запрос снова. Отдельно проверьте клавиатуру: она не должна перекрывать поле, выбранное предложение или единственную важную кнопку.

Последовательность работы над экраном

  1. Составьте карту состояний и отметьте триггер перехода для каждого: фокус, ввод, ожидание, выдача, пустой результат, ошибка.
  2. Подготовьте реальные строки из предметной области, включая длинные и похожие названия, а не только lorem ipsum.
  3. Разведите типографические роли поля, заголовка предложения, его контекста и результата; закрепите их в макете.
  4. Проверьте переносы, обрезку и клавиатуру на самом узком поддерживаемом размере экрана.
  5. Пройдите сценарий целиком: открыть поиск, ввести фразу, уточнить её, выбрать предложение, открыть результат и вернуться назад.
  6. Попросите человека, не участвовавшего в проектировании, найти конкретный объект без устных подсказок; фиксируйте момент, где он сомневается.

Частые ошибки в типографике поиска

  • Использовать placeholder как единственное название области, а после ввода терять информацию о том, где выполняется поиск.
  • Показывать предложения и готовые результаты одинаковыми строками, хотя выбор ведёт к разным действиям.
  • Сжимать поле ради декоративных иконок, оставляя слишком мало места для запроса и курсора.
  • Обрезать заголовки результатов до одинакового начала и убирать единственный признак, который различает объекты.
  • Обозначать активное состояние только цветом или менять кегль при фокусе, из-за чего содержимое скачет.
  • Подставлять искусственные короткие примеры и обнаруживать обрезку длинного текста уже после релиза.
  • Показывать недавние запросы без ясного управления историей или использовать их в чувствительном сценарии.

Короткий чек-лист перед выпуском

  • Назначение поиска и его текущая область видны до и после ввода запроса.
  • Поле сохраняет введённую фразу и не теряет курсор при длинном запросе.
  • Подсказку можно отличить от результата по роли и по ожидаемому действию.
  • Заголовок и вспомогательная строка результата помогают выбрать нужный объект.
  • Пустой результат, загрузка и ошибка сообщают разные ситуации и дают следующий шаг.
  • Длинные названия, кириллица, «Ё», цифры и смешанные коды проверены на устройстве.
  • История поиска не раскрывает лишнее и управляется пользователем.

Вопросы и ответы

Нужно ли запускать поиск после каждого символа?

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

Стоит ли показывать placeholder, если над полем уже есть заголовок?

Заголовок экрана сообщает, где находится пользователь, а placeholder может объяснить, какие данные можно искать. Если оба текста повторяют «Поиск», один из них не приносит пользы. Сохраните краткую подсказку только тогда, когда она уточняет область или формат запроса.

Как оформить недавние запросы на стартовом экране?

Отделите историю от результатов и подпишите её как недавние запросы. Дайте удалить отдельную строку или очистить историю, а чувствительные термины не показывайте без понятной причины. Каждая строка должна оставаться читаемой и не обрезаться так, что теряет смысл.

Можно ли выделять совпавшую часть жирным?

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

Что показывать вместо «ничего не найдено»?

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

Как проверить, что типографика поиска работает?

Пройдите сценарий на реальном устройстве с длинными и короткими запросами, подсказками разных типов, длинными названиями и пустой выдачей. Проверьте поле с открытой клавиатурой, переход к результату и возврат. Отдельно попросите нового пользователя найти заданный объект без объяснений.

Какие системные рекомендации учитывать для поиска?

Apple советует ясно обозначать область поиска, давать полезные предложения и упрощать просмотр результатов; рекомендации доступны в Human Interface Guidelines. Документация Android описывает SearchView и предложения при вводе в руководстве по созданию интерфейса поиска.

Итог: поиск должен помогать сравнить, а не угадывать

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