Информационная архитектура: структура, навигация, именование

Вы уже знаете, кому и зачем нужен продукт: как это выясняют — в исследованиях пользователей, как фиксируют — в персонах и JTBD. Дальше идёт вопрос, который кажется скучным ровно до первого провала: из чего продукт состоит с точки зрения человека и как он это найдёт. Это и есть информационная архитектура — самый дешёвый в изменении и самый дорогой в ошибке слой проектирования. Ошибка в цвете кнопки стоит полчаса; ошибка в структуре стоит года, потому что прорастает в URL, в роутинг, в названия таблиц, в тексты поддержки, в закладки пользователей, в интеграции, в поисковую выдачу и в привычки сотрудников. ИА — не «нарисовать менюшку», а инженерная работа: модель предметной области, вынесенная наружу так, чтобы её мог держать в голове человек, который не читал вашу документацию и не хочет.

1. Что такое информационная архитектура

Классическое определение из «полярного медведя» — книги Розенфельда, Морвилля и Арэнго Information Architecture: For the Web and Beyond — описывает ИА как совокупность четырёх систем: организации, обозначения, навигации и поиска. Разделение не бюрократическое: эти системы ломаются по-разному и чинятся по-разному. Жалоба «люди не находят раздел» может быть дефектом любой из четырёх, и лечение в каждом случае своё.

Аналогия для инженера. ИА относится к интерфейсу примерно так же, как схема данных к приложению: сущности, связи, ограничения — и от совпадения модели с реальностью домена зависит, будет ли каждая фича даваться легко или через боль. Разница в том, что схему БД нормализуют по учебнику, а ИА — по головам пользователей, которые третьей нормальной форме не подчиняются.

Признаки, что ИА сломана, видны без исследований: поддержка регулярно диктует маршрут словами («Настройки → Организация → Дополнительно»); завёлся раздел «Разное»/«Прочее»/«Инструменты» — официальная свалка неотнесённого; доля сессий с поиском растёт при неизменном объёме контента; одна сущность зовётся тремя словами на трёх экранах; каждый релиз начинается со спора «а куда это в меню».

2. Как человек ищет: информационный запах

Основание для дальнейших решений — теория информационного поиска (Information Foraging) Питера Пирролли и Стюарта Карда из Xerox PARC. Идея простая и жестокая: человек в интерфейсе ведёт себя как животное в поисках пищи. Он не строит модель вашей структуры — он идёт по запаху (information scent), то есть по тому, насколько надпись похожа на его цель. Пахнет — идёт. Не пахнет — уходит туда, где пахнет сильнее, или бросает.

Отсюда три следствия, ломающих интуицию новичка. Меню не читают целиком — сканируют до первой «достаточно похожей» надписи и кликают, поэтому пункт, стоящий выше и звучащий похоже, крадёт трафик у правильного. Решение принимают по надписи, а не по содержимому — идеальный раздел с плохим названием невидим; ссылка это обещание, а страница его подтверждает или нет. Возврат дорог психологически — два-три неверных клика, и человек решает, что функции в продукте нет. Отсюда классическое «у вас нет выгрузки», хотя выгрузка есть два года.

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

3. Разбор: «пользователь не нашёл кнопку»

B2B-продукт, таблица заказов. Задача: выгрузить отфильтрованный список в CSV. Кнопка «Экспорт» существует и живёт в шапке приложения, в меню «Ещё» рядом с «Импорт» и «Настройки интеграций». На тесте шесть человек из восьми не нашли её за две минуты, четверо сказали «у вас нет выгрузки». Соблазн — «сделать заметнее»: покрасить, увеличить, добавить иконку. Обычно это лечение симптома; сначала диагноз, а у ненайденного элемента ровно четыре класса причин, и чинятся они по-разному.

В нашем случае люди смотрели в таблицу: искали панель действий над списком, чекбоксы, контекстное меню строки. Это причина 1 — перепутан слой: экспорт относится к текущему представлению данных, а не к приложению целиком. Дополнительно работала причина 2: половина участников называла задачу «выгрузить в эксель», а не «экспорт». Починка: кнопка «Выгрузить в Excel» над таблицей, справа от фильтров, с подписью, отражающей фильтр («Выгрузить 128 заказов»); пункт в «Ещё» оставили — второй вход не вредит, если названия совпадают. Красить ничего не пришлось.

