```json
{
    "title": "Информационная архитектура: модели",
    "url": "https://sherer.pro/blog/informacionnaya-arhitektura-modeli/",
    "datePublished": "2026-10-24",
    "dateModified": "2026-10-24",
    "language": "ru-RU",
    "description": "Разбираем плоскую, иерархическую и сетевую организацию информации, фасеты и их сочетания. С примерами.",
    "author": "Павел Шерер",
    "publisher": "Павел Шерер"
}
```

# Информационная архитектура: модели

В предыдущих частях цикла мы довольно подробно прошлись по сущностям: выделяли их, описывали связи, разбирали свойства и [сводили всё это в таблицы](https://sherer.pro/blog/informacionnaya-arhitektura-sushchnosti-vol-3/). Теперь давайте посмотрим, как из этих описаний получается организация информации в продукте.

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

Вот с этим и будем разбираться. Магазин, товары и цены в примерах вымышленные; правила будем задавать по ходу объяснения.

## Для начала — немного о моделях

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

Допустим, вы отнесли куртку к категории и добавили в подборку. В модели появились две связи. Следующий вопрос: как показать их покупателю? Категорию можно использовать в меню каталога, подборку — вывести отдельным блоком. Но сами связи существуют независимо от того, какие кнопки и переходы вы нарисуете.

Это и есть различие между [информационной архитектурой и навигацией](https://www.nngroup.com/articles/ia-vs-navigation/), которое мы уже затрагивали на [примере композиторского архива](https://sherer.pro/blog/informacionnaya-arxitektura-primer-i-tipizaciya/#5-navigacionnaya-model). Видимая вложенность разделов ещё не описывает все зависимости в продукте.

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

## Плоская модель

Самый простой вариант — показать ассортимент одной коллекцией. Куртки, брюки и остальные вещи находятся на одном уровне. Ни один товар не является родительским для другого.

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

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

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

Заметьте: мы всё это время говорили об одной коллекции. У входящих в неё товаров могут быть и категории, и бренды, и связи с подборками. **Если вы вывели товары одной лентой, информационная модель всего магазина от этого плоской не стала.**

## Иерархическая модель

Теперь давайте добавим категории. «Куртки» и «Пальто» входят в «Верхнюю одежду», а она, в свою очередь, — в «Одежду». Получилось дерево, в котором у каждой категории, кроме корневой, один родитель.

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

Для этого не нужно отдельно прикреплять куртку к каждой категории выше по дереву. Достаточно связи с «Куртками» и правила: родительский раздел включает товары всех своих подкатегорий.

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

![Дерево категорий и принадлежность товара](https://sherer.pro/wp-admin/admin-post.php?action=sherer_diagram_file&post_id=2409&revision_id=6259&page_id=01-hierarchy&theme_id=92fbfe2b22d42cbfbd24da11260d477c2133a6504974bc9b2793ac5f99d8316c&renderer_id=d0d6b273635cc5af13557adca8f595f14031e41e3b12c660f4ded50771b1cb28&pipeline_id=b6365c25981860b383dd57da3e78210d2b194300e5b4809fff376826b552d49a&format=png)

Дерево категорий и принадлежность товара. Товар связан только с конечной категорией. «Верхняя одежда» показывает товары всех вложенных категорий.

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

И вот с этим уже можно работать. Можно разрешить товару несколько категорий. Или дать несколько родителей самой категории. В обоих случаях к объекту появятся дополнительные пути, [полииерархия](https://www.nngroup.com/articles/polyhierarchy/). При этом в нашей модели меняются разные связи: принадлежность товара к категории и отношения между самими категориями.

И ещё: наличие дерева не заставляет пользователя каждый раз начинать с «Одежды». Он может открыть «Куртки» по прямой ссылке или попасть в карточку из поиска. Подумайте, какой контекст нужен ему в этой точке и куда он сможет перейти дальше.

## Сетевая модель

Дерево категорий описывает только часть отношений в нашем магазине. Но наша куртка ещё входит в подборку «Осень в городе». В той же подборке есть брюки, которые редактор рекомендует носить с этой курткой.

Брюки по-прежнему относятся к своей категории. Подборка и рекомендация сочетания добавляют другие связи.

Посмотрим на небольшой фрагмент модели. Здесь P-17 — идентификатор куртки «Город», P-42 — идентификатор брюк.

![Связи за пределами дерева](https://sherer.pro/wp-admin/admin-post.php?action=sherer_diagram_file&post_id=2409&revision_id=6261&page_id=02-network&theme_id=92fbfe2b22d42cbfbd24da11260d477c2133a6504974bc9b2793ac5f99d8316c&renderer_id=d0d6b273635cc5af13557adca8f595f14031e41e3b12c660f4ded50771b1cb28&pipeline_id=b6365c25981860b383dd57da3e78210d2b194300e5b4809fff376826b552d49a&format=png)

Связи за пределами дерева. Общая подборка сама по себе не означает рекомендацию сочетания. Обратную рекомендацию редактор задаёт отдельно.

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

> Если вспоминать теорию графов, то дерево так-то тоже является графом, но сейчас нам важен только смысл этих дополнительных связей.

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

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

Так у вас появляется конкретное правило для наполнения карточки. И понятный вопрос к тем, кто её наполняет: какие сочетания они задают и в какую сторону. Формулировка «ну, покажем связанные товары» этих решений за вас не принимает.

## Фасеты

Теперь покупателю нужна чёрная хлопковая куртка не дороже 6 000 рублей. Раздел «Куртки» он уже нашёл, но внутри ещё нужно выбрать подходящую вещь.

Можно продолжить дерево: «Куртки → Чёрные → Хлопковые → До 6 000». А если человек сначала хочет выбрать материал? Или посмотреть все чёрные вещи независимо от категории? Вам придётся решать, как поддержать другие сочетания признаков и не потерять нужные товары.

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

Сам фасет, кстати, может быть плоским или иерархическим. В нашем магазине цвет можно выбирать из списка, а категорию — из уже знакомого дерева. Фасетная организация и иерархия вполне уживаются вместе. Подробнее об этом — в [Search User Interfaces Марти Херст](https://searchuserinterfaces.com/book/sui_ch8_navigation_and_search.html).

Возьмём четыре товара. Для простоты под материалом здесь будем понимать основной материал изделия.

| Товар | Категория | Цвет | Материал | Цена, ₽ |
| --- | --- | --- | --- | --- |
| P-17, «Город» | Куртки | Чёрный | Хлопок | 5900 |
| P-18, «Ветер» | Куртки | Синий | Полиэстер | 4900 |
| P-19, «Берег» | Куртки | Чёрный | Хлопок | 7900 |
| P-42, «Шаг» | Брюки | Чёрный | Хлопок | 3900 |

Выбираем куртки, чёрный цвет, хлопок и цену до 6 000 рублей. Остаётся куртка «Город». Брюки «Шаг» подходят по цвету, материалу и цене, но не по категории. Куртка «Берег» не проходит по цене.

![Как сочетаются фасеты](https://sherer.pro/wp-admin/admin-post.php?action=sherer_diagram_file&post_id=2409&revision_id=6263&page_id=03-facets&theme_id=92fbfe2b22d42cbfbd24da11260d477c2133a6504974bc9b2793ac5f99d8316c&renderer_id=d0d6b273635cc5af13557adca8f595f14031e41e3b12c660f4ded50771b1cb28&pipeline_id=b6365c25981860b383dd57da3e78210d2b194300e5b4809fff376826b552d49a&format=png)

Как сочетаются фасеты. При одинаковых данных и условиях порядок выбора фильтров не меняет результат.

Осталось определить правила отбора.

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

Отдельным вопросом остаются незаполненные свойства. Если материал неизвестен, показывать ли товар при выборе хлопка? В нашем примере не будем: мы не знаем, соответствует ли он условию. Без фильтра по материалу товар останется доступен.

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

## Собираем всё вместе

К этому моменту у нас есть несколько способов работать с одним ассортиментом. Давайте сведём их в таблицу и посмотрим, откуда берутся данные для каждого представления.

| Задача | Данные и отношения | Правило нашего примера | Представление |
| --- | --- | --- | --- |
| Найти куртку «Город» | Название и идентификатор | Для этого примера используем точное совпадение названия; результат ведёт к найденному товару | Поисковая выдача |
| Посмотреть верхнюю одежду | Дерево категорий и связи товаров с ними | Показываем товары всех вложенных категорий | Каталог категории |
| Выбрать по характеристикам | Категория, цвет, материал, цена | Между признаками действует «И», внутри выбранных цветов — «ИЛИ» | Отфильтрованная коллекция |
| Посмотреть «Осень в городе» | Связи товаров с подборкой | Показываем товары, которые включил редактор | Страница подборки |
| Подобрать сочетание к куртке | Направленная редакционная связь | Показываем товары, указанные для этой куртки | Блок в карточке |

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

Теперь изменим цену нашей куртки: было 5 900 рублей, стало 6 500. Для примера считаем, что у товара одна текущая цена.

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

![Изменение одной цены в разных представлениях](https://sherer.pro/wp-admin/admin-post.php?action=sherer_diagram_file&post_id=2409&revision_id=6265&page_id=04-price&theme_id=92fbfe2b22d42cbfbd24da11260d477c2133a6504974bc9b2793ac5f99d8316c&renderer_id=d0d6b273635cc5af13557adca8f595f14031e41e3b12c660f4ded50771b1cb28&pipeline_id=b6365c25981860b383dd57da3e78210d2b194300e5b4809fff376826b552d49a&format=png)

Один товар — несколько представлений. Цена меняет результат фильтра, но не связь с подборкой.

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

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

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

## Проверяем, что получилось

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

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

Дерево категорий можно проверить с помощью [tree testing](https://www.nngroup.com/articles/tree-testing/): человек просто ищет информацию в текстовой структуре. Но вот работа с фасетами и переходами между товарами уже потребует прототипа соответствующих взаимодействий (благо, теперь это делается быстро). По одному дереву вы не узнаете, понимает ли пользователь сочетание фильтров и может ли изменить условия.

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

А вот универсальное требование «всё должно находиться за три клика» здесь не поможет. [Исследование UIE](https://articles.centercentre.com/three_click_rule/) не подтвердило предположение, что после третьего перехода люди прекращают поиск. Это не повод добавлять лишние действия, просто число переходов нужно рассматривать в контексте конкретной задачи и её результата.

## А если что-то изменится?

Допустим, в магазине появилась подборка «Выходные за городом». Мы уже предусмотрели сущность «Подборка» и её связи с товарами. Создаём ещё одну подборку, добавляем туда существующие вещи. Их категории остаются прежними, копии товаров для нового раздела не нужны.

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

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

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

![Новая подборка и новое правило связи](https://sherer.pro/wp-admin/admin-post.php?action=sherer_diagram_file&post_id=2409&revision_id=6267&page_id=05-change&theme_id=92fbfe2b22d42cbfbd24da11260d477c2133a6504974bc9b2793ac5f99d8316c&renderer_id=d0d6b273635cc5af13557adca8f595f14031e41e3b12c660f4ded50771b1cb28&pipeline_id=b6365c25981860b383dd57da3e78210d2b194300e5b4809fff376826b552d49a&format=png)

Новая подборка и новое правило связи. Слева: категория прежняя; добавлены подборка и связь с товаром. Справа: у общего родителя товар показывается один раз; для хлебных крошек нужно выбрать путь.

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

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

Когда вы проектируете собственный продукт, начните с задачи человека, определите нужные ей свойства и связи, затем решите, как их показать. Так описания сущностей, которыми мы занимались в предыдущих частях, становятся основой конкретных решений.