Алексей Литвин: подходы к проектированию поиска на сайте или в приложении
В это сложно поверить, но когда-то интернет был настолько маленьким, что многие пользователи помнили адреса сайтов, которые они посещают. Прошло время, информации в сети стало настолько много, что полагаться на память стало невозможно, поэтому появились поисковики – специализированные сервисы, позволяющие найти нужную информацию на просторах глобальной паутины. Задача поиска актуальна не только в масштабах интернета в целом, но и для мало-мальски небольшого сайта, насчитывающего хотя бы тысячу единиц контента. Далее поговорим о принципах организации поиска с точки зрения пользовательского опыта и проектирования интерфейсов.
Начнем с постановки задачи. Есть сайт, приложение или сервис, в котором необходимо что-то найти. Качество поиска пользователь определяет субъективно: насколько просто было решить задачу, настолько и хороша система поиска.
В чем заключаются основные проблемы, связанные с поиском?
1. Количество объектов многократно превышает то количество, которое доступно для последовательного перебора за разумное время. Другими словами, пользователь не в состоянии найти необходимый объект без специализированных подходов.
Например, в базе ЛитРес насчитывается более миллиона книг. Пытаться найти нужную перебором – безумие. Случай, когда объектов относительно немного – от нескольких единиц до нескольких десятков, – мы не рассматриваем, так как при таком объеме речь идет не столько о поиске, сколько о выборе из имеющихся вариантов. Задача выбора подробнее обсуждается в других наших статьях: «4 уровня сложности при работе с интерфейсом» и «Пользовательский выбор при работе с интерфейсом и подходы к его проектированию».
2. Пользователь может не обладать необходимыми знаниями и навыками для того, чтобы найти нужный объект – даже при условии, что он есть в наличии. А ведь его может и не быть.
Например, одна из знаковых книг по архитектуре называется «Язык шаблонов». Согласитесь, что связать ее с архитектурой может быть затруднительно, если вы опираетесь только на название. Хорошая система поиска должна компенсировать это незнание.
Требования к эффективной системе поиска можно сформулировать следующим образом
1. Достижимость результата. Система, так или иначе, позволяет найти нужный объект.
2. Эффективность результата. Она позволяет найти объект за разумное, желательно 0 наименьшее, время.
3. Гибкость в отношении к опыту пользователя. Она позволяет компенсировать недостатки пользователя при работе с ней.
Мы выделяем два крупных подхода к решению задачи поиска. Первый основан на сужении поискового поля, второй – на ускорении перебора.
Рассмотрим примеры сужения поискового поля
Пример 1. Редактор интерфейсов Figma предлагает пользователю большое количество шрифтов на выбор. Для того, чтобы ускорить поиск нужного, они организованы в алфавитном порядке.
Пример 2. В интернет-магазине Ozon пользователь имеет возможность упорядочить товары по возрастанию или убыванию цены. Это позволяет сориентироваться по ресурсам и быстрее найти подходящий вариант.
Пример 3. В мобильном приложении Альфа-банка у пользователя может скопиться большое количество транзакций, однако поиск по ним упрощается за счет того, что они организованы в хронологическом порядке – от недавних к совсем давнишним.
Пример 4. Интернет-магазин DNS объединяет товары в рубрики, каталогизирует их: «бытовая техника», «смартфоны и гаджеты», «ТВ и мультимедиа» и т.д. Это позволяет за несколько переходов уменьшить количество вариантов и упростить дальнейший выбор.
В примерах 1-4 поиск упрощается за счет создания структуры, известной пользователю. В этой формуле есть два важных аспекта. Во-первых, структуру создает дизайнер. Во-вторых, она базируется на знаниях и опыте пользователя. Использование структуры, хорошо известной пользователю, обеспечивает понятность, легкость и в конечном счете успешность процедуры поиска.
Рассмотрим еще несколько примеров, где так же, как и в предыдущих, происходит сужение поискового поля.
Пример 5. Для поиска в Google пользователь вводит запрос в текстовую строку, которая ищется в текстовых документах, которые в свою очередь ранжируются по релевантности относительно созданного запроса.
Пример 6. Изображения в Pinterest связаны с подборками похожих. Система предлагает пользователю варианты, которые похожи на то, что он просматривает.
Пример 7. Shazam ищет музыкальный трек на основании звукового сигнала, принимаемого с микрофона. Пользователь, столкнувшись с неизвестным треком, транслирует его в систему и находит в базе музыкальных композиций.
В примерах 5-7 поисковое поле сужается на основе фрагмента искомого объекта. При этом пользователь либо самостоятельно создает этот фрагмент, либо использует ранее найденный.
Рассмотрим еще несколько примеров, где сужение множества вариантов происходит иначе.
Пример 8. Статьи в Wikipedia связаны между собой прямыми ссылками. При этом пользователи самостоятельно создают эти связи в момент написания или редактирования статей.
Пример 9. Операционная система Windows позволяет создавать системы вложенных папок для хранения документов. Это дает возможность организовывать документы и упрощает поиск.
Пример 10. Чтобы быстрее искать нужный фрагмент на YouTube, автор может разметить видео. Пользователь знакомится с оглавлением и переходит к той части видео, которая его интересует.
В отличие от примеров 1-4, где структура создается дизайнером, в примерах 8-10 право структурирования материала делегируется пользователю. Передача прав снимает ответственность с дизайнера – пользователь создает структуру и отвечает за ее понятность и удобство.
Теперь поговорим о решениях второго типа – ускорение перебора
Они применяются на практике значительно реже, поскольку, в отличие от первого типа, предъявляют требования к единицам контента.
Вариант 1 – уменьшить, сократить объект поиска и вместе с ним уменьшить время, необходимое для принятия решения. В итоге за единицу времени пользователь сможет перебрать большее количество вариантов.
Пример 11. Видеоролики на TikTok ограничены по продолжительности, что позволяет увеличить количество просматриваемых вариантов в единицу времени.
Вариант 2 – поиск через последовательный перебор ускоряется за счет структурирования материала. Информация, необходимая для принятия решения, подается в первую очередь.
Пример 12. На Tinder пользователь просматривает анкеты последовательно в одном направлении. Процедура поиска ускоряется за счет того, что главная информация – фото и краткое описание – подаются сразу, в то время как менее значимые данные скрыты.
Итоги
1. Упрощение поиска проводится по двум направлениям: за счет сокращения количества объектов выбора и за счет увеличения скорости принятия решения.
2. Чтобы сократить количество объектов выбора, субъекты применяют:
• структуру, хорошо известную пользователю;
• ранее найденные или созданные фрагменты и объекты для поиска;
• делегирование пользователю прав создания связей между объектами поиска;
3. Чтобы увеличить скорость принятия решения, субъекты:
• уменьшают, сокращают объект поиска;
• структурируют объект поиска таким образом, чтобы главная информация подавалась в первую очередь.
Связаться с автором: ВКонтакте и по e-mail / aleksey.litwin@gmail.com