Мораль шире случая. Порядок диагностики — слой, потом название, потом визуальный вес. Обратный порядок («давайте поярче») — самый частый способ потратить спринт и не сдвинуть метрику. Как устроен сам визуальный вес — в основах визуального дизайна, но визуалом чинится только третья причина из четырёх.

4. Схемы организации: чем можно резать мир

Способов разложить контент конечное число, и выбор между ними — это выбор между разными типами задач пользователя.

Первые две — точные схемы: спорных случаев не бывает. Остальные — неоднозначные: полезнее (человек чаще ищет «что-то про доставку», чем «слово на букву Д»), но требуют решений и проверки на людях. Разбор: навигация по аудиториям. «Физлицам / Бизнесу / Партнёрам» — популярный и коварный приём: работает, только если человек мгновенно относит себя к группе. Индивидуальный предприниматель, покупающий тариф на себя, зависает — он физлицо или бизнес? — и цена ошибки высока, потому что вся структура ниже разъезжается. Резать по аудитории можно при институционально жёстких ролях и лучше не единственным способом: оставьте объекты доступными из обеих веток.

Структура — второе, независимое измерение. Иерархия совпадает с бытовым опытом «папки внутри папок» и даёт ясную ориентацию, но кладёт объект ровно в одно место, а реальность так не устроена. Фасеты описывают объект несколькими независимыми признаками, и «место» вычисляется фильтрами: для каталогов это почти всегда правильнее дерева, потому что «насосы + производитель X + в наличии» не требует, чтобы кто-то заранее придумал такую папку. Сеть — связи между объектами («похожие», «связанные заявки») — доводит туда, куда дерево дороги не проложило. Последовательность — шаги мастера с намеренно ограниченной свободой (потоки). Живой продукт всегда гибрид; ошибка — выражать всё одной иерархией и потом воевать с реальностью.

5. Контент-модель раньше меню

Самая частая причина неисправимого меню — его начали рисовать до того, как договорились, что вообще является объектом в этом продукте. Меню — проекция модели; кривую модель не спасут никакие названия. Поэтому первый артефакт ИА — не карта экранов, а сущности и связи в терминах пользователя (механика моделирования — в системном анализе).

Навигация выводится отсюда почти механически, но не единственным образом — и здесь начинается настоящая работа. У сервисной компании три кандидата в корневые сущности, и от выбора зависит всё меню: диспетчер живёт заявками (список открытых по SLA), менеджер — клиентами (карточка со всей историей), инженер — выездами на сегодня (маршрут, без клиентов и объектов вовсе). Правильный ответ обычно не «выбрать одну», а «сделать три точки входа в один набор объектов»: три стартовых экрана по роли, но не три параллельных мира. Чего делать нельзя — строить меню по внутренним таблицам.

Разбор: слово «Проект» означает три разных вещи. Продажи называли проектом сделку, производство — набор работ, финансы — бюджетную единицу. В интерфейсе появился раздел «Проекты», который каждому второму показывал «не то». Починка оказалась не в интерфейсе: развели понятия и назвали разными словами — «Сделка», «Работы», «Бюджет», — после чего меню собралось само. Это типично: половина проблем ИА решается словарём, а не структурой.

6. Глубина против ширины: где наука, а где предание

Классический спор: пять пунктов с четырьмя уровнями вложенности или пятнадцать с одним? Здесь есть настоящие исследования и очень живучий миф.

Миф — «магическое число 7±2». Работа Джорджа Миллера The Magical Number Seven, Plus or Minus Two (1956) про объём кратковременной памяти при удержании элементов в голове. Меню на экране удерживать не нужно: оно перед глазами, работает узнавание, а не воспроизведение, и ограничение «не больше семи пунктов» из этой работы не следует. Работающее ограничение другое: длинный список нужно группировать и давать группам заголовки, иначе сканирование становится линейным и дорогим.

