Практическая система информационной архитектуры для мобильных сайтов, которым нужно связать продукты, услуги, редакционный контент, инструменты аккаунта и поддержку.
Информационный запах — это обещание навигационной метки
У большого мобильного сайта есть проблема сжатия. Продукты, услуги, редакционный контент, инструменты аккаунта и поддержка не могут оставаться видимыми одновременно, поэтому интерфейс должен скрывать детали, не скрывая смысл. Информационный запах — набор сигналов, по которым люди предсказывают, что найдут после перехода по ссылке. NN/g подчеркивает ясные labels и контекстные сигналы, потому что пользователи выбирают путь по ожидаемой ценности, а не по внутренней оргструктуре сайта.
На мобильном scent должен переживать меньший viewport и более частое раскрытие. Label вроде «Solutions» может быть допустим, если у бренда хорошо понятная продуктовая архитектура, но слишком расплывчат, если там смешаны консалтинг, software и статьи. «Web services», «Shop skincare» или «Journal» передают более сильную категорийную информацию. Тест прост: может ли новый посетитель предсказать назначение до открытия ветки.
Начинайте с пользовательских задач, а не департаментов. Перечислите главные причины прихода, нужные типы контента и словарь, которым люди пользуются. Затем спроектируйте верхнеуровневые категории, разделяющие задачи с минимальной неоднозначностью. Большому сайту не нужно показывать каждое назначение на первом уровне; ему нужно, чтобы первый уровень облегчал следующий выбор. Получившиеся категории должны быть понятны даже тому, кто пришел глубоко внутрь сайта и не видел главную страницу.
Держите первый уровень коротким, но не загадочным
Мобильная навигация часто ломается из-за чрезмерного сжатия. Меню из 3 абстрактных слов выглядит элегантно, но заставляет пользователей открывать ветки только ради понимания базовых категорий. Противоположная ошибка — стена из 20 ссылок без иерархии. Используйте небольшое число осмысленных верхнеуровневых вариантов, затем раскрывайте хорошо названные группы под ними. Правильное количество задается информационной архитектурой, а не универсальной формулой меню.
Labels должны быть достаточно конкретными, чтобы различать соседей. Если «Services», «Solutions» и «Expertise» ведут к пересекающимся предложениям, пользователю приходится угадывать, какое внутреннее различие имела в виду организация. Объединяйте или переименовывайте категории, пока каждая не несет самостоятельное обещание. Если label обязан использовать брендовый термин, добавьте короткий дескриптор или представительные дочерние ссылки, чтобы незнакомый пользователь мог вывести смысл категории.
Отделяйте глобальные утилиты от основной навигации. Поиск, аккаунт, cart, язык, поддержка и location controls часто выполняют другие функции, чем контентные категории. Визуальная группировка не дает меню превратиться в один неразличимый список. Она также создает предсказуемые места для повторяющихся действий, что особенно важно при переходах между продуктами, услугами и редакционными зонами.
Используйте disclosure-паттерны, сохраняющие контекст
Вложенная мобильная навигация обычно является задачей disclosure: раскрыть следующий уровень, не потеряв родительский. ARIA Authoring Practices W3C описывает disclosure pattern как контрол, который раскрывает и сворачивает скрытый контент, поддерживает Enter или Space и состояние aria-expanded. Визуальный дизайн должен соответствовать этому семантическому поведению. Chevron, выглядящий как раскрытие, не должен неожиданно уводить на другую страницу до того, как пользователь увидит дочерние пункты.
Осознанно решите, является ли parent label также назначением. Если у «Services» есть полезная overview-страница, один вариант — сделать текст ссылкой, а отдельный достаточно большой disclosure-контрол — раскрытием детей. Другой — раскрывать всю строку и ставить «All services» первым дочерним элементом. Смешивание этих паттернов между ветками вызывает паузу, потому что один визуальный сигнал дает разные результаты.
Сохраняйте открытую ветку во время исследования. Если submenu заменяет весь экран, показывайте ясный parent title и back control, а не заставляйте человека помнить, откуда он пришел. Breadcrumb-подобный контекст может быть легким на мобильном, но текущая ветка должна оставаться явной. Каждый шаг в глубину тратит ориентацию; интерфейс обязан окупать эту цену более ясным выбором. Держите название ветки видимым глубже, чтобы back возвращал в именованный контекст, а не в анонимный предыдущий экран.
Управляйте глубиной через представительные варианты и hubs
Глубокие иерархии не плохи сами по себе, если каждый шаг имеет сильный scent. Маршрут из 4 уровней «Shop → Men → Shoes → Running» может быть проще плоского списка из сотен продуктов. Проблемы начинаются, когда промежуточные уровни содержат расплывчатые labels, дублирующиеся категории или только 1 осмысленного ребенка. Аудируйте каждый уровень: сужает ли он задачу и может ли пользователь предсказать следующий слой.
Используйте hub-страницы, когда категория заслуживает объяснения, сравнения или cross-navigation. Hub услуг может представить основные семейства, показать доказательства и вывести популярные задачи; journal hub — темы и свежие материалы; shop hub — сочетать категории с поиском и фильтрами. Hubs снижают давление на меню, которому не нужно содержать каждое конечное назначение, и дают восстанавливаемую точку для переориентации.
Представительные ссылки могут улучшить scent внутри широкой категории. Под «Services» пункты «Web design», «Brand identity» и «Marketing» могут объяснить категорию быстрее подзаголовка. Под «Journal» «Business», «Design» и «Technology» делают то же. Поддерживайте примеры актуальными и не создавайте впечатление, что видимые дети — полный набор, если ветка содержит больше.
Сделайте поиск параллельной навигационной системой
На большом сайте поиск — не аварийный выход. Это полноценный маршрут для пользователей, которые знают название продукта, статьи, идентификатор заказа или термин услуги. Держите его видимым или немедленно доступным из каждого основного мобильного состояния. Поле поиска не должно требовать открытия нескольких уровней меню, особенно на сайтах с большими каталогами или редакционными архивами.
Результатам поиска нужны сигналы типа контента. Один запрос может вернуть продукт, услугу, статью и help-документ с похожими названиями. Маркируйте тип, показывайте достаточно контекста для различения результата и давайте полезные фильтры, если объем это оправдывает. Единый поиск без информации о типе способен увеличить неоднозначность, хотя технически ищет по большей части сайта.
Используйте query logs для улучшения навигации. Частые поиски категории, глубоко спрятанной в меню, могут показывать слабый scent или недостаточную заметность. Zero-result queries могут выявлять словарь, который информационная архитектура не узнает. Данные поиска не говорят автоматически, куда перенести ссылку, но дают доказательства о языке и неудовлетворенных потребностях retrieval, которые должны возвращаться в labels и дизайн категорий.
Показывайте свежесть там, где время меняет ценность
Редакционный и операционный контент имеет измерение, которого часто нет у продуктовых таксономий: время. Статья журнала может быть evergreen или breaking; политика услуги — иметь дату вступления; событие — быть будущим или прошедшим. Навигация и поиск должны показывать свежесть, если она меняет полезность назначения. «Latest», даты публикации и status labels могут давать более сильный scent, чем общая ссылка на тему.
Не позволяйте «Latest» заменять стабильную таксономию. Пользователям часто нужна известная тема независимо от даты публикации, поэтому время должно дополнять категории, а не выравнивать их. Большой сайт может сочетать topic navigation со свежим контентом внутри выбранной темы. Это дает постоянным посетителям быстрый путь к обновлениям, сохраняя предсказуемые маршруты для людей с конкретным предметом в голове.
Архивному поведению нужен путь выхода. Когда человек попадает из поиска на старую статью, покажите актуальные связанные материалы, topic hub и обновленную policy- или product-ссылку, если она есть. Навигационная система выходит за пределы menu icon: связи внутри контента и current-status cues помогают восстановиться из устаревших входных точек без ручного возврата на homepage. Если у старой страницы есть замена, показывайте связь явно, а не рассчитывайте, что посетитель сам выведет свежесть из даты публикации.
Проектируйте пути выхода на каждой глубине
Каждое состояние навигации должно отвечать на 3 вопроса: где я, что здесь можно выбрать и как выйти? Ясный close возвращает к контенту; back — на 1 уровень иерархии; label текущей ветки дает ориентацию; Home или крупный hub позволяют reset, если пользователь пошел не туда. Не полагайтесь на browser Back как единственный механизм восстановления внутри сложного overlay.
По возможности сохраняйте состояние нижележащей страницы. Если пользователь открывает меню посреди длинной статьи, исследует ветку и закрывает ее, возврат в начало статьи создает лишнюю стоимость. То же относится к product filters, поисковым запросам и scroll positions. Навигация должна ощущаться как движение по сайту, а не повторное уничтожение текущего контекста пользователя.
Переходы между доменами или в приложения требуют более сильных сигналов. Если управление аккаунтом, checkout или help открывают отдельную систему, сообщите об этом последовательным брендингом и ясным label назначения. Неожиданная смена среды повреждает информационный запах, потому что обещанный путь перестает быть похож на результат. Сохраняйте маршрут обратно к основному опыту и избегайте тупиковых microsites, которые оставляют мобильного пользователя без выхода.
Тестируйте иерархию до полировки анимации
Card sorting и tree testing могут оценивать информационную архитектуру без отвлечения на визуальный стиль. NN/g описывает card sorting как метод понимания того, как пользователи группируют понятия, а tree testing — как способ проверить, ведут ли labels и иерархия к ожидаемым назначениям. Для большого сайта эти методы способны обнаружить слабые границы категорий до того, как инженерия инвестирует в сложное поведение меню.
Затем тестируйте реализованную навигацию на типовых мобильных устройствах задачами, пересекающими типы контента: найти продукт, сравнить услугу, найти свежую статью, дойти до поддержки, вернуться в предыдущий контекст и найти известный элемент. Включите клавиатуру и assistive technology для disclosure-контролов, focus order и state announcements. Визуально элегантное меню не готово, если его иерархия понятна только pointer-пользователям. По возможности тестируйте с новичками, потому что внутренние команды могут успешно двигаться по памяти организации, а не по чтению labels.
Governance не дает scent деградировать. Новые команды будут просить верхнеуровневые ссылки, кампании — придумывать терминологию, устаревшие разделы — накапливаться. Назначьте владельца навигационной модели, требуйте доказательства для крупных добавлений и периодически пересматривайте search logs, task success и stale branches. Лучшая мобильная навигация большого сайта — не самое неглубокое дерево, а то, где labels, disclosures, поиск и пути выхода сохраняют предсказуемость каждого следующего шага.
Практический чеклист
- Перечислите основные пользовательские задачи и типы контента до названия категорий.
- Проверьте sibling-labels на пересечение и внутренний жаргон.
- Выберите одно последовательное поведение parent-link против disclosure.
- Добавьте сигналы типов контента и фильтры в общий поиск, где это нужно.
- Проверьте старые статьи и deep links на наличие актуальных путей выхода.
- Проведите tree tests и типовые мобильные задачи до финальной визуальной полировки.
Вопросы и ответы
Насколько глубокой может быть мобильная навигация большого сайта?
Универсальной максимальной глубины нет. Более глубокая иерархия может работать хорошо, если каждый уровень ясно сужает задачу пользователя, а labels имеют сильный информационный запах. Плоское меню может быть хуже, если показывает перегруженный список или расплывчатые категории. Аудируйте каждый промежуточный уровень: он должен содержать осмысленный выбор, сохранять контекст родителя и давать ясный путь назад. Убирайте уровни, которые не добавляют ценности для решения, вместо стремления к фиксированному числу.
Нажатие на родительский пункт должно открывать страницу или раскрывать submenu?
Работать может любая модель, но поведение должно быть последовательным и визуально ясным. Если у родителя есть ценная overview-страница, label может вести на нее, а отдельный disclosure-контрол — раскрывать submenu, если обе цели доступны и достаточно велики. Другой вариант — раскрывать всю строку и показывать среди дочерних элементов ссылку «Все». Избегайте одинаковых строк, которые иногда переходят, а иногда раскрываются, потому что пользователь не может предсказать результат одного и того же жеста.
Где должен находиться поиск на большом мобильном сайте?
Поиск следует рассматривать как параллельную навигационную систему и держать видимым или мгновенно доступным из основных состояний страницы и меню. Пользователь, знающий название продукта, статьи или термин поддержки, не должен сначала изучать иерархию. Результаты должны обозначать тип контента и давать достаточно контекста, чтобы различать похожие элементы. Логи поиска также могут показывать слабые labels меню, глубоко спрятанные назначения и пробелы в словаре, которые требуют изменений информационной архитектуры.