Что действительно измеряли. Компромисс глубины и ширины изучают с начала 1980-х (Кигер, 1984; Ландауэр и Накамура), а из веб-эпохи — Ларсон и Червински, Web page design: implications of memory, structure and scent (CHI ‘98). Результат устойчив: при равном числе конечных целей широкая мелкая структура выигрывает у узкой глубокой; в этой работе 8×8×8 проиграла и по времени, и по ошибкам вариантам 16×32 и 32×16.

Механика видна из картинки: прочитать пункт дёшево, а принять решение дорого — и не только по времени. Каждое решение это независимая возможность уйти не в ту ветку, и вероятности перемножаются: при скромных 90% верных выборов четыре уровня дают 66% дошедших, два уровня — 81%. Плюс цена ошибки: откатиться на уровень вверх — один клик, а понять, что ошибся три уровня назад, почти невозможно, потому что запах в глубине уже слабый.

Но не наоборот. «Плоско любой ценой» — тоже ошибка: сорок пунктов без группировки сканируются хуже, чем два уровня по семь, и чем площе структура, тем больше нагрузки ложится на названия — подсказки от родительского раздела больше нет. Рабочие ориентиры: глобальная навигация 4–7 пунктов, типичная цель не дальше 3 шагов от входа, локальная навигация — сколько нужно, но группами по 5–9 с заголовками; если пунктов больше пятнадцати, добавьте поиск по списку, а не ещё один уровень. «Правило трёх кликов» как закон — миф: люди спокойно делают пять кликов, если каждый подтверждает, что они идут верно; считать надо не клики, а уверенность на каждом шаге. И про закон Хика честно: он про выбор среди известных равнозначных вариантов, а сканирование незнакомых надписей — другая задача, поэтому «сократить меню до пяти пунктов» само по себе не улучшение; улучшение — сделать так, чтобы нужный пункт находился с первого взгляда.

7. Разбор: форма, в которой невозможно разобраться

ИА живёт не только в меню — внутри одного экрана она тоже есть. Форма заведения клиента: 38 полей одним вертикальным списком, три обязательных где-то в середине, сверху «Тип контрагента», от которого зависят 12 полей ниже, но зависимость нигде не выражена. Заполняют по 9 минут, треть бросает. Дефекты здесь структурные, не визуальные:

1. Нет группировки по смыслу. 38 полей — это на самом деле пять блоков: кто это, как связаться, реквизиты, условия работы, служебное. Без блоков человек не оценивает прогресс и не понимает, где находится, — та же потеря ориентации, что и в глубоком меню.
2. Порядок не совпадает с источником. Люди переписывают данные с карточки контрагента или из письма; при другом порядке каждое поле — отдельный поиск глазами по бумажке. Порядок полей повторяет порядок в источнике, а не структуру вашей таблицы.
3. Зависимости скрыты. Управляющее поле выглядит равным среди прочих; оно должно стоять первым и визуально отделяться, а зависимые — появляться после выбора.
4. Обязательность непредсказуема. О трёх обязательных полях среди 38 человек узнаёт при отправке. Это не про валидацию, а про структуру: обязательный минимум — первым блоком, с честной подписью «этого достаточно, чтобы сохранить».
5. Всё одного уровня важности. «ИНН» и «Предпочтительный способ связи» выглядят одинаково значимыми; иерархия внутри формы — такой же инструмент ИА, как уровни меню.

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

8. Именование: самая недооценённая часть работы

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

1. Слова пользователя, а не компании — источник берётся из интервью и тикетов поддержки (исследования): если в поддержку пишут «выгрузка», раздел не может называться «Экспорт данных».
2. Конкретность важнее элегантности: «Управление ресурсами» не значит ничего, «Сотрудники и доступы» значит.
3. Параллельность форм: внутри уровня один грамматический тип — либо всё существительные, либо всё глаголы; смесь «Заказы / Оформить возврат / О компании» заставляет переключать режим чтения.
4. Одно понятие — одно слово везде: если сущность «заявка», она не «тикет» в другом углу продукта; словарь пригодится и в коде, и в API, и в текстах поддержки.
5. Различимость важнее правильности: «Отчёты», «Аналитика», «Статистика» рядом — гарантированный провал, каждое слово законно, но выбрать невозможно. Сюда же — никакого внутреннего жаргона: «Раздел BPM-2» понятен только тем, кто его строил.
6. Иконка без подписи — потеря запаха: универсально узнаются пять-семь (дом, лупа, корзина, шестерёнка, крестик, бургер, стрелка назад), остальное — «загадочное мясо» и требует текста.

Тест названия за минуту. Покажите человеку только список названий, без содержимого: «что, по-вашему, внутри каждого?» Если ответы расходятся или начинаются с «ну, наверное…» — название не работает. Это дешёвая версия tree testing из раздела 11. И про локализацию: немецкий и французский дают +25–35% длины к русскому, тюркские языки — другую грамматику падежей в шаблонах, так что для многоязычного продукта длина названий не эстетический вопрос, а инженерное ограничение вёрстки, и обсуждать его надо до, а не после (микрокопия).

9. Навигация как система из шести слоёв

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

Глобальная отвечает на «что здесь вообще есть» и обязана быть одинаковой везде — это требование не только удобства, но и доступности (3.2.3 Consistent Navigation); складом для «важного на этой неделе» она быть не может. Локальная держит всю глубину раздела. Контекстная ведёт по фактическим связям модели и часто полезнее меню. Служебная (поиск, профиль, помощь, выход) держится отдельно, иначе предметные разделы тонут среди сервисных. Ориентиры — крошки, заголовок, активный пункт: три независимых сигнала об одном месте нужны потому, что на страницу попадают из письма, из поиска и из закладки, а не только из меню. Подвал и карта сайта — страховка и заодно выполнение 2.4.5 Multiple Ways: к странице должно вести больше одного пути. Что выносить наверх, решается по двум осям — частота обращения и цена «не найти»: редкое, но критичное («закрыть счёт», «выгрузить всё перед аудитом») не должно жить в шапке, но обязано находиться поиском и лежать в карте сайта.

Крошки полезны от трёх уровней глубины и когда на страницу приходят снаружи; по рекомендациям NN/g они дополняют основную навигацию и показывают путь по структуре, а не историю переходов; на плоском сайте это шум. Табы хороши для 2–5 равнозначных представлений одного объекта и плохи как основная навигация: не масштабируются и не показывают глубину. Сайдбар держит 15–30 сгруппированных пунктов и даёт постоянный ориентир ценой ширины. Мега-меню экономит шаг решения в больших каталогах, но у него сложное клавиатурное поведение — здесь легко испортить доступность. На узком экране гамбургер прячет структуру, и скрытое используется заметно реже (NN/g о гамбургерах); практика — 3–5 самых частых разделов видимыми в нижней панели, остальное в «Ещё» (мобильные паттерны).

10. Поиск — часть архитектуры, а не замена ей

«Не решили, куда положить, — пусть ищут поиском» — позиция популярная и вредная: поиск требует, чтобы человек знал слово, а в незнакомом домене слова у него нет. Поиск дополняет структуру в трёх сценариях: много однотипных объектов, известный элемент («заявка №4471») и повторный поиск того, что человек уже видел. Рабочий поиск требует понятной области (искать везде или в разделе — разные задачи), фасетов после запроса (основной способ навигации в больших каталогах; фундаментальный разбор — у Марти Хёрст в открытой Search User Interfaces), словаря синонимов и опечаток («выгрузка = экспорт = скачать csv» — это тот же словарь ИА) и пустого результата как отдельного экрана: что искали, почему пусто, что попробовать, ссылки на разделы (состояния).

Логи поиска — бесплатное исследование ИА, которое почти никто не читает. Топ-запросы показывают, чего не хватает в меню: «выгрузка» в топ-10 — это заявка на пункт навигации. Нулевые результаты показывают дыры в лексике или в контенте. Рост доли сессий с поиском при неизменном объёме — сигнал, что структура перестала работать (метрики UX).

11. Как проверить структуру до того, как её напишут в коде

Хорошая новость: ИА проверяется дешевле всего остального в дизайне — тестировать можно голое дерево, без макетов.

Карточная сортировка. Участник группирует карточки с названиями объектов так, как ему кажется естественным: открытая (группы придумывает он — даёт лексику и логику), закрытая (группы заданы вами — проверяет гипотезу), модифицированная (можно добавлять свои). Метод даёт словарь пользователя, понимание, что в головах лежит рядом, и карточки-«бродяги», которые каждый кладёт по-своему — верный признак, что объект надо переименовать или разрезать. Чего метод не даёт — готового меню: усреднённая структура по двадцати участникам обычно не годится никому. Ориентир по выборке из работы Тома Таллиса и Ларри Вуда «How Many Users Are Enough for a Card-Sorting Study?» (UPA, 2004): корреляция с «полной» выборкой выходит на плато примерно на 20–30 участниках, для качественных выводов хватает 12–15. Практика метода — у Донны Спенсер в Card Sorting, краткое введение — у NN/g.

Tree testing (обратная сортировка) — самый недооценённый метод. Участнику показывают только текстовое дерево, без графики и без поиска, и дают задачу: «где вы будете искать, как отменить автоплатёж?» Никакой визуал не маскирует проблемы структуры и названий, а на выходе — количественные метрики, сравнимые между версиями.

Про первый клик стоит сказать отдельно: многократно воспроизводится закономерность — при верном первом клике задача завершается успешно в разы чаще, чем при ошибочном. Отсюда практика тестов первого клика на статичной картинке (инструменты вроде Chalkmark) — дешёвый способ узнать, куда люди пойдут, ещё до прототипа. Введение в метод — у NN/g, готовый инструмент — Treejack. По выборке: для качественных находок хватает 8–12 человек на роль, для сравнения версий по числам — от 30 на вариант; числа не закон, а следствие того, какой размер эффекта вы хотите различать (юзабилити-тестирование).

12. Доступность на этапе структуры

Подробно тема разобрана в треке accessibility, а внутри нашего трека — в доступности на этапе дизайна. Здесь важно то, что решается именно на уровне ИА и потом не чинится ни цветом, ни атрибутами:

• Порядок в разметке = порядок обхода. Клавиатура и скринридер идут по порядку документа; если «главный» блок визуально сверху, а в разметке в конце — это дефект структуры, и дизайнер обязан указать порядок чтения явно, когда он неочевиден (клавиатура и фокус).
• Заголовки — это ИА страницы. Иерархия h1–h6 не оформление, а оглавление, по которому прыгает скринридер; «заголовок ради размера шрифта» ломает навигацию (2.4.6).
• Ориентиры (landmarks). Шапка, основная навигация, содержимое, подвал должны быть обозначены как области — иначе недоступна навигация по регионам (семантический фундамент).
• Пропуск блоков. Ссылка «к основному содержимому» — требование 2.4.1; без неё каждый переход начинается с тридцати табов по меню.
• Название вместо позиции. «Кнопка справа вверху» — не название: у каждого навигационного элемента должно быть текстовое имя, по которому его можно назвать голосом и найти в списке ссылок.

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

13. ИА в коде и передача в разработку

URL — публичное воплощение ИА и самый долгоживущий её артефакт. Его копируют в чаты, кладут в закладки, вставляют в документацию и тикеты. Отсюда требования, знакомые по Cool URIs don’t change Тима Бернерса-Ли и рекомендациям Google: человекочитаемые сегменты, отражённая иерархия, отсутствие внутренних идентификаторов там, где без них можно, стабильность. Реструктуризация — это миграция: команда перегруппировала документацию, поменяв все пути, и выкатила без редиректов — сломанные закладки у поддержки, мёртвые ссылки в двухстах тикетах и в письмах, падение органического трафика на месяцы, битые ссылки внутри самого продукта. Правильный порядок: карта «старый путь → новый путь», постоянные редиректы 301, обновление sitemap.xml, проверка внутренних ссылок, мониторинг 404 после релиза. Права и роли — тоже архитектурное решение, а не визуальное: скрывать то, что роль не получит никогда, и показывать с замком то, что можно получить по тарифу или по запросу. Инженерная сторона — в роутинге и рендеринге и HTML-семантике.

Что передаётся в разработку. «Отдал макет» здесь не работает совсем: ИА — это правила, а не картинка. Нужны семь вещей: карта структуры — дерево разделов с уровнями, а не набор экранов; словарь названий с каноническим именем каждой сущности и запрещёнными синонимами; карта URL и правила формирования путей; правила слоёв и критерий добавления нового пункта; состояния навигационных элементов — активный, посещённый, недоступный, со счётчиком; поведение на узких экранах — что схлопывается и в каком порядке; матрица «роль → видимые разделы».

Почему «пиксель в пиксель» — плохая цель. Формулировка выглядит как забота о качестве, но смещает и внимание, и конфликт. Она проверяет не то: структура проверяется прохождением задач, а не координатами — сайдбар, съехавший на 4 px, не мешает никому, а пункт, названный не тем словом, стоит денег. Она делает разработку исполнителем, а не участником, и вы теряете самый ценный вклад: знание реальных данных, ограничений платформы и цены решения. И она физически недостижима: разные шрифты, плотность пикселей, масштаб системы, длина переводов и пользовательские настройки размера текста делают точное совпадение невозможным без вреда доступности. Вместо неё — контракт решений: что обязано сохраниться (структура, названия, порядок, приоритеты, состояния, порядок фокуса), что может отличаться (отступы, реализация компонента, анимация) и как проверяем (проходят ли пять задач, совпадает ли дерево, работает ли клавиатура). Разработчик, которому объяснили задачу пункта меню, обычно сам предлагает лучшее решение — он видит, что данные приходят порциями, что счётчик считается дорого, что маршрут нельзя вложить.

Продолжение темы — в передаче в разработку и карьере, а общий язык кода и дизайна — в дизайн-системах.

14. Как ИА гниёт и что с этим делать

Структуры не ломаются одномоментно — они деградируют по одному пункту за релиз, и каждый шаг выглядит разумно: раздел под новую команду, «потому что иначе его не найдут»; пункт «Инструменты» для того, что не влезло; два раздела, частично дублирующие друг друга; «Разное» на 40% контента; выросшая вдвое доля поиска; и наконец редизайн, который переносит ту же структуру в новые цвета. Последний шаг — самый дорогой: перекрашивание симптомов без работы с причиной.

Противоядие — немного управления. У структуры есть владелец — один человек, который говорит «нет», иначе меню растёт как папка «Загрузки». Правило добавления: новый пункт верхнего уровня появляется только вместе с ответом на вопрос «что мы отсюда убираем и почему»; нет ответа — пункт идёт внутрь раздела. Инвентаризация раз в полгода: таблица «узел — назначение — посещаемость — владелец — решение»; обычно 20–30% узлов мёртвые, и удалить их — самый дешёвый способ улучшить ИА. «Разное» — это баг-репорт: значит, правила отнесения не сформулированы. Регрессионный тест структуры: тот же набор задач в tree testing раз в полгода — success rate можно поставить рядом с продуктовыми метриками (продуктовая аналитика).

Про закон Конвея. Мелвин Конвей заметил, что системы копируют структуру коммуникаций организаций, которые их строят. В интерфейсах это видно невооружённым глазом: меню банка, где «Платежи», «Переводы» и «Автоплатежи» — три раздела, потому что это три команды с тремя бэкендами, хотя для человека это одно действие «отправить деньги». ИА — то место, где на закон Конвея нужно сознательно идти против: структура интерфейса отражает модель пользователя, а не оргструктуру. Политически трудно и почти всегда правильно.

15. Где закономерности, где контекст, а где чистый вкус

Честность в этом вопросе отличает инженерный подход от «насмотренности». Не всё в дизайне доказуемо, но и не всё — дело вкуса, и путать эти категории вредно в обе стороны.

Дисциплина простая: спорьте про первые две колонки, и для второй назначайте проверку, а не победителя по громкости. Фраза «давай проверим на пяти задачах в tree testing» закрывает 90% совещаний, которые иначе превращаются в обмен вкусами. И обратное: «доказывать исследованием» вопрос из третьей колонки — трата денег; решите волевым порядком, зафиксируйте и идите дальше. Сборники вроде Laws of UX — полезный словарь для разговора, но многие «законы» это обобщения из узких лабораторных условий; ссылаться на них как на доказательство про конкретное меню — то же самое, что ссылаться на Big-O, обсуждая, почему тормозит конкретный запрос.

16. Типичные ошибки

• Меню из оргструктуры или из схемы БД: «Модуль CRM», «Справочники», «Реестры»; раздел «Разное» — признание, что правил отнесения нет.
• Аудиторная навигация там, где человек не уверен в своей группе; глубина ради «чистого» верхнего уровня: пять пунктов в шапке и четыре уровня под ними — не победа.
• Иконка без подписи в основной навигации; разные слова для одной сущности на разных экранах.
• Действие над объектом в глобальном меню — самый частый способ спрятать функцию; поиск как оправдание плохой структуры.
• Переезд без редиректов — сломанные закладки, тикеты, письма, органический трафик.
• Проверка структуры на красивом макете, где визуальная иерархия маскирует дефекты названий: проверять надо голым деревом.
• Усреднённая структура по результатам карточной сортировки, не подходящая ни одной роли.
• Редизайн вместо реструктуризации: старая ИА в новых цветах; «пиксель в пиксель» как критерий приёмки вместо прохождения задач.

Мини-итог и чеклист

ИА — это четыре системы: организация, обозначение, навигация, поиск. Человек идёт по продукту по запаху, сканируя надписи до первой похожей на задачу, поэтому названия важнее геометрии, а слои навигации важнее яркости. Ненайденный элемент диагностируется по порядку: слой → название → визуальный вес. Структура выводится из модели предметной области в словах пользователя, а не из схемы БД и не из оргструктуры. При равном числе целей широкое мелкое дерево обычно выигрывает у узкого глубокого, но плоскость перекладывает ответственность на именование. Всё это дёшево проверяется карточной сортировкой, tree testing и тестом первого клика — до единого макета. И передаётся дальше не картинкой, а контрактом решений.

Перед тем как отдавать структуру в работу, проверьте:

• каждый раздел верхнего уровня объясняется задачей пользователя, а не внутренней командой; нет разделов «Разное», «Прочее», «Инструменты»;
• каждое название взято из речи пользователей, различимо от соседних, и одна сущность зовётся одним словом во всём продукте;
• типичная задача достигается не более чем за 3 шага, и каждый шаг подтверждает направление;
• у каждого элемента определён слой: глобальный, локальный, контекстный, служебный;
• на любой странице видно «вы здесь» тремя сигналами: крошки, заголовок, активный пункт;
• к важным страницам ведёт больше одного пути: меню, поиск, карта сайта;
• дерево прошло tree testing на пяти реальных задачах с success rate выше 70%;
• размечены порядок чтения, области и ссылка «к содержимому»;
• составлены карта URL и список редиректов для всего, что переезжает;
• описана матрица «роль → видимые разделы» и назначен владелец структуры с правилом добавления новых пунктов.

Источники

• L. Rosenfeld, P. Morville, J. Arango. Information Architecture: For the Web and Beyond, 4-е изд., O’Reilly — oreilly.com; A. Covert. How to Make Sense of Any Mess — howtomakesenseofanymess.com.
• D. Spencer. Card Sorting: Designing Usable Categories, Rosenfeld Media — rosenfeldmedia.com.
• P. Pirolli, S. Card. Information Foraging // Psychological Review, 1999; изложение — NN/g: Information Scent.
• K. Larson, M. Czerwinski. Web page design: implications of memory, structure and scent for information retrieval // CHI ‘98 — dl.acm.org/doi/10.1145/274644.274649; G. A. Miller. The Magical Number Seven, Plus or Minus Two // Psychological Review, 1956 — psychclassics.yorku.ca/Miller.
• M. Hearst. Search User Interfaces, Cambridge University Press — searchuserinterfaces.com.
• Nielsen Norman Group: карточная сортировка, tree testing, крошки, гамбургер-меню, видимый и простой поиск.
• W3C WCAG 2.2: 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 2.4.6 Headings and Labels, 3.2.3 Consistent Navigation.
• T. Berners-Lee. Cool URIs don’t change — w3.org/Provider/Style/URI; Google: структура URL; sitemaps.org; M. Conway. How Do Committees Invent? — melconway.com.

Что дальше

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

Пользовательские сценарии и потоки: от задачи к экранам